Space to cook: notes on engineering leadership | Ian McCrystal

Writing

Space to cook: notes on engineering leadership

July 29, 2026

Some things I've learned about leadership and management while building and growing software teams. Adapted, in part, from an internal document I wrote in early 2026 while at Stripe and written as a reminder for myself and for anyone interested in software engineering management.

Note: I’ve omitted many of the obvious management tropes like, “invest in your best people”, etc, since these can be read in countless management books and blogs.

Have a hierarchy of concerns

At my last job we would say, "Users > Stripe > Team > Me."

I quite liked this because it is simple, easy to remember, and gets the point across: we're here to serve our users first and ourselves last, and just about every decision we make as teams or individuals can be guided by or checked against that hierarchy: Am I optimizing for my team at the expense of our users? Rethink it. Am I putting myself before my team? Rethink it.

Having an agreed-upon hierarchy of "things we care about and in what order" makes every decision easier and makes it more likely that, in any situation, people do the right thing.

"Users > Company > Team > Me" probably generalizes well to most software companies.

Leadership is a behavior

You can be hired or promoted into a "leadership role" but whether or not you're effective and accepted by your team comes down to how you behave: Do you step up and create clarity for others when no one knows what to do? Do you share a compelling vision for the future? Do you energize and challenge people in pursuit of that vision? This is what separates "manager" from "leader", and the latter is the more valuable thing to be.

Some of the most effective leaders I've worked with were individual contributors (non-people-managers) who took on the behaviors of leadership (either because there was a gap or because they were asked to). They did the things that made others want to follow them, and it didn't matter what their title was.

If you want to be the leader (appointed or otherwise), you have to own it and act the part.

You must have a point of view

If you're running a team within a larger organization, the organization (partner teams, peers, leadership) will put demands on your team. Asks will show up seemingly at random and with varying degrees of urgency: "I need this feature", "I found this bug", "Why isn't this metric moving?", "Can you help me with X?", etc. There will be more demands than you have time for. Many teams go through unfortunate periods where, overwhelmed by asks, they're unable to make progress on their goals.

The single best way to protect the team’s time is to have a compelling vision of the future. If you have no vision to prioritize, you’ll lose every argument about what to work on via escalation (and then your team will feel like they have no agency, no one respects them, etc. etc.) People respect a well-articulated vision (even if they disagree with it) and it will give your team space to cook.

At the end of the day, you are accountable for the collective output of the team. If the team isn’t performing well, that’s on you. If the team isn’t shipping things the company cares about, that’s also on you.

You set the energy and the pace for your team

However you show up is (roughly) how the team will behave. This can be hard because some days you feel like crap, but you still need to show up with energy and optimism (if you can't, take a sick day). This is the responsibility of leadership and it matters a lot. It can also make the job pretty lonely, so it's good to befriend some peer managers to talk to and, of course, you can always gripe up. (If you're the CEO, get a therapist.)

Bias toward action

The fastest and best way to learn is to take some action and see how the world responds. Some problems can be reasoned through purely theoretically but these are rare and, in reality, the world is messy and constantly changing. Once you have a goal or objective to work toward it's almost always better to encourage thoughtful action-taking than tolerate excessive debating and hypothesizing. Sometimes it's obvious what to do, so just go and do it. Most of the time it isn't, and this is where teams can get stuck.

In general, teams that quickly move through the loop of "have an idea => try it out => get and incorporate feedback from the world => repeat" are more effective and make more progress (learning compounds, etc). Teams that spend a lot of time debating and analyzing underperform and get frustrated. Time is a resource that you're managing and it, unfortunately, is unceasing and limited.

(The actions you take should be governed by a set of values and, of course, be in service of some goal. This is not an argument for randomness or lack of focus.)

Being a manager is hard, but rewarding

Some management scenarios I’ve seen or experienced:

The team loves and...