Some of your engineers are already deferring decisions to other engineers
But do those other engineers want to be managers? I've certainly picked up some of that work from time to time in my career, and yet if my boss told me, "congratulations, you're being promoted to manager!" I'd have to respond with, "congratulations, I quit."
Maybe they don't, but this is a good test for "qualified to be a decision maker". If other people want someone to help make decisions for them it's because they want the benefit of their prowess.
You could either embrace this as the start of the hierarchy everyone is apparently so desperate to create. Or you could ignore this signal in favor of handshakes, smiles, buzzwords, or however else you intend to pick a manager from your outside funnel.
Part of this reluctance is an aversion to the busy work that often comes with a manager title. Work that managers create for themselves and other managers to legitimize their roles, but which actually impedes progress, and annoys or alienates talent.
I really don't see managers as decision makers. They do help communicate strategic direction, but in terms of tactical decisions, they are too removed to really have valuable input.
OTOH, unless you are the team lead, the amount of bike shedding from simply taking initiative and just making a tactical decision can be overwhelming. It's framed as "not building consensus first."
A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"
Many orgs do not view engineers as decision makers, simply as do'ers, which really I think highlights how the role of a software engineer is just misunderstood. Software engineers are more like writers than they are like carpenters. Consider for example the number of decisions made when writing a single sentence, let alone the upper management that can barely make a decision more fine-grained than the title of the book and whether it should have one or two main characters.
At this point we are almost certainly talking past one another. I've never been at a company where management didn't have the final say. In your world where managers don't decide anything important, I guess they are just HR secretaries? They have 1:1s with people and try to figure out who needs to be replaced and who should be promoted? What is that like?
A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"
This is really the root of the problem. Implicit in all these titles ending in manager is decision making authority, and the selection process does not in practice produce better decision makers. A competent engineer experiencing a customer problem first hand is the smartest and best informed person in the room. They should be expected to make the best decisions about how to use their time and skills. But there is a charade that plays out involving * managers, who have been given decision making authority. They either agree ceremoniously or look stupid with little corrective consequence.
We potentially agree on quite a bit and maybe might not talk past each other.
With regards to our differences, I view software management more as a leadership role rather than as a decision making role. We won't quibble that leaders need to make important decisions, we both agree there. Yet, providing direction is different from deciding direction. That is my point, software managers are deciding neither "what" nor "how", and thus their role is (IMHO) primarily more leadership rather than decision making.
By one metric, I'd suggest software managers are most responsible for helping their team maximize the ratio of time spent focused on-task to the time spent dealing on noise. While that is an interesting metric, it's still hard to tease out the effects of organization and team structure from the role of just one person who is meant to largely coordinate (AKA: direct or lead) and enhance those networking effects.
My MO is deciding anything myself where I feel my chosen solution is Pareto better and force the PO to clarify/specify where customer feedback is contradictory or unclear.
I think this varies wildly from company to company, especially your experience in the first two paragraphs. I've worked at companies where what you're saying rings true (especially about "not building consensus"), and at companies where taking initiative is a hard requirement - written down in company documents - for any sort of advancement into the Senior Software Engineer & beyond levels.
"who told you to do this, where is the JIRA that described this work?"
My standard joke is: We must be doing incredibly well if you have time to ask me that. Ideally the standard joke is followed by a [long] list of things they should or could be working on and then I force the conversation into that direction. If they ever bring it up again I remind them that they had already mentioned it and change the topic to actual work again. I've had a good few burst out in laughter going though the process specially the 3rd or 4th time.
I definitely agree that it's not inherently doomed to failure, but I'm not sure the OP from the post would benefit from an external manager.
Fundamentally, small companies that accomplish things tend to have relatively strong cultures, and external managers (by definition) are not necessarily part of that culture.
I've seen an external manager cause loads of issues because of this, even when they come in with the best of intentions.
In smaller companies, you are almost always much better off promoting internally for a number of reasons. Firstly, it demonstrates (assuming that you make the right person the manager) that there's a path for people on the team to progress. Secondly, they are already aware of the actual problems with the company, and (importantly) the kinds of solutions that are acceptable.
I currently work for a small, fast-growing company and our external manager decided to rebuild a core system at the weekends and push it to prod. Now, the system is actually pretty good (I dislike it stylistically, but i have niche tastes).
However, what this person didn't consider (because they were new) that the org was not going to give much (if any) time to move stuff over to this new system. As a result, we're about 50% of the way done 18 months in, and in the interim, we've had to not do a bunch of stuff that would actually improve our product.
Like, I remember (and HN hate this company so it's unlikely to be listened to) when FB started getting really successful (2013-15), we ended up hiring a lot of Google/Amazon managers and leaders externally and probably through negligence, they ended up destroying a bunch of what made the culture great.
Hiring bad managers is much, much worse than no managers, but if you promote an IC then they have a valid stepdown path if it doesn't work, which an external manager is less likely to have (or indeed, accept).
And thus concludes my Ted Talk about avoiding external managers.
Also, if one of the individual engineers on the team has a desire to try management, took the training courses, has the support of the team, and believes he'll get a shot next time a manager is needed... and then you announce "Well, we couldn't find anyone internal for the job, so meet your new manager: the stranger we hired externally!" I guarantee that engineer will become instantly demoralized, checked out, and will likely quit soon. Source: My experience in my last three jobs.
Comments
But do those other engineers want to be managers? I've certainly picked up some of that work from time to time in my career, and yet if my boss told me, "congratulations, you're being promoted to manager!" I'd have to respond with, "congratulations, I quit."
Maybe they don't, but this is a good test for "qualified to be a decision maker". If other people want someone to help make decisions for them it's because they want the benefit of their prowess.
You could either embrace this as the start of the hierarchy everyone is apparently so desperate to create. Or you could ignore this signal in favor of handshakes, smiles, buzzwords, or however else you intend to pick a manager from your outside funnel.
Part of this reluctance is an aversion to the busy work that often comes with a manager title. Work that managers create for themselves and other managers to legitimize their roles, but which actually impedes progress, and annoys or alienates talent.
I really don't see managers as decision makers. They do help communicate strategic direction, but in terms of tactical decisions, they are too removed to really have valuable input.
OTOH, unless you are the team lead, the amount of bike shedding from simply taking initiative and just making a tactical decision can be overwhelming. It's framed as "not building consensus first."
A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"
Many orgs do not view engineers as decision makers, simply as do'ers, which really I think highlights how the role of a software engineer is just misunderstood. Software engineers are more like writers than they are like carpenters. Consider for example the number of decisions made when writing a single sentence, let alone the upper management that can barely make a decision more fine-grained than the title of the book and whether it should have one or two main characters.
At this point we are almost certainly talking past one another. I've never been at a company where management didn't have the final say. In your world where managers don't decide anything important, I guess they are just HR secretaries? They have 1:1s with people and try to figure out who needs to be replaced and who should be promoted? What is that like?
This is really the root of the problem. Implicit in all these titles ending in manager is decision making authority, and the selection process does not in practice produce better decision makers. A competent engineer experiencing a customer problem first hand is the smartest and best informed person in the room. They should be expected to make the best decisions about how to use their time and skills. But there is a charade that plays out involving * managers, who have been given decision making authority. They either agree ceremoniously or look stupid with little corrective consequence.
We potentially agree on quite a bit and maybe might not talk past each other.
With regards to our differences, I view software management more as a leadership role rather than as a decision making role. We won't quibble that leaders need to make important decisions, we both agree there. Yet, providing direction is different from deciding direction. That is my point, software managers are deciding neither "what" nor "how", and thus their role is (IMHO) primarily more leadership rather than decision making.
By one metric, I'd suggest software managers are most responsible for helping their team maximize the ratio of time spent focused on-task to the time spent dealing on noise. While that is an interesting metric, it's still hard to tease out the effects of organization and team structure from the role of just one person who is meant to largely coordinate (AKA: direct or lead) and enhance those networking effects.
My MO is deciding anything myself where I feel my chosen solution is Pareto better and force the PO to clarify/specify where customer feedback is contradictory or unclear.
I think this varies wildly from company to company, especially your experience in the first two paragraphs. I've worked at companies where what you're saying rings true (especially about "not building consensus"), and at companies where taking initiative is a hard requirement - written down in company documents - for any sort of advancement into the Senior Software Engineer & beyond levels.
My standard joke is: We must be doing incredibly well if you have time to ask me that. Ideally the standard joke is followed by a [long] list of things they should or could be working on and then I force the conversation into that direction. If they ever bring it up again I remind them that they had already mentioned it and change the topic to actual work again. I've had a good few burst out in laughter going though the process specially the 3rd or 4th time.
I do not agree with your premise that hiring a manager from outside of an organization is inherently doomed to failure.
I definitely agree that it's not inherently doomed to failure, but I'm not sure the OP from the post would benefit from an external manager.
Fundamentally, small companies that accomplish things tend to have relatively strong cultures, and external managers (by definition) are not necessarily part of that culture.
I've seen an external manager cause loads of issues because of this, even when they come in with the best of intentions.
In smaller companies, you are almost always much better off promoting internally for a number of reasons. Firstly, it demonstrates (assuming that you make the right person the manager) that there's a path for people on the team to progress. Secondly, they are already aware of the actual problems with the company, and (importantly) the kinds of solutions that are acceptable.
I currently work for a small, fast-growing company and our external manager decided to rebuild a core system at the weekends and push it to prod. Now, the system is actually pretty good (I dislike it stylistically, but i have niche tastes).
However, what this person didn't consider (because they were new) that the org was not going to give much (if any) time to move stuff over to this new system. As a result, we're about 50% of the way done 18 months in, and in the interim, we've had to not do a bunch of stuff that would actually improve our product.
Like, I remember (and HN hate this company so it's unlikely to be listened to) when FB started getting really successful (2013-15), we ended up hiring a lot of Google/Amazon managers and leaders externally and probably through negligence, they ended up destroying a bunch of what made the culture great.
Hiring bad managers is much, much worse than no managers, but if you promote an IC then they have a valid stepdown path if it doesn't work, which an external manager is less likely to have (or indeed, accept).
And thus concludes my Ted Talk about avoiding external managers.
Also, if one of the individual engineers on the team has a desire to try management, took the training courses, has the support of the team, and believes he'll get a shot next time a manager is needed... and then you announce "Well, we couldn't find anyone internal for the job, so meet your new manager: the stranger we hired externally!" I guarantee that engineer will become instantly demoralized, checked out, and will likely quit soon. Source: My experience in my last three jobs.
This was a pretty good Ted Talk!