Learning from failure: a career lesson I carry forward

Three years ago, I sat in a meeting room in Parramatta watching a client presentation I had spent six weeks building fall apart. The dashboard pulled the wrong figures, the integration with the client's finance system had broken overnight, and the polished story I had rehearsed no longer matched the data on screen.

My first instinct was to blame the tools, then the timeline. The instinct that took longer to surface was to admit the failure lived closer to home. I had skipped the dry run, assumed the previous dataset still held, and let my own confidence override the evidence in front of me.

Australian workplaces tend to reward people who absorb a setback and return sharper. The country has a long tradition of giving the underdog a fair go, and that culture quietly shapes how hiring managers in Brisbane and Melbourne read CVs. Whether you are coding in Hobart, briefing stakeholders in Adelaide, or running stand-ups in Sydney's CBD, they want evidence of recovery, not a flawless streak.

That is part of why I keep this page at all. I want visitors to see more than a polished list of qualifications. I want them to see the years behind the skills, the lessons that did not arrive from a textbook, and the way I now approach every new engagement with more humility and a lot more rigour.

The project that slipped through my hands

The engagement was a straightforward scope: migrate a mid-sized financial services client in North Sydney onto a newer analytics stack and hand it over to their internal team inside a quarter. Budget was signed off, the head office was supportive, and the user champions were enthusiastic. On paper, the conditions were near-perfect.

The first warning appeared in week two, when a test environment behaved differently from production. I told myself we would reconcile it later. The second came mid-project, when end users flagged a discrepancy in the regional sales rollup. I logged it and moved on. By the executive demo, three quiet inconsistencies had compounded into a story the client could not trust. The technical work was roughly eighty per cent correct. The story it told was wrong.

Reading the numbers without blinding myself

Within a week of the failed demo, I pulled every metric I had on the project and laid them out in a way I could not argue with. Hours logged per phase, defect rates per sprint, the time between a flagged issue and a fix. The pattern surfaced faster than any manager's feedback would have.

The numbers were clear. I had treated integration testing as a final hurdle rather than a continuous practice. I was measuring progress in features shipped, not in client-validated outcomes. And I had allowed the team's enthusiasm to soften my willingness to push back on schedule risks. The data pointed firmly at me, and that is why it was useful.

Mentors, mates, and the Sydney coffee meeting

A few weeks later, over a long coffee near Circular Quay, a senior engineer I had worked with previously asked what I had actually learned, not what I planned to change on paper. I gave the polished answer first. He gave me the look Australian workplaces reserve for moments when someone is being a touch too rehearsed, and I gave him the real one.

The real one was that confidence and competence are not the same thing, and that the older I get, the more important it becomes to tell them apart. He told me about a similar mistake he had made a decade earlier while leading a rollout for a telecommunications client in Melbourne, and how it had reshaped his own checklist culture. Hearing him describe the same stumble without flinching made the lesson feel portable.

Rebuilding the workflow step by step

With the data in hand, I rebuilt how I run projects of any meaningful size. The first change was structural. I introduced a standing slot every fortnight where the only agenda item was reconciling what we believed about the project against what we could prove. If a belief could not be defended with evidence, it became an assumption, tracked until it could be.

The second change was about rehearsal. I started treating demo practice as a separate, scheduled session rather than an afterthought squeezed in before a client meeting. Across Australia, where a stakeholder in Perth and a colleague in Cairns often share a brief with teams in Melbourne, that rehearsal is the difference between a clear story and a confused room. I worked through a useful primer on building a smoother screen switching routine that has reshaped how I sequence my sessions.

Documenting the lesson on a personal site

One quieter benefit of running a personal site is that it forces you to write down what you have actually learned, not just what your latest job title suggests you should know. When I rebuilt my own page, I treated the project write-ups as a portfolio of decisions rather than a trophy cabinet of completed work.

There is a longer argument for why professionals across Australia, whether they are based in Geelong or Parramatta, benefit from owning their own corner of the internet. I made the case more thoroughly in a piece on owning a personal website, and the short version is simple: it lets your work speak for itself before the interview begins.

Sharing the takeaway with the Brisbane team

When I joined a new team in Brisbane the following year, I asked for a half-hour slot at the next retrospective to walk through what had gone wrong on my previous engagement. I expected resistance. I got curiosity instead. Two senior analysts thanked me afterwards for being the first person to describe a failure in detail rather than a vague "lessons learned" slide.

That openness gave others permission to share theirs. Within a fortnight, we had rebuilt the team's risk review cadence around exactly the kinds of small deferrals that had bitten me. A failure you process alone is a private cost. A failure you share openly becomes shared infrastructure for the people around you.

The question I ask before every new brief

Every new engagement now starts with a short internal briefing I run for myself, even when nobody has asked me to. I write down the three assumptions I am most likely to get wrong, the signals that would tell me each one is breaking, and the moment I will pause to check. If I cannot list those three things cleanly, I am not ready to start.

I still get things wrong. The difference is that the wrong things are smaller, caught earlier, and used as fuel for the next project instead of evidence to be quietly buried.

Practices for turning a setback into a career asset

A short list of habits I now recommend to colleagues who have just had their own version of that Parramatta meeting:

• Write a one-page post-mortem within a week, while the details are fresh and the temptation to soften them is strongest.
• Pull the metrics yourself rather than waiting for a manager, and do not rely on impressions.
• Find one trusted colleague outside your reporting line and tell them the full story.
• Rebuild one concrete workflow so that the same failure mode becomes physically harder to repeat.
• Make the lesson visible by adding it to your portfolio site, handover notes, or the next retrospective you run.
• Audit your assumptions at the start of every new brief, not only the failing ones.
• Decide in advance how you will know you are cutting a corner, and write that down.

If you are hiring, mentoring, or simply curious about the way I work after reading this, the contact details on this site are the fastest way to start a conversation. I am glad to hear from teams across Australia and beyond who take the long view of professional growth, and especially interested in projects where the brief calls for someone who has already learned the hard way and is ready to put that learning to work.