Thursday 25 April 2019

Tech @ Core - What Does it Really Mean?

The Fourth Industrial Revolution

We've been talking within ThoughtWorks, and to our clients, for a few years now about tech@core. I wanted to understand when we had started talking about tech@core and where it came from. From what I can tell from asking around internally, the phrase is derived from an article written by Sai Mandapaty and Dan McClure some time ago. I say "some time ago" because nobody was able to give me an accurate answer as to when it came about. The only thing I can say for certain is that it must predate 2nd November, 2018 because this Insights article, by Namrita Bhat-Rao and Sneha Prabhu references it.

A graphic I have seen a few times, with slight modifications, to explain what tech@core means can be found in both of the above mentioned articles. Here is the one I found in Namrita and Sneha's article:


It is quite clear to me that a modern business needs to stop regarding its technology organisation as a cost and needs to start regarding it as a value creator. This is part of the tech@core transformation. Equally, having worked in several ThoughtWorks clients who do not yet buy in to this type of thinking, it is clear to me what not being tech@core can mean in terms of internal dysfunction. What isn't clear to me, although I hope it is becoming clearer, is exactly how we can articulate the what and the why of tech@core to our clients to get them to buy in to it.

Dogma and Preaching to the Converted

One problem I have noted a few times in my 4 or or so years at ThoughtWorks is that we can be guilty of being dogmatic. This is a criticism that is sometimes levelled at us by our clients as well and is definitely something I've noticed internally. The problem is that we believe in some things so strongly that we sometimes forget that to other people this could be some kind of new fangled, even crazy, idea. I have met and worked with ThoughtWorkers who struggle to articulate to clients why pairing is a good thing because it is all they have done. To them, it is a dogma.

The trouble with dogma is that it doesn't help you to explain to an outsider what is good or bad about something. It is just true. I can give an example from UK politics. Some time ago a left leaning (and very intelligent) friend of mine declared that a policy of the Conservative Party was bad because "it is privatising the NHS". Why is privatising the NHS a bad thing? I asked. To this, she had no good response. She spluttered that it is obviously bad that the NHS should be privatised but couldn't drill into why it was bad. I am not saying I support the privatisation of the NHS but I'd like somebody who definitely opposes it to be able to articulate what is bad about it to help me make a call on whether I should support it or not.

So dogmas are very good for preaching to the converted. In the political arena they make great sound bites for a party conference and if you repeat them often enough they may even start to sound true to those people outside of your bubble. They don't do a good job when it comes to convincing people to modify their stance to somewhere nearer your point of view. So it is with tech@core. I started noticing that we are trotting it out as a dogma and people aren't necessarily doing a good job of drilling into why it will help your business.

What Does it Mean to our Clients?

I worked for a very interesting client last year. They described themselves as a "tech company" but their assertion is based on the fact that 95% of their business is now done through their website. In fact, they are far from being a tech company and that was very clear to us while we worked there. But what is a "tech company" and why is it good?

I'm not sure what it really means to be a tech company. I am pretty sure that the startup I worked for before ThoughtWorks was (and remains) a tech company. My contention to that effect is based on the fact that the tech organisation is highly integrated with the business organisation and takes a full part in ideating and realising the company's products. At every step the tech people are involved in conversations about what the products will look like and they are involved as much as other business people in the high level decisions of the company.

On the other hand it has become clear to me while working for ThoughtWorks what characterises a company that definitely isn't a tech company. Some examples of such behaviours would be treating tech as a cost, "throwing things over the wall" to business people for approval, insistence on detailed requirements before building new things (from tech to business) and insistence on set in stone, almost written in blood, delivery dates for everything to be built, no matter how big or uncertain (from business to tech). In fact, the very existence of a "them and us" attitude between business and tech is pretty easy to spot and probably the biggest indicator that the company is definitely not a tech company.

