Engineering management: holding the tension

An engineering manager is often asked to make several things true at once: move the work forward, keep quality high, build a team people want to stay on, respond to a business that keeps changing, and help each person see a future in work that may not offer a promotion next year. Those aims can pull against each other. A deadline gets closer while a key dependency remains uncertain. One engineer takes on every difficult task; another seems to be standing still. Someone wants a bigger challenge, while someone else is good at the work they already do and does not want to become a manager. A promising idea gets a pilot, but not the funding or ownership to reach customers. This is not a people problem that can be solved with one motivational speech or a new tool. It is the real work of managing an engineering system made of people, decisions, technology and business constraints.

There is no universal team pace

A small team can move quickly because the people doing the work can speak directly and decide quickly. It can also be fragile: one person being away, one supplier delay or one production issue can stop the whole effort. A larger organisation may have more specialists and more capacity, but it also has more hand-offs, dependencies and decisions to coordinate. So I do not think the useful question is, “Why isn’t this team moving as fast as that team?” It is, “What is slowing this team down, what is the cost of going faster, and what are we choosing to protect?” A team may be moving slowly because its goals are unclear, because reviews take too long, because it is carrying too much work at once, or because it is doing the necessary work of reducing risk. Those situations need different responses. Research on developer productivity warns against using a single measure such as commits, lines of code or activity to judge performance. The SPACE framework considers several dimensions, including satisfaction and wellbeing, outcomes, activity, collaboration and flow. A high activity count can mean progress; it can also mean people are working around poor systems or trying to recover a slipping plan. [1] Developer experience research points to practical sources of drag: slow feedback from tools and reviewers, unnecessary mental load from hard-to-understand systems, and interruptions that make it difficult to concentrate. These are not solved by telling engineers to “be more productive.” They often require managers to improve the conditions around the work. [2] The pace I want is not permanent urgency. It is a tempo the team can sustain while still delivering the most important work, learning from results and making room to respond when the business changes direction.

Disagreement is useful; unresolved disagreement is expensive

Engineering work is full of choices with real trade-offs. One design may be quicker to deliver; another may be easier to operate. A business stakeholder may want a visible feature, while engineers see a reliability issue that could affect many customers. Agreement does not mean everybody prefers the same option. A healthy team makes it possible to raise a concern without being labelled difficult or disloyal. Google’s study of its own teams identified psychological safety, dependability, clear expectations, meaning and impact among the team dynamics associated with effectiveness. The study is useful but not a universal recipe: it examined teams inside one company, and its measures combined both people’s assessments and business results. [3] I want disagreement to improve the decision, not become a permanent state. That means making the decision owner clear, hearing the evidence and risks, stating what we chose and why, and agreeing when we will revisit it. Once a decision is made, people should know what they are committing to—even if it was not their preferred option. If new evidence changes the situation, the team should be able to reopen it without pretending the earlier decision was foolish. That is different from demanding consensus. Consensus can hide a lack of ownership. Silence can look like agreement when people have simply decided that speaking up is not worth the cost.

Fairness is clear expectations and follow-through

Most teams have unequal contributions at different times. One person may carry the urgent work, review other people’s changes, support production and still be expected to deliver their own project. Another may miss commitments or avoid work that falls within their role. The first response should not be to rank people by visible busyness. Some work is easy to count and some is easy to overlook. Helping a colleague, reviewing a risky change, sharing operational knowledge and preventing a recurring problem may not produce a large feature card, but the team depends on it. At the same time, calling someone a “quiet contributor” should not become a reason to ignore commitments that are repeatedly missed. I try to make the work and the expectations visible. Who owns the outcome? What is the next deliverable? What is blocking it? Which work is taking capacity away from the plan? If someone is struggling, I want to understand whether the cause is unclear priorities, missing skills, too much work, a dependency, a personal constraint or a gap in follow-through. Those explanations should not be collapsed into one label. Then the conversation needs to be direct. Agree on the expected change, what support is available and when we will check progress. If the work still does not meet the agreed standard, address that honestly and consistently. The CIPD’s performance-management guidance treats objectives, feedback, development, recognition and career progression as connected parts of performance management, and says the approach should be fair, transparent and fitted to the organisation’s context. [4] Fairness does not mean every person gets the same task or the same conversation. It means people understand what is expected, have a genuine chance to meet it, and are treated with respect when the answer is difficult.

Growth is not always a promotion

