Dual Tracks and Innovation

3

A recent thread on an email list I subscribe to started with the question of why there are so many roles for technically oriented people at Google (engineer, lead, manager, product manager, production assistant, etc.) and then moved to the question of how decisions can be made in such an environment. All of this was around the more general topic of how to encourage innovation. I was asked to comment as someone who had some experience in the tech industry. But this is a hard problem, needing more space than a good email. It is also a topic that might be of interest to more than the subscribers of that list. So I decided to move the discussion over here.

Let me start by saying that, in my experience, the worst (and least innovative) technical organizations are those in which there is a single career path that starts with individual contributor and moves to various levels of manager. This might work for some functions (although I can’t think of an example right off hand), but is very bad for engineering. The only real advantage that this sort of organization has is that it is clear who gets to make decisions. The higher up on the organizational tree one is, the more authority one has. It is efficient, lines of authority are clear, and if you are trying to do something technically innovative you are doomed.

This kind of organization has the well-known drawback of making bad managers out of good engineers, but it also means that many of the most important decisions that are technical in nature are made by people who are spending their time on management. Having spent time as both a technical contributor and a manager, let me assure you that it isn’t just the skill sets that are different. The main difference is the way you spend your time in the different roles.

Engineers (and, by that term, I mean anyone who is building something, whether it is a web site, a new OS, or a service) need blocks of time to think about what they are doing. There is a lot of context that needs to be swapped in to the brain, and a lot of concentration that is required to delve into all of the corners of the implications of any decision. They shouldn’t spend much time in meetings, and the unit of time for their schedule should be no less than an hour (it’s even better if it is the day).

Managers, on the other hand, are interrupt driven. If you get a full hour of time to spend on some topic, it is a bonus. A really effective manager may occasionally disappear to do long-range strategy or planning, but once that plan is in place the decision process is to compare an action to the plan and then do the action if it fits and do something else if it doesn’t fit. Contemplation is not part of the job description.

Dual Track Systems

A much better organization is one in which there is a dual career path. One path takes a person into management. The other keeps a person in engineering. And each lets a person move up the organization, increasing scope of authority, pay, and prestige. The first company that I can remember having this sort of plan was Digital Equipment Corporation. I lived in the dual track at Sun for a long time. Most high tech companies have adopted some variation of this scheme, and many that you might not think of as high tech have also decided that this is a good idea. I’d love to see something like this within the IT organization at Harvard.

Most dual track system will have a number of points at which your career can branch. You start as an individual contributor, but at some point (sometimes early on) you can opt to go into line-management or become a technical lead. Line managers and technical leads share responsibility for a development group. The technical lead makes the technical decisions, while the manager makes business decisions, deals with budgets, does reviews, and the like. Clearly, these two people need to work closely together. The manager needs to be technical enough to understand what the technical lead is doing (if for no other reason than to explain the work to other managers) while the technical lead needs to understand the business case for the technology. But the creation of the business case is the job of the manager, while the creation of the technology is the job of the technical lead.

At the best companies, this dual track continues all the way up the organization. At the old Sun (and now at Microsoft, IBM, and lots of others) there was the job of Distinguished Engineer, which was the technical equivalent of a director or first-level vice president. The D.E.s (generally) had no reports, but designed and led the implementations of major parts of the technology. Becoming a D.E. was not something that just happened as a matter of course, just as becoming a director or a v.p. did not just happen. These engineers were often associated with a manager at the same level to oversee larger and larger parts of the company. At the very top of the company, the Chief Technical Officer was the technical representative on the executive team.

Decision Making

This did mean that the authority to make decisions was often unclear. While the distinction between a technical decision (made by the technical person) and a business decision (made by the manager) might seem clear, it often isn’t. The best groups had a team of leaders who could work well together, when those two didn’t work well together, it was not a pretty. When D.E.s decided that they could manage, bad things happened. When managers decided that they were sufficiently technical to make design decisions, worse things happened.

And then there are those companies that have decided that two decision makers is not enough. The thinking there is that while there is a clear distinction between the technical aspects of a project or product and the management of that project or product, there are other stake-holders that need representation. So the role of product manager is introduced to speak for the customer. VMware had such a system, which I believe is also used at Microsoft. At its best, this form of user-representation can provide valuable input into design. At its worst, it introduces the moral equivalent of the political officer in the Soviet military– someone who can second-guess any decision without having the responsibility to actually do the work.

From what I’ve heard, Google has introduced even more roles. At best, this will allow more points of view to be represented in the decision making around what is to be done. At its worst, this will make it harder to move quickly and will make everyone feel less responsible (since there were so many voices). It will be interesting to watch; I’ll express my own skepticism that it will work, but we will see.

Missing the Point

But at bottom, all of this talk about roles, and career paths, and tracks misses the most important point. It confuses management, organizational structure, and process with leadership, which is the thing that is really important.

All of the successful groups, products, and technology development I’ve ever seen or heard about were organized (intentionally or, more often, by chance) around a strong leader. Sometimes this was a manager, more often it was a technical person, and on occasion I’ve seen it be a marketing person or a product manager. But someone needs to be willing to insist that they know where everyone should be going, and have the force of both vision and personality to get others to sign on.

This is not something that you are going to get out of any definition of roles, or career track, or process. My own observation is that when a company tries to insure innovation through one (or more) of these things, it is probably time to look around for another gig. Innovation is the sort of thing that happens in all sorts of ways, almost none of which can be replicated or scaled. It is like good design– all of the best studies show that good design comes from good designers. Innovation comes from (and is driven by) innovative people, no matter what their title or role and no matter what process they use. This makes it impossible to manage, which in turn makes many managers nervous. But it is, I’m afraid, the truth…

 

previous:
Open office hours
next:
RIP Steve Jobs

3 Comments »

  1. Perry Hewitt

    September 12, 2011 @ 2:18 am

    1

    Developing this kind of dual career traffic is vital – I’ve seen too many great programmers thrust into management to the detriment of both capabilities in an organization.

    I’d also add that a trust is the ingredient that greases the skids on all the partnerships you mention. Just as innovation and design are nearly impossible to replicate or scale, trust on a delivery team where people have wildly divergent skill sets goes the same way.

    And thanks for the shout out that occasionally even the marketing folks can lead & inspire technical teams. Are you sure you’re really a programmer?

  2. Jim Waldo

    September 12, 2011 @ 2:15 pm

    2

    I’m pretty sure that I’m (still) a programmer…

    Your comment about trust is to the heart of the relationship between the engineering lead and the management lead. Each has to trust the other to do things that he or she doesn’t fully understand. And each is trusting the other to fill in a talent that is vital to the career of the other. I remember when I was interviewing one of the better managers I ever worked with– one of his questions was “how long have you been married?” Usually that is not something that I would discuss in a job interview, but it showed me that he understood the kind of trust relationship that he and I were going to need to have…

  3. IFSC Code

    December 9, 2011 @ 3:36 pm

    3

    Innovative thoughts and motivation should also be the key aspects.. Keep up good article

Leave a Comment