Essays on data, work, and personal growth that help you simplify without flattening what matters.

To Whom It May Concern: A Self-Recommendation

To Whom It May Concern: A Self-Recommendation

Saturday, March 28, 2026

It is March 2026, I am looking for a new role, and the market is tough as hell.

I received a rejection this week for a job I was genuinely excited about. The reason given was a lack of concrete technical skills, experience with technologies outside the stack I already know well.

It stings.

And if I am honest with myself, it is fair.

For the past four years, I was Head of Operations at Argus, a data and analytics consulting firm. My role was split: half internal operations, half hands-on consulting at clients. It was broad, demanding, and in many ways deeply satisfying. But I can see now that I did not push hard enough to put myself in situations that would force me to learn new technical territory. That is something I own.

What this rejection did, beyond the sting, was force me to examine the full picture. And when I did, I realised I had been so focused on the technical gap that I had not given myself credit for what I actually built over those four years.

So I decided to write myself a recommendation letter. To play the devil's advocate, this time opposite my inner critic.

What I did not do for the people I managed

One of the things I am most proud of is something invisible: all the times I did not step in.

When I was mentoring and coaching my six direct reports, some from their very first project, my instinct as a technical person was always to solve the problem myself. It felt more expedient in the moment. But I didn't.

Instead, I asked questions. I directed. I stayed available. I let them find the answer, make the mistake, and build the reflex. Each of them became autonomous on complex projects. That did not happen because I did the work for them. It happened because I trusted them enough not to.

That kind of restraint is harder than it sounds, especially for someone who came up through the technical side. It requires real confidence in your team, and real security within yourself.

What I built that does not need me

Early in my time in operations, I noticed something that bothered me: too much institutional knowledge lived in people's heads and personal inboxes. If someone left, it left with them.

I argued for internal email aliases so that communication and relationships belonged to the company, not the individual. I created and curated the internal process, evangalised and lived the boring discipline of documenting: storing the right information in the right place, until it became a reflex for the consultants.

I also designed the hiring process and ran it for seven years without a single incident on privacy or transparency. I built the discussion templates and reporting procedures for consultant supervision. None of these things required me to maintain them once they were built.

There is a particular kind of maturity in designing systems that outlive your involvement. It means you are building for the organisation, not for your own sense of indispensability. For someone who started as a hands-on technical individual contributor, learning to think that way was not obvious. I had to grow into it.

What I became that I did not expect

I came into this role as a technical person. I left it as something harder to label.

Over eight years at Argusa, I also organised events, hackathons, drove the company's external presence, managed client relationships, coached consultants, and contributed to the firm's identity from the inside out. None of that came naturally at first. My communication sharpened. My posture in rooms changed. I developed a collaborative instinct I genuinely did not have before, more observant of patterns, more patient with process, more interested in the dynamics between people than I ever expected to be.

And somewhere in the middle of all of it, I wrote a book.

The Analytics Operating System is a framework for making analytics consistently valuable inside organisations. It addresses why analytics so often starts strong and then loses the trust of the business. It covers how to build something that lasts — and how to keep the people doing that work motivated, visible, and protected from the vanity projects and rework cycles that burn them out.

Writing it forced me to articulate things I had been doing by instinct for years. That was its own kind of development, just not the kind that shows up on a skills checklist.

The leap

A few months ago, I quit my job without anything lined up.

I am quite risk-averse by nature. I plan. I prepare. I like to know where I am going before I take a step.

I quit anyway. Because I knew it was time, and I trusted that clarity more than I trusted my fear.

***

As I reach the end of this piece, I genuinely feel the desire to congratulate myself. Something I, as a risk-averse, chronic overperformer, never do.

I made changes in my behaviour and personality that I could not have imagined possible a few years ago. Letting go of hard technical skills to lean into other kinds of work. Admitting a gap and a rejection in public. Quitting a job without anything planned.

So I am proud of myself for having the courage to opt for people and process work rather than the safe path of technical certifications. Something that would have terrified the version of me from just a few years ago.

Sometimes we should pat ourselves on the back.

And then listen to the inner critic. Mine is calling me to work on that AWS certification.

So I will go and do that.

***

The Analytics Operating System is now available on amazon.

No comments yet

Join The Simplicity Stack

The unactionable newsletter. For people tired of doing everything.

Search