Balancing team design with organisational reality

Over many years of delivering systems and architectures for enterprises I've found the most impactful factor for success has not been any specific technology or methodology, but rather how we design teams, and crucially not being frightened to evolve that design or make changes over time.

Team Topologies and Domain Driven Design (DDD) provide key principles for building high performing teams optimised for fast flow and feedback. These include:

• Reduce cognitive load by aligning team boundaries to domains.
• Minimise interactions, dependencies and handoffs with other teams.
• Adopt a DevOps mindset of end-to-end ownership backed by automation.
• Maximise autonomy and push more decision making into teams.
• Limit team size, optimising for small, cross-functional long-lived teams.

These principles provide a strong foundation for a target design, but reality often imposes constraints meaning immediately adopting an ideal model is impractical.

Understanding constraints

A common scenario I see is organisations trying to force their idealised team structure without fully appreciating existing constraints. Organisations look to take a short-cut toward customer-centric domain-aligned teams before their architecture foundations, culture, process or operating model is mature enough to support them.This can create friction rather than realising the benefits promised by the principles above. 

One such key constraint is legacy software monoliths which until retired still play a key role for delivering new functionality as a dependency of new modular, service oriented architectures. Creating domain-aligned teams which span monolithic systems whilst still relying on and changing those non-domain-aligned monoliths often means breaking the first two principles - reducing cognitive load and minimising dependencies between teams.

A common approach is to force an inverse Conway maneuver (design the teams to influence the emerging architecture) but this is sometimes executed whilst the organisation is still too early in an architecture modernisation journey. For example, solid foundations are not yet in place. Without those foundations we can introduce inefficiencies rather than driving modularity where we look to align services with stream-aligned teams, ensuring clear ownership.

Hybrid models

Instead of forcing an ideal model before we are ready, another approach is to optimise the initial team design for immediate constraints and evolve our teams over time. One such example of this is a hybrid model:

1. Domain-aligned, product-driven teams focus on new architectures and business capabilities.
2. A dedicated complicated subsystem team manages legacy systems, ensuring stability whilst prioritising work which minimises dependencies and reliance on those systems.
3. Adopt a bimodal approach where we simplify interfaces between teams and decouple release processes by using techniques such as contract testing to reduce dependencies during integration testing phases.

Note: Whilst the new UI appears to span our teams the solution is modular. Teams are able to deploy their own slices of the UI via the monorepo and using techniques such as: https://www.qovery.com/blog/nx-architecture-part-1-organizing-and-structuring-a-react-project-with-nx/

Optimise for Constraints

To design teams effectively organisations should consider the primary constraint they face today and consider trade-offs against alternative designs. For example:

Although we generally prefer product-driven teams with a bounded and continuous value stream, if constraints mean project-driven work is an immediate need, then allowing short term project-based teams might be a practical trade-off with a longer term plan to transition into a more product-oriented organisation. This doesn’t mean we ignore agile principles such as empowering teams and delivering value continuously (incremental versus the traditional big-bang release), it simply means today we accept we cannot avoid being project-orientated, potentially due to how the work is funded. 

We look to guide the organisation towards product-driven teams with long-term ownership when it is ready.  

Another example might be the type of work ahead of us. If the majority of the work for the next six months involves cross-cutting concerns, technical debt and platform foundations then it’s reasonable to align teams to technologies temporarily and then redesign boundaries later - or adopt a hybrid model.

Another common bottleneck is the delivery of enterprise integrations or infrastructure. Instead of maintaining centralised teams executing this type of work, shift to a self-service model. These teams move to a coaching, upskilling and enabling role, shifting from a “we do it for you” to a “we’ll help you do it yourself”.

Balancing stability and change

Whilst I’m promoting flexibility in team design this doesn’t come without caution. It is important to consider the impact of continuously evolving team structures. Whilst it is necessary to restructure based on evolving constraints, frequent restructuring can introduce inefficiencies and impact morale.

It is important to evaluate whether changes are solving real constraints. Can the teams be stabilised for a period of time before the next evolution and is leadership aligned on the trade-offs between different models?

While flexibility is key especially whilst an organisation is trending towards operational and architectural maturity, stability should be the long-term goal because it allows teams to develop expertise and efficiency.

Effective Leadership

Navigating the social-technical aspects of our organisations requires strong leadership. Leaders should set clear expectations and ensure people understand why changes are being proposed. Strong leadership is required to support teams through change periods providing continuity and guiding to avoid disruption. Leaders should also measure the impact of changes and use data (for example Flow Metrics, SPACE/DevEx and DORA) to support decision making.

Final Thoughts

Whist long-lived, domain-aligned, customer-centric teams remain the goal, real-world constraints mean we should sometimes take an incremental path to get there and instead of forcing structures on teams, and include them in the decision making process:

• Identify the most immediate constraints
• Propose options for team boundaries to address those constraints
• Discuss the trade-offs and impacts of different models
• Plan for evolution over time, have a vision and look for stability whilst optimising for change.
• Ensure pragmatic leaders guide and enable rather than control.

If we optimise for today whilst planning for the future we build teams that are both effective for immediate delivery goals but adaptable for tomorrow.