This post was sparked by reading this recent tweet from Gretchen Anderson:

Who’s got some knowledge to drop on Agile team structure and UX for complex systems?

Most of these notes are my immediate reflections, but I decided to pool them all into a single post instead of a big tweet-storm.

The statements below assume you are working in an iterative fashion with self-sufficient teams. If you still work in silos, God help you.

Organization design is a powerful lever

• Organization design and iteration of team structure is a far under-appreciated lever to affect change on a team’s ability to operate.
• Organization design is often abused or ignored for purposes other than an organization’s success (e.g. laziness, unwilling to lead, personal gain)
• Structuring your organization is intimately related to the structure of the work at hand. If the work changes in a fundamental way, you will need to make changes.
• Planning is important: not in the sense of laying down instructions to follow, but instead thinking ahead and anticipating how the variables are stacked and how they might change. It’s probably more work than you think.
• Architect roles exist between cross-functional teams and specialize in product components, not areas of the product.

Multi-disciplinary thinking

• Success is heavily reliant on PM-driven coordination and co-creation with both technical and experience architect roles.
• Technical and experience architects need to be coordinated on the why, what, how of the vision. They should be creative together (and can learn a lot from each other).
• The myth of the lone designer has no place here, as collaborative creativity is the only path. But ability to make decisions and move forward must be empowered from on high.

Understanding change

• Designing the staging of implementation needs to be considered on both sides, again with strong PM leadership to ensure business goals being met along the way.
• Understand that coping with growth is a natural process of working with complex systems. Code will need refactoring and designs will need to be rationalized. The choice is always: when?
• Early on you are creating building blocks and seeds for future work. Expect your existing structures to change over time. Design accordingly or pay the price in developer sweat.
• Tackle higher order problems first, and keep approach to aesthetics simple or systematic early on to enable speed and quality.
• Fruits (and costs) of early labor not always seen until much later, sometimes years.
• Dig in hard against shallow features with low value but broad implications. They will haunt you on every additional feature.

Embracing complexity

• Your end product is likely hard to prescribe. Enable additional endpoints and learn from how your users get creative.

Post also published on Medium.