What I want a technical leader to stay close to
I do not think an engineering leader stays technical by trying to remain the fastest programmer in the organization.
That is an appealing contest because the feedback is immediate. I can write something, run it, and see a result. Leadership work often has a longer delay between a decision and its consequences.
But competing with the team for implementation work can make the organization more dependent on the leader. That is a poor outcome even when the code is good.
The reason I keep building is different: it helps me maintain useful judgment about the work I ask others to do.
Stay close to the constraints
In my work at Samsara, important decisions cross hardware, firmware, machine learning, quality, and backend services. I need to understand enough of those constraints to recognize when a plan leaves out a difficult part.
Where will the behavior run? What does it need from the device? How will we test it? What happens when the environment changes? Who owns the result across the boundary?
I do not need to make every detailed decision myself. I need to help create a conversation in which the important tradeoffs can be made explicitly.
Technical depth is useful when it lets me ask a better question, detect an unsupported assumption, or help teams resolve a dependency. It is less useful when I use it to override someone who understands the local problem better.
Keep a place to experience the tools directly
My independent projects give me a way to work directly with coding agents without making every experiment an organizational initiative.
I can try a delegation pattern, experience a context failure, build a small tool, and see how much work remains after the generated code arrives. That helps me distinguish a promising demonstration from a workflow I would want other people to depend on.
It also keeps the inconvenience visible. The repeated setup, the stale state, the misleading completion report, the review queue: these are easy to miss when looking only at polished examples.
An experiment on my own project does not establish that the same approach will work across a larger organization. It gives me a better hypothesis and a clearer idea of what to measure next.
Leave room for people to own the answer
There is a useful difference between being able to understand a decision and needing to be the person who makes it.
I want strong engineers and managers to own their work. My contribution should be to make the goals, constraints, and escalation paths clearer, and to help when a decision crosses their authority or information boundary.
Hands-on experience should make that delegation better. If it turns into a reason to pull every decision back toward me, I am using it badly.
The test I use
I ask whether staying close to the details makes the organization more capable when I am not in the room.
Did we clarify a contract? Improve a test path? Develop another person’s judgment? Remove an ambiguity that had been slowing several teams? Those are useful returns on technical involvement.
That is the version of a technical leader I want to be: able to enter the details when the decision needs it, and able to leave behind a system that does not require my constant presence.