Coding is priority number five
bitquabit.com
bitquabit.com
I have in the past categorised managers as "umbrellas" or "funnels" (and I guess there's an inbetween 'pipe').
The idea is that there is work the team should ideally not be doing (the 'shit'). That either needs to be rebuffed by the manager or handled another way (e.g. by stalling on it, doing it themselves, or making it someone else's problem).
Good managers keep the shit away from the team somehow. They're umbrellas.
Poor managers act as simple proxies. If anyone requests anything from them, they pass it on to someone on their team, without considering if they should or could block it (or handle it themselves). They're pipes.
Really bad managers act as intensifiers of the shit. e.g. by getting multiple people on the team duplicating effort on it. Or by being the sort of corporate busybody who goes and attracts more of it. Or by having slow, talky meetings about it which add time and friction. They're funnels.
I vividly recall one incident where I passed along an urgent UAT issue to a self-styled "hot shot" developer, who responded (with cc's) that he was entirely too busy, and that "if I had two hands I could do it myself".. since I was "obviously not busy as I hadn't had many commits lately". Meanwhile, I was two hours into a client call negotiating turning functionality requests into deadline shifts, was simultaneously trying to triage a production issue to see if it was our problem or the client's problem, and had 50+ emails from developers and clients just from that day still un-responded to.. yeah, silent evidence is a bitch.
I do have to agree, however, that moving back to development released a lot of stress for me. It's far less stressful thinking about whether or not I can get something done as opposed to wondering whether 15 other people are going to be able to get something done..
In any role, it's important to communicate the work you're doing (ideally without bragging), up and down the hierarchy. That is hard for an umbrella to do but possible. ("Just checking folks - is anyone keen to fill in 5-min increment timesheets?" (Groans) "Thought not")
Also, changes in manager offer a natural opportunity to compare, since you can detect a difference in the kind of work the team receives.
So, so true. And this is an excellent article.
There's another aspect of becoming a manager that the Benjamin doesn't discuss here, but is closely related:
The best managers/leads are excellent at saying "No". They say "No" to outside (especially upward) voices as well as to the people they lead. The most important aspect of being excellent at saying "No" (as a leader) is to be able to say "No" to yourself.
I don't know Benjamin myself, but he sounds smart and probably has tons of great ideas. The team is executing against a plan and Benjamin might have a really great idea for a new feature, process, etc... To be a really great Shit Umbrella a lead like Benjamin needs to be disciplined about when to say "No" to his own ideas.
Of course, sometimes you have to just set your foot down and just say "No". But I've noticed that as managers get more experienced, they tend to rely on their ability to do so less and less.
Someone gave my wife and I advice early on to avoid explicitly saying no to our children when they were very little. It was very, very good advice.
I was wondering if a person without a development background could take my role as team leader to manage 3/4 developers on a daily basis.
1) You can scope your team's features and commitments more effectively if you have some understanding of the technical complexity of each ask.
2) Understanding the technology (and the skills of your people) means you have better intuition about the right people to bring into the room when a problem arises
3) It's easier to be empathetic with your team when you have engineering experience, because you know that many times the spec is just the tip of the iceberg.
4) Credibility. A group of devs will have a lot more respect for you from the start if they know you're not just a bureaucrat and you can code (even if it's not as well as they can)
Having said that, what happened after he stepped down? Did they hire outside of the company? Promote another senior developer?
I just wrote a comment/follow-up from the flip-side perspective: someone wired to be a "Shit Umbrella" who is stuck in a world where you have to be a "rockstar coder" first – http://levifig.com/articles/a-tale-of-priorities/
TL;DR: Don't think about your career as a ballistic trajectory, but more as a series of interplanetary missions.
http://ceklog.kindel.com/2012/04/08/you-are-thinking-of-your...
So, at my core, I believe it is up to the employee. If you are stuck, GET OUT.