Recent Posts

This is a short talk I gave a while ago about how complex systems fail, and root cause analysis. Transcript is below.

Recently someone said to me “stakeholders only care about milestones,” and something clicked for me.

Work should be completed in a series of small changes, where each change is a polished, fully-working improvement.

The tl;dr is that management is a set of powers and accountabilities that the role confers upon you, whereas leadership is the ability to motivate followers. Anyone can be a leader, and teams run on leadership not management. Management is not necessarily bad, but management without leadership is pretty dang terrible! Also management is like the nervous system of an octopus.

Feedback is a gift.

Some gifts are little treats for you to consume. Think of a box of chocolates. You enjoy them and then they’re gone, but you remember the thought that was put into them.

Sometimes gifts are utilitarian, like getting socks for Christmas. They are not the most exciting thing to receive, but you kind of need them as part of your normal day-to-day life, and you’ll get use out of them.

In this, the third and final part of this series, I’m going to present 10 recommendations for avoiding the pitfalls of using bucketed prioritisation (e.g. must haves, nice to haves, etc.), covered in the previous two parts.

Processes are a prerequisite for high-performance in software engineering teams due to their ability to amplify the skill of the team. I believe there exists no team, given that there is little to no process to begin with, whose performance could not be improved by adding appropriate process.

Engineering Managers (EMs) are sometimes said to be “shit umbrellas”. They are supposed to keep all the distractions away from the team: the short-lived whims and fancies of various stakeholders, vague plans that are going to change several times before being solidified — all that stuff. Distractions are poisonous to good software, so hiding them should help the team deliver more and better software. A large part of this is true.

However, I would like to argue here that behaving like an umbrella is probably not a good thing. Umbrellas are shields that block rain. And what are these EMs blocking? Hopefully distractions, but also information and reality.

In this article I’m going to take a look at software quality as a way to differentiate between junior, mid-level, and senior software engineers, through the lens of failure demand, purely so that I can introduce a new concept that I thought up on a walk today, which I’m calling negative failure demand.

In part two of this series, we’re going to look at how the must-have priority bucket leads engineering to make bad decisions.