Staying close without becoming the bottleneck

A bottleneck can feel like quality control from the inside. I learned how easily I could become one.

For much of my engineering career, being useful meant getting close enough to solve the problem. I could trace a broken data path, write missing deployment tooling, carry a migration across the finish line, or turn an ambiguous requirement into working software. When something important was stuck, moving toward it was usually the right instinct.

That instinct helped me become a principal engineer. It did not automatically teach me how to manage managers.

As my scope grew, people kept bringing me hard problems, and I kept helping in the form I knew best: I got close enough to carry part of the work. In leadership feedback, I was encouraged to delegate more project work and better distinguish supporting a report from stepping in. I understood that as a strength becoming a constraint.

My name for that pattern is the rescue instinct: seeing a problem I could solve and confusing capability with responsibility. It had helped me succeed earlier in my career. At Director scale, it could take ownership away from other leaders.

Most recently, I led a 22-person engineering reporting structure through five direct reports, including three Engineering Directors. Moving from principal engineer to managing managers did not require me to stop being technical. It required me to change what my technical depth was for. I still needed to understand the architecture, test a convenient story against the evidence, and recognize when a risk had crossed a boundary. I could not make myself the route every important decision had to travel.

The difference can be hard to see in the moment. If I take over a problem from an Engineering Director, I may be teaching that Director's team where authority really lives. The immediate problem gets solved, but the decision queue gets longer and the leadership bench gets weaker. Staying accountable means remaining available without quietly relocating the work around myself.

First identify what kind of help is being requested

The most durable lesson I took from that feedback is simple: support is not the same as taking ownership back.

1. Listening. They need room to describe what is happening, test their own understanding, or say something difficult without having the conversation turned immediately into my solution.
2. Coaching. They own the decision and want help examining assumptions, alternatives, consequences, or the recommendation they are forming.
3. A decision. The choice genuinely belongs at my level because it crosses teams, changes a shared constraint, commits resources outside their authority, or requires an accountable tie-breaker.
4. Intervention. There is active resident or security risk, a material service risk or cross-team consequence, dangerously unclear ownership, or a repeated missed expectation that now requires direct action.

The mode can change during the conversation. Listening may expose an active risk. Coaching may reveal that two teams have been waiting on a decision only I can make. A requested decision may turn out to be a reversible local choice that should stay with the person closest to it.

It helps to name the mode. “Do you want me to listen, help you think it through, make the call, or step in?” can prevent a great deal of accidental takeover. So can saying what I believe I am doing: “I am going to ask questions, but this remains your decision,” or “This now crosses a security boundary, so I am taking responsibility for the immediate response.”

I did not produce this tidy four-part model in the moment I first received the feedback. It is the framework I use now to preserve the lesson. That distinction matters to me. A retrospective insight is useful without pretending it was a fully formed operating process at the time.

Technical accountability is not technical control

Technical decisions shape cost, safety, accessibility, delivery speed, and what a team will be able to change next year. A leader accountable for those outcomes needs enough depth to examine the reasoning beneath them. Technical accountability still leaves implementation and local judgment with named owners.

On MyCareer.NJ.gov, I helped lead a statewide workforce platform from an early prototype into a live public service as part of a larger government, research, design, product, and delivery partnership. Within that work, I personally built major parts of the engineering foundation: continuous delivery, release tooling, database migrations, and bilingual middleware. I also architected and directed parts of the system that other engineers implemented.

Those verbs describe different work. Built is not a more impressive synonym for architected. Architected is not a more technical synonym for led. Precise attribution makes the system easier to understand, and it protects the authority of the people who actually carried each decision into code.

As my leadership scope grew, the most valuable use of technical depth increasingly became examining the recommendation underneath the diagram. What evidence supports it? Which failure modes remain silent? Is the choice reversible? Does it affect one team's implementation or a contract every team must live with? Who owns the result after the review ends, and what would make us stop or escalate? The owner should leave that review with clearer authority, not a list of my preferences to implement.

At portfolio scale, I centralized the contracts whose inconsistency could create risk for every team: security and access patterns, delivery and release controls, schema discipline, accessibility expectations, and auditability. Program and technical leads retained authority over their domain outcomes, recommendations, and implementation.

One later decision made that boundary concrete. A new CMS reporting application needed focused capacity and a bounded first release. I held the capacity concentration and first-release boundary. The program owner, technical owner, and dedicated pod held design and implementation. The application reached its first production release in about eight weeks while the existing applications continued releasing.

That is a team outcome. It does not prove that my management model caused the delivery or that every dependency had disappeared. It does show a consequential case in which I remained accountable for capacity and scope without becoming the implementer.

I stay technical through architecture and risk reviews, production-path debugging, and scoped learning, diagnostic, or unblock work under a named owner. Any code I write at that scope needs an explicit handoff. It cannot become a private delivery lane running beside the team.

Growth requires real authority

Nine engineers in the reporting structure I led were promoted, four to Director or Principal. That number does not prove that one framework caused their growth, and I did not make those people capable. They brought the talent, judgment, work, and ambition.

My responsibility was to help create conditions in which that capability could become visible and consequential. People need access to important work and decisions they are genuinely allowed to own. They also need a legible boundary: the outcome, the non-negotiable safety properties, the evidence expected, and the condition that brings a decision back upward.

Another capable leader may choose differently than I would. If only my preferred answer counts as readiness, I am training proxies.

I do not have a formal absence test proving that every critical domain could operate without me, or a clean before-and-after measure showing every dependency disappeared. Supporting without repossessing the work is still a growth edge—a discipline, not a lesson learned once.

The goal is not to disappear

I want to stay close enough to understand the failure modes, challenge a consequential design, recognize when a clean dashboard hides an unhealthy service, and step in when the risk crosses a boundary. I also want the managers and engineers I lead to have enough context, authority, and trust that my presence is an advantage rather than a prerequisite.

The test is not whether I stayed involved. It is whether the architecture became clearer, the owner remained accountable, and the next sound decision could happen without waiting for me.