30 Things I've Done at Startups(bufr.tumblr.com)
bufr.tumblr.com
30 Things I've Done at Startups
http://bufr.tumblr.com/post/9256293725/30-things-at-startups
8 comments
IME, most companies are not enthused at this prospect because it's a lot harder for them to watch you. For some reason, they think physically seeing you and talking to you is the best indicator of how much work you're doing.
It's not, and it hurts them.
To answer your question, though, ask during interviews. It's the only way to find out, unless they put it in the job description.
It's not, and it hurts them.
To answer your question, though, ask during interviews. It's the only way to find out, unless they put it in the job description.
I disagree, at least in the startup case. In my experience, unless you know the person very well and they have demonstrated that they can deliver what they need to, you're only adding extra headache for yourself. If someone's work is drifting away from what you intend, it's a lot easier to spot that over their shoulder and change courses on the spot rather than wait for code to land in your repo and find out after a lot of time and effort has been wasted.
Well that's my point, actually. There should be no 'wait for code to land in your repo'. There should be some peer review before then. There should be daily discussion on progress and problems.
Coders shouldn't be a black box that you hope to get the right answer out of. They should be talked to, but talked to as adults. You don't need to pressure them, you just need to ask for progress (not deadlines!) and help them resolve any issues they have.
Any programmers that have been beaten down in traditional shops will try to avoid the above because they'll think you're pressuring them slyly, instead of openly. You have to be absolutely open and honest and ethical about everything to overcome that.
Coders shouldn't be a black box that you hope to get the right answer out of. They should be talked to, but talked to as adults. You don't need to pressure them, you just need to ask for progress (not deadlines!) and help them resolve any issues they have.
Any programmers that have been beaten down in traditional shops will try to avoid the above because they'll think you're pressuring them slyly, instead of openly. You have to be absolutely open and honest and ethical about everything to overcome that.
Maybe they are expecting something more than a worker who can keep in sync with others? If the very small team is the whole company, they may be expecting someone they can brainstorm with at random times without having to get you on Skype. Why would they want to take an extra step to keep you in sync when the rest of the in-office team already is?
Being the only person who's remote can suck, yes, and keeping one or two people in sync with an otherwise co-located team can also be a challenge (and not necessarily worthwhile for an early-stage company).
I was more wondering why more founders don't see the value in building companies where the whole team is not necessarily distributed all the time, but has the flexibility to WFH or work from the road whenever they feel like it.
I was more wondering why more founders don't see the value in building companies where the whole team is not necessarily distributed all the time, but has the flexibility to WFH or work from the road whenever they feel like it.
This guy is so full of himself he's a Klein Bottle.
Flagged for stupidity.
Flagged for stupidity.
It is titled '30 things I've done at startups.' Naturally, one might think the entire list to be about oneself.
Where can I get me some of this? Most very small teams seem to want co-location and fairly regular office attendance. I find I am a pretty effective remote worker and am quite good at staying in sync with a distributed team, but for some reason founders of mid-early-stage startups seem less enthused by that idea.