Legitimately confused by this. Is it really common that truly non-technical, as in can't write code at all, people are managing Software Engineering teams? I've certainly never seen it, at least until you get to Senior Exec levels of leadership. I've only been in the industry for <10 yrs but I still find it hard to believe it's that common.
Sure, I work at one. But my manager is a former tech lead/architect who writes code everyday and he reports to a former Startup CTO with a CS Degree from UIUC. Are English Majors with no tech chops seriously managing engineers in 2020?
Yes, and there the software managers normally report to non software executives. Engineers reporting to non software managers who are not at a director or VP level is a bad idea.
Writing code != understanding computer science. I know plenty of people who had coded some linear procedural code in matlab for school who I would absolutely not say that they 'understand coding'. I would argue that being CS literate is where you have a logical framework of how code work together to create software - knowing the general idea of encapsulation etc.
Technical managers at the front level get 'cut off' when a reporting chain immediately above consisted of someone who are truly non-technical. You can have 3 software engineering teams each under technical managers, but then they all report to an MBA grad with no technical history at all. Which anecdotally resulted in some decision making that I would characterize as strange from my software engineering perspective.
"practical understanding of software systems" != "understanding of computer since"
Through having done CS helps a lot in being flexible enough in how you thing about (technical) things. (Disclaimer: The last thing can be easily misunderstood, the thing is when you do CS you have to do a lot of brain gymnastic about all kinds of things like e.g. that one thing can be seen as two seemingly unrelated things but still be the same in a given context, but not in a other seemingly nearly equivalent context.)
- The manager did just ended up as a proxy between higher management which create friction. (E.g. in aspects like what features are viable to add in this year and which are not.)
- The manager lost practically all authority (and later one all trust).
Generally a really annoying situation not benefiting anyone. Through then a lot of other things went wrong too in that company.
I agree with the gist of the article. The point is not to throw manager into actual coding task, but for them to have a background understanding of how everything works either through formerly being a software engineer or $(multiple ways one can educate oneself on the principals of computer science).
My anecdotal evidence have strongly pointed that for a software project, managers that have an understanding of computer science have a strong edge on communication and decision making.
Managers should be technical enough to understand what is going on, but claiming that an effective manager needs to be coding 80% of their time (as the article says) is idiotic. Why be a manager at all at that point?
I've personally had much worse experiences with managers who wanted to micromanage every technical decision and every line of code vs. those who just trusted their team with it and focused on people management, clearing organizational blockers, roadmapping, project management, communication to executives and other stakeholders, shielding us from company politics and lots more.
I don't think a manager should be coding at all, but Unless they did enginnering work in the past, it is hard to see them providing effective management.
If a manager trusts their reports, they can manage those reports effectively, because they are getting accurate data about what their people are doing. That trust (also known as being professional) short circuits the need for the manager to understand the work being done.
> If a manager trusts their reports, they can manage those reports effectively, because they are getting accurate data about what their people are doing. That trust (also known as being professional) short circuits the need for the manager to understand the work being done.
That works in the happy case. But lots of things work in the happy case.
The problems happen when ICs do things that are good for themselves, but not good for the company. One obvious example of this is resume-driven development.
>If a manager trusts their reports, they can manage those reports effectively, because they are getting accurate data about what their people are doing
This statement is nonsense. How does simply trusting your reports guarantee anything, let alone that you're getting accurate data about what your people are doing? How would you be the wiser if you didn't have a fundamental understanding of the work being done?
>That trust (also known as being professional) short circuits the need for the manager to understand the work being done.
Again, nonsense.
Your statement is akin to saying that being a successful basketball coach doesn't require knowledge of basketball, but rather just simply having to trust in your basketball players. Yet show me how many successful basketball coaches are there that never played the game, or was around the game to develop a fundamental understanding of the game.
Or hell, put it this way: if trust short circuits any need for management to have any understanding, then anyone could be a successful manager. I'm sure my dog trusts me and most folk, I guess by your reasoning, he could be the manager of any department in any company!
Yeah, nonsense. You need some fundamental understanding of what you're managing otherwise you're a bad manager, or simply a figure head...
> coding, architecting, or doing technical work that requires engineering prowess.
As a software engineer, I don't even spend 80% of the time working coding, in fact it's more like 30%. But I do spend almost 100% of the time doing the stated things above.
However, I do agree with you (mostly). My position is that having an understanding of computer science make them much more efficient in the activities you described, some of which falls into the stated camp. Micromanagement is universally regarded as bad.
I think you have a point. But should making decision that require an intimate understanding of the technical stack be part of those activities? Should drafting new features be considered under architecting? I understand that my managers are heavily engaged in these activities and their decisions are challenged by very technically minded people before they are put to work.
New feature requests are certainly within a manager’s purview, but designing how those features are implemented is not - that’s your engineer or architects.
Of course, if your organization expects a manager to also be a tech lead, that’s something else entirely (and not common in most non-startup companies).
Fair point, but there's just no way all the management work fits in 20% of one's time unless they are managing like 2 people in a very narrow problem space.
I would say absolutely not. The habit of promoting competent technical people into management makes no sense to me, there is no reason to think a good coder would make a good manager. In fact it's probably the opposite case and the 10x type coders are probably a bit spectrum-y and would have real challenges managing people.
No, but IMO they should be one of the more technically competent people. Managing is not a full-time job, at least for a good manager its not a full time job.
Potentially, managing isn't a full-time-job, full-time. There are management moments that can easily consume you for weeks/months, and if the manager should have been coding also, then the timeline is ruined. If the manager has slack, then the team can add staff as needed. Having a manager who is flat-out is bad - it slows decisions, introduces blocking functions everywhere, and ultimately makes things worse.
I think you're underestimating how much work there is at the management level, especially in larger organizations. When management is doing their job, it won't be visible to you or your team. Things will just "align", and work well - but if things are moving smoothly in an organization with multiple teams, your management is working well.
There is a lot of systems thinking required in managing team structures, interfaces between those teams, managing communication between teams, hiring, setting technology standards & architecture, and so on (review the rest of this thread).
I do agree with your thesis though - a manager should be highly technical. I just don't think you can depend on their contribution to features & deliverables. Not because the work is "below" them, but because Engineering Management is a support role and should NOT need to choose between an IC-type task and helping unblock/support a member of their team due to a deadline :)
Hard disagree. Some of the best managers I've had are non-coders. I think a technical manager needs to be able to understand technical concepts at a high level, but actually writing code? Nah.
(Some of the worst managers I've had, contrariwise, were people who started as coders and kept trying to work their decades-old knowledge into conversations. No, this service didn't "ABEND," thanks.)
As a kind-of technical person (tech degree with limited professional application), I think you're exactly right. After going tech role > non-tech role > non-tech-but-managing-tech role, I found it was often most valuable for me to stay at a buzzword level. My team was always happiest when I could take their mostly-natural output and keep the monkeys off their back.
I have been thinking about something else. What is the exact function of a manager other than the annual reviews and hiring? I would like to ask the managers here, what does your day to day look like? How involved are you in the technical things your team does?
Author here: this is something I wonder often. In companies I've worked at that had non-technical leadership in the engineering department I'm suspicious that they just played Bloons TD 4 all day. They certainly never seemed to have anything to do other than hire, fire, and go to meetings to have things explained to them.
That's not it at all - a year ago, we actually defined a new strategic initiative to migrate the legacy userbase to BTD5, and the CEO herself gets regular readouts.
In my experience: communication. It's the manager's job to keep the big picture in mind: how is this team's output impacting major org goals?
If a manager doesn't have the story and line of communication set up (through his Director, etc.), the engineering team could prove P=NP; nobody would notice or care.
It's an incredibly busy position if you're doing it right! I've had development teams of 4 - 20 reporting to me, and I think my responsibilities have generally included:
- Being the point of contact between Development and the rest of the organization, fielding questions about what can and can't be done, plus t-shirt sizing on effort
- Keeping tooling and technology unified (not ending up with one project each using Vue.js, React, Ember, Angular...)
- Keeping up standards (around code reviews, documentation, testing and alerts, end user and developer training)
- Thinking long term about how features, services and tools being built today can be re-used tomorrow
- Decisions about budgets and how to approach a project (use internal people or outsource to a vendor; field RFP responses; negotiate and get paperwork signed)
A lot of communication (inter-team and intra-team), budget work and "architecting" stuff is a reasonable summary, I think.
Aligning with product to build the right things on a schedule everyone can live with that supports the inflow revenue via sales deals. Lots of backlog grooming, coordinating with other teams on their dependencies for the team (including devOps procedures and their shared libraries, new core libraries, new infrastructure, new cloud-native technologies we can use). Ensuring that what the team builds makes sense in the context of the whole company (alignment). Reporting up weekly metrics that are translated and normalized for the whole org across all teams in general (things like scrum/product team efficiency), following released product dependencies, writing change logs, release notes. Testing out APIs (which is sometimes like a variety of program management stuff at times). Learning all the black boxes of the system you're building and also all the ones you interface with, or might interface with. Then all the personnel stuff, the hiring, the care and feeding of the team, the one-on-ones, the hiring, the firing. Attending architectural discussion meetings for your own team, but as well as others. Working with MSPs on outsourced infrastructure, costs, some budgeting. Being accountable when a project goes sideways, and coming up with ways to try and get things back on track. Finding resources at the company to help out with something that might be in a gray area that's not my teams responsibility, but something we need, but is something that we're not experts in....
I still try to code a couple hours/week, but it's mostly around the undesirable stuff, or tooling (like CLI-stuff) to facilitate efficiency, generate metrics, help me play with the platform in a constructive way that facilitates my knowledge, etc...
To answer this slightly evasively, the biggest responsibility of a manager is to handle any day-to-day situation that isn't on anyone's job description. If something isn't anyone else's problem, you make it your problem and figure out how to deal with it. Why is a project behind schedule? Why aren't these two engineers/teams/divisions talking to each other? Why is there an uptick of bugs in recent releases? How do you prepare your organization to respond to service outages or security breaches?
The ability to recognize and deal with such unknowns is the most useful skill for a manager.
Management feels low value sometimes - it's hard to quantify your contribution. At first, I felt a lot of imposture syndrome and wondered if management could be automated. Now I know soooo differently.
Having worked as a manager for a year now, I can say:
It's way busier than you know!
There's a lot of work that happens behind the scenes to keep everything going. The better your manager is, the more invisible this work will seem to the team.
I think this is sort of like asking: what does a coach even do in sportsball? They're not a player, why not just have the team do their own thing?
It's a different layer of the system that requires a lot of systems thinking and people skills. Here is a list of how I spend my time:
- Making sure the right people have the right opportunities to solve the right problems
- Coaching individuals on my team on career development
- Helping to define organizational topology/structure and interfaces between teams & roles
- Manage expectations of those outside the dev team
- Proposing & maintaining process documentation
- Helping define organization culture & maintain it
- Hiring & Interviewing
- Architecture, tech debt, system vision, and helping the tech leads make the business case
- Facilitating communication between teams & acting as a shield for my team, so that they can maintain focus
And then there are things that aren't officially my responsibility, but I end up doing because I do what's needed:
- Jump in to help facilitate the team through an incident
- Act as scrum master / agile ceremony facilitator
- Produce Roadmaps & help define work/user stories when there is no Project/Product Manager / Business Analyst available
- Troubleshoot production issues
And I know there is so much more. To be honest, I would NOT have enough time to do everything if I spent 80% of my time coding. I'm lucky to get 5-20% of my time coding in!
I think the original poster should try Engineering Management for a while to see how busy they get with non-coding tasks.
Competencies you require to be an Engineering Manager:
Attitude is key here. My manager hasn't written non-trivial code in ages, but is deferential to my team when we provide estimates around how difficult something will be to implement, or how long it will take.
> Contrast the idea of a competent boss with the all-too-familiar experience of going to a non-technical middle-management type with an engineering problem, only to be stuck in a teaching session because the boss has never heard of a pub-sub system.
Since we're being reductive, why not posit that if you can't explain your systems to someone who doesn't write code, you shouldn't be building such systems?
>Since we're being reductive, why not posit that if you can't explain your systems to someone who doesn't write code, you shouldn't be building such systems?
If we really want to be reductive, then there's no reason to hire a manager that shares a language with their subordinates, because if you can't teach English to someone who hasn't learned it, what business do you have talking? Clearly, this is absurd, which means there must have been some reasonable grey areas that got left behind along the way...
I've only experienced a non-technical manager once - maybe this more common in older, more traditional companies.
I don't agree that a manager should spend 80% of their time coding, though. Maybe for smaller teams at early stage startups. But for even a team of 4-5, there are typically things they should be doing that are a better use of their time. It helps to code part of the time (maybe 20%) to understand the codebase, your level of technical debt, and proposals from engineers, but coding can be a trap that keeps you from doing what you need to do to enable your team.
In a worse case, technical managers can become micromanagers, and their opinions can have so much outsized influence that they lead to bad decisions.
I don't know about this. For me it always boils down to "it depends". I've seen situations unfold where a non-technical manager steps into a technical clusterfuck and promptly sorts out the mess in such a way that makes everyone happy.
I've found that simply by being an expert in some area, it can be extremely difficult to let certain things go and refocus on other objectives.
For me, there is definitely some yin-yang balance between the technology and business evangelism. Having 2 different humans with 2 wildly different perspectives many times yields a far better result than 2 different humans with 1 unified perspective.
You're correct, but I think the other argument is correct as well. I've seen teams where a manager is so technically incompetent as to be useless in their role. I've also seen teams where the developers were caught in technical minutiae while not contributing actual business value. I don't know if there's a cut-and-dried answer here.
One other way I look at this is as a balance of forces between technology and business. The developers are delegates to the technology while managers are delegates to the business. Assuming they can both arrive at some common middle ground, then you should have something viable to work with.
Sometimes I have to stop my other developers from getting upset with project managers when they are having bad days. If your managers are unhappy, it's very likely that the customer is unhappy as well. Developers should use this as a signal that they may want to re-prioritize efforts or schedule deep-dive meetings with their managers to sort out customer & business concerns.
The exact same idea applies to the technology. If the developers are in a bad mood, its quite likely that they are struggling with some abstract technological foe such as a legacy code base or broken devops process. Managers should recognize this as an opportunity to pause the process and try to allow room for the developers to work through whatever technical difficulties they are having.
If you have this perspective where everyone involved is a delegate to some other ultimate authority, you may develop a greater sense of empathy for your fellow human.
I agree, it mostly boils down to "human" or organizational problems. Technology or code problems aren't stressful in the absence of stress from the organization (time pressure / higher expectations than the team can deliver, etc).
Alternative POV: if they're not an engineer, then they NEED to be good at something else. I can imagine a situation in which a really excellent, organized, project manager with excellent ability to run interference with other teams/management was a valuable manager. This seems that the argument is more like, "Managers who do not code should not pretend they know how to code". Maybe, in that situation developers should look for technical review / help from their peers on the team?
I believe the author of the article is confusing "manager" and "tech lead/senior developer". I think the author has projected things they think are important in a manager onto the roll and those things probably don't align with what senior stakeholders think are important.
I would certainly expect the technical lead to do a good amount of coding in addition to design and mentoring, but expecting the CTO to code as the article suggests seems wrong. I guess this might be true at a 25 person startup, but I think this is an unrealistic requirement for larger organizations.
By a similar argument, would the COO be reasonably expected to work on the assembly line and repair hvac on a regular basis? Again, perhaps at a company of 25 but seemingly (to me at least) absurd at a larger company.
I'm certainly blurring the lines a bit, but I would argue that in most cases there isn't a need for both. The tech lead can be the "manager".
"Managing people" isn't a full time job in most cases. It all depends on how the organization is structured and how many non-technical tasks are being assigned to the "manager". Sometimes a manager is responsible for product, marketing, or HR tasks and all that will be dependent on the company in question.
A managers job isn’t necessarily to manage people but outcomes. People are essential for that, of course, but there’s often a lot of other moving parts to it that warrant a full time manager. The problem is often that building a good management structure is not only extremely difficult but also exceedingly rare, meaning many of us have either worked with bad managers or with managers that were poorly equipped to do their jobs effectively.
To echo what lanecwagner said, this can be a single role. I'm a Team Lead at my current employer. My job involves coding, being the Tech Lead, _and_ managing the (small) team as a people manager.
In software, I think that there is a qualitative difference between managers who have programmed- at any level of experience, even if it was a long time ago- and those who have not. Some exposure gives them a more realistic notion of what is hard, what is easy, and what is bullshit.
Beyond this, programming skills and specific technical knowledge can be useful as a manager, but I'm dubious that they are as essential as this article implies.
I further imagine that a similar pattern holds for other technical fields- you need some basic grounding, but do not need to be a technical expert to manage.
I find it really rare to find managers who regularly code. Even if they once coded, after a year of two of not coding and they've lost all context and familiarly with the codebase or tooling that they probably shouldn't be coding anyway. Managers should be technically competent but largely be neutral arbiters that encourage and support their teams (ideally you have a 1 manager:2+ team ratio or they tend to micromanage). They should really only be making technical decisions if the team is deadlocked and there needs to be a tie breaker (which should be relatively rare and it's likely both directions are reasonable at that point).
Senior engineers should be kept around to mentor younger engineers to provide that valuable feedback and there should be a career path that doesn't require them to go into management (a lot of companies try to do this but I've never seen it done well and the managers always seem to have broader reach, better compensation, and more promotion opportunities).
This rubric is fine at a certain level of scale, but as a company grows, both in size and complexity, it becomes hard to apply except possibly in the leaves of your organizational graph (and not always then).
Personally I manage a team of 400+ engineers. They do the full range of embedded systems across multiple platforms, iOS and Android native development, full stack web development, backend systems, and data science. We go all the way from device drivers that are deployed to 10's of millions of devices to Spark jobs running in a reasonably scaled up cloud infrastructure (5 digit CPU counts, not 6 or 7).
Needless to say, I am not competent in all of these domains. I do my best, and when decisions get to my level I know how to make them in a way that doesn't leave me as the weakest link, but fundamentally I can't possibly be an expert in all of what we do. There aren't enough hours in the day or days in a life.
Compounding that problem, at this level of scale, I believe in cross-disciplinary ownership. We don't have an iOS team that throws things over the wall to a site team, or a FW team that only thinks about how to optimize their part of the world. That means many of my managers are also managing engineers who know orders of magnitude more about their discipline than the manager does. It turns out this would happen anyway, because the manager shouldn't be making most of the technical decisions, and they don't have enough time in the day to stay expert in even one discipline at the level a senior IC is expected to.
You can't expect your managers to be the ultimate expert across the domains they manage, and even if they happen to be, you can't expect them to be able to keep that position (our industry changes too rapidly). What having been a practicing engineer does for them is to give them a perspective on what matters, to ask the right questions, to help the team develop an ownership culture so that they don't rely on the deus ex machina of a manager know-it-all who tells them what to do. Very few of the skills they need relate to having been the best Javascript engineer on the team at some point in time. They need to know how to _develop_ the best engineers, not continue to occupy that role themselves.
Last thought here -- this compounds when you get promoted into a role of managing managers. For many managers, this is a harder transition than moving into management in the first place.
Great insight, thanks for sharing. I believe your example is a good one. I'm still a believer that someone in your position should have a solid understanding of the architecture of your system, and likely experience with at least a part of it. That doesn't mean you need to be an expert in every domain, obviously, as that would be impossible.
>"In this study from Harvard 35,000 employees from the US and Great Britain were polled about their job satisfaction, and metrics were gathered about what influenced their happiness at work.
The results showed that
the single greatest influencing factor on employee satisfaction was whether or not their boss was technically competent."
65 comments
[ 2.9 ms ] story [ 118 ms ] threadWriting code != understanding computer science. I know plenty of people who had coded some linear procedural code in matlab for school who I would absolutely not say that they 'understand coding'. I would argue that being CS literate is where you have a logical framework of how code work together to create software - knowing the general idea of encapsulation etc.
Technical managers at the front level get 'cut off' when a reporting chain immediately above consisted of someone who are truly non-technical. You can have 3 software engineering teams each under technical managers, but then they all report to an MBA grad with no technical history at all. Which anecdotally resulted in some decision making that I would characterize as strange from my software engineering perspective.
"practical understanding of software systems" != "understanding of computer since"
Through having done CS helps a lot in being flexible enough in how you thing about (technical) things. (Disclaimer: The last thing can be easily misunderstood, the thing is when you do CS you have to do a lot of brain gymnastic about all kinds of things like e.g. that one thing can be seen as two seemingly unrelated things but still be the same in a given context, but not in a other seemingly nearly equivalent context.)
The result was:
- No one really managed any software teams.
- The manager did just ended up as a proxy between higher management which create friction. (E.g. in aspects like what features are viable to add in this year and which are not.)
- The manager lost practically all authority (and later one all trust).
Generally a really annoying situation not benefiting anyone. Through then a lot of other things went wrong too in that company.
My anecdotal evidence have strongly pointed that for a software project, managers that have an understanding of computer science have a strong edge on communication and decision making.
I've personally had much worse experiences with managers who wanted to micromanage every technical decision and every line of code vs. those who just trusted their team with it and focused on people management, clearing organizational blockers, roadmapping, project management, communication to executives and other stakeholders, shielding us from company politics and lots more.
That works in the happy case. But lots of things work in the happy case.
The problems happen when ICs do things that are good for themselves, but not good for the company. One obvious example of this is resume-driven development.
This statement is nonsense. How does simply trusting your reports guarantee anything, let alone that you're getting accurate data about what your people are doing? How would you be the wiser if you didn't have a fundamental understanding of the work being done?
>That trust (also known as being professional) short circuits the need for the manager to understand the work being done.
Again, nonsense.
Your statement is akin to saying that being a successful basketball coach doesn't require knowledge of basketball, but rather just simply having to trust in your basketball players. Yet show me how many successful basketball coaches are there that never played the game, or was around the game to develop a fundamental understanding of the game.
Or hell, put it this way: if trust short circuits any need for management to have any understanding, then anyone could be a successful manager. I'm sure my dog trusts me and most folk, I guess by your reasoning, he could be the manager of any department in any company!
Yeah, nonsense. You need some fundamental understanding of what you're managing otherwise you're a bad manager, or simply a figure head...
> coding, architecting, or doing technical work that requires engineering prowess.
As a software engineer, I don't even spend 80% of the time working coding, in fact it's more like 30%. But I do spend almost 100% of the time doing the stated things above.
However, I do agree with you (mostly). My position is that having an understanding of computer science make them much more efficient in the activities you described, some of which falls into the stated camp. Micromanagement is universally regarded as bad.
Of course, if your organization expects a manager to also be a tech lead, that’s something else entirely (and not common in most non-startup companies).
There is a lot of systems thinking required in managing team structures, interfaces between those teams, managing communication between teams, hiring, setting technology standards & architecture, and so on (review the rest of this thread).
I do agree with your thesis though - a manager should be highly technical. I just don't think you can depend on their contribution to features & deliverables. Not because the work is "below" them, but because Engineering Management is a support role and should NOT need to choose between an IC-type task and helping unblock/support a member of their team due to a deadline :)
(Some of the worst managers I've had, contrariwise, were people who started as coders and kept trying to work their decades-old knowledge into conversations. No, this service didn't "ABEND," thanks.)
If a manager doesn't have the story and line of communication set up (through his Director, etc.), the engineering team could prove P=NP; nobody would notice or care.
- Being the point of contact between Development and the rest of the organization, fielding questions about what can and can't be done, plus t-shirt sizing on effort
- Keeping tooling and technology unified (not ending up with one project each using Vue.js, React, Ember, Angular...)
- Keeping up standards (around code reviews, documentation, testing and alerts, end user and developer training)
- Thinking long term about how features, services and tools being built today can be re-used tomorrow
- Decisions about budgets and how to approach a project (use internal people or outsource to a vendor; field RFP responses; negotiate and get paperwork signed)
A lot of communication (inter-team and intra-team), budget work and "architecting" stuff is a reasonable summary, I think.
I still try to code a couple hours/week, but it's mostly around the undesirable stuff, or tooling (like CLI-stuff) to facilitate efficiency, generate metrics, help me play with the platform in a constructive way that facilitates my knowledge, etc...
The ability to recognize and deal with such unknowns is the most useful skill for a manager.
Having worked as a manager for a year now, I can say:
It's way busier than you know!
There's a lot of work that happens behind the scenes to keep everything going. The better your manager is, the more invisible this work will seem to the team.
I think this is sort of like asking: what does a coach even do in sportsball? They're not a player, why not just have the team do their own thing?
It's a different layer of the system that requires a lot of systems thinking and people skills. Here is a list of how I spend my time:
- Making sure the right people have the right opportunities to solve the right problems
- Coaching individuals on my team on career development
- Helping to define organizational topology/structure and interfaces between teams & roles
- Manage expectations of those outside the dev team
- Proposing & maintaining process documentation
- Helping define organization culture & maintain it
- Hiring & Interviewing
- Architecture, tech debt, system vision, and helping the tech leads make the business case
- Facilitating communication between teams & acting as a shield for my team, so that they can maintain focus
And then there are things that aren't officially my responsibility, but I end up doing because I do what's needed:
- Jump in to help facilitate the team through an incident
- Act as scrum master / agile ceremony facilitator
- Produce Roadmaps & help define work/user stories when there is no Project/Product Manager / Business Analyst available
- Troubleshoot production issues
And I know there is so much more. To be honest, I would NOT have enough time to do everything if I spent 80% of my time coding. I'm lucky to get 5-20% of my time coding in!
I think the original poster should try Engineering Management for a while to see how busy they get with non-coding tasks.
Competencies you require to be an Engineering Manager:
- Agile/DevOps/DevSecOps/Continous Delivery/Modern Buzzwords
- Systems thinking
- Organizational Design
- Process design, including things like Lean, Six Signma, Toyota, etc.
- Business strategy
- Recruiting
- Mentoring
- Coaching
- Public Speaking
- Written communication
- Product Engineering
- Infrastructure Engineering
- Negotiation & facilitation of disputes
- And the list goes on!
A really good book I recommend to try to understand the systems thinking required for management is:
An Elegant Puzzle Systems of Engineering Management By Will Larson
> Contrast the idea of a competent boss with the all-too-familiar experience of going to a non-technical middle-management type with an engineering problem, only to be stuck in a teaching session because the boss has never heard of a pub-sub system.
Since we're being reductive, why not posit that if you can't explain your systems to someone who doesn't write code, you shouldn't be building such systems?
If we really want to be reductive, then there's no reason to hire a manager that shares a language with their subordinates, because if you can't teach English to someone who hasn't learned it, what business do you have talking? Clearly, this is absurd, which means there must have been some reasonable grey areas that got left behind along the way...
I don't agree that a manager should spend 80% of their time coding, though. Maybe for smaller teams at early stage startups. But for even a team of 4-5, there are typically things they should be doing that are a better use of their time. It helps to code part of the time (maybe 20%) to understand the codebase, your level of technical debt, and proposals from engineers, but coding can be a trap that keeps you from doing what you need to do to enable your team.
In a worse case, technical managers can become micromanagers, and their opinions can have so much outsized influence that they lead to bad decisions.
I've found that simply by being an expert in some area, it can be extremely difficult to let certain things go and refocus on other objectives.
For me, there is definitely some yin-yang balance between the technology and business evangelism. Having 2 different humans with 2 wildly different perspectives many times yields a far better result than 2 different humans with 1 unified perspective.
Sometimes I have to stop my other developers from getting upset with project managers when they are having bad days. If your managers are unhappy, it's very likely that the customer is unhappy as well. Developers should use this as a signal that they may want to re-prioritize efforts or schedule deep-dive meetings with their managers to sort out customer & business concerns.
The exact same idea applies to the technology. If the developers are in a bad mood, its quite likely that they are struggling with some abstract technological foe such as a legacy code base or broken devops process. Managers should recognize this as an opportunity to pause the process and try to allow room for the developers to work through whatever technical difficulties they are having.
If you have this perspective where everyone involved is a delegate to some other ultimate authority, you may develop a greater sense of empathy for your fellow human.
I would certainly expect the technical lead to do a good amount of coding in addition to design and mentoring, but expecting the CTO to code as the article suggests seems wrong. I guess this might be true at a 25 person startup, but I think this is an unrealistic requirement for larger organizations.
By a similar argument, would the COO be reasonably expected to work on the assembly line and repair hvac on a regular basis? Again, perhaps at a company of 25 but seemingly (to me at least) absurd at a larger company.
"Managing people" isn't a full time job in most cases. It all depends on how the organization is structured and how many non-technical tasks are being assigned to the "manager". Sometimes a manager is responsible for product, marketing, or HR tasks and all that will be dependent on the company in question.
Beyond this, programming skills and specific technical knowledge can be useful as a manager, but I'm dubious that they are as essential as this article implies.
I further imagine that a similar pattern holds for other technical fields- you need some basic grounding, but do not need to be a technical expert to manage.
Senior engineers should be kept around to mentor younger engineers to provide that valuable feedback and there should be a career path that doesn't require them to go into management (a lot of companies try to do this but I've never seen it done well and the managers always seem to have broader reach, better compensation, and more promotion opportunities).
Personally I manage a team of 400+ engineers. They do the full range of embedded systems across multiple platforms, iOS and Android native development, full stack web development, backend systems, and data science. We go all the way from device drivers that are deployed to 10's of millions of devices to Spark jobs running in a reasonably scaled up cloud infrastructure (5 digit CPU counts, not 6 or 7).
Needless to say, I am not competent in all of these domains. I do my best, and when decisions get to my level I know how to make them in a way that doesn't leave me as the weakest link, but fundamentally I can't possibly be an expert in all of what we do. There aren't enough hours in the day or days in a life.
Compounding that problem, at this level of scale, I believe in cross-disciplinary ownership. We don't have an iOS team that throws things over the wall to a site team, or a FW team that only thinks about how to optimize their part of the world. That means many of my managers are also managing engineers who know orders of magnitude more about their discipline than the manager does. It turns out this would happen anyway, because the manager shouldn't be making most of the technical decisions, and they don't have enough time in the day to stay expert in even one discipline at the level a senior IC is expected to.
You can't expect your managers to be the ultimate expert across the domains they manage, and even if they happen to be, you can't expect them to be able to keep that position (our industry changes too rapidly). What having been a practicing engineer does for them is to give them a perspective on what matters, to ask the right questions, to help the team develop an ownership culture so that they don't rely on the deus ex machina of a manager know-it-all who tells them what to do. Very few of the skills they need relate to having been the best Javascript engineer on the team at some point in time. They need to know how to _develop_ the best engineers, not continue to occupy that role themselves.
Last thought here -- this compounds when you get promoted into a role of managing managers. For many managers, this is a harder transition than moving into management in the first place.
The results showed that
the single greatest influencing factor on employee satisfaction was whether or not their boss was technically competent."