People want different things from work. Some want to lead a larger team or move into management. Some want to become deeper technical specialists. Some want to mentor, improve reliability, own a complex service or become the person others trust during a difficult incident. Others may want to do solid work, maintain a life outside the job and not be pushed into a leadership role they never asked for. There is no single ladder that fits everyone. GitLab’s public engineering career guidance is one example of an organisation describing technical and management paths separately, while being clear that promotion depends on both demonstrated readiness and an organisational need for the role. It also encourages people to try management responsibilities before committing to that path. That is a company’s own model, not a rule every employer follows, but it makes one important point: growth and promotion are related, not identical. [5] This becomes uncomfortable when someone is ready to move up and there is nowhere to move. It is also uncomfortable when someone is in a role that has changed around them, or when a team needs a different contribution than the one a person is currently making. Managers should not promise a promotion they cannot deliver. They can make the options visible, offer honest feedback, find stretch work when possible, and be clear about what depends on budget or an available role. Some people are keen to step outside familiar work and take on a stretch. Others would rather deepen the work they already know or keep a steadier role. I should ask, not assume. If someone chooses not to pursue a promotion or stretch assignment, that is not automatically a performance problem. At the same time, “I prefer my comfort zone” cannot excuse repeatedly avoiding responsibilities the person has agreed to own. The role expectations still need to be clear, and any gap needs a fair, direct conversation. The goal is not to manufacture ambition in everyone. It is to understand what each person wants, make the trade-offs explicit and avoid letting the organisation’s narrow ladder become the only definition of a worthwhile career.

Work can be meaningful without pretending jobs are permanent

Technology teams face shifting business priorities, new tools and changing structures. People know that roles can change and jobs can end, even when leaders avoid saying it plainly. I cannot make that uncertainty disappear by telling people they are “family” or promising that good performance will guarantee a permanent place. I can be clear about what I know, what I do not know and when I expect to know more. I can avoid presenting a decision as settled when it is still being considered. I can explain how a change affects the work and what support is available. A systematic review of research on employee reactions to organisational change found that responses vary, and that communication and participation can shape how people understand and respond to change. It also argues that concern or resistance can contain useful criticism, rather than being treated automatically as a problem to suppress. [6] There is a mutual benefit in the working relationship, but it is not a promise of permanence. The organisation gets skill, judgement and commitment. The engineer gets pay, opportunity, experience and a chance to do work that matters. Managers can respect that exchange by being honest, recognising contributions and helping people build skills they can carry forward—whether they stay, change teams or eventually move on.

The last mile is part of the idea

A small experiment can be exciting because the first version works. Then comes the less glamorous work: connecting it to existing systems, dealing with security and support, training the people who will use it, planning for failures, measuring whether it helped and paying for it to run. If nobody owns that last mile, the pilot is not a stepping stone. It is a demo with an expiry date. A 2026 MIT Sloan summary of research on digital innovation describes why organisations can struggle to turn initiatives into business value: teams may be funded up front without evidence gates, left to solve shared dependencies alone, or separated from the portfolio decisions that determine whether the work should scale. The proposed response is shared leadership across the initiative, common resources and the investment portfolio. [7] For an engineering manager, that means raising the last-mile costs before a pilot begins. Who will own it if the test works? Which team must support it? What security, integration or operational work is still missing? What evidence would justify more investment, and what evidence would make us stop? Those questions are not bureaucracy. They protect both the idea and the people asked to deliver it. DORA’s 2025 report makes a related point about AI-assisted development: AI acts as an amplifier of the organisation’s existing strengths and weaknesses, and the greatest returns depend on the underlying system, not simply on buying a tool. [8] The same lesson applies more broadly. New technology does not remove the need for clear priorities, reliable delivery and decisions about who will own the result. The OECD also reports that AI is changing how some workers perform tasks and the skills those jobs require. That is another reason to keep learning close to the work: not every new tool will matter to every team, but teams need room to test relevant changes and build the skills to use them responsibly. [9]

The manager’s part

I do not think an engineering manager can make every priority stable, every person equally ambitious, every idea successful or every job permanent. Pretending otherwise would not be kind. It would only delay the hard conversation. The manager can make the current reality easier to work with. Set a pace that reflects the capacity and risk. Make it safe to disagree and clear who decides. See both visible delivery and the work that keeps the team functioning. Give direct feedback when contribution falls short. Offer growth without forcing everyone toward the same title. Be honest about uncertainty. And before celebrating a pilot, ask who will get it the rest of the way to the people it is meant to serve. That is not a neat formula. It is a way of working that treats both delivery and people as real responsibilities—and keeps revisiting the balance as the business changes.

References

More writing · About Gokul