photo of me

Lindsay Holmwood is an engineering manager living in the Australian Blue Mountains. He is the creator of Visage, Flapjack & cucumber-nagios, and organises the Sydney DevOps Meetup.

AWS in government: risks, myths, and misconceptions

The opinions in this post are my own, and do not represent my employer.

When undertaking digital transformation initiatives in your organisation, to effectively meet user needs, we need infrastructure technology that can adapt to user needs as fast as we do.

Because this type of technology is fairly new to government, there is a lot of uncertainty about how it can be used, as well as a lot of optimism about the opportunity it brings.

Let’s discuss some of the the risks, myths, and misconceptions we’ve encountered on our journey to fully cloud based infrastructure.


Help! I’ve just been made a manager

Your boss calls you into her office.

“Congratulations - I’m promoting you to team lead!”

Your mouth goes dry.

“You’ve been doing such great job on the last few projects, the leadership team thought you could help other people in your team perform just as good as you.”

Your stomach turns to stone.

“Your new role starts now. We’ll see how it works out, and come back in a few weeks to review.”

This experience may feel too familiar – and perhaps painful – to you. You get thrown into the deep end with a life jacket/anchor labeled “team lead”/”supervisor”/”acting manager”.

As we’ve read before, moving into a management position is not a promotion, it’s a career change. But fate (or your boss) may not agree.

How do you survive your first few weeks in your management role?


PreAccident Investigation Podcast Highlights, Sep-Oct 2015

These are notes I’ve taken while binge listening to the last two months of the PreAccident Investigation Podcast, which you should subscribe to.


Blame. Language. Sharing.

Failure can lead to blame or inquiry in your organisation.

When failure leads to blame, organisations subscribe to the old view of human error. They construct a narrative that’s far worse than the reality, a narrative that focuses on a single root cause, which is inevitably human error. This reductionist and deconstructive process has us go down-and-in, treating people and systems as separate entities, with people at the root of the cause.

When failure leads to inquiry, organisations subscribe to the new view of human error. People are part of the systems, inquiry is angled up-and-out, focused on understanding the relationships and bigger picture ideas at play. This is difficult, because it involves acknowledging and embracing complexity.

When failure leads to inquiry, we embrace different perspectives, different stories, different interests - and often these contradict one another. By embracing these differences, we create an opportunity for learning for people inside the organisation, navigating the delta between how we imagine work is completed in our organisation, and how it is actually done.

Learning organisations have three distinct advantages:


Management skills for new leaders

At DevOpsDays Melbourne 2015 I facilitated an Open Space session on management and leadership.

The purpose of the session was for experienced leaders to share their stories and discuss what skills are required for effective leadership, so new managers and people who are thinking about making the switch could learn from people who have been before them.

You can find the original audio on SoundCloud.

This is a writeup of what was discussed in the session.


Talk-To-Think, Think-To-Talk, and leadership

This cop threw me to the ground, cos hip hop is violent,
Said “You got freedom of speech, just choose to remain silent”

– Hilltop Hoods, Mic Felon

Effectively communicating with people in and around your team is the most important skill you need to develop as a leader.

How you communicate with people in your team defines how you build relationships and trust. Understanding how you communicate with people is key to being an effective leader and multiplier.

There are two main communication styles: talk to think, and think to talk.


CD for infrastructure services

For the last 6 months I’ve been consulting on a project to build a monitoring metrics storage service to store several hundred thousand metrics that are updated every ten seconds. We decided to build the service in a way that could be continuously deployed and use as many existing Open Source tools as possible.

There is a growing body of evidence to show that continuous deployment of applications lowers defect rates and improves software quality. However, the significant corpus of literature and talks on continuous delivery and deployment is primarily focused on applications - there is scant information available on applying these CD principals to the work that infrastructure engineers do every day.

Through the process of building a monitoring service with a continous deployment mindset, we’ve learnt quite a bit about how to structure infrastructure services so they can be delivered and deployed continuously. In this article we’ll look at some of the principals you can apply to your infrastructure to start delivering it continuously.


Why do you want to lead people?

Understanding your motivations for a career change into management is vitally important to understanding what kind of manager you want to be.

When I made the transition into management, I didn’t have a clear idea of what my motivations were. I had vague feelings of wanting to explore the challenges of managing people. I also wanted to test myself and see if I could do as good a job as role models throughout my career.

But all of this was vague, unquantifiable feelings that took a while to get a handle on. Understanding, questioning, and clarifying my motivations was something I put a lot of thought into in the first year of my career change.

People within your teams will spend much more time than you realise looking at and analysing what you are doing, and they will pick up on what your motivations are, and where your priorities lie.

They will mimic these behaviours and motivations, both positive and negative. You are a signalling mechanism to the team about what’s important and what’s not.

This is a huge challenge for people making the career change! You’re still working all this shit out, and you’ve got the ever gazing eye of your team examining and dissecting all of your actions.

These are some of the motivations I’ve picked up on in myself and others when trying to understand what drew me to the management career change.


It's not a promotion - it's a career change

The biggest misconception engineers have when thinking about moving into management is they think it’s a promotion.

Management is not a promotion. It is a career change.

If you want to do your leadership job effectively, you will be exercising a vastly different set of skills on a daily basis to what you are exercising as an engineer. Skills you likely haven’t developed and are unaware of.

Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.

You exist to remove roadblocks and eliminate interruptions for the people you work with.

You exist to listen to people (not just hear them!), to build relationships and trust, to deliver bad news, to resolve conflict in a just way.

You exist to think about the bigger picture, ask provoking and sometimes difficult questions, and relate the big picture back to something meaningful, tangible, and actionable to the team.

You exist to advocate for the team, to promote the group and individual achievements, to gaze into unconstructive criticism and see underlying motivations, and sometimes even give up control and make sacrifices you are uncomfortable or disagree with.

You exist to make systemic improvements with the help of the people you work with.

Does this sound like engineering work?

The truth of the matter is this: you are woefully unprepared for a career in management, and you are unaware of how badly unprepared you are.

There are two main contributing factors that have put you in this position:

  • The Dunning-Kruger effect
  • Systemic undervaluation of non-technical skills in tech


Applying cardiac alarm management techniques to your on-call

If alarms are more often false than true, a culture emerges on the unit in that staff may delay response to alarms, especially when staff are engaged in other patient care activities, and more important critical alarms may be missed.

One of the most difficult challenges we face in the operations field right now is “alert fatigue”. Alert fatigue is a term the tech industry has borrowed from a similar term used in the medical industry, “alarm fatigue” - a phenomenon of people being so desensitised to the alarm noise from monitors that they fail to notice or react in time.

In an on-call scenario, I posit two main factors contribute to alert fatigue:

  • The accuracy of the alert.
  • The volume of alerts received by the operator.

Alert fatigue can manifest itself in many ways:

  • Operators delaying a response to an alert they’ve seen before because “it’ll clear itself”.
  • Impaired reasoning and creeping bias, due to physical or mental fatigue.
  • Poor decision making during incidents, due to an overload of alerts.

Earlier this year a story popped up about a Boston hospital that silenced alarms to improve the standard of care. It sounded counter-intuitive, but in the context of the alert fatigue problems we’re facing, I wanted to get a better understanding of what they actually did, and how we could potentially apply it to our domain.