Five Principles for a World-class Development Organization

Some might argue that not every company needs a world-class development organization. We’ll save that argument for another article. However, if you are serious about development and your organization depends on it to succeed, then not following these principles will be costly in the long run. In terms of bad architecture, low quality, dissatisfied customers, and a lot of technical debt. Not to mention the effect it will have on your revenue! Without further ado, here are the tips.

Align the design of the development organization with the business strategy

To ensure a good fit and avoid sub-optimization, the development organization should be aligned with the overall business strategy.

• Continuously invest in developing core capabilities for staying competitive and being able to sense and capture new opportunities and renew the organization when needed.
• Use outsourcing wisely. Ensure a strong base of domain knowledge within the company and that critical competencies are retained and built over time to strengthen your competitiveness.
• Be very intentional with the goals and trade-offs of the design, as well as the factors and conditions that the design is based on. Periodically review them and be prepared to evolve.

Design the development organization to support adaptability and resilience inherently

Since we can’t predict what might happen in the future, we want an organization that can quickly adapt when things change. 

• It’s way more important to lean on fit for purpose, flexibility, and adaptability than uniformity.
• Standardize on a few and carefully selected principles instead of on prescriptive practices to ensure flexibility to changing conditions.
• Integrate agile and traditional governance structures carefully. Use governing structures for learning and enabling, and move decision-making to the people doing the actual work itself.
• The architecture should balance high cohesion and loose coupling. Aim for long-term changeability, but avoid big design up-front. Don’t guess about the future, use only what you know and change when you know more. It’s SOFTware.
• Always aim to align the architecture with the teams so that each team owns and maintains its bounded context. And therefore is also responsible for exposing the data of its bounded context in the organization.

Organize teams around value and outcomes, rather than components and technology stacks

Focusing on end-to-end value and outcomes provides an easier way of optimizing the whole flow rather than just parts (which typically leads to sub-optimization).

• Minimize handovers between teams as well as partly completed work.
• The best code is the one not written. Focus on reaching the outcome with as tiny measures as possible without over-designing the solutions.
• Aim for delivering value fast, often and with good quality to get early feedback from the market, customers, and users.

Emphasize co-creation and continuous exploration with business

Always avoid the disconnect and ‘us vs them’ scenario, where the business writes requirements and throws them over the fence. Instead, build a solid relationship over time that promotes co-creation and collaboration to solve complex problems.

• Keep all information transparent by default, and collaboration will over time strengthen the developers’ understanding of business, and the business’s understanding of development.
• Create shared spaces, outside of teams' daily work, where a diverse set of stakeholders can meet, share perspectives, and navigate uncertainty.
• Focus on continuously building trust between the people involved. Encourage creative conflicts, daring to make mistakes, and being vulnerable with not having all the answers.

Fund bets and values streams, not projects

Avoid funding short-lived projects with temporarily assigned team members. Instead, emphasize funding two things: the end-to-end value stream and bets (small business hypotheses that might be valuable and profitable for the company).

• Use a funnel approach to iteratively and incrementally validate the bets on viability, feasibility, and profitability.
• When working with bets it’s often useful to set a goal and target value as the hypothesis and iterate towards it. This also means that the technical solutions will be more of an explicit combination of experimental and delivery approaches.

Curious about some of the details? Need help on how to make this work in your organization? Don't hesitate to contact us, we would love to continue this conversation!