I have a story about how I built my career around maintenance and tech debt, which led me to Docker and Kubernetes, which in turn has led me to a career centred around how change happens in business.

Read on...

1/n https://twitter.com/bojanrajkovic/status/1381260675620741128

I worked for years in a 'support' position after some years as a dev lead for a software company that delivered a platform to a specific domain.

First it was firefighting (3am 'site down' calls, and bugs during the day), but I turned it into an SRE role over several years.

2/n

It was possible because the customers _actually cared_ about two things:

- downtime (severe revenue and reputational losses)
- fast feature delivery (highly competitive unregulated market)

3/n

Because of these two things, customers cared about (and looked closely at) service levels, and we could draw lines between effort expended on 'problems' (as opposed to 'incidents' (this was in the age of ITIL)) and reduction in cost to their business (fewer incidents).

4/n

I got a Problem Team to manage (think error budgets, but we didn't have this language then), and we had processes around documentation, triage and prioritisation that were super-tight.

(wrote about some of these here: https://zwischenzugs.com/2017/04/04/things-i-learned-managing-site-reliability-for-some-of-the-worlds-busiest-gambling-sites/)

5/n

Once those processes were nailed (it took a few years, change is hard) I moved to the next bottleneck (cf theory of constraints): development environments.

VMs sucked for this, so most people still built and ran their envs by hand.

https://en.wikipedia.org/wiki/Theory_of_constraints

6/n

I heard about Docker, and got into it, building a PoC of our monolith shoved into a container over a couple of weekends.

We built it every night, and slowly got our team and others into containerisation.

7/n

Fixes were more easily tested on desktop and fix times and reliability and quality went up significantly.

I started talking about this in public and got the attention of other companies who were interested in hiring me.



8/n

Meanwhile I asked the company I worked for refused to talk to me about what I'd done. I wanted to present to the board about the 20% cost savings I'd demonstrated, and they said they weren't interested in talking to me for at least 6 months.

I quit.

9/n

I worked in a completely different field, and learned about other domains before going into consulting.

All this from a close interest in tech debt and maintenance.

10/n

The point here is that if you care about business value, then good things can happen, either inside or outside your company.

11/n

Although as a consultant I work a lot on new and shiny, I see my value as working on the processes and culture around delivering that. The new is a Trojan horse into addressing those problems.

12/n

Most often that includes focussing on the tech debt part; if you want to debug why a company can't change, you look at its current context and how it got there.

13/n

Doing the new gives you a chance to demonstrate that those processes and patterns of behaviour (ie culture) led to those difficulties in the first place.

14/n

If you're somewhere that doesn't care or value tech debt or maintenance, then you're not in a well-run company.

15/n

All companies should be thinking _at some level_ about costs of maintenance in a closed look with development - even if to make explicit the choice not to invest in tech debt.

16/n

Also, the truth is that some tech debt is tolerable - it's a business decision whether to make the thing perfect, and how far to gild the lily. Most of us are in a game of trade-offs. The wider business context is everything, and easy to lose sight of.

17/n

Per the original tweet, if you want to 'change that part', learn to speak business.

If business won't listen, quit, and find one that will.

18/n