Big changes are ongoing in Shapemaker and to stay on our toes we have invested in knowledge of best-practice technology leadership. We were happy to meet with Manuel Pais, author of Team Topologies, for a full day course in Oslo on the topic of leading software engineering teams. Thank you Manuel for your amazing work and generous sharing!
Growing pains
We have recently experienced growing pains in Shapemaker. Our product development team has grown from a one-man show to seven developers and three domain experts. Our initial strategy was to keep them all in one team to encourage close collaboration and create familiarity between everyone. Over the last six months this setup has caused meetings to grow longer and every new task we approach includes a lot of learning and exploring. Developers rarely get to re-use the knowledge they have amassed since anyone can end up doing any task and the overall scope is so big. We have started to drift into a situation where developers only feel accountable for parts of the codebase because the difficulty of staying up-to-date on all of it is simply too much.
New goals, new focus
From my past experiences as a developer, I knew that how you create your development teams has a huge impact on what kind of software you can deliver and at which speed you can get it out the door. Speed is essential to Shapemaker, so I decided to do a bit of research before attempting to reorganize. Special thanks to our developer Sindre, who pointed me in the direction of the book Team Topologies by Matthew Skelton and Manuel Pais!
Together with the team, I set out on a path to find a new organizational structure with six goals in mind:
- Conway’s Law-compatibility
- Longevity by design
- Cognitive load on a reasonable level
- Autonomy in delivering value
- Mastery of your domain should pay off quickly
- Purpose for the business should be clear
After a week of thinking we had four competing suggestions but when we sat down to discuss them and pick out what we wanted we made a very important realization: We are working with three very difficult topics in Shapemaker. We cannot have less than three teams if we want cognitive load on a reasonable level and if we want learning to pay off quickly.
This is a very interesting conclusion because 10 people divided into three teams is a lot of teams for our small company. Three complicated subsystem-teams is also quite a lot for any small system, it’s almost an anti-pattern.
You can learn more about the team types here.
The complicated subsystem-teams we were considering would also not be particularly autonomous in delivering value to engineers. As a company we offer a fully end-to-end automated civil engineering process and online platform. A team which is only responsible for e.g. finite element analysis would never be able to fulfill any complete end-user value.
A new reality
After the most engaging series of discussions I have ever participated in, we settled on trying a setup with three teams where each team has a domain responsibility (complex subsystem) and are also responsible for a set of features (value streams). The idea is to handle cognitive load and mastery by each team having a narrow, difficult area to work on while at the same time allowing mostly autonomous work for the features. All three teams work on the same codebase but mostly on non-overlapping parts of it. For us this is “Conway’s Law-compatible” because the domain naturally divides into these three parts and the interfaces between them are fairly stable and easy to define.
This setup makes it crystal clear that we depend on all three of our complicated subsystems to deliver engineering assessments which might lead you to think that this setup is a bad idea. There is a large degree of inter-team dependencies which is clearly outlined as a bad thing in Team Topologies, but I would argue that this is a great setup for us. We are going to be depending on this process regardless of how we organize our teams and bringing this challenge into the spotlight puts us in a position to address it directly.
Our process of change happened over a period of two weeks, mainly consisting of four long all-hands meetings with the goals of finding options, deciding on one, dividing responsibilities and agreeing on new basic day-to-day work processes. We committed to trying our new setup for a full month before evaluating, criticizing and changing whatever is not working.
In hindsight, the most valuable thing we have created is probably involvement. It is amazing to see the effort and energy everyone puts in to make this work and the buy-in we get from involving teams in creating their own opportunity for success is mind-blowing.
The best advice I can give to others looking to incorporate these values into their teams is this: Invite everyone to learn the basics of team topologies, listen to everyone, mind the limitations of your situation and don’t be afraid to try something out and adjust it later.
The future of civil engineering
Going forward I think we are ready to add more developers and domain experts to our existing teams. As the scope of the respective tasks grow I think it is likely that our complex subsystems will grow into internal platform teams and those teams will likely internally be organized as multiple stream teams per structure type or per engineering design standard when we grow even further.
In the short term we will take action to reduce the difficulty for each team by investing purposefully in knowledge sharing. Workshops on specific technology topics is one possible way, bringing in external speakers is another one. The goal is to fill the roles that enabling teams might fill in a larger organization on topics like security, cloud, UX and SRE.
Let the future come, we are ready!
