Principles

One of my team leads came to me today with a proposal. I gave feedback, we talked it through, and at some point we laughed about whether it would be possible to know in advance what my reaction would be, whether my thinking was consistent enough that you could predict where the pushback would land before talking to me.

So I tried to write my positions down, not as advice but as a skill for Claude, an interactive piece that captures the principles I operate on, specific enough that someone could use it to support or challenge an idea the way I would. I don’t like being critical in a certain way, or to come across as a smart ass that pretends to have seen it all. Yet I went through a lot of painful realizations in the last decade from feeling accountable for my team’s outcomes and owning our mistakes.

None of these principles stand alone, and they all point at the same thing: fewer situations where someone has to ask before they can move. (Or simply said, it’s me being lazy and removing myself from the decision-making process.)

Working on ideas and solutions#

Good ideas are not enough to justify the work, especially not in a world with an abundance of tasks: what matters is whether something will change, for whom, at what cost, with what benefit and whether it needs to happen at all. Some of the questions below are specific to roadsurfer, where removing manual work is one of the central objectives.

• Define what is different afterwards: what the actual end state is and how you would measure it, not what happens during the work.
• Eliminate complexity, don’t relocate it: anything new replacing something old is not progress if the same people are doing the same work in a different place. An automation that gives someone a new step to manage is not automation, it is migration.
• Identify who actually benefits: which specific person has a better day because of this, and for me that person is almost always a customer.
• Consider what happens if you don’t: what you would lose is often more revealing than the proposal itself.
• Start smaller and validate before committing: most things that fail do so at an early scale.
• Clarity of communication signals clarity of thinking: if a proposal needs five paragraphs to explain what it does and why, the thinking is not done yet.

Working with people#

I start from the assumption that everyone acts from good motives. Nobody does something badly on purpose, and nobody is trying to work against someone else. When something goes wrong, I look for the system or the situation before I look for the person.

• Have a view, defend it when challenged, update it when the data changes: people with opinions propose things, and waiting for direction is a bad choice, even if it does not feel like one.
• Bring the problem, not a finished solution: thinking it through together is usually where the better decisions get made. When someone flags a risk, I seek the options and a recommendation, not just the risk.
• Be precise when something is difficult: what changed, why, and what it means going forward, because people fill vagueness with anxiety.
• Build relationships before decisions need to be made: share your point of view early to shape things before things are decided, and use those same conversations to understand what is frustrating your stakeholders before it becomes a crisis. If a stakeholder reaches out to me instead speaking to my team, that responsible person has not built the relationship yet.
• Define what needs to happen, leave the how to the team: specifying the how is micromanagement, even when it is disguised as sharing an opinion. (If you are a nosey and genuinely interested person like I am, this is very difficult to deal with as it requires you to step back a lot.)
• Make wins as visible as problems: if you don’t, the team operates as if there is only ever a deficit. I often get feedback that my praises are not scarce enough and even for small things feel out of place, I do not care because I genuinely think even small pieces of good work deserve recognition.

As a leader#

The way I think about leadership is mostly structural and conscious: what conditions you create for others, not how present you are in the execution.

• Empowerment is a structural test, not a style preference: if the team still needs you after sign-off, the thinking is not done. Stepping in is sometimes necessary, but making it a habit prevents the team from growing.
• Drive your domain without being asked: if something is broken or missing in your area, improve it, because waiting to be prompted is not accountability nor ownership.
• Communicate vision, not just milestones: when only intermediate goals get communicated, those become the final goals.
• Push back on learned helplessness: identifying the pattern, naming it, and pushing for ownership is more useful than accepting that the team cannot move without support. This also has a high risk to become toxic and spread into a downward spiral of hopelessness. People start leaving quickly in these environments.
• Move toward hard things, not away from them: most things that look impossible are a question of approach. When a plan runs into something unexpected, that is information, not a conclusion. “Therefore it cannot be done” is a failure of belief, not a reasonable conclusion.
• Embrace ambiguity: I wrote more about how I think about ambiguity separately.

The full skill#

This post covers only the first layer of the skill and a subset of principles. The full document goes deeper into the topics that come up most often: systems and simplification, budget and investment, hiring, roadmap and prioritization, engineering, data, and AI. There is also a section on the key people in my organization and the stakeholders I work with most, so whoever uses it understands how I think and who the relevant people are and what drives them.

Writing it down#

Writing this as a Claude skill was more useful than I expected. In a meeting I can fill gaps as I go, but writing forced me to say things I had only ever implied.

The first day of using it with some of my team, the skill came across as judgmental and directive, which is exactly the opposite of how I try to lead. This document can capture what you think but not easily how you hold it. I do not think a skill like this replaces real conversations with my team, and I would not want it to. At most it is one small tool among many, and right now it is not even that yet.

I hold these expectations for others because I hold them for myself, and I give myself the least room to ignore them. I pull myself back when I want to go deep into a detail, or when I want something done a specific way, or when I am swallowing frustration about something. The principles do not get easier just because I wrote them down. So I might be the one that will be using that Claude skill the most.