How do you organize your software engineering teams for faster flow?
Everyone in a software leadership role is pondering about this question on a daily basis, whether you’re a software engineer, team manager or director of software. That’s why I’d like to share some of my knowledge and experiences on how I navigated this challenging question in a series of blog posts.
First, It’s good to have an understanding of “Conway’s Law”, which states that
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
This basically means that if you let me have a look at the software (architecture) of your system, I can tell you quite accurately how you’ve been organizing your teams (context of domain and ownership) and the communication (about what they communicate and how) between them.
Bold statement? Not really.
Ok.. so what to do with this? Well, with this knowledge you can leverage the so-called “reverse Conway’s law” which means that you can organize your team(s) according to the architecture that you actually desire. This sounds trivial, however, as your software evolves, boundaries fade, feature requests grow, technical debt piles up, etc. WHEN do you actually decide to re-organize your teams? WHEN do you create a new domain/architectural separation between your teams in order to keep them happy and high performant?
I learned about Conway’s law at a conference in London called Jaxx DevOps and I was immediately fascinated. I attended this conference to learn more about building and improving Dev(Ops) teams. Back then I was responsible for 5 different software engineering teams, each with their own specialties, context, and an ambitious roadmap.
After seeing the presentation of Matthew Skelton I was intrigued by what he was talking about so I struck up a chat with him. We talked about the importance of team organization, the context and boundaries of team domains, and cognitive load. All these things have a big influence on achieving higher output, fewer issues, improved ownership, more agility, and eventually happy and high-performing teams!
I was not very surprised to find out that last year he actually released a must-read book called Team Topologies. The book goes into more detail about the things mentioned above and the WHY and HOW of interactions in and between your teams. It also shares common team patterns to avoid with modern software systems, when and why to use different team patterns, and how to evolve your teams effectively. It helps you navigate the evolution of your teams and helps you keep both your teams and software healthy and to optimize for flow.
So, I hope you’ve perhaps learned something or at least had a moment to reflect on the current state of your teams. And I’m curious, what is something that you’ve learned during your experience as a technology leader that you’d like to share?
#stayinside #keeplearning #techleadership #technologyleadership #itmanagement #itorganization #devops #devopslife #softwaredevelopment
