in Work

Resilience

At work we recently had a guided workshop on the topic of resilience. We were asked about what resilience means to us. It brought to mind a few things that have stuck with me over the years.

Four lightbulbs

Hello Internet is a wonderful podcast hosted by YouTuber CGP Grey and video-journalist/filmmaker Brady Haran. Episode 3 introduces us to Grey’s metaphor that each of us has four 100 watt lightbulbs, each one representing an aspect of our life:

The catch is that we only have 100 watts to distribute across the four bulbs. So what do you do? Do you keep each of them glowing at a relatively dim 25 watts each, or do you divide your time up so that you are sending most of your watts to one bulb for a period before switching to another one?

In 2019 I was managing a programme of IT change work with a high-stakes, bet-your-job deadline of 1 July. Our programme had no budget. So to get around this problem, we spent money we didn’t have at the start of the year in order to meet our deadline. If we made it, we could switch off a raft of expensive SLAs and effectively cover what we spent in the first half of the year through the savings we made in the second half. If we didn’t make it, we would have gone over budget by millions of dollars. Over Christmas 2018 I had told my family that for those first six months I would have to sacrifice as much of my time as I could in order to meet my deadline. I worked evenings and almost every weekend. Nearly all of my watts went into the ‘work’ lightbulb and it glowed while the others were barely visible. We made it. The programme was a massive success, but it came at significant personal cost, with the latter part of 2019 being a time of reflection and recuperation whilst trying to keep the next set of milestones on track.

The lightbulbs are an imperfect analogy, but the concept is useful. Burning the work lightbulb really tested my resilience. The whole podcast episode on the topic is worth a listen, but the good stuff starts about 12m40s in.

Learning, and keeping resilient through failure

Back in the early days of Twitter, when it used to be a fun little community and not the rage-inducing doomscroll-fest of today, I often found myself chatting with JP Rangaswami. He had worked as a CIO in the same industry as me. His tweets and blog posts explored the new social media world, the need for a good information diet as well as his love of music. I even found out that he used to drink in the London pub owned by my grandparents many years ago.

JP’s LinkedIn profile is striking. Instead of the usual chronological list of roles and achievements, he reflects on each job from the perspective of what he learned from doing it:

Reproduced with permission.

Reproduced with permission.

It reminds me of the wonderful episode of the Postlight Podcast where Jennifer Dary discusses how she worked out what she wanted to do for a living; she focused on the verbs — what she actually wanted to spend time doing — as opposed to the job titles.

Jen: … I made a very long list of every job I’ve ever had, both volunteer and pay. And I wrote next to each job my favorite thing about it, using, like, a little phrase with a verb… And you know, the reason that I say that is because there may be people listening to this who have no idea what their next step is, and what they think their next step is is a title, and that is bullshit. I will just tell you that. People say titles and they mean lots of different things by them. … And so the three most popular verbs on that list were “leading,” “connecting,” and “writing.” So I thought, cool. If I stay at arc, I need to push for a role in which that is my focus. If I go to another company, I need to look for a role in which that is my focus.

In JP’s profile, he doesn’t shy away from an honest assessment of when things didn’t work out:

Reproduced with permission.

Reproduced with permission.

JP went on to be CIO, MD and Chief Scientist at BT, Chief Scientist at Salesforce and Chief Data Officer and Head of Innovation at Deutsche Bank, so his failure didn’t hold him back. Talk of resilience always makes me think of his LinkedIn profile.

Knowing when to step back

In 2002 I became an ‘IT owner’ of an internally-developed application for the first time. I had a team of two developers, one focused on our database and the other who worked on the front-end of the system. We were trying to get our heads around a particularly difficult problem. We needed to manipulate a database query to allow users of the system to pull data out in a specific way, but it felt brain-meltingly complex. After a couple of days and many hours of looking at it, seemingly making no progress, my front-end developer told me that he was going to step away from the keyboard, head home and do something else. In the middle of the afternoon. We had a deadline to meet and this had me panicking — he was going to leave right now?

I hadn’t been managing people for very long, and we had only been working together for a few weeks. But we had a great working relationship, and he had done some brilliant work. It seemed silly to argue with him and try to persuade him to stay. I’m glad I didn’t.

The next day he wandered into the office with a big smile on his face. The answer had come to him in a flash as he was pootling around his house. We made the changes, and got the system doing what it needed to do.

Twenty years on and I am unsure that I have the level of maturity and self-awareness that my developer colleague did. Sometimes, a rare day that is relatively free of meetings stretches out before me like the road on the cover of The Best of Eagles.

I start the day thinking of all the work I will get done, and then get bogged down by some issue or other. I keep trying to push on, thinking that the only way out is through. I end up tired, with the stream of work from my fingers reducing to a trickle. This isn’t resilience. Resilience is knowing when to step away and do something else instead of grinding myself into the ground.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.