The Spotify model has often been referenced as a way to structure engineering teams for agility and independence. It promotes business-owned product teams, where engineers report into product owners, and uses guilds to ensure that teams stay aligned on best practices. However, guilds often become more like “book clubs,” where participation is optional and relies on personal time. This happens because business line managers prioritize deliverables over cross-organizational collaboration, making it difficult to maintain alignment at scale.

Meanwhile, Team Topologies offers a different focus, looking at how different types of teams interact and organize. It doesn’t rely on guilds but instead emphasizes reducing dependencies and clarifying team responsibilities.

One of the main reasons I organize engineers into a single reporting line, rather than under product ownership, is to avoid these pitfalls. By centralizing the reporting structure, I can prioritize time for engineers to focus on cross-organizational standards and collaboration, ensuring alignment across teams without relying on optional participation.

The Importance of Alignment and Shared Processes

While models like Spotify emphasize team independence, they sometimes miss the mark on alignment. It’s critical that teams don’t end up siloed, each solving the same problems in different ways, or worse, working against established company practices. This is where alignment on best practices, methods, and tools becomes crucial.

Take the US Navy SEAL teams as an example. They are known for their ability to operate independently, much like Scrum teams. However, what people tend to overlook is that all SEAL teams undergo the same training, use the same equipment, and follow standardized methods and processes. This shared foundation is what allows them to operate seamlessly when they come together, even though they work independently most of the time.

In the same way, my approach ensures that engineering teams can solve problems on their own, but they’re aligned on best practices, tools, and processes across the company. This alignment prevents the issues often seen in the Spotify model, where teams risk becoming too focused on their own product work, losing sight of the bigger organizational picture.

Scrum Teams Need Independence from Authority

In Scrum teams, the issue goes beyond just estimation—it’s about the entire collaboration model. Scrum is designed to foster equal collaboration, where team members work together, estimate tasks, and solve problems without a hierarchy influencing decisions. When someone on the team, such as a Product Owner, is also the boss, this balance is broken. The premise of Scrum, which relies on collective responsibility and open communication, collapses.

If the Product Owner or any other leader on the team has direct authority over the others, it can lead to a situation where estimates are overridden, team members feel pressured to work longer hours, and decisions are driven by power dynamics rather than collaboration. This undermines the core principles of Scrum, where the goal is for teams to self-organize and be empowered to make their own decisions.

By keeping authority structures out of the Scrum team, we ensure that collaboration is truly equal, and that decisions are made based on the team’s expertise and collective input—not on the directives of a boss.

How We Balance Autonomy and Alignment

Instead of organizing engineers strictly around product owners and budgets—like in the Spotify model—we’ve created a framework where engineers report through a central engineering line. This keeps everyone on the same page when it comes to methods and processes. Engineers still work closely with product teams, but they don’t lose sight of the bigger picture: adhering to company-wide standards.

This approach solves a problem common in both the Spotify and Team Topologies models. In Spotify, squads may go off and build things their way, leading to inconsistencies across the organization. In Team Topologies, stream-aligned teams can become too focused on optimizing their flow, which sometimes means diverging from company-wide practices. By maintaining a central engineering line, we keep our teams aligned while still giving them the autonomy they need to innovate and move quickly.

The Result

Our approach strikes a balance. Teams are free to innovate and adapt to the challenges of their product work, but they aren’t reinventing the wheel or deviating from best practices. We’ve managed to avoid the pitfalls of silos and fragmented processes by ensuring that every team operates within a shared framework—just like how SEAL teams can work independently, but they all share the same training, tools, and methods.

At the end of the day, it’s not about limiting autonomy; it’s about creating the right kind of autonomy. Teams should be able to act independently, but they should do so in a way that keeps the organization moving in the same direction. That’s the key to scaling effectively without losing sight of what makes us successful in the first place.

Introduction

When organizations add more people (scale up) it quickly becomes impossible to have everyone sitting in the same room to discuss and agree on matters and share the same approach to doing business.

This is my version of a Software Engineering Quality Handbook where it’s easy to get an overview of how an organization can use a well-structured hierarchy for describing how work is done which is crucial for ensuring clarity, consistency, and compliance within a team. The handbook is built up with 5 layers:

• Policies: Broad statements that define the organization’s principles and compliance expectations.
• Rules: Strict directives that must be followed to ensure specific outcomes in certain situations.
• Standards: Mandatory technical and operational requirements that ensure consistency and quality.
• Processes: Detailed, step-by-step instructions that specify how to perform specific tasks.
• Guidelines: Recommended best practices that guide decision-making but are not mandatory.

Each layer of this structure supports the one above it, providing more detail and specificity. Policies and rules sets the foundation and create alignment within the goals of Software Engineering, while standards, procedures and guidelines provide the specifics on how to achieve those goals effectively.

This structure also facilitates easier updates and management. Policies and standards often require more thorough review and approval processes due to their impact and scope, whereas guidelines and procedures can be more dynamic, allowing for quicker adaptations to new technologies or methodologies..

Policies

• Definition: Broad, high-level statements of principles, goals, and overall expectations of the organization.
• Purpose: To establish core values, company vision, and overarching compliance standards.
• Lifecycle: Reviewed annually to ensure alignment with evolving legal, technological, and business conditions.
• Compliance: Mandatory; non-compliance can result in significant legal and business risks.
• Icon: (scroll). It symbolizes official documents, which aligns well with the formal, foundational nature of policies. It’s often used to represent ancient laws and decrees, making it fitting for the foundational rules and standards within an organization.
• Example: A policy might state that all software developed must comply with GDPR and other relevant data protection regulations.

Rules

• Definition: Explicit, often granular directives that are compulsory and usually narrow in scope.
• Purpose: To ensure specific outcomes or behaviors in particular scenarios.
• Lifecycle: Reviewed frequently (e.g., annually) to refine and ensure they address current challenges effectively and are adhered to.
• Compliance: Strictly mandatory; non-negotiable and must be followed exactly as prescribed.
• Icon: (scales). It represents justice, balance, and fairness, aligning with the concept of rules ensuring specific outcomes and behaviors are maintained in a structured and equitable manner within an organization.
• Example: A rule might state that commit messages must include a ticket number from the issue tracker.

Standards

• Definition: Specific mandatory requirements for how certain policies are to be implemented.
• Purpose: To ensure consistency and quality across all projects by defining technical and operational criteria that must be met.
• Lifecycle: Updated biennially or as needed to reflect new industry practices and technological advancements.
• Compliance: Mandatory; essential for maintaining quality and uniformity in outputs.
• Icon: (ruler). It symbolizes measurement, precision, and consistency, which align closely with the idea of standards setting specific requirements and guidelines to ensure quality and uniformity across projects.
• Example: A standard might specify that all code must undergo peer review or adhere to a particular coding standard like ISO/IEC 27001 for security.

Processes

• Definition: Detailed, step-by-step instructions that must be followed in specific situations.
• Purpose: To ensure activities are performed consistently and effectively, especially for complex or critical tasks.
• Lifecycle: Regularly tested and updated, ideally after major project milestones or annually, to adapt to process improvements and feedback.
• Compliance: Mandatory where specified; critical for ensuring consistency and reliability of specific operations.
• Icon: (hammer and wrench). It symbolizes tools and construction, fitting for the concept of processes as they provide detailed, step-by-step instructions necessary to construct or execute specific tasks systematically and efficiently.
• Example: A process might outline the steps for a release process, including code freezes, testing protocols, and deployment checks.

Guidelines

• Definition: Recommended approaches that are not mandatory but are suggested as best practices.
• Purpose: To guide developers in their decision-making processes by providing options that align with best practices.
• Lifecycle: Evaluated and possibly revised every two to three years, or more frequently to incorporate innovative techniques and tools.
• Compliance: Optional; best practice recommendations that are advisable but not required.
• Icon: (compass). It symbolizes guidance, direction, and navigation, which aligns well with the purpose of guidelines to provide recommended approaches and best practices that help steer decisions in software development.
• Example: Guidelines might suggest using certain frameworks or libraries that enhance productivity and maintainability but are not strictly required.

In today’s fast-paced business environment, one strategy stands out: leveraging IT as the core of business operations. This concept, which I call “Amazon the Shit Out of It,” is inspired by Amazon’s renowned “working backwards” approach and their remarkable success story.

Amazon’s methodology includes meticulous planning with their six-page memos and a commitment to long-term investment. Unlike companies focused on immediate gains, Amazon invests with a long-term perspective, which allows them to innovate and maintain a competitive edge. Notably, these six-page memos have also led to the banning of PowerPoints for strategic business planning, encouraging more thoughtful and comprehensive documentation.

A key factor in Amazon’s success is their ability to apply IT to virtually any problem. They did not start as a tech company; they began as a bookstore. By fully embracing IT, Amazon transformed into a tech powerhouse with Amazon Web Services (AWS), revolutionizing the tech industry.

This transformation highlights a crucial point: businesses must evolve into IT-centric entities to thrive in the modern world. It is no longer sufficient to excel in your original industry; you must become an IT company that leverages technology as a primary business accelerator. Amazon’s journey from a bookstore to a tech giant exemplifies this evolution.

Consider any traditional business, whether it is selling beer, manufacturing products, or providing services. Often, competition boils down to price and product quality, which can be challenging to differentiate in the eyes of consumers. For many, beer is beer, toilet paper is toilet paper, and detergent is detergent.

This is where IT becomes a game-changer. By integrating advanced IT solutions, businesses can significantly reduce production costs, streamline logistics, resolve supply chain issues, and optimize operations in unprecedented ways. Amazon’s success demonstrates how IT can be a powerful lever, enabling businesses to move beyond price competition and deliver exceptional value.

A crucial part of this strategy is shifting from a mindset of Relentless Rationalization—merely doing the same thing better—to one of Relentless Value Adding. Inspired by Amazon’s “working backwards” methodology, this approach focuses on continually enhancing the customer experience and adding value through innovative uses of technology. It is not just about saving 10% and delivering 10% more; it is about leveraging IT to create new opportunities, solve complex problems, and fundamentally accelerate business growth.

In conclusion, “Amazon the Shit Out of It” is more than a catchy phrase—it is a call to action for businesses to rethink their strategies and embrace IT as the cornerstone of their growth and innovation. By adopting a Relentless Value Adding approach, they can position themselves not only to survive but to thrive in an increasingly competitive and technologically driven world.

I would encourage everyone to read “Working Backwards”.