I’ve worked at Buffer since 2014, and even before I joined, I was always impressed by the product and engineering culture of the Buffer team: how quickly they shipped improvements and how close which was everyone from the users (it’s not uncommon to see engineers responding to comments on Twitter!).
I found this can-do attitude inspiring and contagious, and it’s amazing when things click like that. Of course, when I joined, we were a team of 24 people; we all wore many hats and had no manager.
As we grew, we began to embrace building team structures and processes to better support and manage that growth. But of course, scaling collaboration while maintaining speed is an art in itself, and friction points began to appear: projects would hit bottlenecks more often, and teams would block each other. Since it would take longer to release features, we would try to get them “right” by spending more time working out the specs of what we tried to build, but of course the bigger the projects, the longer it took to deliver .
We were stuck in a self-reinforcing loop – if it took months to build something, it was very difficult to fast-track and iterate because we’d have other priorities to attend too! This kept reinforcing the need to do more and better and continued to create more pressure to “get it right”.
Last year, we realized we wanted to change certain habits and dynamics at Buffer to get back to the early days of sending frequently – the more regularly we send, the easier it is to manage these changes (because they’re smaller). It feels safer even if the thing we’re shipping fails, creating greater psychological safety for our team. It was clear: we wanted to be builders again and embrace our entrepreneurial spirit and our culture of not acting.
The metrics that help us define creator mode
How will we know we are in builder mode? That we’re moving faster, shipping more often, and tightening our feedback loops with our customers? Some metrics are useful to guide us on this journey: cycle time, the performance of the pull requesti defect rate. Here’s some context on what these metrics mean and how we measure them:
cycle time
Because we want to reduce our time to market, we want to measure how quickly and how often we deliver value to our users. Cycle time is, for us, the time between when we start working on a feature or enhancement (the first change we make to the code base for it) and when a Print request with the changes it is merged and launched into production.
Pull Request Performance
Pull requests are the artifacts we generate as developers to begin the process of merging new code changes into the current code running in production.
We can think of each pull request as a unit of work that provides value (for example, a new feature, a bug fix, or any other improvement to the code base). This is why a total count of pull requests merged (and deployed to production) can be an indicator of delivered value.
Defect rate
Of course, moving faster doesn’t improve anything if it means we’re sending more defects and bugs to our customers!
Defect rate acts as a monitoring metric for us, where we measure how many of the code changes we make address bugs that were introduced in previous changes.
Dynamics we have implemented to drive this change in engineering mindset
Just as habits are vital to shaping our identity as individuals, they are fundamental to evolving our mindset and culture as a company.
Knowing what we wanted to achieve and how to measure it, we started thinking about new dynamics that, as we adopt them, help us build our identity as builders. Also, we kept our eyes open for existing habits that were holding us back from reaching the next level.
Customer engineering sessions
A crucial component for any builder is being in touch with their customers: interacting directly with our customers is key to gaining insight into the questions they ask, the needs they have, and the pain points they feel in our systems.
With customer engineering days, we have each engineering team assign an engineer to each cycle paired with an advocate for a day answering tickets in the inbox and fixing quick wins together. This is a great opportunity for engineers to ask our customer advocates questions about our customers, features and products, and for advocates to share their experiences and provide insights about our customers.
Removing lock extraction requests as much as possible
As we embrace a faster moving culture, one of the first things that struck me was the review process for integrating changes into production: some teams would have a rule that required another developer to review the your code before pushing a live change. Industry benchmarks and research have shown surprising results: approval processes for code changes are not correlated with software delivery performance.
We want to remove change control, promote ownership, and empower people to stay in a state of flow, so teams have started to move away from defaulting to opening pull requests and waiting for approval, and use a hybrid method called “Submit/Sample/Question”. :
- ship it just means this! No need to request a review, just make the change and deploy to production.
- show it’s great for getting asynchronous feedback or sharing some new patterns and learnings with the team, but without waiting to get approval before sending them to production.
- question is the traditional approach where a code review is required before it is merged and sent to production.
Being clear that there are different alternatives and approaches for different situations means that teams can figure out what balance to strike and see if they’re too much in ‘ask mode’ when they could be moving more towards ‘shipping’ or ‘showing’.
Working smaller
Of course, if we focus only on the above practices, it would appear that we are only asking teams to work harder and faster. These goals and practices are for us to challenge and improve the way we work, not how much we work!
A key component to ensuring this, and a huge contributor to becoming a higher performing team, is working smaller: If we break our work into features that allow rapid development instead of larger, complex projects that release infrequently.
Because of this, engineering teams embrace the use of feature changes (also called feature switches) as a way to roll out new features that are still in development to production without negatively impacting the user experience. This eliminates large releases that contain many changes, and instead we can release new features to our users when we’ve already experienced them in production.
Working in smaller batches creates greater psychological safety for our engineers, as the risk of rolling out breaking changes that affect everyone is greatly reduced.
The role of engineering managers also changes to become builders
While the role of the engineering manager across teams has focused primarily on people management, engineering career growth and coordinating ways of working, his key responsibility is to ensure that our teams deliver value by building our product and teams in a way that aligns with our technical and product goals.
So, to truly lead with this builder mindset, our engineering managers need to become builders too! We’ve redefined the role of the engineering manager and now aim for them to spend at least 25% of their time on the team. This “practice” can take many forms, including:
- Deep dive into data analysis for a new feature launch.
- Working on non-critical tasks.
- QA’s new features.
- Interaction with customers.
This gives them even better context and insight into the technical decisions and tradeoffs their teams face and creates a sense of shared ownership across the team as we all contribute in our own way to publishing more often .
The Results: Have We Adopted the Builder’s Mindset?
We started this mindset shift journey 9 months ago and it’s been an incredible journey of cross-team alignment – the number of features and improvements we’ve shipped in the last few months is a reflection of all these changes. We keep asking ourselves “how can we ship the next one faster and with better quality?”. We feel there is a change in motivation and energy.
Now, if we go back to the metrics I shared earlier in this post, we can see that:
- Cycle time has dropped dramatically, from an average of 94.8 hours in 2021 to 55 hours in 2022 so far.
- PR performance is up: 4155 pull requests deployed in 2021 compared to 3687 deployed in 2022 so far (1816 pull requests more than the second half of 2021!).
- The defect rate has dropped: from 18% of time working on fixing defects in 2021 to 16% in 2022 so far.
This means that the engineering team releases faster and more frequently, and that quality is not at odds with delivery speed.
There are some big technical projects underway that will accelerate the entire engineering team much more in the second half of the year, so we’re just getting started! Are there habits your team has been doing that has helped them increase their shipping rate and get closer to your customers? As we continue on this path to becoming builders, I’m excited to continue sharing our learnings and progress along the way.
Feel free to reach out to me on Twitter at @msanromanv to share your experiences!