Why can’t they just deliver in time

The bigger your organisation becomes, the harder it seems to become to keep each other in check when it comes to delivery. Simple epics that should take one sprint can become 4 sprints, and hard stories that seemed impossible can be done in half the time.

This erratic and unpredictable behaviour is endlessly frustrating.

• For business this means that they struggle with too much uncertainty, and an agreement is an agreement they will have to defend (internally and externally).
• For technology this means that they are constantly in an explanatory mode, frustrated by the inability of business to see the complexity and implication behind their questions. They constantly have to explain themselves and automatically assume an underdog position.
• For the company, since their development and business do not seem to be aligned. It constantly attempts to reconcile, but in the process of doing so the arguments don’t seem to fade away and therefore reoccur at a frustrating interval.

Wouldn’t it be nice if there was a solution in which business was constantly empowered by the opportunities that arise from technology and could rely on their commitments?

What’s underneath

For the reader that pays attention to details: yes I did write becomes cursively in my introductory sentence.

I’ve written quite a lot about why Conway’s law has such big implications on scaling companies and their software. And there’s a common folly many organisations will step into when they scale hard. They abandon hope too soon, because reliability outweighs opportunity.

Subsequently, it’s easy to assume that the amount of people working in tech and the output tech has is linear, while in fact it isn’t. There are many factors at play that define the output of a technology department. To name few:

• sickness or fatigue
• unfamiliarity with the territory
• friction in ownership
• unclarity in definitions
• having the ‘right’ people do the ‘right’ things
• knowledge
• congestion
• fear to be out of a comfort zone
• effectiveness of programming time

But the biggest one of them all: The output of an organisation is depending on Price’s law. Price’s law states that 80% of the output of an organisation is made by the square root of the number of employees. The rest is either enabling, gold-plating, discussing, maintaining, etc etc. The only variable we have here is: what is the definition of output.

For example, when you’d fire your 10% of top employees. What will happen? Output will go down, but again, not linearly! The rest of the organisation will struggle more, and thus their output goes down as well. The same law wil apply even without these top ten people.

There’s an opportunity here

And this is the fun bit. Since there are so many factors influencing the output of an organisation — and in this case, a technology department — there are many things you can do in the way things currently are to improve double the output and predictability, without having to double the amount of employees.

Good developers are hard to come by

It’s hard to find them, and even harder to retain them. You’ll need to create a climate that’s at least conform the market standards. This means car-lease contracts, good wages, the possibility to grow and learn, a positive vibe with emotional support, short travel distances, flexible work hours to name a few.

Remember, 80% is done by the the employees that fall into the square root of the amount of employees hired. Thus, when you hire very seasoned developers, they will improve the output of others as well. And that’s common sense as well, if there’s someone next to you being top-class, you’ll be inspired at least! This is the reason it’s important to understand the needs of this group of employees and invest in having a learning climate as well.

Transform and make it ownable

Conway’s law states that organisations can only produce (and maintain) systems that resemble the communication structure of the organisation. Changing the structure inherently means you’ll change your software. So, when you scale up from 1 team to many, you’ll initially will have many teams working on a very few number of applications.

But who’s responsible for what? When can you release? Will it break, why and by whom? This will create excellent Problem Owners hot-glueing in new features, but you’ll miss Product Owners that actually feel responsible for performance and stability. This will reflect in delays and continuous re-work. This is also the reason why we make things small and we move towards a Service Oriented Architecture based on Domain Driven Design.

By transforming these applications into smaller pieces, we can better see the interconnectivity of functions. Impediments can be spotted earlier in the process and can be worked on in parallel, which drastically improves predictability.

Focus

Context switching creates a tremendous loss. Up to 60% of output is lost because of a lack of focus. Employees need to be able to commit and connect with a real cause. This makes it so that they are intrinsically motivated, which can only be attained when the output of their effort is measured and shared. Of course there is always background noise, however we can — and should — remain realistic in the value attribution of opportunities. This means we should curate which exact pieces of them are bringing the value (and validating those) before pursuing them in their entirety. When everything is top priority, none of it is.

Be Fierce

The default nature of every animal (including ourselves) is to be fearful. Stick to what you know best. Bathe in comfort. Even when we know that things need to change rigorously, we tend to hold back on changing.

Changing something familiar will always bring discomfort. We don’t do well with discomfort. Things like: But what if I’m wrong? What if they reject my ideas? What if they see that I have no experience in this area at all? What I’m making it worse instead of better? Will always come to mind.

The common denominator here is the word ‘I’. All these thoughts are rubbing against the validation of the self, and bring a form of existential anxiety with it. That feels horrible, and therefore we try to avoid it. We tell ourselves horrible stories that are never validated against the real world, but nonetheless these stories are inhibiting us from doing or becoming better.

Times of stress are also times that are signal for growth. We can grow through adversity. — Rabbi Abraham Twerski

Practically, this means that we should stop exaggerating short-term losses when we should do an intervention to optimise. Simply put, if you don’t optimise, nothing will change and thus the moment of intervention will never come at all. Newly gained efficiency wil soon overtake the short term losses that held our fear.

Be fierce and optimise, even if this inherently means that for tomorrow you’ll do slightly worse, I promise you’ll do exponentially better over time. And who said you need to halt all progress? By introducing technological enhancement during the solving of business requirements we bring focus, quality and long-term improvement altogether.

Insanity is doing the same thing over and over and expecting a different result — Albert Einstein

When we develop, we add business value

Sounds logical, right? Well if it’s that logical no company ever would have any technical debt. And the fact is, we all do. So why is that?

We tend to be near sighted. We understand short-term benefits better than long term benefits and go with what we know. While instead, focussing on reducing friction for each developer seems like an investment at first, but has a major benefit when you look beyond the horizon. Examples of these would be: investing in high performant laptops, investing in a frontend platform, preventing unnecessary reliance on knowledge hidden in peoples heads or a hard to digest confluence environment, structurally enabling standard work routines trough automation that sets you up for immediate business value attribution.

Allocating resources — financial or actual people in development — on these isn’t blocking you from releasing business value, it enables you to win the game. Not doing it is penny-wise pound-foolish and harms you in the long run.

An analogy for conclusion

I tend to look at an organisation as a machine or a factory.

• Don’t expect carpenters to forge steel
  make sure you have the right skills in house.
• Build railways to move the products, instead of expecting your employees to carry
  invest so that the cadence can be increased
• When you see more than one team waiting for a machine, it’s either used for too many things or it needs to scale
  split big things in such a way that they can stick to a product owner with a team that’s responsible for it
• Provide the right tools, focus, training and knowledge
  invest to improve the quality in each cycle of the cadence
• Keep a keen eye on which pieces of the production chain can’t keep up when you increase the pace. Don’t increase the ability you can take in, before you have optimised the speed in which you can process it.
  know which chains exist and first focus on the pain-points on the floor to increase overall output. That also means that you first optimise how your people work and feel, before you search for more people to join.