You are what you do, not what you say you'll do
We're all equal in the sense that everyone has 24 hours per day and 7 days a week to do something. The best teams and the average teams have the same amount of time. The difference is in how they spend it. In this chapter, I'm going to share the daily rituals we adopted at Stan that enabled us to operate at our peak productivity.
The best way for a Software Engineer to spend is writing code. Writing code is not difficult, but this craft requires time, patience, and flow. At larger companies, most engineers spend a third of their time in meetings. They share context, provide input, brainstorm ideas, mentor someone, or align with someone. While this can be helpful and necessary, we have to remember that an engineer’s time is best spent on building things. We have to protect this time at all costs. Talking about the work doesn’t get the work done.
Here is a calendar snapshot of an average week for one of Stan's engineers. These are all recurring weekly commitments. The empty space is for building.
One of our longest-standing traditions at Stan is our daily Standup, run religiously at 9 a.m. Always on time, never rescheduling. The hardest thing to achieve at a company at any company is alignment. It gets harder as the teams grow. Having the entire (small) engineering team in one room for 30 minutes gets everyone on the same page. Everyone has 5 minutes each to update the team on their work and get input. The Engineering Manager has a chance to share context from outside engineering that happened the day before. During this time, projects get calibrated, shuffled, unblocked, and canceled.
In addition to its main purpose, alignment, the daily standup is a great accountability framework. No one wants to show up in front of their A-player and have nothing to share. It’s a great opportunity to bounce off ideas and reframe problems. Once in a while, someone would say: “I see why you’re doing it this way, but have you thought about X?” or “I see you’re investing a lot of time into this implementation, but I actually wonder whether this work needs to be done at all. What if we don’t do it?”.
Fitting the entire engineering team into a single room to align, share context, and make decisions is remarkably productive. Large teams can’t do that.
If there’s a single, most important management tool available to founders and company leaders, it would be one-on-ones. It’s easy to neglect spending 30 minutes with your people individually, especially when you see them every day. Naturally, A-players on your team are heavy hitters who push themselves to bring back results. While they are at it, they also have things to say, insights to share, and feedback to offer.
Weekly 1:1s are your opportunity to connect with your best people and ask:
These conversations give meaning to everything that’s happening and create an environment for two-way communication. It shifts the dynamic from boss-employee to two people being there for each other, trying to figure out how to bring out the best in each other, share feedback, and help each other grow.
Setting engineering goals is a heavily debated topic in our space. It’s quite surprising how hard it is to get it right. Some companies count the lines of code an engineer has shipped, which can lead to writing poor and repetitive code. Others try to measure the impact, spending unacceptable amounts of time debating what impact actually is.
At Stan, we’ve landed on a simple framework. Every week, everyone on the team is expected to ship one customer-facing update per week that that improves our product in the eyes of our customers. Building on our cultural value of “always be shipping”, we share freedom and autonomy with our people to choose what it’s going to be. In this framework, the product receives 10 people * 52 weeks = 520 impactful updates per year. The impact of small, impactful updates compounds overtime.