Technical Equity
Ashley Roper asks "If Technical Debt represents risk, does building Technical Equity offer opportunity?"

It is not only in financial terms that attention should be paid to debt accrual. The concept of Technical Debt[1] is one that everybody in a leadership or commissioning position should understand.
The specific term “technical debt” was first used by Ward Cunningham[2], one of the authors of the Agile Manifesto[3]. If not managed well it can seriously affect everyone. It can impact department spend, interrupt and disrupt service delivery, and even damage professional reputation.
What is Technical Debt?
For the purposes of this article, Technical Debt can be simply explained as the gap between the ideal technical solution and what you currently have. Reasons for the “gap” or the “debt” might be commissioning errors, budgetary constraints, lack of engagement between the organisational leadership and the IT leadership, or quite simply the speed of technological evolution and changing business requirements.
So what is the issue with Technical Debt?
Just like a financial debt, Technical Debt accrues interest which needs to be serviced and paid down. When you are investing your capital in paying down financial debt, you cannot put it to work investing in things which accrue value. Technical Debt has a similar effect. It results in time, energy and resources being diverted away from creating possibility, to avoiding disaster.
Is there such a thing as Technical Equity?
Technical Equity is the other side of the balance sheet . When you have control of your finances and your debt is not accruing interest and absorbing your cash, you can invest. You can build wealth rather than manage “day to day”.
Developing Technical Equity means that rather than simply having a stable environment where your IT estate invisibly meets today’s needs (a dream for many IT and Business Leaders), your most technically literate and innovative people are free to help your business streamline, optimise and innovate.
Things that were impossible a year ago are possible today. And even more will be possible tomorrow.
Organisations need to pay down debt and build equity quickly if they are not to fail.
So why don’t we just do that?
Because it is hard. If it was easy, it would already be done. Knowing where to start is difficult, and asking for resources without a plan is challenging. So let us help.
RPNA has developed a series of diagnostics that will help leaders and team members tasked with delivery and improvement ask the right questions, of the right people about the right things.
And because we’re nice people…we often just give them away (despite people routinely telling us we’re mad).
If you want Diagnostic One which will help you ask the right questions to build Technical Equity in your organisation, just ask. It will help you get to the heart of what is happening today and build a plan for tomorrow and we will jump on a call to configure it and send it right over.
What areas does the diagnostic cover?
There is a lot to think about and accomplish. I’ve wrangled the requirements for a Technical Equity building organisation into an acronym below – you can use it in your business case for change!
Technical Equity can only be efficiently accrued in environments where:
Organisational and IT strategy alignment is high.
People Development and Planning is mature.
Partners and Supply Chain are aligned and well managed.
Organisational resources are focused on maintenance AND innovation.
Routines and processes contribute to frictionless operation.
The technology estate is understood, documented(!) and well maintained.
Unified incentives and targets align with the organisational strategy.
Nothing gets in the way of developing people.
Informed decision making is directed by great user engagement.
Trust and Psychological Safety is high within all teams
“Yo” is the favoured team greeting
OK so yes, that took some effort and no, not even ChatGPT could help with Y.
Let us know your thoughts...
What are your thoughts on the concept of Technical Equity?
What else is needed to build possibility and opportunity?
How do we get IT leading the business not just supporting it?
What would you have written for Y?
Is anybody still reading?
Photo by micheile henderson on Unsplash
[1] https://en.wikipedia.org/wiki/Technical_debt