This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...
About 4 months ago as we entered this new normal, thanks to the pandemic which shall not be named, we asked ourselves how we could best position Pinpoint for success in light of working from home and the general disruption to our daily lives (read how our team's have adapted to remote work.) We started to revisit how we had structured engineering and what we could do to become more effective.
Our engineering team had been divided into a typical structure of siloed stacks of frontend, backend, data science, and infrastructure teams. We called this an “east-to-west” team structure where one team would work on an issue and then it would have to be passed back over to the other functional team. This model had us feeling a bit stuck in the mud.
We researched how other high-performing organizations had structured their engineering teams to be more effective. We knew that however we structured the team, we would continue to be fail-friendly and focus on continuous improvement driven from the bottom up. We also wanted to maintain our culture where mistakes are not discouraged but the learnings from those are shared.
As we started to look around at what other engineering teams were doing we came across the Spotify model which is fairly well known across the industry. There is a two-part video series, Spotify Engineering Culture that covers it pretty well. This model aligned well with our wishlist and the nature of having full-stack teams that control their own destinies made this feel like the right approach.
The Spotify model focuses on fostering community and trust rather than structure and control. It consists of a few basic concepts: agile methodology, decoupled releases, teams composed of autonomous squads, and small and frequent releases. There is quite a bit of controversy over the fact that even Spotify no longer uses the Spotify model but, I think that’s the point. When seeking to improve in any particular area you want it to be an evolution where you continually adapt — not just adhere to some stringent model that worked for you at one time. We adapted the Spotify model to a framework that we felt would work for us.
Some of the principles of the Spotify model that we embraced were:
We quickly made the decision to move to full-stack teams where each team is self-contained and autonomous. Each team is equipped with all the functional areas it needs — frontend, backend, data science, and infrastructure expertise. This reduced the need for work to move in and out of the immediate team in order to be more productive. During our weekly priority call, each team would be given a business objective and the team would be responsible for defining how they would work and how they would build it.
Below you can see the Epics our teams are currently working on inside our Organization Dashboard. I use this to keep tabs on how things are progressing and specifically if any of the teams are blocked. It also helps me understand when things are projected to finish which allows an open discussion with the team when things start to become at risk. As a part of our priority call each Monday we will review these Epics to align on priorities and to allow the teams to give current status updates. We also use this meeting to determine if there is some new body of work that teams should be prioritizing ahead of their current work train.
At the heart of our model, we wanted to build a true MVP culture. The Spotify approach had a mantra of “Think It, Build It, Ship It, Tweak It” which is relevant not only to our engineering teams but throughout our entire company. Our teams are encouraged to deliver the smallest features possible that will bring value to our customers, get their feedback, and then iterate quickly. The purpose was to have fewer points of decision making and give more autonomy to the smaller groups.
It was also important that we kept the functional areas of expertise such as frontend, backend, and data engineering communicating well and bringing the knowledge and tooling back to their respective working teams. Spotify called these guilds and we do as well. These guilds meet at least once a week to share what they are working on, any issues they are faced with, and tools that could help, and then bring that knowledge back to their teams. We have incorporated other means of knowledge sharing across the entire organization such as sprint demos and lunch and learns.
We decided early on that we would occasionally shuffle the teams to meet the needs of the business. We do not do this just for the sake of doing it, but to ensure we have the best teams assembled to achieve our short term goals. There are other cultural benefits of building comradery amongst the entire organization by allowing people to interact and work with each other.
The benefits of this team and guild structure is that each team has the expertise required to release a feature, they control their own releases and plan as a team. The idea is we would see less east-to-west communication and more north-to-south where the teams controlled their own destiny end-to-end.
After making these changes, we saw immediate results, and the teams rallied around the concepts much quicker than I could ever have imagined. Within the first week, the teams started commenting on how they felt much more empowered to make the right choices and work on the smallest iteration. It also eliminated group thinks where we typically hopped on calls, bantered about some ideas and waited for the decision to come down — all which slowed down work. Our product management team was also no longer the go-between for the siloed teams.
Some of the measurable results we saw within the first month of making the changes included:
We now have one priority call each Monday with the team leads to ensure alignment and to adjust priorities as necessary but then it’s up to the teams to determine what works best for them. Most teams collaborate daily in Slack and use our Stand-Up feature in Pinpoint which eliminates the need for additional meetings.
Our average cycle time on issues went from nearly 6 days to right around 3 as shown below in our team dashboard.
There was a huge uptick in the issues being closed as well as code being deployed. In one, 14-day period we saw 125 issues closed by our three teams, 293 merged pull requests with 709 commits!
There were 130 deployments of our web application and over 100 backend deployments in a 1-month period along with 8 major features released. Check out our changelog to see all of the releases.
I was blown away by how the teams embraced the new model and continue to be amazed at how much a small team of engineers can get done with a simple alignment change. It also helps to have an extremely talented group of people that embrace change and get stuff done.
Keep an eye on our changelog to see what this awesome group of people will do next!
Vice President, Operations
Automating data science is hard, and we do a lot of it.
As part of our latest release, our Agent underwent a complete transformation in order to simplify the installation of in...