steveheadshot.jpg

Hi.

Welcome to my blog. I talk about all things tech & leadership.

On Surviving Cannon Battles and IT

As a kid, I was never really into playing pirates. When I would play with my friends, we would play tag or army or something, but never pirates. And before you ask – no, we never played “datacenter disaster” as kids. It’s not fun now, and it wasn’t fun then either. But I never really played pirates. Maybe it was because I grew up near a river instead of the ocean, and “river pirates” doesn’t even sound like a cool thing; it sounds like the name of a AAA baseball team that can’t quite get fans in the stands and so has to make it interesting by having every player use a peg leg and a hook. Maybe they throw in $2 beers to sell tickets, too.

There’s absolutely nothing quite like the sea breeze and pirate cannon fire to teach you the principles of strategic IT survival.

There’s absolutely nothing quite like the sea breeze and pirate cannon fire to teach you the principles of strategic IT survival.

Anyways, I wasn’t big into pirates as a kid, but as I’ve gotten older I’ve become more fascinated with pirate stories and legends. I think it started when I read Michael Crichton’s Pirate Latitudes while on a beach vacation in Jamaica. Something about reading about pirates while looking out at the ocean they were sailing between where I was and Cuba made it all the more real for me. Since then, I have paid more particular attention to nautical movies like “Master and Commander” and pirate documentaries (there’s actually an interesting one on Netflix right now). The longer this has gone on, the more I started to long to be out on the ocean.

I’ve wanted to have a boat for a while now. I feel like I’m exactly the kind of person who would enjoy spending a long time out on the water tooling around. Of course, this is a bad idea for several reasons. First, I do not possess the free capital to purchase a boat; those things are really expensive - because let’s be clear - I’m not talking about buying a canoe. The other reason I probably shouldn’t have a boat is because I don’t really know anything about boats. I don’t know what a bilge is nor do I know what side starboard is. I’m usually okay knowing my right from left, but understanding port and starboard is a bridge too far for me. What I do know about boats is that the water goes on the outside of the boat, and if it’s coming inside the boat, you have a problem that you should address immediately.

So, instead of having a boat of my own I recently started playing “Sea of Thieves” with some friends sometimes at night after my kids go to bed. It’s not a very deep or complex game, but it’s fun  – and who doesn’t like throwing out an occasionally “Arrgh, matey” on the Discord channel? Recently, we were in a particularly difficult battle against some players that were far better than us. Our ship had been pummeled especially hard by enemy cannon fire so we had a bunch of holes in our hull, our masts were knocked down, the ship had started to burn, and we were anchored. The holes meant we were sinking pretty quickly, the masts and anchor meant we couldn’t get out of the way, and the fire was causing damage to our characters as we ran around the boat trying to fix things. Of course, the other ship was still shooting at us, so things were continuing to deteriorate.

Usually we work pretty well as a team, but we had a few moments of total chaos where we couldn’t decide on what to do. We were all asking different questions and couldn’t decide on a priority. Should we work on the masts and anchor so that we could try to get away? Do we patch the hull so we don’t sink? Do we bail to buy us more time before we sink under the waterline? And what about that fire? Should we put that out first so we stop losing hit points? If we died, we couldn’t save the boat. We knew we had to do all of the things to get back to seaworthiness, but we all had our own ideas about what we needed to do right now – we didn’t know where to start.

Flash forward to twelve hours later, and I was sitting in a meeting during work, and we were wrestling with how we balance expanding technical debt, the daily fires that pop up, and new projects and priorities that are coming down the line for us. We hadn’t been in the conversation very long before I realized that this meeting and the sea battle from the prior night were in many ways the same conversation. Aside from getting a chuckle that being at work bears some remarkable similarity to a pirate video game, it forced me to reframe how my team and I were approaching the situation.

I find that just stopping to think when something is falling apart generally returns dividends many times over.  Even when in the office.

I find that just stopping to think when something is falling apart generally returns dividends many times over.

Even when in the office.

I started to think through how to approach the conundrum from a goal-oriented standpoint. What I mean is that I started with our desired end state, which included more automation and reliability so that we didn’t have to fight so many daily fires initiated by customers. We also wanted to catch up on and pay off a bunch of the technical debt that was causing some of these problems to crop up in the first place, which would mean we would have the bandwidth to quickly address upcoming projects instead of fighting to stay “afloat” (hey, I recently wrote about how much I love analogies – you should have expected that.)

