6 ms·
Manager Can’t Code? They Shouldn’t Be Your Manager
- devalgo 6y agoLegitimately 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.
- vikramkr 6y agoThere are non software companies with software teams
- devalgo 6y agoSure, 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?
- deleted 6y ago[deleted]
- ciceryadam 6y agoMBAs, mostly.
- enitihas 6y agoYes, 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.
- ciceryadam 6y agoYep, it's happening. Even worse, I've dealt with Architects with minimal IT training.
- Aperocky 6y ago2 observations. 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.
- dathinab 6y agoanother observation from me: "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.)
- res0nat0r 6y agoAbsolutely.
- dathinab 6y agoI was in this situation. 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.
- Aperocky 6y agoI 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.
- deleted 6y ago[deleted]
- paxys 6y agoManagers 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.
- enitihas 6y agoI 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.
- falcolas 6y agoIf 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.
- Rury 6y ago>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...
- yllus 6y agoI'm curious about a related question: Does a manager need to be the best coder on the team? How much does it help/hurt if they're not?
- qvrjuec 6y agoDefinitely not. The manager should be proficient enough to manage, but their main responsibility isn't to code, it's to... manage.
- JadeNB 6y agoIf the manager is the best coder, then they'll be tempted to—and arguably they should—code, not manage.
- devalgo 6y agoI 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.
- lanecwagner 6y agoNo, 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.
- abakker 6y agoPotentially, 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.
- managementthrow 6y agoI 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 :)
- mkozlows 6y agoHard 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.)
- curiousllama 6y agoAs 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.
- yalogin 6y agoI 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?
- lanecwagner 6y agoAuthor 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.
- curiousllama 6y agoThat'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.
- deleted 6y ago[deleted]
- curiousllama 6y agoIn 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.
- deleted 6y ago[deleted]
- yllus 6y agoIt'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.
- badrequest 6y agoAttitude 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?
- whatshisface 6y ago>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...
- jmcgough 6y agoI'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.
- bob1029 6y agoI 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.
- potta_coffee 6y agoYou'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.
- bob1029 6y agoOne 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.
- abakker 6y agoAlternative 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?
- fortran77 6y agoSo Steve Jobs shouldn't have run Apple?
- uberman 6y agoI 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.
- lanecwagner 6y agoI'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.
- deleted 6y ago[deleted]
- LeoTolstoyJr 6y agoA 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.
- autarch 6y agoTo 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.
- RodgerTheGreat 6y agoIn 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.
- deleted 6y ago[deleted]
- siliconc0w 6y agoI 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).
- sulam 6y agoThis 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.
- lanecwagner 6y agoGreat 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.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- peter_d_sherman 6y ago>"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."