The TOP Structure - how it all started

As you may already be aware, my latest project is the "TOP Structure." Let me give you some insights into how it all started. Back then, it wasn't very refined, just some thoughts in my head.

The world of traditional IT

Traditional IT organizations typically separate themselves into a development and an operational area. To execute, they again separate into line and project - commonly resulting in matrix organizations. Requests for delivery of new stuff are typically thrown over the fence by "business," or - in more advanced companies - negotiated by Business Analysts. In any case, once a project was scoped, we task a Project Manager with ensuring delivery in TQB. That leaves Project Managers with a wide range of work: setting up a capable team, prioritizing and distributing work, coordinating schedules and tracking progress. Unfortunately, as the proverb goes, "if everything is important, nothing is." Many project managers drown in schedules and tracking, leaving them little time for taking care of the people doing the work.

Scrum changed the game

The move to "stable teams" and continuous "product development" led to the need for a different way to structure teams, and Scrum provided it. In a Scrum context, the line no longer "provides resources" to "projects." And there's no more a final delivery thrown over the fence at the deadline - software in an agile setting is never "finished." Features become available in a continuous flow of value.

Still, line managers have a role - and oftentimes, business initiatives are still funded as pre-packaged projects scoped for "Agile Delivery."

Why is all of that relevant? Because of the resulting interactions.

Scrum teams learn to self-organize themselves, and how to manage their interactions with their surrounding organization. The person accountable for this is the Scrum Master. Often being neither technical nor understanding the product in depth, Scrum Masters focus on Organization. Their value proposal isn't in any code they write or anything sold to customers - it's enabling their team, focusing on "Who" and "How." (i.e. people and process)

The second key of a successful Scrum team is the Product Owner, focused on the Product. Both organization and implementation aren't their concern, only ensuring that the "What" and "Why" are clear and prioritized, so that stakeholders are happy and the team does the most valuable thing at the most suitable moment.

And finally, what would be a good Scrum team without competent developers? They take care both of development and outcomes, that is: they do everything technical. Developers own their Technology.

SAFe repeats the same

Let's do a simple relabeling exercise to demonstrate how SAFe copy+pasted Scrum in this regard, at a level of abstraction.

Competency	Scrum Role	SAFe Role
Scope	Scrum Team	Agile Release Train
Technology	Developer	Agile Team
Organization	Scrum Master	Release Train Engineer
Product	Product Owner	Product Manager

(Now - we could formidably debate whether SAFe's copy+paste approach at scale is appropriate and smart, but that's not my point.) I'd like to highlight that if we gloss over implementation details, then Scrum succeeds most likely when there's sufficient attention being paid to all of Technology, Organization and Product (TOP) - and SAFe must repeat the same thing at a higher level of abstraction.

From this, the idea was born of the TOP Structure as a universal pattern: To succeed with a sustainable software organization, you must ensure that all three domains receive sufficient attention.

Thus, the idea behind TOP is first and foremost that we have to build a structure that pays appropriate attention to all three domains, staffs them with sufficient competency, and doesn't force us into making either-or choices between them. Which is what often got traditional Projects into trouble - a PM rarely has time to fix organizational issues, as deadlines are constantly pressing.

TOP Dysfunctions

Let's turn this around, and take a quick peek at what happens when we pay too little - or no - attention to one of the core TOP competencies:

Illustration	Dysfunction	Consequence
	Exclusive Tech Focus	Technical excellence disconnected from people and their needs - technological wonders that nobody needs.
	Exclusive Product Focus	Ephemeral, great ideas that eventually get killed by the inability to execute.
	Over-focus on Organization	Having the right people working effectively means little when it's not the right thing.
	Lack of Product Focus	An over-focus on methods and implementations could lead to missing the needs of the customer entirely.
	Lack of Organizational Focus	A "bias for action" mindset that bulldozes over people and their needs in order to "move fast and break things." Gets things done in early phases, leads to unproductive (and potentially extremely costly) chaos in the long term.
	Lack of Technical Focus	Emphasizing value generation and order, at the expense of technical sustainability. Most such products incur fatal technical debt at some point in the future.
	(none)	Technology, Organization and Product all get sufficient attention, nothing gets shoved under the rug and energy is distributed wisely in each domain.