Sometimes a company is struggling so badly to get something, anything, done that any improvements we can help them make are welcomed. In that way we can start to improve things and play our messaging at the same time. The improvement will be seen and the messaging will reinforce that the better place that we are on a journey towards is called tech@core and everybody knows that we are getting there because they can see it. Thus the message becomes a bi-product of the necessary actions we are taking rather than a thing that helps us to start on the journey.

But why should a company aspire to be tech@core if it can't see a problem that needs fixing? My problem last year was that our client, dysfunctional though it very definitely is, is delivering on its growth targets in spite of everything. How can we convince them that they need to be tech@core when the only thing the CEO sees is the bottom line which seems to be a good bottom line? Our biggest problem is unlocking some of that growth to fund the investment that their platform and their internal organisation needs to avoid a looming disaster. And therein lies the problem. We gave a proposal involving a smallish team of our people spread across their business to help start them on the journey from where they are to tech@core. The first response was that the cost was "more than [the CTO's] capex budget for the whole year". This comment told me a few things but most importantly it told me that the company saw technology as a cost centre that supported its business.

So What IS Their Problem?

We worked at MyBigClient for 3 months with their technology teams. We saw a lot of dysfunctional behavoiur, including, but not limited to the following:
  • Mistrust between business and technology. Leading to:
    • Insistence on specifying delivery dates for features at the time of maximum uncertainty for the implementation (the start).
    • Reluctance on the part of technology teams to innovate because of perceived risk and the desire to not be blamed for failures.
    • Time consuming risk management theatre style meetings ostensibly to decide on actions but in reality to share blame collectively when things go wrong. 
  • 2 weeks "regression testing" before every release leading to longer cycle times and more risky releases
  • Misalignment of goals between business and technology.
  • Some teams driving technology led change without business sponsors or clear business value,
  • Poor understanding of Agile principles leading to poor engagement in Scrum rituals.
  • Ever increasing technical debt, the tech debt cycle that I have previously written about.
BUT despite all of this dysfunction the company is still (as far as I know) achieving the growth targets that have been set for it by the private equity fund that owns it.

The Cost of Doing Nothing

We were asked by the CTO to make a case for implementing the change that we believe is necessary for the business to continue to be successful. As I've said before, everybody understands waste and wants to eliminate it from their business so initially I focused on how much money MyBigClient wastes every week / month / year on the processes they have in place to make up for the fact that their culture and structure are dysfunctional. I did some calculations and it turned out that the amount of money being wasted in this way was surprisingly uninteresting. It was so uninteresting that it was dwarfed by the spend that we were proposing for the first 6 months of our engagement with them. This was a little surprising to me and not a little disappointing since it meant I had to try to make a convincing economic case first to myself and then to their CEO.

Building a Case - Understanding the Problem Myself

We were asked to attend a board meeting at MyBigClient at which we would summarise our findings from the earlier engagement and make a case to the wider board (the CTO and head of product were already convinced) that they needed to engage a company like us to solve their problem. We got together a small team to work out how to make this pitch. This team consisted of myself, the CP (Client Principal, ThoughtWorks speak for a client relationship manager) and two product specialists. At various times we had some of our retail domain specialists in the room to help understand the wider context of MyBigClient.

I had already prepared the "cost of doing nothing" slide for an earlier meeting with MyBigClient and passed on to this bid team the disappointing findings of it. Very quickly, one of our product people told me that he wasn't at all surprised. He went on to tell me that we shouldn't even be talking about technology staff, or indeed any staff, as a cost. Thus it was wrong headed to talk of cost saving as this is very limited in its impact (as I'd already discovered) and its story telling power (as I was starting to learn).

Burning Platform - NO

As a quick aside, I was asked if MyBigClient was a case for the Burning Platform metaphor. I actually think it was (and remains) a very solid candidate for this metaphor. I didn't, however, want to use this argument for two reasons. Firstly, I wanted to paint a more positive picture to the client than "if you don't do anything you'll die" message that goes with the burning platform. Secondly, I hate this metaphor with a passion. My cousin works in the Scottish oil industry and I know several others who work in that industry. I think it should be beneath us to use such a grisly metaphor and we should be capable of coming up with something better to illustrate this point.

Opportunity Cost

While we were at MyBigClient there were at least two major production incidents that caused a prolonged inability to sell things. It was possible to estimate the cost of lost sales incurred by these outages but again it wasn't that interesting. It was even less interesting when some people made the argument (not proven as far as I'm concerned) that those sales weren't lost, they were just postponed.

