MongoDB.local Auckland, what an incredible event!

MongoDB.local In Auckland is done and dusted for 2023, and to call it an outrageous success would almost be an understatement.

It was an incredible privilege for me to present some of my story, particularly the events that occurred in 2013 that caused me to begin my search for a better database, ultimately leading me to MongoDB.

With great power comes great responsibility, and we, as software engineers, have an increasing, and probably disproportionate, influence over the success and failure of the organisations we represent and serve.

With that comes enormous opportunity and responsibility.

Our decisions as engineers and as engineering leaders have the potential to be business-critical, and through the zerospam story (a business I founded in 2006), I was able to share how a critical database failure resulted in a thriving business going out of business within three days.

We should always assume that our decisions are long-term unless we are 100% sure that we know otherwise.

You don't always know when an idea or system is going to take off. When we designed and built zerospam, we built it for what we expected the customer base to be. However, growth exceeded this, and e-mail velocity and volume vastly exceeded this.

Changing engineering decisions on systems that are running at scale is like changing a flat tyre on a vehicle travelling at 100 kilometres per hour on the motorway. It's almost impossible and almost never happens. What inevitably happens is that those engineering decisions become massive anchors that create drag and slow the business down.

Long-term decisions require careful consideration, and it was interesting that in a follow-up conversation with an experienced engineer over lunch, he commented that the more experienced he became, the more cautious he became in his decision-making because he realised the significance and the impact that those decisions would have on his organisation.

Decisions, particularly around our tech stack, have the potential to radically affect the agility, not only of our teams or engineering functions but of our entire organisations. They can equip us with the tooling to disrupt markets or serve as anchors that create massive drag and slow us down, increasing our delivery cost and ultimately giving our competitors an advantage they didn't even ask for.

The key takeaway from my presentation yesterday was that we, as engineers are deeply responsible not only for the success and failure of our systems but, at times, the success and failure of the businesses and organisations we serve.

When a building collapses, and people are injured or killed, we expect the engineers that designed and built that building to answer some questions. Shouldn't we then, in the same way, have that same expectation of ourselves when systems fail and businesses collapse and die?

I also spoke about some practical steps we've implemented at Cloudize to ensure this type of failure will not occur in our business.

Composition has always been part of good software design. However, as we abstract our level of composition and we start designing engineering solutions by composing systems from reliable, robust, secure and dependable cloud technologies, we find ourselves in a wonderful position to reduce our area of focus and expertise to our core value proposition, the thing our customers genuinely care about, the reason that our businesses exist and what our customers pay us for.

My final challenge to the audience was never to stop asking, "What else am I doing that my customers don't directly care about?". Inevitably, there will be several things that your customers indirectly care about. These are not the things you should be building but rather present an opportunity for you to partner with organisations that have made delivering those capabilities their primary reason for existence.