The TOP Question

And thus, the idea of the TOP Structure was born as a simple, yet effective mechanism of asking the question: "We have 100% of our energy. We can distribute it in any way that we want. Where should we put how much?" There's no fixed or perfect ratio such as, "60% T, 10% O, 30% P" that would serve as a recipe for success. Instead, the first answer is often, "We currently spend too much energy on (X) and too little energy on (Y).

TOP thus started as a simple tool for teams, teams-of-teams and entire organizations to determine whether sufficient energy was invested into the different areas in the past - and whether we should redistribute that energy in the future. For example: "We'd need a bit more time for process improvement, and a bit more for Refinement. That's only possible if we invest a bit less of our time for development - can we do that? How? Is there something in any of the competencies we're currently doing that we could discontinue?"

How it evolved

As you can already see from the three circles - they overlap. Initially, I put "management" into the center, with the intent of stating that management has the responsibility that all three competencies get adequate staffing, funding and attention. Then I decided that this isn't what we'd like in self-managing teams. So I decided to put "Teams" into the center, indicating that a self-managing teams should do all of that. It didn't feel right, either. And thus, the current version of the TOP Competency Spectrum was born:

The TOP Competencies

The model of the TOP Competencies Spectrum is mostly a reshape of the circles into one segmented circle, giving names to the different intersects of the circle:

As you move further away from pure technology towards organization, you enter the domain of Architecture, concerned with the question of "Do we have the right means of doing what we do, and is how we do it the best way of doing it?" - Architecture, in the TOP Competencies model, isn't a separate thing from either Technology or Organization: it's the discipline that brings both together!

Likewise, Design fuses the question, "Why do people need it?" with "How do people need it?" - crossing the chasm between user perspective and technical implementation. Thus, the TOP competency of Design requires connecting technical and product competency for best outcomes. Which is needed to which extent at which time - may vary, and as the color indicates: it's a blended mix.

The other TOP Competencies are similar: At the outer part of the circle, activities are more "domain specific," and the closer we get to the center of the circle, the TOP Competencies blend and become indistinguishable. 

Quality, at the core of the TOP Competencies, is much more than "product quality" - it's quality of everything: how we communicate, how we work, what we produce, and any other outcomes we get (including, of course, satisfaction with our jobs.) As quality is everything in a TOP Structure, it's also everyone's responsibility, and everyone constantly contributes towards it, be it consciously or unconsciously, positively or negatively. The TOP Structure should remind us of this, and inspire us to replace unconscious poor quality choices with conscious good quality choices.

This extended model of the TOP Structure focuses less on the question of "Where do we assign our energy?" - somehow, the entire circle makes up for 100% of our energy, with fluctuating investments across the week - it focuses more on People and Interactions: In our current organization, how do we interact with ... Architecture? Is it smooth, do we have boundaries? Where is it: is it part of the team, or outside? Does information flow freely from and towards that domain, or is it thrown over the fence? 

Is there a continuous exchange between developers and product people, or is it a stage-gated Waterfall? What does our relationship between design and quality look like: Do we design for quality, or do testers consume the result of a design process for test case creation?

The TOP Structure, in this regard, makes no imposition of what you must do - much rather, it guides us in the questions we can ask to identify where we've got improvement potential and where we're potentially missing something important.

What's next

And that's how I formed the basis for the entire model of the TOP Structure you can now find on my official company page. I invite you to sign up to my newsletter and follow me, because I have big plans for the TOP Structure: I believe it should be a staple tool for any Coach and Consultant supporting organizations on their journey of Continuous Improvement - regardless of which framework, or no framework, or the approach they choose.

My own journey with TOP has just really begun to get exciting - you're still in time to be an early adopter!