Our company has been rather fortunate in the last year, given all the world events. We've seen confident, measured stewardship from our founders and senior leadership that have meant we're actually growing our team when other businesses have had to let people go. Having brought two new developers on at the start of this year, I had to make some decisions around what the best approach to delivering our product in a sustained way would be.
Outcomes vs Structures #
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure - Conway's Law
It's still very common to see technology teams built around the architecture of the product: front-end teams building UI and features, back-end teams handling the infrastructure and low-level business logic. Those teams make sense on the face of it, but become hard to scale in ways that allow cross-functional collaboration and flow of ideas and effort. Scheduling each team's deliverables can be a massive headache as each team scales at different rates and compromises in the sake of expediency create downstream problems on software maintainability, architectural complexity and more. Teams become wedded to, and focused on, the technologies rather than the product.
A better approach is to keep your teams aligned to the intended customer or product outcomes. This is where the manager comes to the fore: not only making the decision about how to break out different work groups, but ensuring there is an abundance of clear communication on why those workgroups are structured that way and what the standards and goals are for each of them.
Cognitive Load #
Throughout the later half of last year, one of the biggest challenges my teams were facing was work in progress (WIP) and context-switching. The cognitive load being demanded of the individual contributors was too high. People who were supposed to be focusing on specialist skill areas were unable because they were being tasked on helping out in other domains. Teams were nominally structured around our market focus, but were predominantly software-centric and much of the operational work was obfuscated. There was an increasing disconnect between a team's stated purpose and the make-up of people actually working on specific tasks.
Cognitive load is reduced when there is a clear ownership of a domain or product outcome. A team that has a remit to drive a feature or project from inception all the way through to delivery is able to focus their energy and coordinate their communication lines more effectively than a team that has to rely on "outside" help in order to complete their work.
Remember, in Conway's Law (above), there is a clear trend in any organisation to build software that reflects the communication structures it relies on. So the more stakeholders you have in a given outcome, the proportionally more communication channels that need to be invoked.
Team Topologies #
A respected colleague of mine pointed me towards the idea of "Team Topologies". The essence of that idea is building software that fits in the teams' heads. The amount of mental effort required to visualise the whole component (or feature, or workflow) should be discrete and manageable. If you work on features that disappear into other teams before emerging again before being pushed to production months later, building a team around a specific software function might seem easy, but will cause bigger problems later as people try to understand complexity in systems, communication and responsibility.
Taking socio-technical approaches to building software allows the business to create solutions that leverage the human contributions in the most effective way. In my case, I needed a way to ensure my teams were able to build features that corresponded to the highest customer value, but I also needed discovery around the technical health of our product, the strategic future of our market (and the technical response to that), and the optimisation of the product's performance as we scaled.
Breaking my teams into subgroups who were accountable for those business outcomes made more sense than splitting based solely on technical function or product areas. People who were previously exclusive to operations work now find developers and architects included in their group. Development groups have the remit to do whatever best facilitates the flow of change. The workgroups have a range of skills so that a given project can be picked up and delivered by that team alone.
Conclusion #
I'm not the first person to be presented with this problem. I absolutely will not be the last. Trying to envisage how to create the right conditions for your people to do their best work is sometimes not easy or clear through the lens of your own business context, but I've found that looking at the business outcomes being supported helps inform the sorts of people I want to focus in a particular direction; especially when one of the forces acting on my teams is growth.