Currently I lead the Experimentation Services Squad within Skyscanner. Below are my reflections on moving from a dev only team to multi-discipline squad.
When I joined Skyscanner we had “Flights Teams” in Edinburgh who would work on any part of the flights product – front end to back end, stopping short of database work by consuming various APIs created by other teams.
We tried a couple of project teams around this time, but shortly afterward started moving toward the squad model as we all hurried to read “The Goal”. The squad model we started with has changed a lot between then and now, and it’s the latest evolution of my current squad that I want to discuss.
The teams you’ve worked in might have been different, but up until now the teams and squads I’ve been involved in have all been very developer focused. Almost exclusively these teams have been made up of 100% developers, with a project manager or product owner attached – often working across several teams.
This has worked well for the squads I’ve been in without a doubt, especially recently when our squad’s focus was in the area of internal “Developer Enablement”. We completed a migration to AWS, built SDKs in collaboration with another squad in the tribe and got a long way to releasing our new experimentation platform under this model. We knew what we wanted to do, how to do it and we just got on with it.
More recently however the team make up has started to change. At first we gained a data scientist, a little later a designer joined the team and most recently we were joined by a growth hacker. Conveniently this happened as we began moving toward an internal product focus within a tribe focused on helping growth teams win in their markets.
The Good Bits
Now obviously this isn’t going to be a model that is useful or necessary for every team, however, as a team of developers moving from enablement to building an internal product for a largely non-developer user base, this has been incredibly useful.
There are many things, little and large, that have come out of discussions between the different discipline groups we have now that we’d not have considered alone.
Adding data science to the team has allowed us to really drill down and understand the fundamentals of the experiment tool we’re offering. Questions around allocating users, building statistically valid experiments and how to analyse experiments without bias or incorrect interpretation have all been given significant thought by an expert in this area. This information can then be communicated back to the team to inform how we build out the next versions of the experimentation platform.
Having a member of the growth discipline has given us an invaluable insight into the primary user group for the platform going forward, especially useful as this is a group we’ve had a relatively small level of interaction with before now. How do growth teams run experiments? What do they need from an experimentation tool? How do we make the ideal experimentation work flow easy to use and understand? All these types of questions can be investigated and thoroughly thought-out and worked into our roadmap.
Finally having a designer in the team has helped us pull together the requirements from data science, growth and engineering into a coherent vision. We can now take input from data science on the perfect experimentation tool, add the needs of growth teams and bring this together with a fantastic UX to end up with an easy to understand and use system. Having a designer dedicated to our team has been fantastic. Being able to fully explore upcoming development tasks from a design perspective means that we have well thought out user flows and interfaces built out, ready for any of the developers to pick up and execute. No more tacky elements tagged on without much thought just to complete the current card.
Having all this extra input has been incredibly eye-opening, never before have we had such a clear understanding of the rest of the business, what we need to build and why.
Of course, having this extra input doesn’t happen magically and as a team new to integrating other disciplines into our workflow we’ve had a few challenges along the way. It isn’t rocket science but hopefully it’ll be useful if you are facing a similar situation.
Firstly I’d highly recommend going through a goal setting exercise, or at least taking a look at the “why” of your team again. Perhaps working to a back brief style template you might be familiar with if you’ve come across “The Art of Action”.
This was especially useful for us as we had recently changed goals. It allowed us to take our stated execution plan and break it down – where could each of the disciplines add value? In which order could we do things so that any data science research, user testing or growth analysis could take place ahead of the developers picking up the work? Doing this made sure we were all aligned on a vision and that everyone, not just the developers, had meaningful goals to aim toward.
Another challenge we had was making sure we get input from each of the disciplines at the right time. There is little point in a developer picking up a card only to be blocked waiting on the data science investigation or querying why the design doesn’t match reality. This sounds pretty obvious, and all it takes is a little forward thinking to solve, but when you’re used to creating cards that anyone can work through end to end it can be easy to forget. Calling this out in planning / pre-planning and going through the backlog with an eye for this type of issue every so often can be helpful.
I also want to mention meetings. In changing our goal and tribe, plus adding new team members we’ve had more meetings recently than I’d care to admit – some have gone amazingly well and others have been terrible. As a team our number one take-away from this process has been to embrace small targeted groups for meetings. Rather than having a mega full-squad meeting, with members in different locations, break the meeting down into sub-groups. In our case that can mean data science, growth and design coming up with a shared vision as a small group before presenting that back to the developers or perhaps just a designer and a developer having a catch up on a specific topic. For this to be effective everyone needs to be comfortable that they can’t know everything that is going on all the time, but as long as you can communicate the headlines back to the group via Confluence, Slack or something else this is much more effective than mega meetings, in our experience. We’ve also found that sending out a Confluence pre-read and agenda is super helpful in making sure we can have short action-oriented meetings – push back on meetings without an agenda!
Finally – call out meetings that aren’t working. We found this helpful when we mistakenly called a mega meeting at short notice, 10 minutes in and it was clear we weren’t going to get what we needed out of the meeting. The call connection wasn’t great and we were spending more time asking people to repeat what they’d said than discussing the issues. At this point it made most sense to give everyone their time back and come at the problem again from a different angle with smaller groups. You don’t necessarily have to cancel the meeting, but be brave enough to call out meetings which aren’t working toward actions and save everyone useful daylight hours.
I really hope that more teams in Skyscanner move toward a multi-discipline approach, especially in product areas or where we’re developing internal tools for a specific non-developer audience. The close collaboration between disciplines within a team leads to amazing outcomes and well-informed decisions, without the overhead of ongoing cross team meetings, competing time commitments and the other little things that get in the way of collaboration over the course of a day.
Before we had it we didn’t know we needed it, when it first arrived it was a little overwhelming but now we wouldn’t want to live without it.
Here’s to the data scientists, growth hackers, designers and all the other disciplines out there!