Over time, I think all leaders come up with a series of ideas that they aim to convey over and over again. These principles might be based on what they’ve seen work (or what they’ve seen fail!), or the ways that they find the most comfortable to work. These are my current set of leadership principles; some of these have been stable for quite some time, while I’ve only recently seen the important of others.

There is only time to work on the best idea

Many teams waste a lot of their time solving the wrong problem. A team is most effective when we continuously ask ourselves if we’re solving the right problem, and if it is the right problem to solve right now. We always ask why we’re doing something, and are not afraid to deprioritize work if it no longer seems the best path

“Progress means getting nearer to the place you want to be. And if you have taken a wrong turn, then to go forward does not get you any nearer. If you are on the wrong road, progress means doing an about-turn and walking back to the right road;” -CS Lewis

All of this means that we aggressively seek out feedback and value being on the best path vs being right. It also means that we value impact over output – the best ideas are often those that have disproportionate value relative to their effort.

It’s us vs the problem

“I told you so” is one of the least helpful professional sentimets. A team’s goal is to add value to the world, and doing so is a team sport. We work in concert against the problems we face, and differing viewpoints of or conflict about the best approach are only in service of ensuring we are successful as a team tackling the problem in front of us.

Iteration over perfection, long-term excellence over short-term time to market

We strive for continuous, iterative improvement. We’d rather improve 1% each day than 30% better at the end month – both because our users will feel that continuous improvement, and because feedback on each step of the process is critical to continued improvement. Being iterative allows us to avoid unnecessarily long planning, avoid deadlocks, and derisk what we do faster, increasing the value we create for users. Postponing shipping leads to them being outdated, creates complexity in managing what’s not been shipped, and delays learning what high quality is. This is balanced by a desire to build towards long-term excellence; that means that we prefer to build a high quality core and then iterate quickly on the surrounding systems.

Operate at different altitudes

I believe in operating at different altitudes and leading from the front. Does that mean I shouldn’t think about the highest leverage work I could be doing, or that I don’t trust my team with critical tasks? No! Does it mean that sometimes I write code, or take an on-call rotation, or do some other task alongside the team that they usually handle? Yes! I believe that this builds my own empathy, gives me a deeper understanding of what’s going on, and helps build context. I learned this from Michael Lopp at Palantir, where he called this tasting the soup

The decision maker is singular, and explicit. The person doing the work owns the decision by default

One of the most effective ways to lose velocity is to make decisions ambiguous. If a decision requires multiple people to say “yes”, or if it isn’t clear who can even make a decision, projects will tend to move very slowly or attempt to route around important decisions instead of tackling them head on. Every decision has a single decision maker and who they are is explicit - if, at any time someone is confused as to who is the decision maker, they should raise their hand and help resolve the ambiguity.

The person closest to the work is the decision maker, by default. They tend to have the most context and centralizing the decision making tends to lead to efficiency. This doesn’t mean that they can make those decisions without consulting others, and sometimes there are decisions that do need a different decision maker, but pushing that responsibility as close to the work as possible leads to better outcomes on average.

The process was made for us, not us for the process

Process is important, but my ideal process is the least amount of process that allows us to achieve our goals. Because the process is made for us, not us for the process, if the process is getting in the way of doing the right thing (see There is only time to work on the best idea), we should jettison it - while making it clear that we’re doing this.

This principle does mean that organizations I lead tend to have seams that are in danger of bursting. I try to patch those seems in a “just in time” fashion - neither patching them too early (where the fix means we will have more than the minimum amount of process and may not be the right fix) or too late (when something has totally burst at the seams). For some, this can be anxiety-inducing because there are areas where stuff is almost going wrong.

Teams are teams

A team shares a common vision, and goal, and succeeds or fails together. They aren’t a group of people who happen to work in the same room. This also means that teams support each other, care about each other and do the deep work to build a culture and environment where we can function as a cohesive group. We are one team. There is only one Mindbody team, and only one engineering team. Because everyone has a clear vision, we are always working cross-functionally, thinking about how our decisions impact other teams.

Who you hire is who you are

The people we surround ourselves with are our destiny. We believe in hiring people who are passionate about the mission we’re on - whether that’s passion about fitness, wellness, helping small business, or our interesting technical problems - smart and driven. We also believe in hiring folks who are not a culture fit, but a culture add - people whose presence on the team, due to a different background, viewpoint, or experience will make everyone else stronger.