Leading Engineering Teams as They Grow

When informal coordination stops working

A small team can keep a surprising amount of context in conversation. Everyone knows who owns the release, why a shortcut was taken, and which customer is waiting for a fix. As more people join, that shared context becomes harder to maintain. Someone misses a discussion and makes a reasonable decision that conflicts with another team's work.

At Acquia, I helped establish an offshore engineering center that grew to 200 employees, and managed an engineering team of more than 15 developers. Those are different kinds of responsibility. Managing a team means staying close to its work. Helping an organization grow means making it possible for other teams to work without depending on you for every answer.

My starting point is to look at where people are waiting. An unanswered ownership question, a review queue, or a decision that keeps reopening can tell you more than the organization chart. Fix the specific delay before adding another layer of process.

Make ownership specific

Consider a checkout feature that needs work from frontend, payments, and infrastructure teams. Each team can finish its assigned tickets while the feature remains impossible to release. Nobody has agreed who checks the whole flow or decides what happens if payments fail.

Give someone responsibility for that outcome. The team owning checkout should know who it needs to consult, which decisions it can make, and how to escalate a blocked dependency. Owning an outcome does not mean doing all the work yourself.

Write down the boundaries in terms people can use: who owns the API contract, who handles incidents, and who approves a breaking change. A team name beside a service is a start. It does not answer those questions on its own.

Revisit these boundaries when teams repeatedly need each other's approval for routine changes. The problem might be an unclear contract, a missing capability, or work split across the wrong teams. Another coordination meeting will not necessarily fix it.

Write down the decisions

A decision needs enough context to survive the meeting where it was made. Record the problem, the chosen approach, the main tradeoff, and what would cause you to reconsider. A few paragraphs can be enough. An elaborate template is easy to abandon when delivery gets busy.

For example, a team might keep billing in the main application because it shares transactions with orders. Recording that reason helps the next engineer evaluate a proposal to extract it. Without the reason, the decision can look like an oversight.

This matters even more across time zones. Send a proposal before asking for a meeting, leave time for written responses, and publish the final decision where the work lives. Rotate inconvenient meeting times when a live discussion is necessary. Recording every meeting creates a backlog of video; a short decision note is easier to find and use.

Choose what to standardize

Teams need some shared rules. Authentication, handling sensitive data, and recovering from a failed deployment affect more than one team's preferences. A common approach can reduce both risk and repeated work.

Other choices can stay local. Two teams do not necessarily need the same planning ritual or identical internal component structures. Before making a rule mandatory, name the failure it is meant to prevent and who will maintain it.

A coverage threshold illustrates the tradeoff. It is easy to check, but a passing number does not establish that a payment retry or a permission boundary works. Ask for tests of the important behavior. Use coverage to find gaps, then inspect what those gaps mean.

Apply the same scrutiny to process. If every release requires a manual checklist because deployments often fail, work on the failure and automate the checks you trust. Review the checklist after that work. Temporary precautions have a way of becoming permanent obligations.

Give people room to grow

A senior engineer should be able to grow without becoming a manager. Technical leadership and people management overlap, but they involve different responsibilities. Someone who enjoys difficult architecture work may not want to spend their week on hiring, feedback, and performance conversations.

For someone interested in management, make the responsibilities explicit and provide support. Pairing with an experienced manager and taking on a bounded responsibility is more useful than adding people management to an already full delivery role.

Hiring also needs capacity on the receiving team. A new engineer needs a working environment, an approachable reviewer, and a first task with enough context to finish. If the same senior engineer must unblock every newcomer, hiring faster can make the bottleneck worse.

In interviews, assess the work the role actually requires. For a technical lead, that includes explaining a tradeoff, responding to new information, and helping someone else understand a problem. Agree on the evidence you are looking for before meeting candidates, so a preference for familiar personalities does not decide the outcome.

Keep architecture tied to the problem

Team growth does not create a requirement for microservices. A modular application with clear ownership may still be the easier system to change and operate. Splitting it introduces deployment, networking, and data consistency problems that someone has to own.

Extract a service when there is a reason: an independent release cycle, a different scaling need, or a boundary that the existing application makes hard to enforce. Check whether the proposed service can actually change independently. If every release still needs coordinated changes across both sides, the split may have moved the dependency onto the network.

Meanwhile, ordinary developer tooling deserves attention. A reliable local setup, understandable CI failures, and a safe rollback procedure help every new hire. Choose improvements from the delays engineers report; arbitrary targets for build time or deployments per day can send a platform team toward the wrong work.

Find out where work gets stuck

Look at how long changes wait for review, how often releases need repair, and how much help a new engineer needs to complete their first task. Discuss the causes with the team. A slow review might need another qualified reviewer, a smaller change, or a clearer priority. The number alone cannot tell you which.

Avoid using these observations to rank individuals. People will adapt to whatever is rewarded, and a queue of small commits says little about whether the customer problem was solved. Delivery data should help the team decide what to improve.

The leader's own behavior belongs in that assessment. If routine decisions keep coming back to you, ask what the team is missing: authority, context, skills, or confidence that a reasonable mistake will be treated fairly. Then address that need. The next decision should be easier for them to make without you.