I've never been very successful communicating to my customers and bosses the difference between a "super programmer" and a "mortal programmer". It's a critical distinction that eventually must be understood by organizations that build software. So instead of trying to explain, I just email them this link:<p><a href="http://www.joelonsoftware.com/articles/HighNotes.html" rel="nofollow">http://www.joelonsoftware.com/articles/HighNotes.html</a><p>Then they finally get it.<p>Now I have another link to help them understand why their management style isn't working they way they think it should. Thank you, Joel.<p>A few more Joel links like these two in my back pocket and I won't have to spend so much time explaining much of anything anymore. I can just go back to building stuff.
I agree with this post, but it is <i>very</i> light on details. "Don't be a douche. Let your employees think." thanks for the tip...<p>So, to that end, my management tips:<p>1. Make sure people are working on the right things. This is most important and where Joel's academia argument breaks down. The problem is that everybody in the company doesn't have a transparent view of everything in the company (past ~10 people).<p>To do this, you ask questions and provide information. "Why is this the most important thing?" "What about <some thing they may not know>?" Etc. ideally, you are proactively providing that information, but if your employees are always waiting for you to provide information, you are the bottleneck.<p>2. Cultivate communication. Make sure the rit people are talking to each other. Make sure the environment is sipuch that people not only want to, but are incentivized to talk to each other.<p>3. Be open about when you learn something new. Few people don't enjoy teaching the boss something new. Give people that opportunity.<p>4. (EDIT: Forgot one of the most important) Conflict resolution. At some point, two very smart people are going to disagree. Your job isn't to pick a winner (usually), but to make sure resolution happens.<p>I'm sure there are others (feel free to tell me!). FWIW, I don't think I'm being original here. For details on how to do many of these things, Joel's blog is not a bad place to start (though I really don't like the lunch thing at Fog Creek ;).
<i>I’ll bet more entrepreneurs model their behavior on Captain Picard from Star Trek than any nonfiction human. [..] Turns out, it’s positively de-motivating to work for a company where your job is just to shut up and take orders.</i><p>I like the post, but.. at the risk of sounding like I've thought about this for too long, <i>Picard's</i> management style wasn't of the tough "command and control" style described here.<p>Picard's crew had a significant amount of autonomy and a reasonable scope to question their direct superiors (although going too far up the chain usually seemed to backfire). The buck always stopped with the Captain and he set the crew's overall mission, aims and goals (with significant input and advice from his crew) but in terms of the day to day running of the ship (and even many of the crisis situations) he was not at the center of most decisions and relied heavily on his crew to do the right thing.<p>All this makes me realize that as much as being a sci-fi show, TNG was particularly good at demonstrating management styles and crew relationships (with many episodes dedicated entirely to these matters or contrasting them with those of other crews and civilizations).
"Command and Control probably worked great in the toothpaste factory where Charlie Bucket’s father screwed the little caps on tubes."<p>I thought that it is totally obvious that the more intellectual and complex the task is, the less the hierarchical 'command and control' approach works. I think this is told in the first one hour in any course about management.<p>I once stated it here but state it again: the older I grow the less useful I find the posts of the great bloggers (Joel, pg, etc...). Their posts are usually good feel-good posts for us developers, but in their posts they overabstract and oversimplify everything (overabstraction can be also called 'architecture astronautism'), when what really matters are pretty much in the details (or at least cannot be communicated in such simple blog posts), and depend on hundreds of parameters, and I am sure they bacame successful because they have been taking care of the details in their everyday actions.
The Tina Fey autobiography / jokebook had an interesting comment - one of her mentors explained that the role of a (TV) Producer was to reign in / prevent creativity. The idea was you had hired amazingly creative people, and if you did not provide necessary constraints the whole would be way less than the parts. (the example was asking the props dept for a teacup. No not on a silver platter the reflection will kill the camera, no not with sugar tongs these are simple countryfolk etc etc)<p>Steve Jobs is just an extreme example of this role - provide a common vision, explain the constraints and edit edit edit the great ideas coming at you. (nb editing is not the same as directing, something I tend to forget I my code reviews - an editor should accept a brilliant idea and change the other work to fit it in, a director, directs...)
I use the following model:<p><pre><code> CEO is defining desirable outcomes, defines WHAT TO ACHIEVE
Team members are defining HOW TO ACHIEVE
</code></pre>
CEO is a resource to the team, providing knowledge, connections and keeping project documentation up to date
Someone send this to Page.<p>I've said it before and I'll say it again, leaders need to make a culture and create a managament style THEIR way. Whatever works for them and their company, not attempt a copy/paste of another CEO.<p>Engineers can't adopt a designers management style overnight because they don't have the background to attain the respect their decisions will require.<p>Just like coders hate an MBA telling them to build the next facebook in 3 hours because it's "just a few pages and they all look the same anyway, how hard can it be?".
What I'd like to understand is why is management professional training so oriented towards 'leadership' if you believe that facilitators and administrators are required.<p>Working for a large multinational tech firm, I recently saw them launch online training across all the various disciplines. Much of the management material is about leadership, whereas non-managers are considered 'individual contributors'. Doesn't this seem to run entirely counter to the philosophy espoused here?
Excellent post on the outline of his management style, but far too short on details. How does this management style deal with inevitable conflicts between engineers? How does this style deal with pivots? Who makes hiring decisions for managers in this layout?<p>I <i>imagine</i> that this could work, but this would seem to scale even worse than the traditional model; four thousand engineers, all of them "bosses", does not a productive company make.
The style of management he recommends works well for companies in the size scale of 30-100 people. I believe it breaks down after that, and, ironically, as you grow to a few hundred and into the thousands, you actually have to shift back to more of a command/control structure or you risk evolving into a bureaucratic entitlement kind of organization. You still need to know how to trust and delegate, but you (and by extension your now necessary mid-level managers) also need to be able to shut down the endless bike-shedding (which has now morphed into full-on ego flame wars) and make executive decisions to prune the tree of possibility and keep things moving along productively.<p>I think Google is a good example of a company that is (later than most) realizing the academic model only scales up to a certain point. They now seem to be moving towards a much more traditional Cpt Picard/Steve Jobs-run type of organization, from what I've gleaned.
Great post. I'm going to show this to management because this is exactly the idea that they advocate yet they keep hearing they should be more like Steve Jobs. Not many people would want to work for a pseudo-Jobs. Problem is, there seems to be a plethora of them out in the wilds of big corporate America.
I think the university analogy is distracting from the real point. He's advocating a form of servant leadership, which is where the CEO/President/etc is perceived more like a steward than an autocrat.<p>If you've ever worked for someone who had a broad array of responsibility, was universally respected, displays humility, and available to help resolve problems, that's what Joel is talking about. A great professor tends to adopt this role -- which is probably where the university analogy came from.<p>The "catch" to this style is that you actually need to be respected, empathetic and humble. (Know-it-alls need not apply.) That usually comes with lots of experience.
In my views, it's mostly about balance rather than picking between divergent choices. Who says one can't be a firm leader also capable of soliciting and respecting the opinions of others?<p>The NY Giants won the SuperBowl as you note, with a famously dictatorial top-down coach [Tom Coughlin]; the NY Jets didn't even make the playoffs with a very horizontal come-as-you-are coach [Rex Ryan].<p>Interestingly, Coughlin didn't win any SuperBowls - he now has two - until he learned to loosen up. And by all appearances, the NY Jets won't win one until Ryan learn to tighten up.<p>Apologies for all the football references:) But I suspect Mr. Spolsky would understand very well.
I wonder why the CTO sits above the VP Engineering in Joel's picture? Is this generic, or specific to Jeff as the SE CTO, perhaps because he wanted to code, rather than manage?
Did not like this post. Like many others over here, I also have read all the great posts by him over the years, on joelonsoftware. But, honestly, this one just does not cut it for me.<p>He is over simplifying everything. And his extreme view ends demoting the "top" of an Organization's chart. Heck I won't want to start a company to just <i>move furniture around</i>.<p>And you can not have a binary classification for a CEO - Steve Jobs or not. In reality there will be lot of people who are perhaps very skillful, experienced and work very hard at the top. So their skill level might be closer to <i>Steve Jobs</i> than your average Joe. So you have to treat it like a spectra.<p>He makes a very fair comparison of developers and similar in a software company with that of a toothpaste company. But his fairness goes for a toss, when he compares the people at the "top". IMO just <i>administrators</i> should have no place being in a software product company in the first place.<p>He makes a good point, that its best for the organization that if all the brains are used rather than just one brain. But he goes to the other extreme to make this one point.<p><i>Experience</i> does have a role after all. A fresh bright programmer might want to code everything up in the latest shiniest thing, if you _know_ that its a wrong decision. Then is it not your duty to explain him and convince him.<p>In such a situation, who has the luxury of acting like a university Chair, and setup a committee to take the right decision? :-)<p>So the comparison with university is wrong. I see another comment in this thread referring to 'architecture astronaut' in the context of this post. IMO, this is more of 'architecture polish' ... just skims the surface :-)
What's needed isn't more or better management and communication.<p>But to design a system whose secret lies in what’s unstated or not communicated to one another (in an explicit sense)—in order to exploit lower‐level initiative yet realize higher‐level intent, thereby diminish friction.<p>If this is the state of the art in tech companies, I'm very blessed to have a real durable competitive advantage.
It's always going to be a pyramid.
But you have to value and trust those whose daily decisions have the biggest impact on the customer's experience.
Whether that's in product design, tech support, customer service or sales.
It's de-motivating when you're working for managers who don't understand what that means.
Joel is right but he's a bit harsh on Steve Jobs.
I'm sure Steve Jobs was a pain in the *ss to work for but Steve did value designers more than any other company and he did value the people at the Genius bar more than any other retail company ever did. And I think that's exactly what Joel's article is about.
Didn't everybody already know this? I'm not particularly in Silicon Valley, but I really thought most startups work the way Joel describes, instead of with the fake Steve Jobses. Was my idea of the world too good to be true?
I don't agree with the hole post, but the "administration layer" paradigm Joel has been proposing is kind of interesiting. In a way, it's the extreme opposite of the norm, and that's good, it challenges the way people normally think about "managment". It's humanistic by design. The problem is that, as not everybody is Jobs, not everybody is Spolsky.<p>This shouldn't be read as a sctrict methodology or recipe to copy. In programming, as Joel wrote, there are cheffs and there are McDonal's "burger flippers". That analogy also applies to managment.
> Seductively, it even works OK for a three person company.<p><i>Anyone</i> who thinks command and control is a good idea with 2 other people has got bigger fish to fry than finer points of effective management.
Based on this, one would think that the "support/administrative/service corps" would receive much less compensation than the "talented individuals" who do all the real work. A lot of organizations preach or follow this philosophy, but I have yet to find one that puts its money where its mouth is and distributes compensation accordingly.
<i>The saddest thing about the Steve Jobs hagiography is all the young “incubator twerps” strutting around Mountain View deliberately cultivating their worst personality traits because they imagine that’s what made Steve Jobs a design genius. Cum hoc ergo propter hoc, young twerp.</i><p>I loved the swipe at the fake Steve Jobs's out there. I worked for one, although he wasn't young and it wasn't in Mountain View. He would cite Steve Jobs to defend defective practices. It was ridiculous.<p>It's a great essay, and I like Spolsky's management philosophy a lot, but I don't entirely agree. A business isn't academia. Businesses have to ship products and please their customers, and leaving these tasks to "the crowd" doesn't work. "The crowd", when we're talking about software engineers, produces brilliant chaos. That's great sometimes, and it can produce excellent products, but it's not good when you need focus or to meet a ship date. Sometimes a CEO or CTO needs to decide what gets worked on, how people do it, and to motivate people to make sure it happens.<p>Likewise, sometimes a leader needs to step in and resolve bike-shedding conflicts among two equally smart, strongly opinionated engineers who disagree on a core question, and to look for a compromise. "Management fiat" shouldn't be used lightly, but it's not without purpose.<p>That said, I think Spolsky deserves a lot of props for pointing out that the managerial relationship is two-sided. A lot of companies and bosses don't figure this out until they face uncontrollable talent bleed, and even then there's a lot of self-deception (I've known some ineffective managers to become bitter about their best reports "abandoning" them, as if it were some ethical lapse, but never to own up to their role).