Over the last few episodes I've talked about learning to improve our individuals, teams and entire organisations to handle change. In this episode I want to explore why it is so important to that we are learning to build our Software right. Often the focus of our teams is to build the right thing - which is certainly important. But we also need to think about building the thing right.
Or listen at:
Published: Wed, 15 Jul 2020 15:36:55 GMT
Links
- "Avoiding the alignment trap in IT" article by Bain & Company
- “Why Building the Right Thing Means Building the Thing Right” presentation by Liz Keogh
Transcript
In her talk “Why Building the Right Thing Means Building the Thing Right” presentation by Liz Keogh; Liz made me aware of the article "Avoiding the alignment trap in IT" by Bain & Company.
The "Avoiding the alignment trap in IT" article provided analysis of the success of organisations based on two characteristics.
How aligned the organisation felt that IT was and how effective IT was in delivering change.
From these two characteristics they defined 4 groups;
- The "IT-Enabled Growth" group if the IT was aligned and effective
- The "Alignment Trap" group if IT was aligned but not effective
- The "Well-Oiled IT" group if IT was effective but not aligned
- The "Maintenance Zone" group if IT was neither aligned or effective
They combined this with a survey covering 504 respondents and found the following;
74% of respondents considered themselves within the "Maintenance Zone" - where IT was not closely aligned to the organisation and IT was not considered effective at delivering change.
Of those organisations considering themselves in the "IT-Enabled Growth" category, they reported that their three-year average sales growth exceeded the average by 35% and their costs were 6% lower.
To me, neither of the results for those two groups caused much surprise.
While the original survey was from 2007, I really wouldn't be surprised to find much of a different result today. Many organisations still falling into that "Maintenance Zone" group - a clear sign that there are considerable opportunities available.
And of course having a highly capable and effective IT aligned closely to the organisation would intuitively lead you to expect brilliant business outcomes.
What comes as more of a surprise would be the results of the remaining two groups;
Of the two you could be forgiven to expect that better business outcomes are achieved from having a highly aligned IT rather than a highly capable and effective one.
The survey however showed this to be incorrect.
Those organisations that identified themselves as in the "Well-Oiled IT" group - with a highly effective but less aligned IT - reported that their three-year average sales growth exceeded the average by 11% and the costs where 15% lower.
While those in the "Alignment Trap" group - with a highly aligned but less effective IT - reported that their three-year average sales growth was below the average by 14% and the costs where 13% higher.
The results from the survey where clear; an effective and capable IT lead to considerably better business outcomes than have an organisationally aligned IT.
And this is what led to Bain & Company labelling that group the Alignment Trap.
By doing something that seemed correct - IT alignment to the organisation - actually resulted in considerably worse business outcomes.
Worse even then those in the "Maintenance Zone".
And this holds true to my own personal perspective.
I've worked with many companies over the years where their IT effort has been highly aligned, integrated with the local business unit.
The owner of business unit believes they are getting the best IT they can because they can control exactly what is required for their unit.
And at the unit level that maybe fine.
When however you expand further afield and look at the wider organisation you find that that narrow focus makes it very difficult to operate effectively.
If you are trying to do anything that crosses those Business Unit boundaries then suddenly you have a complete clash of technologies, principals, terminology – all of which are expensive problems to overcome.
I like to equate this sort of thing to town planning.
If each neighbourhood has sole responsible for its own planning then they will build based on their own wants. Each neighbourhood will have its own priorities.
Each will have need for water & sanitation facilities – so they build their own rather than gain the efficiencies of shared resources.
Each will zone its area based on its own wants. Your residential estate may back onto your neighbour’s toxic waste dump.
Each could build very effective and good roads within their neighbourhood – but what happens when that road crosses into another neighbourhood?
You need to be looking at engaging with your neighbour and convincing them that their side of the road is at least as important as you have it.
Otherwise you may find your 6 lane super-highway suddenly becomes a dirt track once you cross the border.
Hopefully you start to get the idea.
I once worked with a company that had a very aligned development team.
They had created a solution for the company and it worked really really well for their major client.
When however they landed a second client, their solution simply hadn't been built to support it – so with tight timescales – what other option did they have other than to “copy and paste” their existing solution?
Because their solutions wasn't effective, they has to spend a lot more IT money to expand it – plus they would really have struggled to have grown the business at any speed.
So it really doesn't sound unlikely that with the high alignment and low effectiveness that the business would have experienced the below average sales growth and higher costs reported by the "Alignment Trap" group in the article.
Taking a second example, a complex website had been developed very closely between the MD and a single developer.
The website was very closely aligned to what the MD wanted – which was great.
It wasn't however built using best IT practices, leaving the software in a very complex state.
That state was so complex that every change made to it became increasing more difficult (and expensive) to implement and test.
Again another example of falling into that Alignment Trap group.
In both of those examples, I found that two factors came into play that kept them stuck in the alignment trap;
Firstly, as there had been ineffective IT, each had amassed considerable technical debt.
I introduced technical debt in episode 16 as a way of equating short term based decision making in Software Development with Financial Debt.
We may choose to incur longer term costs for short term gain.
Taking a high interest loan to achieve a particular goal.
Or "cutting corners" with Software Development to meeting a critical target.
At some point however the debt needs to be paid down. Otherwise the overhead to afford the interest on the debt could be devastating.
With the two examples I provided; neither made an active choice to incur the debt.
They didn't know it existed until the organisations effective stumbled to a halt.
They didn't know enough to even be aware it was something they needed to address.
And they certainly aren't alone in that, in episode 16 I gave the example of LinkedIn.
In 2011, following a successful IPO, LinkedIn found themselves struggling to get new features released due to their technical debt.
LinkedIn would try to add a bunch of new things at once, then the site would crumble into a broken mess, requiring engineers to work long into the night and fix problems.
They reached the point that their technical debt was so great that they needed to stop adding new features - and fixed the technical debt first.
Not a great position following an IPO, being under high scrutiny by the market.
The second factor that kept the two example stuck in the alignment trap, was the lack of Learning.
These organisations simply did not see Learning as a important - thus failed to see, and learn from, the various warning signals that had come before.
As I've said before, the need to Learn is seen by some organisations as a negative - as a weakness.
And these two organisations fit that mould.
The fault was seen very much as being with the individuals. The individuals where lazy and should work harder.
The organisations has failed to understand the truth of their situation and the need to instigate a Learning culture.
One in which individuals, teams and the organisation as a whole purposefully engaged in learning.
Using that learning to iteratively review and make course corrects as they went.
I'd personally consider their executive teams obvious to the growing problems right up to the point that they run their organisations on to the rocks.
Returning to the original article, it was interesting to see that the advice on escaping the alignment trap was to drop back into the maintenance zone first. Then move into the well-oiled IT. And finally re-align with the business to move into that IT-Enabled Growth quadrant.
That isn't going to be a quick exercise.
It will likely take time and investment.
In most organisations we are talking years rather than months.
The rewards however - the reduction in IT spend and increase in annual growth – would certainly make a reasonable business case for it.
I would however suggest that, if done correctly, it should be possible to move out of the "Alignment Trap" group to the "IT-Enabled Growth" category through adoption of a Learning Culture.
I would always favour retaining that Business alignment where possible over returning to the "Maintenance Zone" category with the lack of alignment.
After all, we should remember that we really want to get to the "IT-Enabled Growth" group - with IT being both high effective and highly aligned
In this episode I've talked about why it is just as important, if not more so, to build the thing right with highly effective IT than to build the right thing with highly aligned IT.
And I've talked about how Learning is the path to that highly effective IT.
I have referenced the "Avoiding the alignment trap in IT" by Bain & Company and the "Why Building the Right Thing Means Building the Thing Right" presentation by Liz Keogh. Both of which I will include a link to in the show notes.
I would recommend reviewing both.
In next weeks episode; I want to talk about how dangerous it can be assigning intent to an individual based on their action.
I'm coming up to the 50th episode of "Better ROI from Software Development" podcast
I've been recording these episodes for just over a year now, and have over 8 hours of episodes.
Week in and week out I script, record, edit and produce these podcasts - and sometime it can feel like I talking to the wilderness.
So if you're a listener I'd love to hear back from you. Please reach out and let me know if you are listening.
I'd love to include any feedback or comments in the 50th episode.
Thank you for listening.
I look forward to speaking to you next week.