TOP Structure - the Technology Domain

 Too often, organizations reduce the technical aspect of software development to coding and delivering features.

This, however, betrays a company which hasn't understood digital work yet, and it begs the question who, if anyone, is taking care of:

Technology is the pillar of software development that might be hidden in plain sight

Engineering

Are you engineering your software properly, or just churning out code? Are you looking only at the bit of work to be done, or how it fits into the bigger picture? Do you apply scientific principles for the discovery of smart, effective and efficient solutions? How do you ensure that your solutions aren't just makeshift, but will withstand the test of time?

Automation

What do you turn into code? Only the requirement, or also things that will help you do your work easier, with higher quality, and lower chance of failure? Do you invest into improving the automation of your quality assurance, build processes, your deployment pipeline, your configuration management - even your IDE? How many things that a machine could do is your company still doing by hand, and how much does that cost you over the year - including all of those "oops" moments?

Monitoring

Once you delivered something - how do you know that it works, it works correctly, is being used, is being used correctly, has no side effects, and is as valuable as you think it was? Do you make telemetry a standard of your applications, or do you have reasons for remaining ignorant about how your software performs in the real world?

All of the items above cost time and require skills. Are you planning sufficient capacity to do these things in your work, or are you accumulating technical debt at a meta level?

Think for a minute: How well does your team balance technological needs and opportunities with product and organizational requirements?

TOP Structure - the Product Domain

Many companies misunderstand Product Ownership - or wose: Product Management - to be nothing more than managing the backlog of incoming demand. While that work surely needs to be done, it's the last thing that defines a successful Product Owner - "there's nothing quite as useless as doing efficiently that which shouldn't be done at all," which is what often happens when teams implement requests that are neither valuable, useful nor good for their product.

To build successful products, we need to continuously ask and answer the following questions:

The Product Domain is the third core pillar in the TOP Structure

Direction

1. What's the vision of our product, how close are we, and should we keep it? How does our product make our users' lives better? Where are we in the Product Lifecycle, and what does that mean for our product strategy? Do we have what it takes to take the next step?

Position

2. What does our product stand for, and what not? Will adding certain features strengthen or dilute our product? Are we clear on who's our target audience, who's not - and why? Do we want to expand, strengthen or shift our user base?

Discovery

3. What's the problem we'd like to solve? How big is this problem? Who has it? Is it worth solving? Which solution alternatives exist, is our product really the best way of solving it?

A weak Product Pillar leads to a weak product, which limits opportunities to make the product valuable and profitable - which quickly leads to a massive waste of time and money in product development, whereas a strong Product Pillar maximizes the impact of product development efforts.

Check your own team - on a scale from 1 to 10, how easily and clearly can you answer the questions above?

TOP Structure - the Organizational Domain

 It sounds tautological that every organization needs organization - and yet, most companies are really bad at keeping themselves organized, and it hasn't gotten better with the advent of Remote Work.

Although it's technically correct that organization is non-value adding, it is essential to get organization right:

The Organizational Domain is the second core pillar in the TOP Structure

People

Do we have the right people in the right places, are they equipped and do they have the necessary support to succeed? People aren't just chess pieces we can freely move around on an org chart - they're individuals with needs and desires, and if we don't take care of our people, performance will decline.

Collaboration

Can our people collaborate efficiently and effectively? Are the right people in touch with each other? How much "telephone game" are we playing? Do we have policies that cause us to block one another? Do we optimize for utilization of individuals, or getting stuff done?

Learning

Do we get genuine learning from events, or are we continuously repeating the same mistakes? Do we have functioning feedback loops? Are we figuring out the levers for meaningful change, and do we turn all of this into action? And do we only focus on how we execute, or also what we work on, and how we think?

Why Organization often doesn't work

Especially project organizations and large "Programs" commonly neglect investing into working with people, improving collaboration or creating a learning environment.

Even "Agile" environments often delegate the responsibility for organization to the Scrum Master, although none of the items mentioned above can be done by a single person on a team - they're everybody's job: team members, support roles and management alike.

When the Organizational pillar isn't adequately represented, we quickly accumulate "organizational debt" - an unsustainable organization that becomes more and more complex, costly, slow, cumbersome and unable to deliver satisfactory outcomes.

Check your own team - on a scale from 1 to 10, how well are the above mentioned organizational aspects tended to?

TOP Structure - the domain of Architecture

In software, there's a critical intersect between technology, that is - how we turn ideas into working software - and our organization - that is, who is part of development and how they interact.

Architecture is at the crossover point of Technology and Organization

This domain is Architecture, and it exists one way or another - if we don't manage it wisely, the outcome is haphazard architecture, most likely resulting in an inefficient organization delivering a complex, low value solutions in a long time and at a high cost.

Am I trying to advocate for a separate architecture team? No. Take a moment and think about Conway's Law: If we have the wrong organization, the consequence is the wrong architecture, the consequence is the wrong technology - and the consequence of that is a failing business.

Architecture is bi-directional. The right organization depends as much on technical choices as vice versa. We need a closed feedback loop between how we develop, and how we organize ourselves.
In many companies, the architectural feedback loop is utterly broken, hence they're doing with 50 people what could be done with 10.

One of the key organizational failures which lead to the need for "Scaling Agile" is that architecture is either disconnected from workplace reality, or not even considered to be important. By architecting both our organizational system and our technology to minimize handovers, communication chains and process complexity, many of the questions which cause managers to ponder the need for "Scaling Frameworks" are answered - without adding more roles, events or cadences.

This form of architecture doesn't happen in ivory towers, and it doesn't require fancy tools - it happens every day, in every team, and it either brings the organisation in a better direction, or a worse direction.

When was the last time you actively pondered how technical and organizational choices affect one another, and used that to make better choices in the other domain?

Make - or Buy?

Determining which systems, components or modules we should "Make" and which we should "Buy" (in extension: use from Open Source) is a challenging aspect for every IT organization. Even when there's a clear votum by management of developers in favor of one option, that vote is often formed with a myopic perspective: managers prefer to "Buy" whatever they can, whereas hardcore developers prefer to "Make" everything. Neither is wise.
But how do we discern?

There are a few key factors at play here:

Factor	Details
Availability	When there's an affordable, ready-made solution, then "Buy" to avoid reinventing the Wheel. Be sure that ready means ready and "affordable" has no strings attached.
Uniqueness	you need to "Make" anything that's unique to your business model.
Adaptability	When there's only a small need for change and customization, "Buy" is preferable. Never underestimate "a small change."
Sustainability	"Buy" only when both initial cost plus lifecycle cost are lower. Include migration and decommissioning costs.
Skill	If you need specialists that you don't and won't have, "Buy" from someone who has.
Dependency	If your business would have to shut down when the solution becomes unavailable, "Buy" puts you at your vendor's whim.
Write-off	You can "Buy" to gain speed even when all indicators favor "Make," if - and only if - you're willing to write off everything invested into the "Buy" solution.

Choose wisely - the answers are often not as obvious as they seem.