What kind of harness are you building?

The Main Thread

SubscribeSign in

What kind of harness are you building?<br>The system of incentives you build for your organization behaves like a harness for your colleagues and influences their performance.

Alessandro Diaferia<br>Aug 11, 2026

Share

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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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...