With agentic coding disrupting how we build software, many are trying to push the narrative that everyone is turning into engineering managers. The rationale is that everyone works with multiple coding agents at once and orchestrates them on multiple projects.
While I see how easy it is to make the leap, I think this is an oversimplification of a manager’s job. Managing humans through the unpredictability of life towards a common business goal is orders of magnitude more difficult than just prompting a bunch of agents to build software. If you think that’s all there is to being an engineering manager, you have either been incredibly lucky in your career or you haven’t really managed people.
With that out of the way, I still think there’s value in an analogy that involves agentic coding to describe how a manager’s style contributes to building the harness software engineers operate within and how it can influence their attitude towards the projects they work on.
We can think of software engineers as more or less capable LLMs that have been trained over the course of their career. More experienced software engineers perform better on technical challenges and in specific technical fields depending on tenure and specialization.
Software engineers aren’t evaluated solely on technical challenges, though, and other aspects of their profile might have more or less weight in their professional success: tenure, job title, team structure, business context might require software engineers to exercise their soft skills as well.
A junior software engineer with high agency might still have a significant positive impact on a team, even without deep technical expertise. At the same time, a very strong technical senior engineer might plateau if unable to serve the team beyond just solving technology-specific challenges.
When I say agency I refer to that sense of ownership that makes the individual want to bring a project to completion, even (or especially) if they are not formally identified as the project lead. Certain people have a disposition to plow through challenges and strive to remove blockers and ensure the team can ship.
The sense of ownership, comfort with ambiguity, ability to communicate clearly and build relationships, understanding the business outcomes the company is looking for as well as being able to put themselves into the customer’s shoes, are all traits that strongly influence a software engineer’s performance.
Those traits are enhanced or weakened by the harness, the organization they work within. One’s own raw capacity for solving complex challenges, instead, is the underlying LLM.
A junior engineer who lacks sufficient expertise to solve a very technical problem might still have a positive impact on the project by talking to the right people, asking for help, deeply understanding the customer problem the project is trying to solve and ultimately making sure that the problem gets worked on, instead of waiting for an answer to fall into their lap.
By contrast, a deeply technical senior engineer who stops at the first poorly specified requirement, incapable of chasing an answer outside the boundary of their team, waiting for their manager to feed them the next step, is often perceived as ineffective or unhelpful.
If you are a manager reading these paragraphs and feel like you are rooting for the junior engineer, I won’t blame you. Seeing a junior report autonomously bringing projects to completion is a great feeling: you see the project progressing with minimal involvement from you. You think you are doing a great job and you’re the best manager ever.
I don’t want to take away from the enthusiasm but I think this feeling is flawed and superficial. Since I started that analogy, let me clarify what I mean by continuing it.
The junior engineer is on auto mode. You gave them a poorly specified requirement and they’re plowing through it. They’re hardly checking in with you but you can see they are making progress overall. They’re building relationships, setting up meetings and closing tickets. Deep down you might wonder how they’re managing to solve the most technical challenges of the project, but since everything seems to be ticking along, you go with the flow. Sure, they might make stuff up along the way, but hey! They’re moving the project forward! Eventually, the project is ready to be shipped.
On the other hand, the senior engineer keeps reaching out for input. Auto mode is not working for their harness as it keeps reverting to manual mode. They are blocked once again, waiting for your input. Those requirements are insufficient, the project doesn’t make sense. Why are we even considering building this? You are getting looped into every decision, to the point where you feel you are doing their job. You stop focusing on the senior’s analysis and instead start focusing on how much of their work is landing on you because of their lack of agency.
You expect them to be more autonomous. You start questioning their seniority because you have subconsciously started evaluating their performance by how many interrupts you get from them.
As a manager, you might even have the urge to promote the junior engineer because they’re seemingly making your job easier. You’re probably thinking they’ve been so effective at managing that last project that the next natural step for them is getting an official Team Lead title.
Over time I realized this is not ideal, and might even harm someone’s career. As Will Larson notes in his piece, the team lead role might develop early in organizations that have a strong concept of team, but he also notes how people ending up leading teams should’ve worked on complex technical projects first, earlier in their career.
If you’re promoting someone junior into their first leadership position ask yourself: is this the right move for them or for you? Their great performance acting as glue (Tanya Reilly has a great piece about it) for the rest of the team is probably compensating for their lack of opportunity to practice their technical skills. The right move should really be helping them grow in that direction. As a manager, the gap you should identify is figuring out why they ended up acting as the project lead, taking time away from practicing their technical skills.
At the same time, it’s worth thinking twice about what type of agency you should be expecting from a senior engineer. We might argue that stopping frequently on poorly specified requirements still means being proactive about clarifying discrepancies, after all. The fact that they’re not plowing through them autonomously does not necessarily mean lack of agency. Some gaps might actually need you, the manager, to be involved because they are critical decision points.
Admittedly, inability to do much outside the technical-specific realm is an indication that the organization (or you, for that matter) are not incentivizing them to be proactive. Have they stopped thinking of themselves as team players and started acting as consultants? It is a signal that you are not giving them the right feedback to improve on levers outside the technical realm.
Just like by not reviewing your coding agent’s work you might be missing out on important technical decisions, similarly, favoring the attitude that bothers you the least optimizes for project completion rather than technological sustainability and actual outcomes.
How many of those decisions might you have overlooked on the junior engineer’s project just because it was progressing fine? How many architectural decisions have gone through despite working against some fundamental constraints your organization worked so hard to establish? The context your agents work within needs to be carefully engineered for them to be trusted to honor the constraints you care about. Equally, you need deliberate incentives so the right decisions can emerge as autonomously as possible.
An agentic harness can lift a weaker model or hold back a stronger one. Similarly you, and the organization you help build, can help your colleagues grow or plateau.
This post was originally published on Substack. If you enjoyed this post, consider following me there or on X for a more unfiltered stream of thoughts as I go through my personal and professional journey.
Leave a Reply