Do you prefer your manager to be technical or non technical?
24 comments
> Having to constantly explain basic things gets tiring very quickly.
That's because they are a non-technical manager who doesn't trust you.
I think there are two archetypes that work on the technical vs non-technical dimension:
Good: Technical, but has actually done the work (or does it currently) and is able to. In software that means they can program, set stuff up, debug things. Will be more experienced and coach, or smoothly bridges the gap between social and technical challenges.
Bad: Technical, but only "high level" and can't do the nitty gritty work but will make bad technical decisions that pushes you into a corner. Will demand concrete technical solutions instead of stating goals.
Good: Non technical, but hands off and actually trusts experts. Knows people well and how to handle tricky situations. Keeps the BS away. Approaches projects with a calm, organized fashion. Tries to take good opportunities and doesn't cling to bad decisions.
Bad: Non technical, but will constantly demand explanations, 'sell' deadlines and deliverables before consulting workers. Demands specific solutions instead of stating problems clearly. Thinks primarily about cost and efficiency instead of value and growth.
That's because they are a non-technical manager who doesn't trust you.
I think there are two archetypes that work on the technical vs non-technical dimension:
Good: Technical, but has actually done the work (or does it currently) and is able to. In software that means they can program, set stuff up, debug things. Will be more experienced and coach, or smoothly bridges the gap between social and technical challenges.
Bad: Technical, but only "high level" and can't do the nitty gritty work but will make bad technical decisions that pushes you into a corner. Will demand concrete technical solutions instead of stating goals.
Good: Non technical, but hands off and actually trusts experts. Knows people well and how to handle tricky situations. Keeps the BS away. Approaches projects with a calm, organized fashion. Tries to take good opportunities and doesn't cling to bad decisions.
Bad: Non technical, but will constantly demand explanations, 'sell' deadlines and deliverables before consulting workers. Demands specific solutions instead of stating problems clearly. Thinks primarily about cost and efficiency instead of value and growth.
This is a great answer. I've had one great technical manager, one great non-technical manager, and two average to below average non-technical managers. The difference between the non-technical vs the technical is very well described here. The technical was great as well because they were curious about what I was working on and my solutions in a genuine way, and took an active role in my development.
Some of the worst managers I've met are non-tech and trusting. A red flag is someone who says "my team can do whatever you ask them to do," before consulting the team.
I had a very VERY short lived manager at one point that immediately agreed to a request from another manager that violated the laws of physics and said we could do it (SLO including FTL latency multiregion cloud related).
Sometimes I still think about this.
Sometimes I still think about this.
We need to distinguish between being trusting versus naive then.
I'm reminded of the scene from Into the Spiderverse.
Doc Ock: If we fire again this week, we could rupture the space-time continuum.
Kingpin: You got 24 hours.
I'm not sure if naivety is the best word. It's more like laziness that translates into blind trust. The manager doesn't manage, they just push the problem to someone else.
Doc Ock: If we fire again this week, we could rupture the space-time continuum.
Kingpin: You got 24 hours.
I'm not sure if naivety is the best word. It's more like laziness that translates into blind trust. The manager doesn't manage, they just push the problem to someone else.
"Bad: Technical" are basically managers with less than 3 yoe of experience as IC.
"Bad: Non technical" are basically micro-managers
Finding Good: Technical will always be easier to come by than Good: Non technical, since understanding what you are managing gives you a leg up.
Good: Non technical works if you already have a strong team of ICs. It will quickly fall apart if not.
"Bad: Non technical" are basically micro-managers
Finding Good: Technical will always be easier to come by than Good: Non technical, since understanding what you are managing gives you a leg up.
Good: Non technical works if you already have a strong team of ICs. It will quickly fall apart if not.
As you scale and become more experienced as a manager, it's extremely hard to impossible to maintain technical chops forever. The situation is that either you manage your team of 12 thoughtfully, spending time on team meetings, 1 on 1s, strategy planning and considerations no one else is focusing on, and reading and listening to people... or you're heads down and hands off because you're still coding or building and managing is a distraction.
Long term the latter doesn't scale. The CTO won't know all of what his direct knows as well as the directs of the directs. The CEO won't know all of what the CTO knows, plus the CFO and the CISO. Etc.
An architect building a new office building hasn't personally done what every sub contractor and specialist has done, and yet makes decisions of their directions.
A strong hands on technical manager who can mentor plus lead plus deal with external bureaucracy is as rare as such a person working 80 hour weeks is common.
It's also easier with smaller teams and leaner environments without a zillion meetings.
I'm a previously-technical, and now less so tech manager and that's my experience. It's a trade off in terms of time and investment in skills.
Not to mention the technology changes constantly, leading to more non work homework if you need to stay relevant.
Long term the latter doesn't scale. The CTO won't know all of what his direct knows as well as the directs of the directs. The CEO won't know all of what the CTO knows, plus the CFO and the CISO. Etc.
An architect building a new office building hasn't personally done what every sub contractor and specialist has done, and yet makes decisions of their directions.
A strong hands on technical manager who can mentor plus lead plus deal with external bureaucracy is as rare as such a person working 80 hour weeks is common.
It's also easier with smaller teams and leaner environments without a zillion meetings.
I'm a previously-technical, and now less so tech manager and that's my experience. It's a trade off in terms of time and investment in skills.
Not to mention the technology changes constantly, leading to more non work homework if you need to stay relevant.
I agree fully, though I’d like to add a layer of nuance.
The best engineering leaders I’ve encountered have been hands-off (as you said, at a certain point it’s nigh impossible to scale otherwise) However, they’ve uniformly retained engineering mindsets, and have great spidey senses for when things are being overengineered, or when complexity is being underestimated, and much more. They all have also demonstrated the ability to drill in deep when the situation arises, and tend to have strong understanding of high level architectures and systems. I’ve had “pure people managers” who were non-technical and ended up having myriad weaknesses. The opposite has been even worse. But the best know exactly when and how to put on both their people and technical hats.
The best engineering leaders I’ve encountered have been hands-off (as you said, at a certain point it’s nigh impossible to scale otherwise) However, they’ve uniformly retained engineering mindsets, and have great spidey senses for when things are being overengineered, or when complexity is being underestimated, and much more. They all have also demonstrated the ability to drill in deep when the situation arises, and tend to have strong understanding of high level architectures and systems. I’ve had “pure people managers” who were non-technical and ended up having myriad weaknesses. The opposite has been even worse. But the best know exactly when and how to put on both their people and technical hats.
To your point maybe one key is if someone has had years of past engineering experience with wisdom that has translated into leadership skills.
I want a manager that can speak to technical matters (ie, they're not a complete "dunce" technically), but I want even more a manager who can keep team cohesion going - someone who can encourage everyone to do their best (whatever "best" is for each person, and in whatever manner "best" is for each)
For some people, it's speaking money
For others, it's speaking tech [enough] to understand frustrations the team (or team member) is going through
For others, it's conveying the business reason(s) behind [non]technical decisions
Etc
For some people, it's speaking money
For others, it's speaking tech [enough] to understand frustrations the team (or team member) is going through
For others, it's conveying the business reason(s) behind [non]technical decisions
Etc
Technical, but not in the weeds. I'd rather have non-technical than a technical manager who is always diving way too deep for their role and derailing every call.
I don't care how technical my manager is. As long as they understand what I'm doing, back me in justifying why I'm doing it, are willing to listen when I have problems, can give me some career guidance, can give me direct feedback when things are going poorly, and can explain why we're doing things that seem out of plan, I'm happy.
None of these things need technical skills. In fact, if I can't explain what I'm doing without getting deeply technical, then I question whether I'm doing the right thing _or_ if how I'm doing it needs to be simplified.
In my experience, bad managers will hide negative feedback to avoid upsetting you, cow-tow to their management when they have grievances with you or want to waste your time, will phone in 1x1s and will generally just be a roadblock.
One of the best managers I ever had was non-technical. She was very good at building people. Rare skill.
None of these things need technical skills. In fact, if I can't explain what I'm doing without getting deeply technical, then I question whether I'm doing the right thing _or_ if how I'm doing it needs to be simplified.
In my experience, bad managers will hide negative feedback to avoid upsetting you, cow-tow to their management when they have grievances with you or want to waste your time, will phone in 1x1s and will generally just be a roadblock.
One of the best managers I ever had was non-technical. She was very good at building people. Rare skill.
I prefer non-technical. I find most managers are just not very good, such that I as a developer have to manage them.
And I find it easier to manage a non-technical manager versus a technical manager.
And I find it easier to manage a non-technical manager versus a technical manager.
I came here to say this.
A technical manager has also the downsides of a developer like bad estimations, i.e. "This would just take me 1 day".
Also, hard to find a good technical person that has good people skills.
A technical manager has also the downsides of a developer like bad estimations, i.e. "This would just take me 1 day".
Also, hard to find a good technical person that has good people skills.
Why not just change companies and interview any prospective boss similar to how they interview you.
It can be hard to find a good fit, but its something only you can do.
I’d say once you have a good manager or executive it pays dividends not just in work life balance but the desire to explore other options (eg always looking for more money/etc) fades away.
I’d say once you have a good manager or executive it pays dividends not just in work life balance but the desire to explore other options (eg always looking for more money/etc) fades away.
Is this a biased audience given that it's HN?
In any case, my personal answer is definitely technical but with caveats that I won't repeat as others have made solid arguments and the additional caveat that I would prefer a technical vs. non-technical lead any day.
This is partly based on experience and partly based on my personal feelings. I feel more inspired by leaders who have been in the trenches before. Also, in my personal experience (emphasis on personal) I've noticed that non-technical leaders tend to have a chip on their shoulder about technical issues which leads them to either 1) devalue (often publicly through statements) technical ability or 2) take any criticism or negative feedback personally (in some cases, HR have gotten involved as there were accusations of *-ism).
In any case, my personal answer is definitely technical but with caveats that I won't repeat as others have made solid arguments and the additional caveat that I would prefer a technical vs. non-technical lead any day.
This is partly based on experience and partly based on my personal feelings. I feel more inspired by leaders who have been in the trenches before. Also, in my personal experience (emphasis on personal) I've noticed that non-technical leaders tend to have a chip on their shoulder about technical issues which leads them to either 1) devalue (often publicly through statements) technical ability or 2) take any criticism or negative feedback personally (in some cases, HR have gotten involved as there were accusations of *-ism).
In general I prefer technical managers because it's easier to communicate, but I will say that the best manager I ever had (by far) was non-technical.
His superpower? He listened. All the time. When he didn't fully understand something, he would ask for an explanation. That forced me to pause for a moment, reevaluate why I'm doing something a certain way, and then explain it to him -- in a doc, in graphics, in a presentation, whatever was required. Yes, that took a bit of time (a few hours here and there), but in the end it made our team much stronger because everyone -- devs, designers, managers, marketers -- began to better understand the value of why we're doing things a certain way. It made our architecture simpler and clearer too, because those pauses made us reevaluate and optimize our designs, if only to be able to more easily explain them.
Then, once he understood a concept, he would be able to translate it into business-speak to sell it to the higher-ups and other departments. That's the part of the job I would never want to do -- engage in corporate BSing -- but he was good at that, and didn't mind it, and was able to clearly defend our choices to anyone who asked.
Over time I started to think of my manager not as "the guy who tells me what to do" but "the guy who advocates for us against other departments". Interpersonal communication is a huge (and difficult) skillset that many devs undervalue, but when speaking to non-technical audiences (like much of management, if you're not in a pure-tech company), being able to translate effectively is a big deal.
If your manager is super technical but not a good communicator, a lot of your efforts will get roadblocked or overridden by other priorities because your manager wasn't able to clearly communicate their value.
If you can have both, great! That's the best of both worlds. If I were forced to choose, though, I'd choose the better communicator over the more technically skilled, every time.
Skills and technical complexity can be taught to anyone who's reasonably competent and intelligent. It's much harder to teach them effective interpersonal communication skills, IMO.
His superpower? He listened. All the time. When he didn't fully understand something, he would ask for an explanation. That forced me to pause for a moment, reevaluate why I'm doing something a certain way, and then explain it to him -- in a doc, in graphics, in a presentation, whatever was required. Yes, that took a bit of time (a few hours here and there), but in the end it made our team much stronger because everyone -- devs, designers, managers, marketers -- began to better understand the value of why we're doing things a certain way. It made our architecture simpler and clearer too, because those pauses made us reevaluate and optimize our designs, if only to be able to more easily explain them.
Then, once he understood a concept, he would be able to translate it into business-speak to sell it to the higher-ups and other departments. That's the part of the job I would never want to do -- engage in corporate BSing -- but he was good at that, and didn't mind it, and was able to clearly defend our choices to anyone who asked.
Over time I started to think of my manager not as "the guy who tells me what to do" but "the guy who advocates for us against other departments". Interpersonal communication is a huge (and difficult) skillset that many devs undervalue, but when speaking to non-technical audiences (like much of management, if you're not in a pure-tech company), being able to translate effectively is a big deal.
If your manager is super technical but not a good communicator, a lot of your efforts will get roadblocked or overridden by other priorities because your manager wasn't able to clearly communicate their value.
If you can have both, great! That's the best of both worlds. If I were forced to choose, though, I'd choose the better communicator over the more technically skilled, every time.
Skills and technical complexity can be taught to anyone who's reasonably competent and intelligent. It's much harder to teach them effective interpersonal communication skills, IMO.
I still can't decide.
Anecdotally the very best and the very worst managers I had were not technical. Instead my technical managers, think ex-engineers, were on average from mediocre (new to the role) to good (experienced).
I built a mental model that the difference between non technical EMs and technical ones is that the distribution of quality is broader for the former. I suspect people skills is the real leverage.
Anyhow engineers have little influence on deciding which kind of manager they are gonna get, so it's better to focus on what we can control and learn the secret art of how to manage your manager.
Anecdotally the very best and the very worst managers I had were not technical. Instead my technical managers, think ex-engineers, were on average from mediocre (new to the role) to good (experienced).
I built a mental model that the difference between non technical EMs and technical ones is that the distribution of quality is broader for the former. I suspect people skills is the real leverage.
Anyhow engineers have little influence on deciding which kind of manager they are gonna get, so it's better to focus on what we can control and learn the secret art of how to manage your manager.
Ask a bunch of technical people this question and you will be shocked to hear that most prefer technical managers. That’s due at least in part to people placing the highest value on things they are good at.
The worst manager I ever had was super technical but profoundly unable to relate to people. What I want most in a manager is (a) management skill, and (b) empathy.
It would be nice also if they’re technical, but a good manager can work around that limitation. A bad manager can’t work around whatever their limitations are. And everyone has limitations.
The worst manager I ever had was super technical but profoundly unable to relate to people. What I want most in a manager is (a) management skill, and (b) empathy.
It would be nice also if they’re technical, but a good manager can work around that limitation. A bad manager can’t work around whatever their limitations are. And everyone has limitations.
I've only had technical managers for over a decade.
However, these were technical people who had done the same job at a more junior level. They knew enough to know my job, but not enough to know the exact details of everything I was doing.
Now that you ask, I'm not sure any of that matters.
The best qualities a manager can have are to get along with you, trust you, support your growth, have good ideas, and challenge you to be better. None of those are technical skills.
However, these were technical people who had done the same job at a more junior level. They knew enough to know my job, but not enough to know the exact details of everything I was doing.
Now that you ask, I'm not sure any of that matters.
The best qualities a manager can have are to get along with you, trust you, support your growth, have good ideas, and challenge you to be better. None of those are technical skills.
A technical person with good people skills is the solution. The combi is not rare. It is not payed properly, but defineyely not rare.
I had many non technical managers stuck in their ideas from '70s or from condoms production lines. Non technical managers should either adapt to the industry's dynamics or go elsewhere. They burn a lot of time of the team.
But an unexperienced team does require a manager, of any kind.
I had many non technical managers stuck in their ideas from '70s or from condoms production lines. Non technical managers should either adapt to the industry's dynamics or go elsewhere. They burn a lot of time of the team.
But an unexperienced team does require a manager, of any kind.
You have a bad manager who happened to be non-technical. I've had plenty of bad technical managers too.
A manager's job is not to be more technical that you, it's to manage multiple parts of a project and it's people. Of course they know what they are talking about- but often they have the people skills to get past the interviews.
A manager's job is not to be more technical that you, it's to manage multiple parts of a project and it's people. Of course they know what they are talking about- but often they have the people skills to get past the interviews.
It is generally a positive that a manager understands what and how to do the things that the people they manage do, however it is not a requirement for a good manager. To an extent, a manager will never fully be versed in everything that their direct reports do, however, a good manager knows the limits and trusts their employees to make the right call.
It depends on the level of narcicism. If they're nontechnical but can read stuff like blogs and 1 pagers and act rational, great. If they use being "nontechnical" as an excuse to misunderstand on purpose, they tend to be insufferable narcissists to avoid at all costs.
Technical. The analogy I usually give is: would you take an mba and put them in charge of a platoon of marines? Why not? Because they don’t know which end the bullet comes out of and would be worse than useless.
Ok, so then why put them in charge of a software company?
Ok, so then why put them in charge of a software company?
It's a funny Dilbert-esque visual to think about some cocky MBA who doesn't know about guns trying to guide a platoon of hard-nosed marines, but your analogy doesn't particularly work for me because of one key difference. Weapons are physical objects. This physicality of real-world objects is key IMO. Learning the basics of how physical objects work can be taught to almost anybody of even low intelligence. We prove this in times of war by ramping up training very quickly so basically anybody above room-temperature IQ can be quickly trained in various guns and equipment. Even if you assume that an MBA doesn't know what end of a mortar shoots out stuff on day 1, this is the kind of thing that anybody can learn.
Software and Internet stuff is much harder for the layperson to learn because so much of this stuff is abstract. There's no real world equivalent for much of what we talk about and there's no Internet you can physically hold in your hand and easily create a mental model for.
Personally speaking, I'd say that technical managers who have the capacity to code are ideal, but I'm fine with them as long as they understand the domain. If I'm talking about some potential issues with some HTTP request in a call, I don't care if a manager doesn't understand the nitty gritty details about HTTP headers, but they should understand what a request is and at least have a basic understanding of what is going on and how to explain it credibly to whoever they need to to avoid wasting my time on 13 separate meetings with different departments and stakes holders to explain the same issue over and over again.
Software and Internet stuff is much harder for the layperson to learn because so much of this stuff is abstract. There's no real world equivalent for much of what we talk about and there's no Internet you can physically hold in your hand and easily create a mental model for.
Personally speaking, I'd say that technical managers who have the capacity to code are ideal, but I'm fine with them as long as they understand the domain. If I'm talking about some potential issues with some HTTP request in a call, I don't care if a manager doesn't understand the nitty gritty details about HTTP headers, but they should understand what a request is and at least have a basic understanding of what is going on and how to explain it credibly to whoever they need to to avoid wasting my time on 13 separate meetings with different departments and stakes holders to explain the same issue over and over again.
5echnical enough that we can have technical discussions when needed, but not too technical to think they can do my job instead (and if they can, then stop being my manager and join me as my peer).
Why would you expect that just because someone can do your job, they should join you as your peer? That might be true for more junior folks - they have proven they are on at least the same level, emphasis on at least. What's wrong with more senior folks, who may also have skillets you don't, still retaining their tech chops?
I have no problem with my manager being more technical than me or being better at what I do, as long as they don't try to do my job instead of theirs.
If they are actively trying to do my job then by all means stop being my manager and become my peer instead.
If they are actively trying to do my job then by all means stop being my manager and become my peer instead.
This separation is artificial.
Manager is either smart or not.
Guess which one I prefer to have.
Manager is either smart or not.
Guess which one I prefer to have.
Imagine your a team of doctors conducting a surgery but being led by an MBA in the operating room. What do you think is happening?
Honestly, the best approach might be to just elect the manager from within the team.
Dilbert Principle: companies promote incompetent employees to management to get them out of the workflow.
Technical but clear about their job, which is management and no longer hands-on.
technical enough that we can have technical discussions when needed, but not too technical to think they can do my job (and if you can than stop being a manager and join me as my peer).
Having been in software development for nearly 20 years, it really does depend on the manager, but I would say the preference is option A with very large asterisks. My ideal would be what I would consider "non-technical" manager in role and skills, but have perhaps had direct technical experience X years prior, minimally a solid working understanding of the development/engineering side of the house, even if he/she is not a coder.
I would much rather have a manager that understands the domain of the business and have some technical background/domain knowledge so that they understand the conversation mostly, than having one thinking they are "in charge" of the technical solution and team decisions. Nothing is more annoying than a technical manager to dictates down very specific architecture/stack/implementation decisions down to a technical team [specifically one of senior engineers, specialists, and trained architects]. Sure you can get this with both A & B, but B's trend more over-involved.
A non-technical manager, however, should come with other skills often missing in strictly "technical" ones... specifically the management/strategic ones. Too often you have a manager who was just a technical lead and jumped up to a management role without learning management, perhaps for salary/career development/etc. In these cases, even if they don't dominate the technical discussion as suggested above, they can lack key project/roadmap/strategic skills and experience which basically make them more of a "middle-man" than a manager.
A well-functioning development team or set of teams should more or less be able to make all the needed technical decisions and advise up to the manager and CTO-level roles not only what but why. The CTO and development-side management (again, I am arguing technical knowledgable, but non-tech) should be taking the expert advise from their developers and doing the big-picture strategic stuff. Likewise, they should be bring "problems" (feature ideas, needs that a customer or market is not being used, pain points, long term goals) to the developers for vetting, solution gathering, and implementation advise. As such there is a two way dialog. The management level gathers "outside" data and requirements and informs strategy and goals and the development team provides implementation, architecture, solution advise [or alternatives, as factors such as recurring costs or time to implement all play roles on the business end], and, well, the actual code/solution. The development team is able to focus on their domain/codebase/etc. without having to deal much with the "outside world."
Mind you, I am talking about manager and not "team lead". Leads should always be senior and know at least one software domain to an expert level [i.e. if a web application team, the lead can be front end, back end, or ops, but should know enough of all three domains, even if expert in only one]. Leads should still have a hand in code. Some orgs have leads to help bridge light management function and development expertise, but it depends on the org.
So going back to OPs experience, the non-technical manager is the one lacking. They should have more understanding of what the engineers are talking about.
I would much rather have a manager that understands the domain of the business and have some technical background/domain knowledge so that they understand the conversation mostly, than having one thinking they are "in charge" of the technical solution and team decisions. Nothing is more annoying than a technical manager to dictates down very specific architecture/stack/implementation decisions down to a technical team [specifically one of senior engineers, specialists, and trained architects]. Sure you can get this with both A & B, but B's trend more over-involved.
A non-technical manager, however, should come with other skills often missing in strictly "technical" ones... specifically the management/strategic ones. Too often you have a manager who was just a technical lead and jumped up to a management role without learning management, perhaps for salary/career development/etc. In these cases, even if they don't dominate the technical discussion as suggested above, they can lack key project/roadmap/strategic skills and experience which basically make them more of a "middle-man" than a manager.
A well-functioning development team or set of teams should more or less be able to make all the needed technical decisions and advise up to the manager and CTO-level roles not only what but why. The CTO and development-side management (again, I am arguing technical knowledgable, but non-tech) should be taking the expert advise from their developers and doing the big-picture strategic stuff. Likewise, they should be bring "problems" (feature ideas, needs that a customer or market is not being used, pain points, long term goals) to the developers for vetting, solution gathering, and implementation advise. As such there is a two way dialog. The management level gathers "outside" data and requirements and informs strategy and goals and the development team provides implementation, architecture, solution advise [or alternatives, as factors such as recurring costs or time to implement all play roles on the business end], and, well, the actual code/solution. The development team is able to focus on their domain/codebase/etc. without having to deal much with the "outside world."
Mind you, I am talking about manager and not "team lead". Leads should always be senior and know at least one software domain to an expert level [i.e. if a web application team, the lead can be front end, back end, or ops, but should know enough of all three domains, even if expert in only one]. Leads should still have a hand in code. Some orgs have leads to help bridge light management function and development expertise, but it depends on the org.
So going back to OPs experience, the non-technical manager is the one lacking. They should have more understanding of what the engineers are talking about.
I don't understand how a non technical person can "lead" a technical team. How can they even help the team because they don't even understand basic concepts. How are these people getting these technical jobs is beyond me. I keep running into these "engineering managers" who know nothing about engineering and I'm sick and tired of it. I just want a technical manager who is on the same level as the technical people on the team or at least understands what the engineers are talking about during meetings.