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.
One thing I found from my experience as a team lead (and which is somewhat touched on in this article), is that sometimes, because team members never get a whiff of all of the deflected things that never reached them, the more critical will sometimes get the opinion that you're doing nothing at all other than acting as a pipe.
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..
Yes, and I didn't mean to be rude to any team leads, sorry if it came across that way.
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.
Sorry, the muse for my post was to vent tangential memories that it recalled moreso than anything you said that seemed particularly rude or short-sighted :)
What's the analogy for really, really bad managers who pass everything through, but not before completely misunderstanding the request and garbling it beyond recognition such that the developers deliver something completely different than what the customer actually wanted? These managers are also adept at completely misunderstanding their developers and telling clients outrageous things because they're just pretending to understand.
"Your job, should you accept it, is to become what I’ve lovingly dubbed Shit Umbrella"
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.
I suspect you and I agree on this, but I'd like to reframe your argument a bit. I would argue that a good manager should strive to never explicitly say "no". There are plenty of ways to limit misguided ideas without explicitly saying no. For instance, you can say "Yes but...", "Perhaps, but only if...", or (my personal favorite) "Good idea, but I personally like your other idea much better". The advantage this approach has is that it makes sure that you're not shutting down a good idea that has some major (albeit fixable) flaws.
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.
I used to be a developer. I now work as a team lead / client liaison. Coding is not in the top 5. My job is to anticipate what my team will need and make sure that there are no obstacles. I also help with DB design and platform choices. Strong knowledge and experience with what developers need help me a lot.
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.
Agreed. It happens a lot (in all my previous jobs I had mostly non-technical people as leads), but they have to work 10x harder to be effective. I think that even a limited technical background does a lot of things for you:
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)
At a previous company I had a project manager who's technical background was putting up Wordpress sites. He tried really hard, but he still made mistakes in #1-3. The company's COO, however (small company, so he was just one level above my manager), used to be a coder several years ago. So he understood time commitments and could sensibly discuss software design. I think that's what really kept the development team running, because it's sure what kept me running (deflecting "shit" and making sensible management decisions). At the very least I had a lot more respect for him, just like you say in #4.
Holy crap, I couldn't agree more. Thank you Benjamin!
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/
I remember reading about Microsoft having a Program Manager job title, which sounded exactly like what you're looking for. Might be worth approaching them, or looking to see whether other companies have something similar?
Thanks for the tip! Currently, I'm working on a startup I co-founded so I got my plate full. I wrote that article knowing that there are more people like me and because I just now found myself in a position to do what I love but spent some 10 years looking for it… :(
Wow, this article couldn't have come at a better time for me. Recently, I jumped from being a lead developer to being an architect and manager. Benjamin articulates exactly what I'm going through. Unfortunately, I don't think going backwards is an option for me.
I actually did enjoy being a team lead for awhile (once I got the hang of it). If you're a people person, it can be tremendously rewarding to see your team thrive at delivering piles of awesome. I just reached a point where I wasn't learning anything anymore (Fog Creek's just not that big; you do pretty much run out of novel managey things after awhile) and wanted to do more coding again. So I guess I'd tell you to grasp on really tightly to the idea of hanging your success on your team's success, and knowing that if they're doing their job well, you're probably doing the right thing.
Great advice. Similar to you, the main vexation has been "what comes next". Being a developer, you can scale your knowledge vertically and horizontally, constantly improving yourself and growing. Being a "shit umbrella", though, doesn't seem to lend itself to such growth opportunities.
Thanks for sharing. I really like your perspective (not to mention the analogy). Would you agree, though, that part of the problem is with company's views on their own employee's trajectories?
I was fortunate enough to work at one company for 21 years (MS) that supported this model. I suspect, given my personality, passions, and style, if MS had not supported me in this way I would have just done it across many companies.
So, at my core, I believe it is up to the employee. If you are stuck, GET OUT.
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.