Nicolas Pieper

Blog · Engineering management

How I organize the Solutions engineering team.

· 5 min read · Nicolas Pieper

Ten engineers, a portfolio of platforms that must not fail, and a manager determined not to become the bottleneck. This is the operating model we converged on, and the reasoning behind each piece of it.

Die-cut sticker: four hand-drawn islands, each with a planted flag, one orange, and small teams at work; two engineers pass an orange block across a footbridge, beside a column of orange blocks sorted from large to small
  1. One portfolioEvery platform belongs somewhere.
  2. Owner and backupResponsibility and knowledge both have names.
  3. One priority viewTrade-offs are made in the open.
  4. Direct contextEngineers speak with the people they build for.
  5. Delegated growthOwnership expands with support.
The operating model: organize the portfolio, make ownership explicit, share context, then grow autonomy.

Start from the portfolio, not the org chart#

The Solutions team does not run one product. It runs a portfolio: established platforms with years of history, newer services still finding their shape, and everything in between. The naive way to staff that is to slice people across projects and hope. The problem is that projects end; platforms do not. Somebody has to care about each system on the day nothing is planned for it.

So the unit of organization is not the project, it is the product area. Every platform in the portfolio belongs somewhere, and every engineer knows which parts of the map are theirs.

A named owner, and a named backup#

Ownership only works when it is explicit. “The team owns it” sounds generous and means nobody does. For each product area there is one engineer whose name is on it, and a second engineer who could take over tomorrow morning.

The owner is the person stakeholders talk to, the person who knows why the system is the way it is, and the first call when it misbehaves. The backup is not a spare wheel; the role forces knowledge to move: reviews flow between owner and backup by default, and the backup takes the lead often enough for the arrangement to be real rather than ceremonial. Vacations stop being risk events. Departures stop being crises.

One list of priorities, visibly arbitrated#

Roadmap features, modernization, technical debt, security requirements and production support all compete for the same ten people. The dysfunction I want to avoid is five parallel lists, each owned by whoever shouts most recently.

There is one view of what matters, and when two demands collide, the trade-off is made in the open. Sometimes debt wins over a feature; sometimes it is the reverse. What matters is that the team can see the reasoning, because engineers who watch priorities being arbitrated honestly will accept outcomes they would have resented as decrees.

Autonomy runs on context#

Owners speak directly with product, business and operational stakeholders. I do not sit in the middle of those conversations, because a manager who relays everything becomes a queue, and queues add latency without adding judgment.

What I owe the team instead is context: why this client matters this quarter, what constraint the business is actually under, which risk keeps the architecture board awake. My interventions are exceptions with a shape: a decision nobody wants to own, an escalation, a disagreement between areas, or a moment where I simply ask “what does this assume, and is it true?”

Delegation is the development plan#

People grow by carrying slightly more than they carried last quarter, with someone watching the load. The progression is concrete: backup of an area, then owner of a small one, then owner of one that talks to clients, then the technical voice in decisions that cross areas. Feedback is regular and specific, and the next step is always visible.

This is also the honest answer to “how do you retain engineers”: you make staying the most interesting option in the room.

What I refuse to do#

  • No heroes: a system that only survives thanks to one heroic engineer is a failing system with good PR
  • No knowledge vaults: if it lives in one head or one undocumented command, it is a liability, not an asset
  • No manager-as-proxy: I refuse to be the mandatory hop between engineers and the people they build for
  • No invisible trade-offs: a priority that cannot be explained is a priority that cannot be defended

The test of the model is simple: could I disappear for three weeks without anything important waiting for me? Every quarter, the answer should be closer to yes.

The condensed version of this model lives in the Solutions team case study. This article is the reasoning behind it.