On this episode of the Story of Software podcast, Didier Caroff, VP of Engineering at Akeneo, shares his insights on structuring and restructuring engineering teams as tech departments grow.
The Guest – Didier Caroff, VP of Engineering at Akeneo
Didier Caroff is the VP of Engineering at Akeneo, a global leader in product experience management. Akeneo helps merchants and brands deliver customer experiences across all sales channels, including eCommerce, mobile, print, and retail points of sale to global brands such as Sephora, Fossil, Shop.com, and Auchan.
How to Structure Engineering Teams
As software departments grow, the requirements and processes needed to sustain a solid team structure also change. How a 10 person software team works and communicates is vastly different from a 50 or 100 person team. So, what are the ideal conditions and structure to create a productive engineering team?
Some of the topics covered in this episode include:
- Ideal engineering team structures for startups and scaleups
- Quality assurance within autonomous squads
- Team structures that maximise engineer satisfaction
- Common mistakes when structuring engineering teams
Transcript (abridged version):
[…]
I would love to talk to you about the structure of engineering teams within a startup. From your perspective, is there an ideal engineering team structure in a startup, and how might that structure change over time?
In fact, you evolve, and you learn by doing. Today I’m continuing to do this, to evolve, learn, and adapt to my current engineering organization because we grow a lot. So, from my point of view, it is really a non-stop job. If I could explain my current organization by an analogy, I’d say it’s like a restaurant, it’s not because you know how to cook one meal that you are able to run a restaurant. If you leave your work dirty or poorly cleaned, you will throw it away daily, and this is the same for engineering. So, I love to take this analogy because when you are clean with your work, you’re able to move faster, you are able to add a cleaner code base and this will help your product for sure. You need and you have to easily monitor and maintain your different environments and maintain their high availability as well. So yeah, I like to take this analogy because this is really what we do every day. We are praying to be a restaurant open 24/7. In terms of the real organization today, we are organized by what we call autonomous product squads, with a mission that is close to the Spotify model. In fact, your teammates are able to own their missions. My current setup, and the most common case, is some software developers, then a lead developer, and also a product manager. So this is a wonderful squad of five people, and it is the sweet spot for a squad in terms of numbers. We already experienced larger squads with 8 or 10 people that in fact were not a real success. There was too much interaction, too much discussion, and too many things that required the “buy-in” of everyone. So that’s why we’ve limited the number of people in the squad, to ensure that the squad is able to perform well and also to reduce, I would say, the connective load, and also platforming. So, we are practitioners of the team topology organization, whereas the special needs of a team reduce the collective load in the squad by providing support, and also occasionally by providing tools.
What’s the general level of engineer happiness with this type of engineering team structure from your perspective? Is this a mode of working that gives engineers the most satisfaction or what’s your opinion on this?
This is my personal opinion. What I love is people; developers or engineers or everyone in an engineering organization want to have a sense of work, and a sense of work is done by the mission. And this mission is owned by the team. So, you have a sense of what you are doing, of your impact, and this is why people like to work like that, they understand why they’re doing it, they understand the impact but also at the company level, at the product department level and so on and so on. So, I think it is really important to have a sense of the work when you are doing something.
When you think about those typical mistakes companies make when they structure engineering teams, what are the things that you hear about companies getting wrong or things you’ve observed in that regard?
One thing is, people believe that more people means more delivery. This is a classic one; if I have 4 or 5 people, and I double with another 5 people, I double the delivery like that. This is not true. So I really stress, in this case, your delivery will only improve by two or by three or something like that. Also, I believe that there are steps within a company. When you are at 10 people this is a step, when you are at 50 people is another step, when you finally reach one or two hundred people this is another step. So it’s not possible to take a simple example, but when you are, I would say fifteen in the company and ten in engineering, I’m not sure you need an engineering manager. However, once you reach 50 people, you need an engineering manager. So you really are designing and organizing your organization depending on the number of people first, and also the number of systems. This also depends on what your business is, what your core domain is, your own communication structure, and so on… […]
—
You can find The Story of Software podcast on:
Apple Podcasts, Spotify, Stitcher, Deezer, & any other podcast platform of your choice.
The Story of Software Podcast is produced by Zartis. We hope you enjoy listening to this tech podcast and feel free to share any feedback with us: podcast@zartis.com
