The maker/manager transition phase(joel.is)
joel.is
The maker/manager transition phase
http://joel.is/post/36051780992/the-maker-manager-transition-phase
10 comments
I totally agree with this.
There is no bigger disservice to your team or company than being the guy in charge whose knowledge is 10 years out of date.
That doesn't just apply to technical things either. It's an easy example to talk about the project manager who cut his teeth writing procedural code in QBASIC and has an unrealistic grounding. It also applies to the store manager in a fast food restaurant who hasn't made a cheeseburger.
That doesn't just apply to technical things either. It's an easy example to talk about the project manager who cut his teeth writing procedural code in QBASIC and has an unrealistic grounding. It also applies to the store manager in a fast food restaurant who hasn't made a cheeseburger.
I think those are two different jobs. On one hand you have the Product Leader, whose job it is to stay on top of the technology that drives the product, and to be aware of the codebase. On the other hand, you have the Team Leader, whose job it is to facilitate communication between team members. To make sure team members are productive and happy.
I've seen people do the side project thing and I think it's somewhat of a waste. I'd only advocate it for personal satisfaction reasons.
If you think your technical skill is an asset and you want to stay fresh I'd say you should be participating in technical design discussions, doing code reviews and occasionally writing tests. If you're doing those things you should have a very comprehensive knowledge of the system despite actually writing very few lines of code.
If you think your technical skill is an asset and you want to stay fresh I'd say you should be participating in technical design discussions, doing code reviews and occasionally writing tests. If you're doing those things you should have a very comprehensive knowledge of the system despite actually writing very few lines of code.
Two points to augment the article:
1) It's too easy to fall into the pattern of bullsh%t by day, hacking by night. There are two problems with that. First, you're still seeing management as bullsh%t (a natural inclination for a hacker.) Second, it's unsustainable and overwhelming. If you find yourself feeling like you never get anything done while other people are around, then your job is no longer coding and you have to accelerate the transition to manager (especially in your own mind.) This has been my experience.
2) Not every engineer should make this transition. If you're a founder or CEO, you will have to, but make sure you build a company where every engineer does not have to. I've worked at companies where the only path to success was through delegation and distance from the code. That sucks. Some people are amazing coders who will continue to deliver increasing value for years and you will only lose them if you can't find a way to let them progress their careers without having to do things they find uninteresting or are simply not well suited for.
1) It's too easy to fall into the pattern of bullsh%t by day, hacking by night. There are two problems with that. First, you're still seeing management as bullsh%t (a natural inclination for a hacker.) Second, it's unsustainable and overwhelming. If you find yourself feeling like you never get anything done while other people are around, then your job is no longer coding and you have to accelerate the transition to manager (especially in your own mind.) This has been my experience.
2) Not every engineer should make this transition. If you're a founder or CEO, you will have to, but make sure you build a company where every engineer does not have to. I've worked at companies where the only path to success was through delegation and distance from the code. That sucks. Some people are amazing coders who will continue to deliver increasing value for years and you will only lose them if you can't find a way to let them progress their careers without having to do things they find uninteresting or are simply not well suited for.
I am also a CTO for a small startup in Seattle. We now have an engineering team of 4 and I find myself oscillating between playing these roles. At this stage, I have to make sure I don't ignore either position.
If I ignore coding, I begin to feel detached from the product we are developing. It becomes easy to lose interest in the quality of what is being produced. On the other hand if I ignore the managing aspect, we become a much less effective team.
Sometime later this year we will be growing and I wonder if and when it will be appropriate to drop coding altogether and start developing my management skills with 100% focus.
If I ignore coding, I begin to feel detached from the product we are developing. It becomes easy to lose interest in the quality of what is being produced. On the other hand if I ignore the managing aspect, we become a much less effective team.
Sometime later this year we will be growing and I wonder if and when it will be appropriate to drop coding altogether and start developing my management skills with 100% focus.
I work on an internally-funded startup within a small business - equal parts management, development and devops simply by necessity. So i'm guilty of finding management a chore, or at best, a huge time-sink.
But there are highlights. It's oft-repeated but it really is true that supporting your customers and dealing with marketing can give you great insight into your own product. Through customer interaction i've gotten simple feature requests that add significant value, that I would never have encountered on my own with a programmer mindset.
I'd still take a pure 'maker' position any day of the week.
But there are highlights. It's oft-repeated but it really is true that supporting your customers and dealing with marketing can give you great insight into your own product. Through customer interaction i've gotten simple feature requests that add significant value, that I would never have encountered on my own with a programmer mindset.
I'd still take a pure 'maker' position any day of the week.
A key ingredient in this transition and being successful in it is trusting in your team.
We've gone from 3 to 10 in last year and realizing everything might not happen my way but will still be done well required some mental adjustment for me. But the ability to do this was purely a function of trust in the people on the team and their instincts, judgement, skills, etc. (note: the mental adjustment remains a work in progress. Maker tendencies are not easy to lose)
We've gone from 3 to 10 in last year and realizing everything might not happen my way but will still be done well required some mental adjustment for me. But the ability to do this was purely a function of trust in the people on the team and their instincts, judgement, skills, etc. (note: the mental adjustment remains a work in progress. Maker tendencies are not easy to lose)
Great read, I've put some similar thoughts of mine here - http://gtziralis.com/from-doer-to-leader/
Fantastic post, and one that I think a lot of developer founders can sympathize with. If you're in the specific circumstance of being the developer founder turned CEO, I think this is one of the toughest aspects of that role. I appreciated the fact that you brought in advice from numerous outside sources as well.
When I've been on bigger teams, it's probably more like 10-15% coding, 120% other.
I find that it's beneficial for me to always be in the code even as the team grows - even just a little bit. But, I usually take on small "nice to haves" (or small bugs) that no one relies upon and isn't critical to the product. So when it takes me a month to write it, no one cares.
In the least, it forces me to understand how to keep the system up and running on my machine and answer/demo general purpose stuff to other folks without looking like an idiot.
If you're a technical manager, I think dropping to 0% coding is a bad thing. It's way too easy to get out of touch.