I've been reading Spence's posts about becoming a manager with some interest, given that I hadn't heard the full story before. Last time I worked in the same building with Dave it was right after I suckered recruited presented him with the opportunity to build StorageScope after I had worked on the initial research and design.
I find it even more interesting because Dave is one of the better software engineers that I have worked with (we collaborated quite a bit on building Navisphere ). When Dave became a manager, I always wondered, why did he do that? Now I know!
His story about becoming a manager has me reflecting on why I never did. It's a good case study of two technical people, one who successfully moved into management, and one who never even tried. My reason is pretty simple.
I like building stuff too much.
When Projects End
I always like to stick with an innovative idea until it ships. When the product hits customer hands, there's a support period that follows, including customer visits and/or spinning some fixes that slipped past QA. In general, 6-9 months after the product goes out the door, I've got a decision to make.
Becoming a manager never crossed my mind. Not even once. My choice always came down to one of two options.
Option 1: Re-architect
I was never that interested in sticking around and making incremental improvements to the new products I had worked on, but I was interested in implementing new features that involved some sort of complex rearchitecture. The best example I can think of was adding a mirrored write cache to CLARiiON back in '93 or so. I had written the RAID5 algorithms at the bottom of FLARE, and the mirrored write cache was a chance to completely rip out the top half of FLARE and replace it with some pretty cool write cache code.
After we shipped the write cache, the nature of the work on FLARE turned incremental for me (e.g. add read cache functionality), and so I exercised another option that I've repeated several times as well.
Option 2: Leave
I decided to leave the FLARE team to start the Navisphere team. Navisphere wouldn't be incremental, and it wouldn't be a re-architecture. It would be "create the architecture from scratch".
I remember a former manager had once told me that it's actually quite rare to be a software engineer that's handed a blank sheet of paper (he was recruiting me to write FLARE at the time). He said it was even rarer to have it happen more than once. The Navisphere opportunity seemed great because it would be an architecture that mattered; CLARiiON only had a text-based (curses) interface at the time (GridMan). With hundreds of field units and multiple attach options (e.g. MSoft/IBM/Sun/SGI, SCSI & FC), the CLARiiON product needed an architecture that could managed a family of storage systems for years to come.
We spent the next six years building it. Not sure we would have made it if Dave Spencer hadn't come along ;>)
Re-architect or Leave
My post-Navi career has consisted of those two career choices: re-architect or leave. For example, eventually the Navi team made the decision to run our software inside a browser. I had the choice to re-architect Navi or to leave.
I left Navi to build StorageScope.
I left StorageScope to build PowerPath Data Migration Enabler.
I left PowerPath to work on Centera.
Once I spent some time learning about Centera, I realized that the object-based storage technology is faily ripe with opportunities to innovate. I've decided to do some re-architecture work (XAM) as well as build some new stuff (Centera Seek).
This "moving around" pattern is actually fairly common and encouraged at EMC. After all, there are plenty of cool technologies to choose from (the Information Playground theme).
The Technical Career Path
One of the traditional side effects of deciding not to become a manager was that software engineers used to plateau pretty early here at EMC. Choosing to manage always had a pretty well-defined Director->Sr. Director -> VP -> SVP -> EVP progression. For software types, "Senior Consultant" was about as high as you could go (which was the equivalent of "Director").
This meant that as a software engineer there was really nothing to shoot for career-wise (other than trying to build the next cool thing).
Lately, however, EMC has rolled out the Distinguished Engineer / Fellow program. This is the best of both worlds. Creating new products can now occur in the context of working towards corporate goals as well, which keeps things fresh. I like it.
I have always felt that if I became a manager my focus should be on empowering people and NOT on continual innovation. I'd be interested in hearing if other people feel the same.
What do you think?
Steve
Steve, great post! In my technical days, I always felt I enjoyed most when I could produce something other developers would use, and do a good job of it. Enabling other people to succeed was always my most satisfying.
Just like as a developer, as a manager I spend a lot of time dealing with tactical work, but there are times when I can be an empowering influence. Without a doubt, those are the most satisfying days of this leg of my career.
Posted by: David Spencer | December 09, 2008 at 07:52 AM