I suspect many of you who read this blog are software programmers. If you’re not, great! For those of you who are, suppose for a moment that you are not. All together now, suppose that you are an accountant or an analyst. Suppose further that you’re good at it: your assignments are completed at high quality; you find novel solutions to difficult problems; you plan your work and communicate progress; you finish on time. One day the CEO says, “you know, you’re doing such a great job at accounting/analysis that we’d like you to write some code now.” “Great!” you say, “I’m good at lots of things, I can figure out this software engineering thing too.” You’ve heard that a lot of programmers use IDEs, so you download a copy of Eclipse, open it up and start typing.
Sound strange? Now substitute “management” for “software engineering”. This presents a more familiar scenario: individual contributors who are rewarded for their contributions with a promotion to management. But the job of engineering management is about as far from engineering as accounting or analysis. It’s a completely different skillset. Yet many of us charge ahead thinking, “I’m smart, I’ll just figure it out.”
While some do, most of us have to read books, take classes and learn from more experienced practitioners. In the past year I’ve done a lot of the first. Currently I’m working through The Leadership Pipeline: How to Build the Leadership Powered Company. A few chapters in, the most interesting observation is that we cannot divide work into the simple roles of “contributor” and “manager”. The skillsets required of a “manager of doers”, for example, are not the same as the skillsets required of a “manager of managers”. Looking forward to the rest. Two of the book’s authors were part of the leadership team at General Electric, a company with hundreds of thousands of employees and many layers of management. Not the same as the challenges that face a typical startup, but interesting nonetheless!