… as pointed out by Eric Ries at Kiwi Foo:
- Write software
- Lead a team of people writing software
- Manage people who lead a team of people writing software
- Advise people who manage people who lead a team of people writing software
What’s the next step after that?
What do you do?
Related:
Another interesting question is, what’s the career path for the heads-up developers who *don’t* want to do the people management stuff. e.g. performance reviews etc. Who instead want to do business-facing stuff e.g. product management, strategy etc.
What are these folks (we folks?) meant to do :)
@Koz – build a company where you can do what you want to do. (You’ll probably need a critical mass and a co-founder with complementary skills).
@koz – find a friend with a world class raytracer and build a business around it, hiring people to do the bits you don’t want to as you go along.
Meh!
I hate this model of the ‘developer’.
Why can’t someone go on to be a more brilliant developer? Why does everything have to devolve into management?
I like the position that Microsoft have of Distinguished Engineer…. which is basically code for a really smart person who doesn’t need a whole tree of direct reports to be effective at writing great code. I actually like the term Engineer less here becasue arguably engineering is far more prescriptive than software development which, at its heart, is as much an art as a science. I’m almost inclined to say that a great dev is more like the top litigation partner in a law firm…
I’m not a brillint dev myself… I am that businss dev/sales/strategy person that Koz talks about. But, I have a heap of BRILLIANT devs in my organization and it pains me that the default ‘path to greatness’ is not one that truely leverages their skill.
D’oh… “Heads Up” had a lot more meaning to it once I found the Heads Up vs Heads Down post…. General sentiment still stands.
I agree, there is a lot not to like about this. I wouldn’t describe it as a “path to greatness” at all.
On the other hand, the best heads-up developers already have the people skills, so management should not be a stretch.
As you say Chris, you have heaps of great developers working with/for you and that gives you a lot of leverage as a dev/sales/strategy guy. When you have to do everything yourself, including all of the coding, it’s not so much fun.
I’m definitely railing against any “management” label.
Building bigger, better and more reliable systems is one path. That’s a path into architecture rather than implementation.
If the goal is architecting bigger better and more reliable systems, then at some point that will involve a team of people rather than just an amazing individual working alone. And, when that happens, the person responsible for that team is “management”, whether they have a personal aversion to that label or not.
I’m not saying this is necessarily the way that everybody would like it to be, just that it’s the way it is.
You can either wish it were different, or find a way to work with with.
You asked what the next steps were?
5. Write a blog about managing developers.
6. Write a blog about how to blog about management.
Touche!
another 5: train the people who advise the people who manage the people…
>engineering is far more prescriptive than software development, which, at its heart, is as much an art as a science … almost inclined to say that a great dev is more like the top litigation partner in a law firm …
goodness, as an engineer I wouldn’t recognise that at all – indeed, wouldn’t be surprised if most, even all, lines of human endeavour are as much an art as a science – including the arts & sciences !
Chris