Leadership principles I practice
, 3 min read
Leadership became more concrete for me as my responsibility moved beyond the code. A technical decision changes a system. A leadership decision changes who can make the next hundred decisions, and how well they make them.
These are the principles I return to while building products and teams.
Plan while the direction is uncertain
Planning should reduce uncertainty. Once the direction is clear, another planning cycle often delays the evidence the team needs.
I plan when the team disagrees about the goal, the cost of reversal is high, or an untested assumption sits under the work. I push for delivery when the decision is reversible and customer use will teach us more than another meeting.
The leader's job is to tell those conditions apart and make the change of pace explicit.
Adapt to the person and hold the outcome steady
People need different kinds of support. One engineer may need a clear boundary and room to work. Another may need faster feedback or help turning a broad problem into a first step.
Adapting the support does not require lowering the standard. The expected outcome, owner, and review point should remain clear. Fair leadership gives people what they need to meet a shared bar.
AI can produce code; people own the result
Generated code makes implementation faster. It does not own intent, judgment, coordination, or the production incident.
Engineering leadership now places more weight on problem selection and review. Teams need to understand why a change exists, which behavior matters, how the system can fail, and who will make the call when the evidence is mixed.
Code volume is a weak measure of progress. A team that deletes an unnecessary service or replaces a model with a rule may have made the stronger engineering decision.
Put company goals into the work
Company goals become useful when teams can connect them to product behavior and customer outcomes. A slogan at an all-hands does not create alignment.
I want a team to know which customer problem a project addresses, what evidence will change our view, and which tradeoff we accepted. That context helps people make local decisions without waiting for approval.
Personal growth should happen through meaningful responsibility. The company gets better work, and the person gains judgment that survives the current project.
Reward care and ownership
Technical skill can grow through practice. Care is harder to create through process.
I look for people who notice when a result is incomplete, ask about the effect on customers, and stay with a problem through the unglamorous last mile. Leaders should protect that behavior from environments that reward visible activity over durable outcomes.
Ownership also needs boundaries. A person cannot own an outcome without authority, context, and time to act. Assigning responsibility without those conditions is delegation in name only.
Do the homework before asking for trust
Teams read a leader's clarity as evidence of preparation. A vague answer may be honest, but repeated vagueness tells people that the decision has no owner.
When I do not have an answer, I say what I need to learn and when I will return with a position. That is more useful than filling the space with confidence.
The quality of a team's decisions cannot rise far above the quality of the context its leaders provide. Clear goals, named tradeoffs, and honest uncertainty give people something solid to work with.