Want Happier And More Productive Engineers? Give Them More Freedom
“Control leads to compliance; autonomy leads to engagement.” - Daniel H. Pink
Background
Last year I wrote publicly about how we designed a highly autonomous team at HubSpot. I encourage you to read that entire post but if you don’t get a chance to here is one of the most important sections:
When you spend more time talking to “internal stakeholders” than your customers, you’ve lost the ship. That’s the truth. It’s a failure that can sneak up on you.
One of the highest impact decisions we made at HubSpot was to constrain both the size of the teams working on a product and the scope of work they undertook. Small teams mean fewer distractions, less risk of getting mired in pet rocks, and a singular shared focus on the customer problem at hand.
Today I want to share some details I’ve never shared publicly.
In March of 2014, I gave a private talk to the HubSpot Executive Leadership Team on how the Product organization (Engineering, Design & Product) within HubSpot was able to operate with a high autonomy model.
Because of our model, I believe we were able to set internal records for employee happiness, employee retention, customer happiness, and team performance.
Here’s the internal presentation I gave (I’ve never shared this publicly):
The Next Evolution: Key Ingredients of a High Freedom Culture
Since we saw how much of an impact autonomy or “high freedom” (as Laszlo Bock calls it in his book Work Rules!) had at HubSpot we wanted to make it a foundational to our culture from day one at Drift.
In the last year we’ve boiled down the ingredients of autonomy to these five things:
- Customer-Driven — This is the most important ingredient. The team has to be spending time with customers continuously. They need to learn to place the customers needs ahead of their ideas. They consistently WOW customers and increase their products usage and adoption metrics. The entire team, especially the tech lead, spends time with customers each week, and the team doesn’t try to offload this responsibility to the PM or Designer because they are “busy”. They understand that delivering customer value and understanding customers is the best use of their time.
- Accountability — This is the ingredient that people get wrong the most. They try to have a model of autonomy with very little or no accountability built into their model. Autonomy with no accountability is anarchy, not autonomy. Each person needs to be personally accountable for their decisions for autonomy to work. Finger-pointing and excuses destroy autonomy. Because of this teams are designed to be as independent as possible (e.g. dedicated, not shared, designer)
- Transparency — The next key is to default to transparency. Each person and team over communicate their goals, performance, ideas and concerns with the entire company via Show-n-Tell time, the Wiki and via a public scorecard of the metrics they are responsible for.
- Iterative Approach — After Accountability this is the ingredient that most people get wrong. They interpret being customer-driven as only focused on major improvements/features. What I have learned is that customers appreciate an incremental approach. An incremental approach shows customers that you are listening to them and making changes based on their feedback. It also turns out that most of the biggest impact items you can improve are user experience issues that are preventing a customer from using your product fully. Don’t interpret being customer-driven as being lost in weeks and weeks of customer conversations.
- Ownership — Critical that individuals/teams be set up to have clear ownership over a customer-facing product. Most companies get this wrong and always regress to a “pool” model where no one has clear ownership and people work across products on design/backend/frontend tasks. In my experience, we need to keep the small independent team model and never let it regress to a “shared” resource model for Customer-Driven Autonomy to actually work.
If you’re interested in developing “high freedom” and high-performance cultures check out the latest episode of my podcast, Seeking Wisdom.
