I’m a member of a monthly meetup of technologists from different organizations throughout the greater NYC area who are looking to become better leaders. This is a wonderful meetup of startup CTOs, VPs of Engineering, Tech Leads, Entrepreneurs, Senior developers on the leadership path, individual contributors, and more.
The monthly meetup is a forum to discuss challenges we face as leaders related to people management, process, and technology. Last week’s meetup was a special event, part of QCon New York, with a presentation centered around Enabling Team Autonomy and Servant Leadership at Booking.com.
Links? Check. Context? Check. Let’s get to it.
So what was the presentation about and what were some of my takeaways?
- What was the presentation about?
- What did Booking.com learn?
- Who was the speaker?
- Assorted musings and tidbits
- My key takeaways
What was the presentation about?
As Booking.com faced tremendous growth, it was critical to ensure their teams maintained high performance and motivation. To this end, Booking.com experimented with autonomous teams - teams without leads/managers - to provide more developer bandwidth, increase motivation, and drive their own (and the company’s) performance.
For context: their “standard” team structure was comprised of a team lead, product owner, and a cross functional team of developers/QA/designers/etc. Team leads were responsible for people growth (~20%), team performance (~20%) and core contributions (~60%).
Autonomous teams would:
- Set their own goals (OKRs, KPIs)
- Work with product owners
- Choose how they want to organize and meet (some do Scrum, some Kanban, etc.)
- Conduct 360 performance reviews
- Not have a team lead
To see if this new structure was beneficial, Booking.com ran an experiment. They kept the majority (54) of their teams standard (team lead, etc.) and shifted a significant portion (24) of their teams to autonomous. Experimentation is built into their culture and they definitely practice what they preach.
So how did it go? - Not so good, some teams did well, but most did not.
What did Booking.com learn?
- Autonomous teams can work, but present new challenges
- Without team leads, there may not be a shield/buffer between the Project Owner and developers
- This could lead to too many features being requested under tight timelines, no time for technical debt, and developer burnout
- Senior team leads were being overtaxed (too many issues were bubbling up)
- Still sometimes need one person to make decisions
- With no team leads, there was no mentorship for engineers who wanted to become a lead
From these learnings, they evolved to “Servant leadership”
- Servant leadership is “democratic leadership” that is not about telling people what to do, but rather working through challenges collectively
- Teams once again had team leads
- Team lead responsibilities were now: people growth (~40%), team performance (~15%) and core contributions (~45%).
Who was the speaker?
- The speaker, Georgiy Mogelashvili, is a team lead at Booking.com with over 10 years of experience in the industry.
- He clearly understood the business, the challenges faced, and presented the material well. He came across knowledgeable, insightful, and cracked a few jokes. Good dude.
Assorted musings and tidbits:
- Booking.com grew rapidly, went from 600,000 bookings a day to 1,000,000+ bookings a day in a couple of years
- Grew from 1 to 2 to 5 offices
- They have ~1,000 engineers
- Experimentation is built into their culture, they put up new features and test them out all the time. If the feature works (e.g. hits KPIs) great, if not, they roll it back
- This experimentation is reflected in their work with autonomous teams
- Performance reviews are done quarterly
- They have agile coaches to help out teams
- Each team is allowed to choose their own tools (e.g. Jira vs Trello)
- However, all code is written in Pearl. Just Pearl, and Pearl, and Pearl. One language to rule them all…
- In the autonomous teams, the performance reviews were 360 reviews and everyone gave feedback to everyone…this process could take an entire day!
- The autonomous teams that did work - including the team our speaker was part of - were allowed to stay autonomous
- Every 2 weeks teams get together and have retrospectives…not on tech/project, but on team dynamic “how are we working together?”
- The big metrics for their teams are OKRs and KPIs (not velocity, burn down, LOC, etc.), this aligns with the findings outlined in Accelerate.
My key takeaways:
- Do not be afraid to change, you can and need to change
- Be a leader, not a boss
- “Team lead” is not about telling people what to do, but rather figuring out problems/solutions together
- Create a safe environment where people feel comfortable sharing ideas and providing feedback
- Teams go through a process: forming, storming, norming, performing
- Autonomy is not scary: autonomous teams can work, but present new challenges
- OKRs and KPIs are critical, have teams create them (bottom up, not top down)
- Do not be afraid to try new organizational structures
- Share trust within the team, all decisions should not fall on one person
- Experiment, learn, and grow