Thread by @ianmiell, I have a story about how I built my career around maintenance [...]

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">https://twitter.com/bojanrajk...

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

I worked for years in a & #39;support& #39; 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 & #39;site down& #39; 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 & #39;problems& #39; (as opposed to & #39;incidents& #39; (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& #39;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">https://zwischenzugs.com/2017/04/0...

Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Sites

tl;dr For several years I managed the 3rd line site reliability operation for many of the world’s busiest gambling sites, working for a little-known company that built and ran the core backen…

https://zwischenzugs.com/2017/04/04/things-i-learned-managing-site-reliability-for-some-of-the-worlds-busiest-gambling-sites/

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">https://en.wikipedia.org/wiki/Theo...

Theory of constraints - Wikipedia

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

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.

https://www.youtube.com/watch?v=zVUPmmUU3yY&t

8/n">https://www.youtube.com/watch...

Meanwhile I asked the company I worked for refused to talk to me about what I& #39;d done. I wanted to present to the board about the 20% cost savings I& #39;d demonstrated, and they said they weren& #39;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& #39;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& #39;re somewhere that doesn& #39;t care or value tech debt or maintenance, then you& #39;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& #39;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 & #39;change that part& #39;, learn to speak business.

If business won& #39;t listen, quit, and find one that will.

18/n

Latest Threads Unrolled: