The catch-22 of software management is that the ones who want it most are usually the worst at it ...First, kill all the managers, eh, Steve?
Software companies that prize managers above engineers are guided by their own Invisible Hand to become a henhouse of clucky managers pecking viciously at harried engineers. Sadly, most software companies fall into this trap, because they're borrowing traditional ideas about management from non-tech industries ...
I don't think anyone's figured out how to make a no-management structure work for an org with hundreds or thousands of engineers. I do know one great company that's come really close ...
Unfortunately I have neither time, nor space, nor in all likelihood permission to explain their recipe for success with almost no management. You'll just have to take my word for it: if you take all the managers away, great engineers will still build great things. Maybe even faster.
If you have seen the harm middle managers can create, it is hard not to be sympathetic with this view. I do think Steve is right that a software engineering company can do very well with almost no management.
Mentoring and program management are probably better off being independent of technical management. Forming a unified vision for an organization, an important part of leading a group, does not require layers and layers of middle management.
Steve may not be willing to talk about Google's recipe for success, but, to the limited extent that I know it, I can.
Google has almost no management. In 2003, managers were at the director level or higher and had 50 or so reports. More managers have been added since then, but I believe that 20+ reports is the norm.
Program management is done in a separate organization. The PMs have no power over the engineers, not even an appeal to engineering managers, since there are none. The PMs try to bring order to the chaos, but they must do so by convincing people, not by commanding them.
Mentoring is done by other engineers. People learn by doing. You want people to dive into the code and learn from those who are closest to the problem.
Parts of the vision emerge from everywhere, brought together, clarified, and unified by the few managers that exist. Despite a few people wandering up other peaks, most are guided up the same hill.
Communication is direct through informal networks, not through the management hierarchy. Transparency and pressure from peers provide for accountability and limit free riding.
Titles are unimportant. A "software engineer" could be a former tenured professor or a recent college graduate. A "program manager" could be a former CTO.
To imitate Google, it is important to realize that there is more to do here than just suddenly sending your middle managers out to sleep with the fishes.
Tasks often done by managers need to be moved out of a management hierarchy. Informal networks and a culture of transparency need to be encouraged. Hierarchies must be destroyed, titles made irrelevant, and compensation and rewards redesigned.
If you can do all those things, then let's bring out the cement shoes.
13 comments:
The answer is easy, it's the same as writing and designing. The guy who do can both is much better as the 2 guys who argue over it. The manager of the future is going to do actual work. Single skills just don't hack it today.
Break out the champagne. Web 2.0 companies are nothing like the companies of the past. Fundamentals don't matter! Stock prices through the roof! C'mon, this is almost all speculation and hype. Haven't we just been through an experience that should teach us that fundamentals matter? That sustaining a large corporation's momentum is a world apart from building a startup from scratch? That anyone who tells you "first kill the managers" is selling the latest snake oil?
Management is simply a different skill than software engineering. Sometimes it's used well, sometimes not. I regularly see engineers on slashdot insulting their managers, with little to no idea of what management is doing besides "standing in the way". They've got no concept of department budgets, space management, resource allocation decisions, filtering information from outside clients or upper management.
There are also good managers and bad managers, just like there are good and bad engineers. The good managers I've worked with have been worth their weight in gold. The bad managers have been worse than having my teeth pulled without novacaine.
More importantly, despite their own internal claims, most companies are successful not for the reasons they state, but because of a combination of factors, including competitor's mistakes, macroeconomic factors and sales/business development success.
Take Microsoft, whose real success was in crafting monopolistic deals with PC manufacturers. Nearly all of their profits (OS and Office) stem from that aspect of their success, along with a couple major missteps from competitors (OS/2, Word Perfect). Everything else they do (MSN anyone?) is basically failed R&D.
The IT industry is littered with the wrecks of countless innovative, engineering-driven companies. And there are plenty of overly heirarchical companies that have incredible track records delivering high-quality, on-time products.
Let's see, in 10 or 15 years, what google turns into, and then maybe we'll listen to them about their management structure. I think the jury's still out.
Good comments, Anonymous.
I didn't mean to come across as promoting Google's strategy, though it certainly is unusual and is worth analyzing and discussing.
A lot of the secret seems to be moving tasks -- for example, the department budgets, space management, resource allocation decisions, filtering information tasks you mentioned -- to people outside of the management hierarchy. The tasks don't disappear, but the people doing the tasks have less power than the norm.
Frankly, I would have expected it to break down years ago, and I said so years ago. I am surprised and impressed by how long it seems to have lasted and how well it seems to be going.
Oh, the break down will come, and then everyone will become overly pessimistic about google's future and everything they did to get to that point (see Microsoft now, for example). No one then will be any more accurate about google's "failings" than they are now about google's "success". It's just not as black and white as people who write "the manager of the future is going to do actual work" (by that they mean engineering).
I think externalities, luck & timing have a lot more to do with a company's success than most people are willing to admit. Jim Cramer (Mad Money) responded to a question about how much of his success in picking stocks was luck vs. skill and he said "50/50. Anyone who tells you they're success is all skill is lying". Perhaps he was being generous to himself, but if you asked me how much of a company's success was due to genuine innovation in internal factors vs. right place/right time, I'd probably say what Jim did.
All that said, I think it would be neat if google survived into the future and became a huge force in our economy. I'm all for companies that can create jobs, add to economic growth, innovate, etc. But if it does succeed, I wouldn't attribute more than 50% of google's success to "skill".
Even places like amazon and Microsoft seem to have limited "skill" in leveraging any early success.
As a professional IT project manager who has been a developer and who has delivered IT projects on time and on budget with happy customers let me just say that there is no evidence that letting developers run projects leads to success. In fact it's likely to lead to disaster.
For instance developers are usually terrible at estimating. It usually takes developers at least twice as long to complete their own tasks as they think it will. And when estimating they usually forget about all the things that other people have to do such as analysis, architecture, testing and implementation.
Developers usually do not produce good quality products. The first time pass rate on code vs. test cases is typically only 40% to 60%.
Developers are often bad at planning and prioritizing their tasks. They don’t understand which tasks are on the critical path and often leave the tasks that have the most impact on the schedule until later.
Developers are often bad at co-ordinating their activities with other people. They do things like deleting data from the test environment without consulting the test team or implementing code without discussing it with the DBA's and system administrators first.
Developers, especially younger ones, often don’t take responsibility for their actions and blame other people for their mistakes. When problems with estimates, co-ordination and quality are discussed with them developers often deny responsibility, sulk and start a campaign of personal attacks to undermine the critic.
Developers are often bad at communicating with stakeholders. They often agree with everything they are asked for leading to major scope creep or argue with stakeholders and imply that they are idiots for asking for the things they do.
I worked in a very ideological web company like Google that had 360 degree assessment and PM’s with no power over the engineers. PM’s had try to bring order to the chaos, by convincing people, not by commanding them.
The developers liked it but the executives, product managers and operations people were very frustrated with the IT department. IT projects nearly always took twice as long and cost three times as much as promised with deadlines and budgets that just kept slipping further every week.
In this structure PM’s were responsible for bringing projects in on time and budget but had little control over the means to do so. On the other hand developers and engineering managers had all the power but didn't have to accept responsibility when things went wrong.
There were some very negative side effects of this approach. Developers were forced to work weekends and evenings to meet unrealistic deadlines; product and IT fought constantly; developers lied about problems and did not take responsibility for them; none of the underlying issues of poor planning were addressed; large number of topics were taboo and a culture of vindictiveness.
It was a lot like “Lord of the flies”. The only project manager that lasted was a guy who was very Machiavellian and didn’t really care if projects went well or not.
I have deliberately used “often” and “usually” here. Occasionally I come across developers who are good at estimating, produce high quality code, co-ordinate their activities with others, take responsibility for their actions and communicate well with others. However these people are rare.
I agree with Brian that “there are also good managers and bad managers, just like there are good and bad engineers. The good managers I've worked with have been worth their weight in gold.”
Good points, Murray.
Another part of the equation may be Google's incredibly high hiring bar and habit of calling even very senior people "software engineers".
Their developers are unusually smart and talented, and many of them have managed large teams and large projects in the past (as Steve Yegge did). A formal hierarchy may be unnecessary if you have this kind of talent everywhere.
On a meta point, please don't get too offended by the sensationalistic title on this post. If we were to take the title on this post seriously, with my management background and MBA, I'm sure I'd be one of the first against the wall.
However, I do think what Google seems to be doing is quite interesting, not just from a technical point of view, but also from a management point of view.
It is worth analyzing. It is worth figuring out whether this organizational structure works, whether it can continue to work, and whether it can be duplicated.
when looking at copying another companies approach in some area we need to ask ourselves the following questions.
What is the evidence that Googles success is because of this practice?
Why is this practice causing better performance?
What are the downsides of implementing this practice and how can they be reduced?
To quote from "Evidence Based Management" which I highly recommend.
"Southwest airlines is the most successful airline in the history of that industry. Herb Kelleher served as CEO during most of Southwest's history and remains the chairman to this day. Kelleher drinks a lot of Wild Turkey bourbon. So does this mean that if your CEO starts drinking as much Wild Turkey as Kelleher, your company will dominate it's industry?"
The reference is "Hard facts. Dangerous half-truths and total nonsense. Profiting from evidence based management" by Pfeffer and Sutton
Murray - Thanks for those references (this is anonymous, who you quoted). I think the whole "don't start drinking bourbon" is really my central argument. The evidence from other books, like "Built to Last", is that management policy specifics usually have little to do with long-term success. And, btw, I agree with you about PMs and managers needing some sort of power.
Although I would argue that Greg does make a good point, at least in theory, about google's hiring practices. Most companies focus on short-term needs when hiring, and often are willing to "lower the bar" (not just on experience, but actual talent) when pressed for time. It's pretty hard to overcome bad hires, especially a lot of them. On the flip-side it's pretty easy to mask any organizational problems if everyone is really talented and committed.
We can also see hiring practices "go awry" when you have places like Microsoft that so believe their own hype that their hiring practices ensure they can only hire people that fit into what has become a dysfunctional culture.
I also wonder what will happen to google's celebrated hiring practices and employee satisfaction when everyone's stock is under water for a couple of years, or there are a couple of large RIFs due to declining profits. I think that's a truer test of a company than when everything is going great.
That's a great point, Anonymous. I too am interested to see how resilient Google's culture is when they face their first real crisis.
I couldn't code to save my life, so to say that one should say "bye bye" to the managers does cause me some concern. My experience with the engineers is that they can be a smart, passionate and a daring breed, so maybe we should hand-over the farm. Then again, how come whenever this debate comes up only one company is ever mentioned? And remember, only one of that company's products actually makes money (albeit a hell of a lot!!!). And when the rest of the world catches up to that product (which will happen) we'll see which of the enginers puts their hand up to say "bye bye" to a few colleagues... Sorry folks, but the world ain't that simple. Go play "The Sims" if you want a world ruled by the engineers.
As I'm an Aussie, I thought I'd check out Google's current employment requirments to see the engineer / non-enginner ratio and here it is:
• Engineering (7 roles)
• Operations and IT (3 roles)
• Partner Solutions Organization (5 roles)
• Product Management (1 role)
• Sales (5 roles)
• Online Operations (2 roles)
• Marketing (1 role)
• Facilities (2 roles)
• Human Resources (1 role)
Looks like even Google understands that it just can't sit around and code all day long.
Google can get away with it because:
1) they are a r&d/product shop with no delivery date pressure,
2) they are flush with cash.
This does not represent the state of most IT shops in corporate America for whom these are the two largest constraints under which they must operate.
I love the hubris of these statements like "kill all the managers." Right away, it sets up a conflict between managers, who are described as overhead and "knowledge workers," who are described as the real value producers for the organization.
The reality is that developers tend to be concerned with building things "right," without regard to schedule and budget constraints. The domain model or the technology becomes the most important thing, and they lose sight of the business problem they are trying to solve.
To my mind, the result is that managers are definately needed for development organizations that are subject to those two constraints.
Post a Comment