It’s Friday, June 17, 2022 in Portland, Oregon and it’s a cloudy day that was supposed to be raining but is instead just sulking, a sort of morose teen weather of a day, sitting heavily in the sky with a scowl on its face, implying in its language that it could rain, it just doesn’t want to right now, but if it doesn’t get what it wants, then it definitely will rain and then won’t you be sorry.
Apparently just one thing today.
… but you can make it easier for them to decide.
I’m going to write down a story here describing a pattern for modernizing how an organization does technology. Let’s start out by setting the scene:
You are in an office building. Or, you were in an office building, but it is 2022 now, so all bets are off. You are perhaps simultaneously in an office building and also in your home.
You are at a back office organization, which is to say, it “does the IT” for the other bits of an organization. Roughly speaking, it’s okay to make the lightly-held assumption that this part of the organization may not be particularly well regarded.
(That’s because it’s probably a cost center, in that it doesn’t really contribute to making money, it’s just one of those blood-sucking parasites (I paraphrase) that is told it needs to be economical and save money, rather than show how it adds value).
In fact, we can zoom out a bit. The organization looks like this: it’s been around for decades. The business relies on a bunch of applications, and there’s probably a main application, or a core set of main applications, and a little ecosystem that’s grown up around them. The core set – which might just be one – is probably a system of record. The fact that there’s cost centers in general is a sign of how management and leadership treat technology in general, which is to say that it’s something over there and while it’s acknowledged to be critical, it’s more tolerated rather than embraced.
At least, until now.
Now, someone with a taupe blazer has come in and is all excited. A change has happened, you see. In some environments, it might be a big forced-from-the-outside-world change, like, I don’t know, the massive, public failure of a vaunted service. The big emergency lit such a fire to the extent that the toppest of top leaders took it upon themselves to personally bring in some people to Do What It Takes To Get Things Done. Well, things got done, and they got done well, and now there’s a vague sense that we should Keep Doing Things In This New Way, Because It Shone A Light On How We Were Doing Things. This is awkward, because nobody was in trouble for how things were being done before – it’s just that they hadn’t failed spectacularly, so there was no reason to change how things were done. They were working, so why bother?
A gamma ray burst of disruption has washed over the organization now and people are looking at this back office with its applications. All of those applications are essentially silos because, well, why wouldn’t they be? IT was just a tool to get things done (fair! An entirely understandable and defensible position!) and the extent to which IT had been coordinated to date was more along the lines of “try not to spend too much money” and “are you sure you’re not doing the same thing?”, plus a bit of “well I know you said you need this, but I think you actually need that, and isn’t it a happy coincidence that what I say you need costs substantially less? Good? Excellent”.
You’re going to have to change, and the thing is, you’ve accreted a good few decades worth of inertia and org charts (and the odd re-org), but fundamentally, not much might have changed.
Oh, I should mention. You probably don’t have much internal capability because you outsourced most of it. IT is somebody else’s problem, so why not make it really somebody else’s problem? You get to hire experts, and if it gets messed up, well, it can’t be your fault, right? You hired experts.
> examine self
You are not wearing a taupe blazer, but you know the kind of people who do, and you sincerely hope that you are not one of them. You were brought in after The Great Disruption Event to bring the good news to this organization and, well, you’re in a bit of a pickle.
The first thing you did was a bit of fire fighting. It turns out that once there was someone who was in the right position (you) and knew what to look for (you) and had some sort of responsibility for not just understanding what was happening but also what should happen (also you), that there was quite a lot that wasn’t working exactly right.
But it’s a bit more difficult, because again, nothing was spectacularly wrong. In your eyes, though, you saw inefficiency plied upon inefficiency, you saw that things could be more reliable, could be improved more quickly, could be more responsive to what people in the front office wanted. Your eyes blazed, as it were, with seeing the opportunity for improvement. This was a fixer-upper that the occupants didn’t really know was a fixer-upper. Why, with the right coat of paint (your first mistake, really), this place could really shine.
So you start looking around and you’re in your grace period because you came off The Great Disruption and quite highly recommended, and at this time people in all these different siloed teams are quite happy to listen to you and do what it is you ask them to do because that’s the way the wind is blowing right now.
All is well. Nobody thinks things are on fire, but with your augmented reality, you are Neo and you can see the fallen power lines that are about to start potential raging wildfires and you, on your lonesome, have just spent a year or two wandering around finding those troublesome sparks and stamping them out and even, if you’re lucky, doing some preventative deforestation.
You’ve done some triage, and it feels pretty good. You can relax a bit. The worst of the invisible bleeding has stopped and while you have the support of your bosses and their leadership, you can’t shake this feeling that, really, they don’t know what it is that you’ve done, because, well, things weren’t really that broken in the first place. Sure, there were lots of reports about how best practices weren’t being followed and how perhaps you weren’t on some sort of cloud bandwagon (which doesn’t even make sense, how can you get on a wagon of clouds?) and you weren’t being sufficiently innovative, but hey, there’s progress reports and things are progressing and not regressing.
But now you’re two to three years in and there’s lots of things that make sense to do: all of those best practices, remember? You take a look at all of these application teams that are in your purview and some of them could get better at testing, some of them could probably get better at this mythical twelve-factor thing, some of them are quite happy with how they’re deploying their applications (which, to your horror, involves several hours worth of work at the weekend). You have a very, very long list of things that make sense to do.
Now, you can’t decide what needs to happen next.
And worse, it turns out you don’t get to decide what needs to happen, either.
See, you’re in-between. You weren’t hired into one of these application teams. In this organization, a new role has been created for you. Maybe you’re the Vice President of Infrastructure Innovation, but what matters about your particular situation is that you don’t manage any of these application teams directly. There’s someone who does that. And there’s someone who manages them, and who manages them, and so on, right up to the toppest of the top. You are alongside one of those people. You do not have a direct line, you have a dotted line. Most of the time, when you’re lucky and people feel like it, those application teams will listen to you because some of their members recognize that you have technical knowledge, skill and experience that has formerly been lacking in the organization’s management structure.
We should be careful here. You’re not implying that the organization’s management structure is technically inexperienced, that it (and therefore the actual individuals, the people with names and families and dogs and cats and so on) lacks the knowledge and skill to manage the development, maintenance and operations of these critical business applications (and yet the management of hwich is also, in some hard to describe way without rocking the boat too much, disdained). You couldn’t imply that because these applications exist and, as has been noted previously, none of them are on fire at the moment. Nothing is sinking. They are working. If they were on fire and/or sinking, well, people would know and heads would be on LinkedIn looking for new jobs.
What you have is influence without authority. You can suggest that people do things, but unless these teams’ managers and directors decide to do those things, they’re not going to get done. You do not set priorities. Your peers set the priorities. You merely inform. This might hurt and if you’re not careful, it might also lead to burnout.
If you weren’t aware of this already, your job is not to advise and manage the development and transition of these historically siloed applications that might be called “legacy” but you attempt to do so only in the non-pejorative sense, that they are just older, and not newer, and the closest you might get is to start saying that they might have accrued some technical debt (but even then the phrase technical debt might be contentious because it implies that someone, somewhere, has not been meticulous and fastidious in terms of managing their household technical finances, spending above their means and so on. It doesn’t matter, of course, that debt isn’t necessarily bad, it’s the continued accrual of it that can lead to problems).
No, in this particular case, your job is not just to let your peers and your boss (and so on) know all the exciting things you’re doing and help them understand them, but at some point, you’re going to need to persuade them (and thus manage them) into choosing to do the things that you think should be done instead of other things that they think should be done. Which isn’t a helpful way of putting it, you realize, because what you’re trying to frame is “what we should do” and expand the definition of “we” and the list of things that go into “should” so that it’s slightly wider and incorporates different, additional priorities than it does now.
This may be where you encounter significant friction because: haven’t you heard? There’s already technical debt. We’re already behind. It already takes too long to deliver features or whatever’s required by the people in the front of the organization, where they’re busy having parties at counter service (which itself is in the process of being outsourced). There’s technical debt because there’s too much to do.
Ah, you say. But the amount of technical debt is increasing. And if we do not do something about this technical debt, then it will keep increasing, and pretty soon we will drown.
Your peers (and so on) get a bit alarmed about this because nobody likes to be told that they are drowning if they feel they are not drowning, it can be seen as a frivolous waste of time. If they are indeed drowning and they know so, they also do not like to be told about it because can’t you see? They are drowning. Stop gawping and come and help. (This would not be the time for you to point out that perhaps they would not be drowning if we had done that work you suggested at the drowning prevention class).
So now you start to draw everything together. You have a long list of best practices and checklists and things to do that will help make your DORA numbers move in the right direction, all of those pipelines and monitoring and test methodologies and infrastructure-as-code (which is okay, because people have read about that in industry magazines) and containers and so on. Whenever you tried to get a team to work on one of these things that you picked it was pretty much a crapshoot: maybe they would, maybe they wouldn’t. And the reason why would normally rest on whether they gave a shit or not, and whether they gave a shit or not depended on their priorities at the time. Making a case based on best practices and abstract improvements or gains when, to be fair, everyone thinks everything is working well enough, was unreliable, to say the best.
You realize you need people to give a shit. You need people to decide that something is important because while everyone has said that of course all of your best practices are important, nobody is treating them as important because quite clearly, other things are more important. They are so much more important that your things, which you believe you have been hired to care about and implement and make sure get done, turn out to be rarely or reliably present in any sort of planning that goes on, explicit, implicit, deliberate or even accidental.
You need to make it easier for people to decide that what you think matters actually matters. You need leadership to decide that it matters, and you need leadership to decide (and realize) that it matters so much that they will step in front of a goddamn freight train full of shit and lay down their life in the biggest shit-umbrella of all time to shield their precious application development teams from furious, kicking, screaming stakeholders who’ve potentially been told that their precious new feature might take a little bit longer because it is very important for them (i.e. your leadership, them personally, at this point) to get this done.
You need that because your leadership needs to prioritize it so that everyone else down the chain can prioritize it down to the engineers, product, project managers, testers, account managers and so on actually treat this work as important, which means it gets scoped and prioritized. And you realize that things can only really get prioritized well if people understand why they’re important. While the stick approach may work in the short term (it’s important because I say it’s important for you to brush your teeth, you don’t have to agree with me, you just have to do it), ideally in the long term people agree with you as to why this (i.e. dealing with technical debt and, e.g. infrastructure and if you really want to go that far, “DevOps”) is fundamentally important and should form part of any prioritization exercise until the death of the universe.
You could also say that you can’t really do DevOps if the Ops part isn’t working with and collaborating with the Dev part, and the Dev part includes prioritizing what gets done (i.e. what gets Developed), so come on.
You can’t make people decide to treat something as important. But you can make it easier, and there are things you can do to make it easier.
But that’s another story.
That’s it for today, and this week!
How have you been?