The Progressive Architect is a ranger

The Progressive Architect ensures that product teams can safely go off managed trails and explore new ones, and provides a way back when they get lost.

Architects and platform teams play crucial roles in standardizing the way of working for product teams. Like a ranger, a Progressive Architect creates trails to make it easy for hikers to not get lost in the woods, providing well-marked paths that guide them through the forest. These “managed trails” allow teams to go fast and focus on their product. However, a Progressive Architect is not afraid of a team that wants to wander off the trail to explore, and gives guidance when they do.

Envision an organization where teams excel at what they do best – delivering value to end-users. This post dives into how architects and platform teams can facilitate this achievement.

Create trails, not requirements

As an organization grows, there is often a need to standardize how different teams execute tasks such as security, vendor management, product releases, architecture, and design. These tasks then evolve into a set of "non-functional requirements." Non-functional requirements are a double-edged sword: while they can help teams focus on the specifics of their product, they can also hinder teams from optimizing certain processes to align with their preferred way of working.

Instead of treating these requirements as biblical texts, consider them as recommendations, or “managed trails”. Teams can choose to adopt them fully, partially, or not at all, depending on how well they align with the product they are building. Central teams, such as Cloud Center of Excellence or platform teams, can offer the highest level of support to product teams following such a managed trail, but a team can also decide to take a right turn onto an unexplored trail, or even go off trail.

But what are these managed trails exactly? They are well-known solutions to a problem that adhere to the standards and compliancy of the organization. For example, a template for continuous delivery for a web application or a Confluence page that describes how to release a new version of the system. Teams can simply follow the trail and end up at the known destination. However, this is also where the problem lies: not all destinations are known. Sometimes, teams are experimenting without a strict outcome in mind. In these cases, the managed trails prevent them from finding the best answer to their questions. They must wander off the trail and explore the landscape for themselves. A Progressive Architect travels with the team off the trail and helps them figure out if the new path could become a managed trail. But they should also recognize if the new trail is a dead-end and help the team to get back on track.

Provide assistance, don't obstruct

Describing the ranger's role is no simple task, but we all know that they are responsible for keeping the trails clean, constructing new trails, and at times, removing dead trees; if they are still alive but sick, he marks them for another ranger to address. A Progressive Architect has a similar role, ensuring that teams can move at their own desired pace without major technical or organizational obstacles on the trail. They actively improve processes to minimize delivery complexity, ensuring the team delivers on time.

Offering this kind of support as an architect can be done in various ways, starting with trust-building and helping teams operate autonomously. For example, teams responsible for developing applications should also take ownership of the infrastructure on which it runs. However, this responsibility specifically relates to closely linked components such as message queues, API gateways, or the server-less function executing their code - not the entire corporate or cloud network. A Progressive Architect makes sure that teams can actually own this infrastructure, maintain it, and prevent it from becoming a burden.

You might wonder how, but this ties back to what we highlighted at the beginning of this article: "Architects and platform teams play crucial roles in standardizing the way of working for product teams”.

The Progressive Architect should provide teams with the right abstraction of standardization. This means they shouldn't micromanage a team’s decision making, but they also shouldn't allow the organization's tech landscape to become scattered all over the place with different technology choices.

A great example would be that you provide teams with a robust CI/CD strategy, outlining that containers must be built once and promoted to production via the various test environments, along with how database migrations should be done and how APIs should be versioned. These criteria would define the requirements for the particular tools and libraries that the team itself would introduce for tasks like migrating a database or deploying a container. Avoid restricting teams by dictating the libraries, tools, or technologies they should use. Instead, provide the team with clear insights and context, enabling them to choose their preferred tools, as they are the experts in their domain.

Minimize dependencies, maximize responsibility

Architects often position themselves as gatekeepers, or at least are seen as such. Design changes must be approved by them, and new platform features must be built by them. This creates dependencies for the product teams, limiting their independence. Even worse, it takes away their sense of responsibility for creating and maintaining the product. When something is broken, the architects and teams start pointing fingers at each other instead of fixing the issue. Over time, this will lead to a lot of frustration, and the delivery of new features will slow down.

Instead, product teams should be able to operate independently from the architects and platform teams. They should be able to build and release functionality on their own. If the platform is missing a feature that they need, they should be allowed to build it themselves. A Progressive Architect has a guiding role and does not interfere with the daily operations of a product team, just like a ranger does not control every tree, plant and animal in the forest.