Effective Positioning for Engineering Managers
Aug 4, 2025
—
One of the questions that Engineering Managers often ask themselves is how much they should be involved with the team from a technical point of view, in particular in terms of how much they should be coding. The debate around whether Engineering Managers should code is a recurring theme, recently amplified by a discussion started by Ethan Evans stating that he never wrote a single line of code during his career as a software engineering leader.
There is plenty of advice available on whether managers should be coding. The discussion is often polarised between the two camps of “a manager should never code” and “a manager needs to always be coding”, and it is often framed as a matter of either personal preference or resource allocation.
In my years leading engineering teams, I have constantly asked this question myself, and being asked it by the managers I have supported. Through observation and experimentation, I’ve developed a simple yet effective framework that helps map and optimise this balance. I believe this approach holds unique value for navigating the role, and in a time of frequent talks about Founder Mode, team efficiency, and budget constraints, I would like to offer it to managers and leaders so they can answer this question for themselves.
I will show that this question can be framed in terms of a leader’s effective positioning, and I will offer a theory that can help managers understand what the optimal positioning for them would be. More importantly, I will show that effective positioning is a dynamic process, and a leader needs to constantly adapt their position to make sure they stay effective.
What is positioning?
Positioning is a term that originated in the context of military leadership, and it can be described as the choices that a commander makes of where to position themselves in the theatre of operations.
One of the jobs of a commander is to exercise authority and direction to achieve a common goal. This is referred to as Command and Control. If a leader positions themselves too close to the front, they risk being involved in so many tactical details that they lose focus on the overall operation. If, on the contrary, they position themselves too far in the back, they won’t know what is happening up front, and they can’t provide effective command.
In choosing an effective positioning, a commander needs to then balance two competing needs: a) operational clarity, that is being close enough to provide command and control to the attacking force and b) situational awareness, that is having enough information to ensure their command and control is effective.
“Understanding proper positioning as a leader is a key component of effective Decentralised Command, not just on the battlefield. In any team, business, or organisation, the same rule applies.” — Jocko Willink, Extreme Ownership
How does this apply to Engineering Management?
Should a manager write code?
The job of a Manager, using Peter Drucker’s definition, is to perform the specific purpose and mission of an organisation by achieving its objectives, and this happens through the exercise of authority and direction. In many respects, the job is not at all different from the job of a military leader described in the paragraph above.
Applying the principles of Command and Control, we can reframe the question of manager involvement in coding as one of effective positioning. Instead of asking yourself the question “should I code?”, ask yourself “where should I position myself to best exercise Command and Control in order to enable my team’s success?”.
In order to choose an optimal positioning, a manager needs to find the level of involvement that allows them to have the best situational awareness so they can make themselves effective and provide the best operational clarity so the team knows what they have to accomplish. As we saw before, these variables move in different directions: more operational clarity improves the ability of the team to achieve the mission, but generally might make the mission less effective as the leader gets bogged down into the details. Vice versa, stepping back gives the leader the ability to appreciate the global situation better, but this is useless if they are unable to communicate effectively with their team.
Many Engineering Managers have an intuitive understanding of the effective positioning, often honed through years of experience.
For example, in a new team consisting mostly of junior engineers, it might be useful for the manager to be in the code. The manager doesn’t need to necessarily contribute on the most critical path, but active contribution helps the manager gather direct insights into the challenges the team is facing, and it helps the manager set the standards for code quality, testing, and documentation. If the new team sees their manager as someone who can actually do the work, this will build trust, and allow the manager build confidence. Command and Control is thus provided through immediate feedback, on the job training, coaching and mentorship.
Another common situation where it is useful for a manager to be in the code is when a manager joins a new company, and they are unfamiliar with the technology and the codebase. What I have found is that spending 4–6 weeks actively contributing to the codebase is enough for the manager to be able to provide effective Command and Control.
How can we generalise this into a set of principles to help Engineering Managers make the best positioning decision for themselves?
A Positioning Framework for Engineering Managers
In order to generalise, we can express the decision the manager needs to make as a function of two variables: situational awareness and operational clarity.
Situational Awareness refers to the ability of a leader to know what is happening, why it is happening, and anticipate what will happen next. When a Manager possesses a High Situational Awareness, they have a consistently accurate and comprehensive understanding of the operational environment. They are able to perceive relevant information, integrate it into a coherent mental model, predict likely future conditions, and remain adaptable and responsive to changes. They are “one step ahead”.
On the contrary, a Manager with Low Situational Awareness has an inaccurate understanding of the operational environment. They may miss vital cues, misinterpret information, fail to integrate different data points effectively, or struggle to predict likely future events. This can lead to slow reactions, poor decision-making, and increased vulnerability.
Operational Clarity refers to the degree to which the team understands what needs to be done, why it needs to be done, and how it fits into the larger strategy.
High Operational Clarity exists when all members of the team demonstrate a unified and precise understanding of their team’s goals, their individual responsibilities, and how their collective efforts contribute to the overarching mission. When a team is in such a state, direction flows easily because the team is already aligned and well equipped to execute.
Low Operational Clarity signifies a deficient or fragmented understanding of the team’s mission objectives, individual roles, and the desired end-state. It’s characterised by the need of frequent clarification, misalignment, and roadblocks.
If we consider these two dimensions, thus the question becomes:
“Which positioning will give me the most effective way to provide direction given the current level of operational clarity while maintaining enough situational awareness?”
Considering everything together, we have a traditional 4 quadrant matrix where each cell corresponds to the following combinations:
- Low Situational Awareness, Low Operational Clarity → Crisis Mode
- High Situational Awareness, Low Operational Clarity → Ambiguity
- Low Situational Awareness, High Operational Clarity → Flying Blind
- High Situational Awareness, High Operational Clarity → Clarity
Let’s look at each quadrant in details, highlighting the optimal positioning and the actions the manager can take in each of them.
Crisis Mode (Low Situational Awareness, Low Operational Clarity): Learn & Stabilise
This quadrant represents a situation of crisis. The manager lacks a strong understanding of the technical complexities and the team struggles with direction, priorities, and processes. As a result, execution is fragmented and inefficient.
The manager needs to focus on immediate crisis management — prioritising actions to stabilise the situation. Hence, the suggested approach for the manager is Learn & Stabilise. The manager should first regain Operational Clarity immediately, by establishing a simplified goal to get things under control, but as soon as the situation is triaged and the crisis contained, they should shift towards building Situational Awareness. Prioritising coding is a good way to rapidly acquire knowledge. Direct coding gives the manager the ability to understand the codebase, team dynamics, and critical processes. This is a short-term goal to help the manager move to High Situational Awareness.
Real World Example — I was once hired in a new team as an engineering manager, and the four engineers which were part of the team all started the same day as myself. The engineers also had less experience than me.
After we were done with the initial onboarding, Monday came, and with it the need to start operating as a team.
Since we were all new to the company, to the product, to the codebase and to the technology stack, my focus for the first week was to understand the product we were building, and what was the next milestone. I set clear expectations with the team that we would not focus on long term vision, strategy, career growth and similar things for the first few months. Once I gained Operational Clarity with this simplified goal being accepted and established, I dived deep into the coding work, building part of the features for the next release. This helped me gain Situational Awareness of the technology, the business, and my team’s skills, which meant that I was better prepared to start working on increasing Operational Clarity.
Ambiguity (High Situational Awareness, Low Operational Clarity): Lead by Example
The manager deeply understands the technical complexities but the team lacks a clear roadmap, shared priorities, or standardized processes. In this situation, the manager’s first priority is to accelerate learning and knowledge transfer, clarify objectives and roles, and facilitate team discussions to build shared understanding and accountability.
This is often best done when the manager is leading from within, using their strong interpersonal skills and the ability to influence without formal authority. If the manager does this from the outside and they don’t handle if carefully, they risk of being perceived as overly critical or micromanaging, thus damaging the very outcome they have set to achieve.
In this quadrant, the best strategy for a manager is to Lead by Example, and this includes coding. If the manager shows the team that they are part of the team, and they share the same burden of responsibility, they will build credibility and human capital that will help them coach and mentor the team towards a higher level of Operational Clarity.
Real World Example — There was a time where after a re-organisation all the engineers had moved on, and I had to hire a new team from scratch for a specific product area. Since I was the last one remaining on the team, I was also the most knowledge person about the particular set of products we were supposed to support. My priority at that point was to quickly ramp up the new engineers. Working within the team as a senior engineer allowed me to build the team faster, since I was able to build trust and operate more closely to each individual on the team.
Flying Blind (Low Situational Awareness, High Operational Clarity): Passive Coding
The manager lacks a strong understanding of the technical complexities, but the team operates with clear direction, shared priorities, and efficient processes. Execution is smooth despite the manager’s lack of technical depth. This typically happens when a manager joins an established team.
In this context, the manager should seek out information to improve technical understanding. They should engage with technical leads and subject matter experts. Their focus should be on effectively executing the plan and removing roadblocks for the team. This requires a willingness to admit knowledge gaps and a continuous learning mindset.
From a coding point of view, the suggested approach for the manager is Passive Coding. The manager should do targeted coding contributions that helps them ramp up quickly on the codebase.
Real World Example — When I join a new team, I usually spend weeks in Production Support taking care of bugs and other production issues. This gives me the ability to do targeted deep dives in the codebase, and quickly gain technical depth that allows me to understand better the why behind the way the team does what they do.
Clarity (High Situational Awareness, High Operational Clarity): Strategic Direction
This is the ideal positioning that a manager should aim for. At this stage the Engineering Manager possesses a deep understanding of the project’s context, including technology and business goals, and has clearly been able to articulate the team’s mission, roles, and anticipated outcomes.
At this level, coding provides limited value, and the optimal positioning for a manager requires them to provide Strategic Direction, in terms of long-term planning, risk mitigation, talent development, and fostering a culture of innovation and continuous improvement.
Although coding provides limited value at this level, it is important to note that coding can still be leveraged. The main challenge for a manager in this quadrant is maintaining both Situational Awareness and Operational Clarity consistently over time. The biggest risk come from complacency, and coding can help the manager scan the horizon for potential disruptions.
Real World Example — My current team constantly operates in the Clarity quadrant, but with the raise of LLM assisted coding, I started to increase the amount of coding in order to understand how the new technological landscape would affect both the operational environment and the way of working of the team.
Positioning is Dynamic
It is important to remember that effective positioning is dynamic, and the manager needs to allow for temporal shifts that requires them to change position.
Even when the manager is striving for the Clarity quadrant and they managed to position themselves there, it’s inevitable that shifting priorities, unexpected challenges, or emerging opportunities will require adjustment.
For example, a sudden technical failure or an unexpected innovation might immediately lead to a loss of both Situational Awareness and Operational Clarity, and plunge the team into Crisis Mode, demanding immediate triage and a rapid shift towards information gathering to regain footing.
Similarly, a strategic business pivot could erode Operational Clarity, forcing the manager to shift into the Ambiguity quadrant.
Rather than aiming for permanent residence in any one quadrant, the most effective Engineering Managers need to proactively monitor their position, and regularly assess whether their actions are in line with the requirements of the quadrant in which they are operating.
The key for the manager is avoiding complacency and staying adaptable.
Should you prioritise Situational Awareness or Operational Clarity?
Since there is a natural tension between Situational Awareness and Operational Clarity, one might ask the question about which one a manager should prioritise.
In the long run, prioritizing Situational Awareness is the most reliable path to team success. Without a thorough understanding of the technical landscape, even the most diligently executed plans can falter.
Situational Awareness acts as the Foundation on which optimal positioning is built. Higher Situational Awareness allows a manager to anticipate problems, make informed choices, and proactively steer the team in the right direction. It reduces the likelihood of ending up in Crisis Mode, and creates a base for operational efficiency.
Operational Complexity follows Situational Awareness. You can’t effectively define clear objectives and roles if you don’t understand the context. Thus, Situational Awareness provides the grounding for Operational Complexity.
Even when a manager is operating in the Clarity quadrant of High Situational Awareness and High Operational Complexity, a team can encounter challenges where a manager’s direct involvement becomes invaluable. Sometimes a particularly complex bug requires deep diving into the codebase, a novel solution demands rapid prototyping to validate feasibility, or a critical path is blocked and needs immediate attention. If a manager is willing to get closer to the code, they are better equipped to detect these situations, thus recognising when the team is struggling despite their expertise, or when a faster iteration cycle demands hands-on participation. Adjusting positioning accordingly — temporarily shifting closer to the action — can unblock progress and demonstrate continued technical understanding.
Conclusion
As the technology landscape continues to evolve, the role of the Engineering Manager will keep evolving. Ultimately, there’s no single right amount of coding an Engineering Manager should do. However, this framework offers a pathway toward making informed positioning decisions, adapting to dynamic circumstances to maximise both individual effectiveness and team success. By regularly assessing your current quadrant in terms of Situational Awareness and Operational Complexity, proactively seeking opportunities to expand situational awareness, and strategically using code as a tool for understanding and influence, you can transform the challenge of “should I code?” into a powerful lever for building high-performing teams and achieving impactful results.
If you found this useful, please let me know!