Human DevOps - Sunday 31st March - Building Strength and Resilience


A couple of weeks ago, I ran the Amstelveen Marathon in support of Suicide Prevention NL. It's the first marathon I've attempted in over 12 years and my fifth overall. My fastest time ever was 3 hours 46 minutes. This time, I hoped to complete it in under 4 hours 30 minutes. I figured that with decent training, including some strength training, I'd be able to manage this okay.

However, I really learned an important lesson on the day. I eventually completed it in an undistinguished time of 4 hours 40 minutes - this was outside my goal and about 30 minutes slower than I secretly hoped for. So what had gone wrong?

I certainly had some extra time to think about this as I completed each painful kilometre. Two things were immediately obvious.

Firstly I had not trained for that extra time on the road. I assumed I'd be able to go at a faster race pace on the day and trained for time rather than distance. So my longest training run was 3 hours 30 minutes, but the distance covered in that time was only 27km. If I'd actually just stuck to my previous training plans and made sure I'd run 33 or 35kms during training I would have discovered my true race pace plus got used to the extra time out on the road.

Secondly, I'd not done enough strength training for the rest of my body. All that extra pounding - another 12% of extra time when the body was already tired - really was very hard on my frame. The week after the marathon, I struggled with back pain, which I'm only just getting over.

I think I made a couple of wrong assumptions in my training. I guessed that I could train pretty much as in years previously and get the same results with only a bit more effort. While I credited my increased age, I only really paid that lip service. Secondly I assumed that my experience would be enough to see me through. And while it was, it was a painful experience.

How do make our lives less painful when it comes to attempting the hardest things? Do we trust our experience or treat it like something new the next time? I believe you need to do a bit of both: ensure that you respect the challenge even if you have done it before, but also lean on your experience to improve the areas you know you can improve.

Therefore, it's not enough to be mentally strong; we must be physically strong and competent. We need to work hard at our technical abilities as a team and put in the hours as experts. We can prove this to ourselves every day by showing up for the work we do and for each other.

Sometimes, it's not enough to be kind; we must also be fiercely competent.

I wish you a pleasant and restful Easter weekend if you're celebrating it, and if not, I hope you enjoy this long weekend.

If you'd like to learn more about improving resilience and productivity in DevOps teams, reply to this email to register your interest. I'm putting together some resources specifically for training teams in resilience, mutual respect and productivity.

-- Richard


Monitoring Azure DevOps Build Pipelines with Prometheus and Grafana

Published on March 29, 2024

The best way to have a good time at work is to ensure you have just the right amount of surprises in your day. The right amount of surprises is the minimum amount of surprises unless you are a serious endorphin junky. Living on endorphins released by the excitement of firefighting is something that no… Read More »Monitoring Azure DevOps Build Pipelines with Prometheus and Grafana

Read more...

The Human Software

Software systems rule our world. My regular newsletter explores the human factors that make software engineering so unique, so difficult, so important and all consuming.

Read more from The Human Software
Human Software 272 - Impatient, Needy Writers

Writers are terribly impatient. We are so fragile, we crave attention all the time. So, for us, writing into a vacuum and not getting anything back is the worst. We will happily take anything including "wow, it really sucked" or "how could you be so old and so feeble at writing?" At this point in the journey of Human Software, I'm so desperate for feedback, I'm even willing to pay for it! So that's what I did. In January, I hired an editor, and he's been great. He helped me with the...

Human Software 271 - Drawing Inspiration from History

Over the last week, I drew a map of Kent reimagined as if the 1286/7 floods hadn't happened. According to the history books, those large storms and tidal events significantly changed the coastline of eastern England. The former Wantsum Channel became blocked with alluvial mud and sand, turning the once important seaport of Sandwich into a landlocked town too far away from the sea to accept large boats. Further afield Dunwich in Suffolk suffered a similar fate: In the Anglo-Saxon period,...

Human Software 270 - Finding Something to Say

Three years ago, I started a podcast without much idea of its future. Before that, I'd started writing, wandering through automation, programming techniques, infrastructure, DevOps, and thoughts about management, leadership, and how companies are organised. Where was I going? While I'd read a few books, it was clear that I was searching for something. Was I just talking for the sake of it? It sometimes certainly seemed that way. And then, about eighteen months ago, I started writing a novel....