Q&A with Francesco Vivoli on Moving 90 People into 13 Autonomous Teams
We recently talked with Francesco Vivoli, Engineering Director at B2B tech company The Workshop, after an intriguing tweet from him on moving a 90 people “conglomerate” into 13 autonomous teams.
We definitely wanted to know more about this journey and Francesco kindly answered our questions.
We hope you enjoy his insightful answers!
Team Topologies (TT): Hi Francesco. Could you introduce yourself briefly for the readers?
Francesco: So, I’m a developer that has over the years matured an interest in why the craft of developing software products seems to be always so ad-hoc and fraught with obstacles. Nowadays I’m the proud Engineering Director for a product development organization of around 90 engineers. I’m also working on a couple of tech startups which I hope to launch this year.
TT: We were intrigued by your tweet on moving a 90 people “conglomerate” into 13 autonomous teams. What was the initial situation like?
Francesco: When my company asked me to step into my current role, what today is my team (or team of teams I should say) was organized according to mix a of dimensions. Some teams where aligned by technology or component with a remainder of feature teams - which were depending on the other ones anyway.
There was a great deal of Conway’s Law going on and overall not much any team could do that didn’t involve a degree of handoff and upfront scheduling. The perception that the cost of developing a feature was higher than necessary was definitely well-justified.
TT: What was the trigger for the redesign of the team structures and interactions?
Francesco: As I was saying, there was this mounting feeling that changes were intricate. The “system” was definitely not in a state of flow. At the same time, I don’t think that would have triggered any change per se, had it not been for another driver, which was our initiative to rewrite almost our entire product line. Which seems crazy but actually something we do periodically.
So from one side you have a feeling that things can be better and that tied up nicely with an actual program of work.
TT: How did you go about leading this transformation? What kind of obstacles did you face and how long did it take?
Francesco: One of the very first observations we made was around the fact that with teams that are component / technology aligned it’s very hard to have clear accountability for feature development. For me, that’s probably the biggest reason why everything becomes a planning problem, estimates becomes _so_ important and local variations produce such a large impact.
Armed with this, we set off in two major directions. The first was one aiming at rebalancing skills across teams so that - to make an example - not all front-end development expertise was clustered in 2-3 teams. This didn’t take so long and it allowed us to start working on truly end to end features, which we could then leverage to ease our planning pains. It basically took away the need of inter-team handoffs and dependency management.
The second axis of change was centered around how work flows within the team. This means that even in a team that possesses all skills required to develop an end to end feature, you can still have a series of handoffs where for example an user story is split according to individual skills. This usually has the effect of a pretty flat burn rate where nothing is “done” until all pieces are completed.
With this in mind we set off on a much longer journey aimed at broadening the skills of any given engineer. This process has involved training, hands-on doing and coaching and has resulted in an updated working agreement that puts the focus on completing work as opposed to just having more work in progress. It’s been around one year now that we have removed roles like Java or Angular developer; now everyone is “just” a Software Engineer.
I’d say the biggest obstacles have been around providing enough clarity on the reasons why these changes were pushed forward. For example, the whole concept around T-shaping was taken by some as we didn’t appreciate the value of being an expert in something. Which is definitely not the case.
On the plus side, I feel I was very lucky in that I’ve enjoyed a great deal of support from my peers and stakeholders.
TT: Could you share any insights and/or metrics on the benefits this transformation has brought to that organization?
Francesco: The biggest benefit is definitely that we can now start talking about value streams, which opens up the door to giving meaningful missions to our teams that are aligned with our corporate OKRs. The nice thing about value streams is that once you have self-sufficient teams then roadmaps and plans become incredibly easy to manage.
Another massive improvement is that this new working agreement and team structure allows us to implement a true continuous deployment strategy. Prior to that we could push code to production but never a fully developed, value-adding feature. One metric I can share is we ship to production ~15 times more frequently while having somewhere around 3 times less production incidents.
I don’t want to get into the throughput conversation because the type of work we have done recently is fundamentally different than what we had two years ago and it’d be comparing apples with oranges.
TT: Thank you Francesco, it has been really interesting hearing about your experience with organization design. Any final thoughts/recommendations?
Francesco: I’ve found that many people naturally gravitate towards incrementally improving a system without fundamentally changing it. The problem with that is you can endlessly optimize something and still end up with a non-desirable outcome. Sometimes you just need to question the status-quo and take a fresh look.
So I guess that if I had to share a lesson-learnt comment on this whole experience, that would be: find early support and put all your energy into solving something that couldn’t be solved before.
We hope to have Francesco in our podcast soon for a longer interview, stay tuned!
If you want to know more about how to build value stream-aligned cross-functional teams with the right mix of skills, check out our book “Team Topologies: Organizing Business and Technology Teams for Fast Flow”.