Our product person was very quick to home in on cycle times and how long it took to release new features. She was asking such great questions that I realised that the original engagement may have had slightly better outcomes if we had had a product specialist instead of one of the two technologists for the duration of the gig. In any case the question became "how much did it cost to not have these features"? We had always had this question in the back of our mind but it is a hard one to answer because it involves understanding the value of a feature before you've tested it live.

The "Killer" Feature

When she asked me to give some examples of stuff we'd seen it became pretty obvious pretty quickly what we should be concentrating on. MyBigClient had been delaying its launch into the US market for months pending the release of a feature that they were calling "US Tax". I don't remember the precise details but apparently you can trade up to a certain turnover in the US (which they were doing) without calculating local, state and federal tax on your sales. Rather, you can leave it to the buyer to pay the relevant taxes. In order to for MyBigClient start marketing campaigns or open a bricks and mortar presence in the US, it was necessary for them to have the US Tax feature in production. This feature was at least 6 months late despite it seeming relatively simple to implement.

So if we made some simple assumptions about the opportunity size of selling into the US market and multiplied that by the delay, assuming some reasonable time for the implementation of the feature for a high performing business, it was possible to paint a much more convincing picture of why change was necessary. More importantly (at least for my sensitivities) we could do this without painting a bleak picture.

Why did it take so long and what is the Solution?

It is hard to say exactly why the feature took so long to deliver except by saying they aren't doing anything much right. All the dysfunctions are there. Engineering practices are weak, there is lack of trust inside the company, lack of engagement at all levels and a huge fear of taking decisions or any kind of risk. Our problem was to summarise all of this in a couple of slides. The solution, sadly for them, is not a silver bullet but a long program of change. But how could we convey it? Eventually, after much discussion, we came up with some wordy slides around opportunity cost, focusing on US Tax, coupled with the slide reproduced below which drilled into what tech@core means for them.

Drilling in to Tech@Core

My concept slide that I gave to the demand person in our team:

 

My idea was that I wanted to home in on their (mistaken) belief that they are a tech company ("we do 95% of our sales through the website, of course we are a tech company") by splitting it into some sliders that they wouldn't dispute. The argument being, move yourself to the right of this picture and you will fix some of your problems and you will become a tech company and everything will be great.

Fortunately, the client principal I was working with is much better than I am at playing with graphics in Google Slides. He loved my concept, played around with it a bit and came up with this:


So we had found a way to link their dysfunction with the solutions to their dysfunction in a way that we could link back to our own marketing of tech@core.

The Outcome

We had the meeting in which the CEO accepted all of our points. They were impressed with the knowledge that we had built up of their organisation and the "amazingly accurate" descriptions of what had happened in the past that we hadn't seen or asked about. They agreed that they needed to put in place a plan to fix all of the dysfunction that we had highlighted. A few weeks later they came back to us to tell us that they wanted to implement the suggestions we had given them in the outputs from our original short engagement but they felt that they can do it all without us. Ah well, you win some, you lose some. I really enjoyed working there and I would have loved (would still love it if the opportunity arises) to go back there to drive their transformation. Good luck to them, I hope they succeed and I'll be very interested to cycle back to them in a couple of years, if they haven't engaged us in the meantime, to see if it is possible to drive an effective and lasting transformation without introducing an external change agent.

4 comments: