What do technical managers do, anyway?(dandreamsofcoding.com)
dandreamsofcoding.com
What do technical managers do, anyway?
http://dandreamsofcoding.com/2013/01/22/what-do-technical-managers-do-anyway/
39 comments
Sounds like you work at a horrible place and are a little naive. No group of 100 people is going to naturally just take care of themselves. A hierarchy will develop, and folks will take on management roles on an adhoc basis.
Managers should be working at a level of abstraction up from the folks doing the work. Usually in a big project, folks end up specializing on a specific area and have a hard time grasping the "big picture" in their heads.
As one of those useless manager people, I'd say that my job is about understanding what's going on, course-correcting when what's happening isn't consistent with what we need to do, and figuring out how to get more productivity out of folks. As a "technical" manager, I stay close enough to understand what is happening, but don't do alot of hands on anymore.
When things are good, 80% of my job is keeping BS away from the folks I'm responsible for. When things are not so good, it's all about triage and finding solutions to whatever is wrong.
Managers should be working at a level of abstraction up from the folks doing the work. Usually in a big project, folks end up specializing on a specific area and have a hard time grasping the "big picture" in their heads.
As one of those useless manager people, I'd say that my job is about understanding what's going on, course-correcting when what's happening isn't consistent with what we need to do, and figuring out how to get more productivity out of folks. As a "technical" manager, I stay close enough to understand what is happening, but don't do alot of hands on anymore.
When things are good, 80% of my job is keeping BS away from the folks I'm responsible for. When things are not so good, it's all about triage and finding solutions to whatever is wrong.
When did commenting on HN become so predictable? Yes, there are bad managers, just like there are bad everything-elses.
Small companies don't need management, but the larger a company gets, the more important communication gets or everybody goes off in their own direction. You can't accomplish big things if everybody is rowing to a different rhythm.
Further, there is a limit to how many people a person can effectively manage directly. Most bad organizations I've see put way too many direct reports on managers, forcing the manager to be flighty and generic.
Finally, engineers put very little importance on personal interactions, but business is run on those personal interactions.
Just like there are bad places to work as a developer, there are bad places to work as a manager. And they often (but not always) overlap.
Small companies don't need management, but the larger a company gets, the more important communication gets or everybody goes off in their own direction. You can't accomplish big things if everybody is rowing to a different rhythm.
Further, there is a limit to how many people a person can effectively manage directly. Most bad organizations I've see put way too many direct reports on managers, forcing the manager to be flighty and generic.
Finally, engineers put very little importance on personal interactions, but business is run on those personal interactions.
Just like there are bad places to work as a developer, there are bad places to work as a manager. And they often (but not always) overlap.
I have been wanting to write a much more ranty version of the OP for a really long time. Yes, there are and always will be bad managers out in the world. But it makes me laugh when the immediate reaction people have is to just get rid of all the managers, because developers are all clearly rock stars, way smarter than managers in all ways, and can perfectly self-organize themselves. Really? I would love to see such a group in action. I imagine they must exist, but I also strongly believe people hear the myths of such teams much more than they actually have experienced such a thing themselves.
Meanwhile, I'm going to head back to figuring out to get a QA member to stop being so toxic to our overall efforts, make sure a developer properly knows the expectations on how to interact with the rest of the team, sort out the next 3-6 months of priorities with the executive team accounting for all internal department requests and our lengthy product roadmap, help a lead dev resolve an issue with a really smart developer who has taken twice as long as expected on a straightforward task, find time to look through a whole bunch of resumes that are likely nowhere near where what we're seeking in candidates, and then make sure all the right people receive updates to all of those activities. We'll see what tomorrow brings.
To be clear, I absolutely love my job. It's extremely rewarding to see even one of those items get checked of the list in a given day, or the not-always-well-communicated but good-intentioned appreciation that a single member of my team sends my way after helping him remove an obstacle or provide some sort of useful feedback. It's definitely a much different type of challenge from when I was a full-time dev, but I honestly get at least as much out of the experience as I did solving problems with code.
I can't point people at a team of 100 developers that operate like a herd of unicorns, negating their 1 bumbling manager. However, I can provide examples of teams that perform really quite well and have competent managers who deserve at least a bit of credit in their teams' successes.
Meanwhile, I'm going to head back to figuring out to get a QA member to stop being so toxic to our overall efforts, make sure a developer properly knows the expectations on how to interact with the rest of the team, sort out the next 3-6 months of priorities with the executive team accounting for all internal department requests and our lengthy product roadmap, help a lead dev resolve an issue with a really smart developer who has taken twice as long as expected on a straightforward task, find time to look through a whole bunch of resumes that are likely nowhere near where what we're seeking in candidates, and then make sure all the right people receive updates to all of those activities. We'll see what tomorrow brings.
To be clear, I absolutely love my job. It's extremely rewarding to see even one of those items get checked of the list in a given day, or the not-always-well-communicated but good-intentioned appreciation that a single member of my team sends my way after helping him remove an obstacle or provide some sort of useful feedback. It's definitely a much different type of challenge from when I was a full-time dev, but I honestly get at least as much out of the experience as I did solving problems with code.
I can't point people at a team of 100 developers that operate like a herd of unicorns, negating their 1 bumbling manager. However, I can provide examples of teams that perform really quite well and have competent managers who deserve at least a bit of credit in their teams' successes.
I think you have an unrealistic view of how well a large team of engineers can "self organize." It's hard to keep track of the 10,000ft view when that's your job, it's nearly impossible when you're in the thick of code, in some subsection of the overall application.
I think 100 is a bit much.
A the place I work we have one manager for about 30-40 people. He's managing about a dozen projects. Why is he effective?
0 - He knows he's not working on each project day to day, so meetings and decisions are not very top down and are mostly done by consensus.
1 - He's got about 20 years of experience, so he can provide technical input and bring in ideas from other projects. If we hit a problem he'll throw out ideas that have come across in previous projects. He's not a super coder or a math genius and technically isn't super strong (which can make it frustrating to explaining things to him) but he can quickly bounce ideas off of us.
2 - Since he's very familiar with a lot of people (both because he manages a large group and because he has the years of experience) if our team gets stuck or we are not sure of something he knows exactly who to bring in from outside the project to help.
3 - All the above could apply to anyone with enough experience. What makes HIM the manager is he's exceptionally good at dealing with clients. In part this is from experience and in part because he has a natural knack for it.
By no means do I think he's the best manager ever. He has plenty of problems - but a the end of the day I have to say he's very effective in getting things done and getting the teams the help they need.
A the place I work we have one manager for about 30-40 people. He's managing about a dozen projects. Why is he effective?
0 - He knows he's not working on each project day to day, so meetings and decisions are not very top down and are mostly done by consensus.
1 - He's got about 20 years of experience, so he can provide technical input and bring in ideas from other projects. If we hit a problem he'll throw out ideas that have come across in previous projects. He's not a super coder or a math genius and technically isn't super strong (which can make it frustrating to explaining things to him) but he can quickly bounce ideas off of us.
2 - Since he's very familiar with a lot of people (both because he manages a large group and because he has the years of experience) if our team gets stuck or we are not sure of something he knows exactly who to bring in from outside the project to help.
3 - All the above could apply to anyone with enough experience. What makes HIM the manager is he's exceptionally good at dealing with clients. In part this is from experience and in part because he has a natural knack for it.
By no means do I think he's the best manager ever. He has plenty of problems - but a the end of the day I have to say he's very effective in getting things done and getting the teams the help they need.
I agree that traditional businesses often have too many managers. However, my perspective is that well functioning teams do not require day to day involvement with the manager. Consequently the manager may appear to add less value.
It is a tricky balance, I've worked for good managers and seen them lose track of things as their team grows either as a product of being successful or pressure to grow. There are also bad managers who are wasteful (of people) or are just skimming off the efforts of their team and not adding a lot of value. From the top of the organization it is probably quite difficult to tell the difference.
It is a tricky balance, I've worked for good managers and seen them lose track of things as their team grows either as a product of being successful or pressure to grow. There are also bad managers who are wasteful (of people) or are just skimming off the efforts of their team and not adding a lot of value. From the top of the organization it is probably quite difficult to tell the difference.
One other disadvantage of having too managers is that it leads to a reduction in organization productivity. Each team reporting to a manager eventually becomes a silo. A team only works on the tasks assigned to it by its direct manager only. This results in some teams which are overburdened, while the team sitting next to them doesn't know what to do with their time.
The managers are too busy in their daily meetings to figure out what is happening on the floor. This causes lot of resentment in the teams.
If a project gets assigned to a manager and the best resources to work on this project are on some other team, it is really tough to pull them in to work on this project. This results in reduced overall efficiency as teams have been artificially divided to create a reporting structure for the manager.
I understand that some of you would not have seen this type of manager in your work life. But I am speaking from my own experience and recognize that there are managers which are very good. But I have seen too many of them coasting along, doing little real work while increasing the organizational inefficiencies.
The managers are too busy in their daily meetings to figure out what is happening on the floor. This causes lot of resentment in the teams.
If a project gets assigned to a manager and the best resources to work on this project are on some other team, it is really tough to pull them in to work on this project. This results in reduced overall efficiency as teams have been artificially divided to create a reporting structure for the manager.
I understand that some of you would not have seen this type of manager in your work life. But I am speaking from my own experience and recognize that there are managers which are very good. But I have seen too many of them coasting along, doing little real work while increasing the organizational inefficiencies.
There are only two options for managers:
"You can either be a shit funnel, or a shit umbrella."
http://www.kevgibbs.com/2011/08/3-suggestions-for-engineerin...
If you do the former then your reports hate you, if you do the latter then they like you but wonder what it is you actually do.... :-)
"You can either be a shit funnel, or a shit umbrella."
http://www.kevgibbs.com/2011/08/3-suggestions-for-engineerin...
If you do the former then your reports hate you, if you do the latter then they like you but wonder what it is you actually do.... :-)
If you're a shit funnel, the people you're managing will hate you, but the people above you will love you. If you're a shit umbrella, the people below you will love you, but the people above you will hate you.
The people below you aren't the ones who hand out promotions.
The people below you aren't the ones who hand out promotions.
In Silicon Valley startups, the most valuable thing you can provide, as a manager, is the ability to attract a great team. When startups look to hire a manager, it's almost always with growth in mind. Your career is an opportunity to build a group of people who will follow you anywhere, thus making you very valuable yourself. Getting people to love working for you, while still making execs happy, is a non-trivial skill.
Therefore, the best way to be successful as a manager, in the long term, is for people to love working for you. You will get amazing results. They might not be exactly what the people above you asked for, but that's where your skill is required--show that it's better and that they can trust you and your team more than they thought.
Therefore, the best way to be successful as a manager, in the long term, is for people to love working for you. You will get amazing results. They might not be exactly what the people above you asked for, but that's where your skill is required--show that it's better and that they can trust you and your team more than they thought.
I have experienced every negative thing that can come from being an umbrella, to the point people on other teams hated my team because they were happier. If you go that path, expect negative reactions from everybody (except your team, that is, which was all I cared about).
"You can either be a shit funnel, or a shit umbrella."
Thank you painting such a vivid imagery in my mind with that metaphor… :O
Thank you painting such a vivid imagery in my mind with that metaphor… :O
The term may have originated here (edit - actually, probably not based on the publication dates.) But it's where I first saw it:
http://bitquabit.com/post/coding-is-priority-number-five/
http://bitquabit.com/post/coding-is-priority-number-five/
I go to meetings so my team doesn't have to.
As an engineering-driven company, both daily tactical decisions and our overall strategic decisions are (usually!) based on technical data. This requires our management team to understand enough of the technical details in order to make sane decisions around product, forecasting, marketing, technical partnerships, etc.
It's important to note that I don't necessarily view the above tasks as more "important" than engineering. They're simply other business functions that need to happen for the business to work, and it's more efficient if I do it in my role rather than taking time away from actual development to provide the data we need for those functions.
Another function I serve on my team is technical tiebreaker. I work hand-in-hand with my tech lead, delegating most of the daily responsibilities to him, but when the team is mired in debate, I either cast a tiebreaker vote or if I don't know enough about $TOPIC, I can at least ask some questions to get them to consider the issue from different perspectives, which is enough to make progress in the debate..
Again, I note that the fulfilling the above job function doesn't mean I'm smarter than my tech lead (I'm not). But engineering isn't as black and white as we want it to be, and ofttimes we just need to make a decision, else the team wastes too much time bike-shedding.
A good manager is like a good IT guy. If he/she is doing the job properly, the team is only ever rarely aware of it. And that's just the way I like it.
As an engineering-driven company, both daily tactical decisions and our overall strategic decisions are (usually!) based on technical data. This requires our management team to understand enough of the technical details in order to make sane decisions around product, forecasting, marketing, technical partnerships, etc.
It's important to note that I don't necessarily view the above tasks as more "important" than engineering. They're simply other business functions that need to happen for the business to work, and it's more efficient if I do it in my role rather than taking time away from actual development to provide the data we need for those functions.
Another function I serve on my team is technical tiebreaker. I work hand-in-hand with my tech lead, delegating most of the daily responsibilities to him, but when the team is mired in debate, I either cast a tiebreaker vote or if I don't know enough about $TOPIC, I can at least ask some questions to get them to consider the issue from different perspectives, which is enough to make progress in the debate..
Again, I note that the fulfilling the above job function doesn't mean I'm smarter than my tech lead (I'm not). But engineering isn't as black and white as we want it to be, and ofttimes we just need to make a decision, else the team wastes too much time bike-shedding.
A good manager is like a good IT guy. If he/she is doing the job properly, the team is only ever rarely aware of it. And that's just the way I like it.
This is one of the best answers here. As a technical manager I go to meetings so my team doesn't have to. I answer the emails and questions so my team doesn't have to. The code I work on is to support my team and keep the little stuff off their plate and to make their job easier. I prioritize work based on what they're currently working on so they aren't moving from one part of the code base unnecessarily while still managing the external team priorities. I act as a coach/recruiter to hire the best team possible and give them the tools they need to succeed.
TL;DR; I prevent interruptions: http://news.ycombinator.com/item?id=5092589
TL;DR; I prevent interruptions: http://news.ycombinator.com/item?id=5092589
Well look, I already told you! I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?
Beat me to it...
IT manager. your list is almost perfect, I think you left one very key role off. The manager is responsible for ensuring the future of the team. This means ensuring that once whatever they are working on now is completed, that there is work coming up behind that. That can mean BD outside the company, or more often sales internal to the company to ensure your people are picked for the next big project. I like to break down my job into past (recognition, raises), present (evaluation, guidance, material support), and future (new work coming down the pike).
I manage a set of engineers, a content team, a graphics team, and a QA team. I know a lot of engineers like to say "managers don't do anything" but thats often when they take a painfully narrow view on production.
For example I have to set and square requirements of a technical nature (sometimes down to details) with each of these parties. Decisions like which image format will be best from a size/performance/integration perspective need to be agreed upon by all teams, up to approving designs, ensuring engineering implements them exactly, approving the UX, and making sure the QA team tests for all those standards set. Sometimes I have sit the engineers down and do a brief code-review to ensure they are following the overall architecture of the larger system.
Managers do those details on TOP of all the basic things like team budget, hiring/firing, recruitment, organizing new incoming work, and taking care of small HR issues. And at times we have to step in and do the work of any of those teams OURSELVES if there is a temporary gap. That includes and is not limited to coding, designing, and QAing.
For example I have to set and square requirements of a technical nature (sometimes down to details) with each of these parties. Decisions like which image format will be best from a size/performance/integration perspective need to be agreed upon by all teams, up to approving designs, ensuring engineering implements them exactly, approving the UX, and making sure the QA team tests for all those standards set. Sometimes I have sit the engineers down and do a brief code-review to ensure they are following the overall architecture of the larger system.
Managers do those details on TOP of all the basic things like team budget, hiring/firing, recruitment, organizing new incoming work, and taking care of small HR issues. And at times we have to step in and do the work of any of those teams OURSELVES if there is a temporary gap. That includes and is not limited to coding, designing, and QAing.
> For example I have to set and square requirements of a technical nature (sometimes down to details) with each of these parties.
Without knowing the specifics of your company, this feels like a needless managerial role. These are the things you want to trust your people with, so you can focus on the bigger picture. I mean, if you are taking away technical planning from an engineer, what real engineering work is left?
Your final paragraph is a better example of the manager's role. To shield the outside world. To deal with problems of the people on the outside (clients, investors, etc.). The team should come to you with problems that arise, but you should generally not need to go to the team at all.
Without knowing the specifics of your company, this feels like a needless managerial role. These are the things you want to trust your people with, so you can focus on the bigger picture. I mean, if you are taking away technical planning from an engineer, what real engineering work is left?
Your final paragraph is a better example of the manager's role. To shield the outside world. To deal with problems of the people on the outside (clients, investors, etc.). The team should come to you with problems that arise, but you should generally not need to go to the team at all.
Here is my take on the problem between managers and other employees:
1) Money.
2) Control.
The first is obvious. Managers tend to make more than others. From the point of view of an engineer, the manager is doing an easier job that requires much less training. Thus, they should, if anything, earn less, not more.
On the second topic, many managers seem to come from the view "I am boss. You do as I say." Rather than the view of "My job is to make your life easier. How can I help?" The former view will naturally create a lot of friction.
The other problem with control comes back, once again, to background. Managers that were previously engineers generally get a pass. But it seems that in some cases you have managers making technical decisions without the required technical background. Unsurprisingly, the people who do have the technical background, and get paid less on top, will have an issue with this.
I suspect that these are the true problems in the room, but ones that nobody wants to address.
1) Money.
2) Control.
The first is obvious. Managers tend to make more than others. From the point of view of an engineer, the manager is doing an easier job that requires much less training. Thus, they should, if anything, earn less, not more.
On the second topic, many managers seem to come from the view "I am boss. You do as I say." Rather than the view of "My job is to make your life easier. How can I help?" The former view will naturally create a lot of friction.
The other problem with control comes back, once again, to background. Managers that were previously engineers generally get a pass. But it seems that in some cases you have managers making technical decisions without the required technical background. Unsurprisingly, the people who do have the technical background, and get paid less on top, will have an issue with this.
I suspect that these are the true problems in the room, but ones that nobody wants to address.
I like this article, but I disagree with one point about task assignment.
Good engineering decisions are always based on the big picture like long/short term goal, budget and deadline. By keeping those in mind, an engineer can then go and understand task priority, and decide which solution might be best for each task.
If an engineer team understands the bigger picture, they can in most part self-manage and figure out what to do to achieve the end goal.
However if a manager or PM shields engineers from those bigger pictures, it becomes much harder to make informed engineering decisions on individual tasks, or how to allocate time among those tasks, causing slipped deadline and over budget. This reinforces the impression that managers should provide closer guidance on what to do.
In my experience, most technical manager/project manager will only talk about the bigger picture when pressed, and only some are able to describe it clearly.
Good engineering decisions are always based on the big picture like long/short term goal, budget and deadline. By keeping those in mind, an engineer can then go and understand task priority, and decide which solution might be best for each task.
If an engineer team understands the bigger picture, they can in most part self-manage and figure out what to do to achieve the end goal.
However if a manager or PM shields engineers from those bigger pictures, it becomes much harder to make informed engineering decisions on individual tasks, or how to allocate time among those tasks, causing slipped deadline and over budget. This reinforces the impression that managers should provide closer guidance on what to do.
In my experience, most technical manager/project manager will only talk about the bigger picture when pressed, and only some are able to describe it clearly.
This is a very valid point. Most managers think communicating the immediate work load of the team is their only responsibility. But most of the time the team really needs to know the bigger picture. What is the future direction of the company, product etc. and most of the managers are really stingy with these types of details. This behavior results in lot of duplication of efforts. Managers are happy as they have something to show in their status reports. But in the long run, it reduces the overall product quality as most engineering decisions cannot be prudently taken without having the bigger picture in your head.
Not always. There are always disagreements on teams; generally they can be resolved among the participants but not always and especially not on issues where everyone has strongly held opinions.
GitHub seems to be doing just fine without managers .. http://gigaom.com/2012/03/26/tales-from-the-trenches-github/ .. from an end user's perspective.
I admire GitHub's organization and structure more than most, but we can't pretend they're a run of the mill business.
The bar to get hired as an engineer, for instance, is not trivial. Once you have the ability to cherry pick your hires, you can also better select for fit (in this case, capacity to be self-driven on a mostly-remote team).
Also on a purely product-related note, their UX has always (personally) felt lacking.
The bar to get hired as an engineer, for instance, is not trivial. Once you have the ability to cherry pick your hires, you can also better select for fit (in this case, capacity to be self-driven on a mostly-remote team).
Also on a purely product-related note, their UX has always (personally) felt lacking.
An interesting and accurate allusion, and one I'm quite fond of, technical managers herd nerds.
By reading this "job description" for project managers I still wonder why on earth would people think management is a natural step in a developer's career path (at least here in Europe). These are different jobs entirely! How are the experience, knowledge and skills I earned from studying and writing code for years going to make me any good in dealing with people in the future?
[deleted]
A manager's job is to remove all obstacles in the team's path. This doesn't mean telling them what to do, and it doesn't involve making their technical decisions for them.
The manager's job is to solve people problems. Most developers are great at analytical thinking, but very bad at emotional thinking. Nerds are usually introverted, and moody, in my experience. Great managers are the opposite of nerds. They are extroverted, warm, communicative, cheery, and, (for the lack of a better term) dumb. Its a huge mistake to put a nerd in a manager role, as much as it is a mistake to put a manager in a programmer role. I've worked under my fare share of "nerd managers" as well as "manager programmers". Both do more hard than good.
Where does technical fit in? That sounds like a plain old PM.
How many plain old PMs know how to code?
How many plain old PMs mentor the developers and lead the code reviews?
There is some adhoc planning going on at this level but most of the time it is dictated by what is being conveyed from the top. This takes care of all the planning, task assignment work. If the manager has capable team members then all that is required is to just tell them that they are now going to work on project X. After that it is the responsibility of those team members to manage the work. All that the so called managers do is check periodically about how it is going.
Recruitment of engineers is again completely left to senior engineers. Once 3 senior engineers say yes to a candidate, the manager just has to complete the formalities. So there is no contribution in building better teams.
There is no technical input from the managers as this takes lot of time and is somehow beneath them.
With agile processes, the team manages their work flow on a day to day basis. So the manager role is reduced even further.
All they work on is performance review once a year. It is more of a give and take as the manager and his manager don't have any realistic idea of an individual's contribution.
I think time has come to cull the managers rank and just have 1 manager for 100 developers with developers organizing themselves in self-managing teams. The managers just get too much credit and money for doing essentially nothing.