We found out pretty quickly that if we spent all our time on fighting the daily fires, we’d never be able to get out from the technical debt or invest in projects that create real value or forward momentum – we just don’t have enough resources. And if we spent our time on just the new projects, we’d end up failing the university because we didn’t tend to user requests and tickets that were critical to the institution’s overall operations. To go back to our boat analogy, we realized that if we spent all our time patching holes in the boat, fighting fires, and bailing we’d continue to take cannon fire forever. We may not sink, but we would never get under way and make any forward progress. We’d just forever be patching holes and taking blows. Likewise, if we spent all our effort on getting the masts up and sails ready, we’d sink before we ever got moved a foot.

Eventually, we got to a point where we all agreed that we would be best served if we didn’t do either of those things 100%. Instead, we split the team up into a group that could focus on projects, and another that would handle the daily fires and tickets that came in. We acknowledged that it meant we’d make slower progress on new investments, and that not all tickets would be resolved in a timely manner. In effect, we had to learn to strategically fail at certain tasks; we couldn’t get to every ticket as fast as we wanted to and we couldn’t do all the projects that were worth doing as quickly as we wanted to. We had to be okay with not doing A+ work on both areas, and needed to get to a C- in both to get out of the sticky situation. Some things had to be sacrificed in order to prevent the team from sinking as a whole.

We ended up be aggressive about prioritization. If a ticket needed to be acted on because it was critical to the business, we’d do it. If not, we’d table it so that we could keep our projects team focused on building some automation. In our case, it was getting some better endpoint management software in place so we could do more self-service for our end users – something that both our customers and our desktop techs were desperately asking for. Just being able to get that margin back from the self-service got us to the point where we could start to get even more cycles back to invest in more projects that move the ball forward. Ultimately, the goal is to spend as little time as possible fighting the fires so that we can spend more time transforming the tech infrastructure of the university.

Again, to think of it in boat terms, we needed to patch the minimum number of holes, and bail just enough water to keep us from sinking. The only goal was to not sink – it wasn’t to stay totally dry. Once we reframed that and accepted the modified goal, we had someone available to go upstairs and work on the masts and sails, which got us to start moving a little bit. That made it just a bit harder for the enemy to hit us, and so then we were able to have one less person bailing and patching and we started to move just a little faster. The goal is to keep repeating this until we don’t need to bail at all, and we can spend everyone’s time on improving the boat instead of fixing it.

Look, I just like designing things more than I like fixing them. So for me, the ideal state is less broken stuff and more time spent on building new things.

Look, I just like designing things more than I like fixing them. So for me, the ideal state is less broken stuff and more time spent on building new things.

Look, I don’t know about you - but for me, IT is the most fun when we’re building new things and introducing new technologies and new opportunities to help people be more productive or solve problems they didn’t know how to solve before. While I may not have met you, I bet you feel the same way. After all, who ever heard of an IT Pro who said the best part of the job was dealing with an endless stream of tickets that they knew deep down were not truly necessary if they had the right tools in place? While it may not be fun to get a flooding boat moving while taking fire, sometimes we have to get through that stuff so we can get to smoother sailing.

Currently, I’m working on getting my colleagues and team comfortable using my boat analogy to talk about important decisions or priorities when it comes to the tension between investing or building for the future and taking care of the fires that keep popping up all around us. It turns out that most don’t share my enthusiasm for life on the high seas, so I may end up needing to rewrite the script to fit a Star Trek storyline. However, I think it’s helped everyone get clarity about why we’re operating the way we are when we find ourselves needing to strike the right balance between repairing, bailing, and gaining momentum.

So, what ever happened to us in the game? It would be too poetic to tell you that we were able to keep the boat afloat long enough to get some distance between us and the enemy, get fully repaired, came around and opened fire sinking our attacker. Alas, that was not the case – not by a longshot. I wish we were able to, but ultimately, we ended up getting boarded and murdered because we never did get moving. We were stationary too long. After we respawned, our boat was going under, our treasure lost, and the night effectively wasted. Then, in proper gamer culture the attackers insulted our mothers and repeatedly typed “EZ.” Keep it classy, gamers.

How about you? Are you forgetting to get moving, or are you spending all your time gaining momentum at the expense of taking on a ton of water down below? I hope it’s neither. I know for us, we’re consistently spending more time moving forward each quarter, because we acknowledge that our goal isn’t a perfect record on tickets.

Questions for reflection:

  • Have you ever been in a situation where you had to choose between fighting the fires and building the technology to prevent them?

  • Have you thought through what your goal for daily firefighting is? Is it to get to 100% success?

  • How do you feel when you spend your time fighting issues and problems? How about working on technology investments? Which do you enjoy more?

Make the Most of 1:1 Meetings With Your Boss

Is Software Getting Worse? (Part II)

Is Software Getting Worse? (Part II)