I don't see how taking 2 days and leadership time demonstrates concern for employees. Getting someone in who can take care of the problem quickly and efficiently* seems like it's better 'staying out of the programmer's way' than taking two days.
I think the lesson from the toilet cleaning was, "Look, if I'm going to require perfect inspections, I'm sure as hell going to have an immaculate bathroom. I also recognize that I need to show you how to perform to the level I expect. So here's how it's done."
That hands-on, know-what-you're-doing leadership is what's respectable. Making an object lesson, on the other hand, is hardly laudable.
*This falls into the "why I hesitate": if Joel could do it faster and more cheaply than having someone else come in that knows what they're doing, my criticism is less harsh, though I still think he's taking the 'wrong' lesson from his military experience.
Personally, I think Joel has shared some good lessons and insights. However I also think he ran out of really good material about 2 years ago, yet various outlets "demand" more from him.
This tends to happen a lot with almost any person who tries to blog/write too much on any sub-topic. At some point you've exhausted all of your unique datapoints and end up resorting to trying to spin the obvious into new and interesting stories. This is why, among other reasons, I like PG's almost-monthly essay installment schedule. I never feel like he is straining to product content.
I think you're missing the real point of these exercises. A good hacker, and anybody else for that matter, performs best when he is secure in the knowledge that he is being trusted and supported by peers and management. putting up drapes is a subtle way of showing thet the CEO will do anything to make you comfortable and make sure you can get work done.
It's not about the most efficient way of cleaning toilets or putting up drapes, it's about psychology.
My point is that most good hackers I know see through things fairly easily, and it undermines the message of "you're supported" when that support is not functioning in the best way possible. For instance, why does it take "days" to realize the sun is shining through the window and then two more to have someone who's not that great at putting up blinds put them up? Get someone in, fix the problem, get them out, bing-bang-boom, and you have a happy hacker, given most hackers I know. Take 5 days for something that should take 2 at the most (1 day to see the sun issue, 1 more to put up blinds) doesn't make people "secure in the knowledge that he is being...supported."
Hackers laugh, cry, have girlfriends (or boyfriends) just like everyone else. And they are suspectible to the same psychology as everyone else. They just often don't realise it because they think the world revolves around logic.
I've managed hackers in different startups, and my experience is that they aren't that different from anyone else in this respect. The primary difference is that they think these rules don't apply to them, which of course makes it much easier to apply them.
I'm not saying they don't have emotions, but nice try. Nor am I saying there's no such thing as hacker psychology. I have no idea what you mean when you say something like "same psychology as everyone else", My point is that the psychological boost support provides still needs to be actual support.
Yes I think the real lesson is "servant leadership" - what Joel (and Michael) did wasn't just a hollow corporate gesture (as it would appear if this was done in faceless BigCo as a matter of policy). But Joel is often like that, taking on the dirty tasks, building a installer for an app (cause it was grubby work that no one else could do, and he had some time) - I think its this consistent "servant leadership" that adds weight to it. And I massively respect that.
* When you do something humble - is it still humble when you waste a few more hours writing about it and showing it off to the world?
* When you do something humble and it's rather unnecessary waste of time and effort - is it positively humble or genuinely pointless?
* When you want to send the frugality message to the team - do you first spend a few Ks on the blinds, then tear them down and then ruin the ceiling trying to undo what you did previously? Is that the "I'll do anything for your comfort" message?
There are million other ways to show support and make your people feel good. Pointless and unnecessary stuff is not among those ways.
The prim sergeant cleaning the toilet story is getting old, but the rest of the article after that was actually pretty good. Persistence, reluctant readers!
The only part that bugs me is: what kind of leader does something like this and then writes about it to brag?
I think Joel's actions, by themselves demonstrate humility and the quality of being down to earth. But the article...I think it would it would have come off a lot better if someone else wrote it about Joel.
Speaking as one of the developers who watched Joel put up the blinds, I know that this one shared instance of "servant leadership" falls in line with plenty of others that go unmentioned.
Just off the top of my head, I remember one Fog Creek get-together when one of my guests (Joel barely knew her) mentioned to me that she was thirsty, and before I could do anything about it Joel rushed off to get her a glass of water. While not a huge deal, fetching water for his developers' guests is not something that Joel really has to do.
...and even if I were to assume the basest of motives (that Joel wants to keep his developers working at Fog Creek so they make him lots of money), it's still a compliment as a developer and the type of attitude that makes me enjoy working hard.
I don't think he's claiming to be a humble person, just humble about his role within his own company. It's not necessarily a contradiction for him to claim that he's really good at being a humble boss.
If you truly believe you're awesome, I'm not sure it's beneficial to sit around and wait for someone else to recognize it. People won't ask you to contribute to the conversation; they'll assume that if you have anything to say, you'll speak up.
I'm not sure Joel wrote about this to brag; at the very least, he wrote about this because it made for an interesting / relevant entry for his monthly Inc.com article.
I agree that it might come off a bit as preening, but to be fair Joel's column hasn't stayed away from mistakes and bad decisions he's made as well. As such I take the tone as being closer to "this is what I've done and why I've done it" than "look at this awesome thing I did".
No, that would be a successful startups. Most startups I've seen have the CEO sitting on a pedestal (e.g. Steve Case), with the developers at the very bottom of the totem pole.
He and his execs did not get out of the way and let us do our jobs, they actually did the opposite and made it harder to do our jobs, mainly because we had so much trouble figuring out what it was that they wanted us to build for them.
And naturally they expected us to make up the difference from their dawdling and indecision and ship on time, even though they ended up delaying almost all of our projects by around six months.
I'm all for leadership by example. I think that Joel led by example when he was still actively developing code.
Hanging blinds? Not so much. Hanging blinds strikes me more as an entertaining diversion from normal work than as a way to show leadership.
I enjoy Joel's writing and think he sounds like a good guy. I'd be curious to see what he did if some of his employees left Fog Creek to start a company. The reaction would be a good measure of leadership.
I think the right way to handle that crisis would be to support them in their decision, but make sure they aren't directly competing with Fog Creek. Maintain contact, and make a gentleman's agreement that they won't poach people from Fog Creek. Keeping things friendly would be far more beneficial in the long run.
A lot depends on how many people would be leaving, too. If it's 2 or 3 people, it's not a huge deal, but if it's half the company, and if they are going to be making bug-tracking software, I think they might have to try to take a harder line.
I think the article is right on the money. We've been inundated the past few months with articles about a__hat CEO's in the financial services industry who were absolutely clueless, allowed their people to take financial risks that have brought their companies to their knees, while taking tens of millions of dollars in bonuses.
Meanwhile, Joel says that sometimes as a CEO, it's helpful if you put up the blinds and not just say that you care about your employees. CEO's get stuff out of their way so their people can do the work.
Hell, a CEO just using the term, "servant leadership" to describe their philosophy of management is a pretty idea these days, considering what the financial sector is going through.
I don't see how taking 2 days and leadership time demonstrates concern for employees. Getting someone in who can take care of the problem quickly and efficiently* seems like it's better 'staying out of the programmer's way' than taking two days.
I think the lesson from the toilet cleaning was, "Look, if I'm going to require perfect inspections, I'm sure as hell going to have an immaculate bathroom. I also recognize that I need to show you how to perform to the level I expect. So here's how it's done."
That hands-on, know-what-you're-doing leadership is what's respectable. Making an object lesson, on the other hand, is hardly laudable.
*This falls into the "why I hesitate": if Joel could do it faster and more cheaply than having someone else come in that knows what they're doing, my criticism is less harsh, though I still think he's taking the 'wrong' lesson from his military experience.