Recently, I came across Patrick McKenzie’s blog post about working at Stripe. He breaks down why he feels like Stripe has been able to move faster than most other companies of the same size.
There are obviously many factors at play here including organizational policies, team structure, communication norms, hiring…the list goes on. I really loved this line of questioning though:
I have seen truly silly improvements occasioned by someone just consistently asking in meetings “Could we do that faster? What is the minimum increment required to ship? Could that be done faster?” It’s the Charge More of management strategy; the upside is so dramatic, the cost so low, and the hit rate so high that you should just invoke it ritualistically.
Most organizations operate at nowhere near the frontier of their capabilities. That is a choice, and strikes me as a valid choice, but you can choose to move closer to the frontier, too.
What Working At Stripe Has Been Like, Patrick McKenzie,
There truly is very little downside in asking the simple question “Could we do that faster?”
That question has been bouncing around in my head for quite some time specifically as it relates to my role in leading people and teams. How can I create an environment that increases the cadence of our team? What obstacles commonly get in the way? How can we avoid them?
Here’s a non-exhaustive list I’ve compiled on why teams move slower than necessary and how to address each.
We’re waiting for “perfect.”
If you’re continuously waiting for the perfect iteration, you’ll waste months of time, learning opportunities, and incremental progress. Shipped is better than perfect.
For example, I worked on a team once that was responsible for rolling out a new onboarding experience for a segment of customers on WordPress.com. New sign-ups would be offered a one-on-one session with one of our Happiness Engineers. We could have waited until we had the perfect set of tools built right into the product. Instead, we opted to email customers individually and set up one-off Zoom links. This was much more work upfront, but we started learning immediately. It was a big learning experience for me and continues to influence how I approach projects.
Don’t wait for perfect. Ship something. Begin learning. Iterate over time.
Urgency and importance aren’t clearly communicated.
If we’re losing $100k per day with a million dollars in runway, we have a huge problem that needs to be addressed right now. I’m doing an obvious disservice if I ask someone to “Look into our churn rate and see if we can make improvements.”
When establishing projects or assigning work, reiterate the importance, priority, and ramifications of the work whenever possible.
The approver isn’t known. Or, we’re waiting for consensus.
It’s easy to waste time searching for the right person to sign-off on a particular project. Depending on the size of the group, gathering consensus can be even more difficult.
For every project, it’s worth clarifying the DACI upfront even if just making a mental note. Some suggestions related to the DACI framework and getting agreement:
- The due date is a critical component. Projects and decisions without a due date tend to drag on in my experience.
- Similar to the due date, milestones are important to communicate, as in “Get feedback in by XYZ.” In most cases, I’ve found that 48-72 hours creates a sense of urgency while also allowing ample time for teammates out of office or in different timezones.
- For contributors, it’s key to let them know how, when, and where to contribute. I’ve also found it helpful to specify the kind of contribution I’m looking for at particular points along a project (do I need help brainstorming ideas or fine-tuning a particular process?).
- If you’re looking for 100% consensus before moving forward, follow-up individually. This is rarely a necessity and more of a comfort factor in my experience and typically only applies in small groups when deciding about big process changes that will impact everyone. In that situation, reach out individually 24 hours before the contribution window closes with a personal note.
Historical norms are holding us back.
This can manifest in a few different ways:
- If everyone is used to storing up ideas for the next quarter, we’ll get comfortable with keeping an ideas list and waiting to move until an idea is formally baked into a quarterly plan.
- If we always discuss ideas on Tuesdays during our company meeting, it will be exceedingly difficult to move a new idea forward on a Wednesday.
- If a certain level of management generally leads big projects, it can be difficult for individuals at a lower level to feel empowered to run with new ideas.
This harkens back to another quote from McKenzie’s post about cadence:
Design control and decisionmaking structures to bias heavily in favor of preserving operating cadence.
What Working At Stripe Has Been Like, Patrick McKenzie
Historical norms and company policies impact speed both positively and negatively.
Communication pathways are holding us back.
Communication mediums matter. Synchronous meetings have their advantages as do asynchronous modes of communication. One isn’t necessarily better than the other. The key is to have both available to your team and accepted guidelines for each.
Group size also plays a role here. In my experience, work is often best accomplished solo and communicated in groups. For example:
- Team meetings are great for informing everyone of decisions, getting consensus where necessary, and ideating a list of necessary work (i.e. what needs to happen by next week?).
- Small Working groups are great for assigning work, scoping a project, and deciding on deliverables.
- Individual working sessions is where the actual work is accomplished.
Team meetings are generally not the place to solve the problem. It’s better to identify the problem, set the boundaries, and decide who is interested in doing the work.
Individuals don’t feel empowered.
Finally, each individual in the organization should feel responsible for the cadence and empowered to influence it. Revisiting the original quote in this post:
I have seen truly silly improvements occasioned by someone just consistently asking in meetings “Could we do that faster?”
This isn’t just a question for managers or company leaders. It’s a question everyone should be asking routinely.