Then I read this great piece: ‘How To Not Be Replaced by AI’ by Max Berry and it nudged me to finish this and post it. You might want to read his post first.

I’m a dad. We have an 11yr old and a 13yr old. They are at an age where they are just beginning to enjoy school subjects and extracurricular interests on a level that might eventually shape a career.

If you’d asked me five years ago what I’d push my kids towards learning, I would’ve said “coding” or “design”. Now I’m not so sure.

Honestly, I don’t just worry about how AI might affect their choices. I worry about the immediate future of my own white-collar job too.

I don’t want to get into AI hype versus skepticism. But it seems to me that two things are profoundly true:

• White-collar work almost always involves individuals generating things based on past skills and experience.
• Generative AI is very good at generating things.

So if white-collar work is going to exist long term, and if my own career is going to keep making sense, I’ll need to keep generating things that AI doesn’t, or can’t.

What do I mean by “things”?

In software, we generate artefacts like code, designs, and slide decks. We also generate softer outputs like negotiation outcomes and strategic direction.

AI is going to keep getting better at generating all of these. It’s already surprisingly competent at the soft stuff.

You see the same pattern elsewhere. In pharmaceuticals or hardware, AI is catching up to, and sometimes exceeding, human ability to generate artefacts and even manage parts of their deployment.

Arguably, AI’s greatest potential isn’t just recreating human work, but generating genuinely novel artefacts. New medicines. New materials. New climate solutions humans might never have thought to try.

Sometimes it feels like there’s no limit to what AI can generate.

I think there is.

As yet, untrained

AI models are fed enormous amounts of data. The bigger and better the datasets, the better the outputs.

Those datasets come from public and proprietary sources, but they share something important: they’re available.

The subconscious mind is not.

Today, AI can use available data to approximate subconscious human skills. Facial recognition is a good example. AI can distinguish between identical twins faster than their family can. And that same family, over time, learned to do better than strangers through repeated subconscious exposure.

Many “soft skills” AI is improving at, like writing a strategy document, follow the same pattern. AI finds patterns in available data and uses them to achieve outcomes humans often rely on learned subconscious processes to produce.

But not everything in the subconscious is learned. There are many human processes we don’t fully understand, don’t know how to articulate, and sometimes don’t even know why they exist.

A skill we don’t understand can’t be documented.

Data that isn’t documented isn’t available.

There’s a large corpus of data locked inside us that AI simply isn’t close to training on yet. That gives humans, including white-collar workers, an edge.

What now?

To keep my own job relevant, I’m planning to keep training my brain. That means not just leaning into soft skills that are harder for AI to catch up on, but deliberately exploring creative edges of the world.

For my kids, I’m going to gently steer them away from anything that’s purely artefact-driven, and more towards:

• Emotional intelligence and soft skills
• Resilience and adaptability
• Going deep on a few subjects while staying broad elsewhere (T-shaped, if you like)
• Building creative muscle

So how do you exercise creative muscle?

This might sound a bit wacky, but these are approaches I’ve personally tried, found useful, and don’t think AI will meaningfully penetrate for a long time. This list is as much a note to myself as anything else. There are other ways to exercise creative muscle and your milage may vary.

Make lots of things, preferably with other people

Start with doing… and then repeat. The more you create things, the more you learn (consciously and subconsciously!) what appeals and what doesn’t.

And doing this with others is even better. Collaboration forces you to explain ideas, absorb different perspectives and move faster. Showing work to real people teaches you what resonates beyond your own personal taste.

Dreams

Yes. Dreams.

Dreaming is an incredible creative resource.

Easy = Keep a notepad by your bed, or duck into the bathroom and record a quick voice note when you wake from an interesting dream. Don’t overthink it. Go back to sleep. Revisit it in the morning and see where it leads. You’ll be surprised.

Harder = Combine note-taking with lucid dreaming. I’ve managed to train myself to do this. Being able to gently guide dreams into certain spaces has led me to some genuinely new threads of thought.

Studying great art and bad art

Go to galleries. Read great books. Listen to great records. Then deliberately compare them with bad examples in the same medium.

Make notes on what separates them. The more abstract the art form, the better. It forces you to analyse intent, not just technique.

Human communities

Find communities to learn from, especially ones that feel “other” to you. Observe what makes them interesting. Ask questions. Notice what doesn’t translate easily.

Giving yourself constraints on purpose

You’re probably used to constraints at work — budget, headcount, time, feasibility. But these are all put upon you by someone or something else.

When you give yourself a set of rules or ‘code’ to play by, this can be an awesome lever for pushing you to think of different solutions. Some of the best human endeavours ever created were not just because the author had external constraints but because they created their own constraints to work within.

In summary

My thesis looks like this:

1. AI is trained on data
2. That data must come from an available corpus
3. AI uses that data to pattern-match and generate outputs
4. Those outputs may be familiar or even novel to humans
5. Humans also generate outputs using subconscious processes we don’t fully understand
6. Those processes don’t enter available datasets
7. Which means there are things humans can do that AI won’t, until the subconscious becomes conscious

That window may close one day. For now, it’s where I’m finding my professional edge, and where I hope my kids learn to find theirs too.

For a while now I’ve been using LLMs to create little side projects just for me.

I love automation and making myself more productive with little tools, utilities and scripts. But I’m a lousy programmer, so vibe coding has given me a way to quickly build these things without caring about the quality or scalability I’d normally worry about at work. As long as the outcome is what I want, great. IDGAF how I got there.

However, this holiday season, I found myself vibe coding a project primarily for myself that I then thought, “hmm, other people might like to use this.”

But before flipping that GitHub repository setting from ‘Private’ to ‘Public’ I hesitated:

• “What if ‘real’ programmers look at the commit history and notice that it’s a mess?”.
• “What if ‘real’ programmers judge me for vibe coding a project without even really looking at the code?”
• “What if someone wants to use my project for something ‘proper’ and soon realise that it doesn’t scale because it was built so poorly”.

These are obviously dumb concerns, rooted in the deep imposter syndrome I’ve felt ever since working in tech:

• Commit history and Git hygiene don’t matter in this context — it wasn’t a collaborative project and no one is going to need to understand the history past ‘now it just exists’. If anything, having a messy, vibe-code driven history declares ‘it is what it is, take it or leave it’.
• If someone is inspired by the project or finds utility in it, but realises the code is crap, they can submit PRs to refactor it (or just recreate the idea entirely themselves).
• I should be so lucky that anyone cares enough to use my project, let alone peek at the code. Most open source projects get used by nobody but the creator.
• I’m a Product person by trade — you’d think by now I’d practice what I preach and focus myself more on the outcome than the implementation!

If you’re interested in hearing about the project, the TLDR is this:

As an ex-GitHubber, I’m all in on using GitHub as a knowledge store. But my problem with viewing markdown files on GitHub repo pages is that they have too much distracting UI “chrome” — viewing a markdown README file in a repo has lovely, well-styled and readable content, but all the other stuff gets in the way.

Yes, GitHub has a Wiki feature, but I never cared for the design and UX of that.

So I created a simple Jekyll theme that basically mimics a stripped-down GitHub markdown preview experience (clean content, simple navigation via a tree view, etc.) for any repo that contains README files. Any directory that contains a README becomes a nav item. Simple.

Anyway, here it is if you’re curious:

https://github.com/lukehefson/github-readme-theme

Product Managers at tech companies are like bass players in bands:

• It’s easy to pick up the basics and fake it.
• You can get by doing the minimum required.
• You’re not always necessary – others can do the basics.
• It’s deceptively hard to get good at it.
• Great ones are easy to spot and lift up everyone else.

My advice for any would-be PM or Bassist (and note, I have been both):

Either put your direct team first, be widely hated, or find a different job.

I personally like my job, enjoy being productive and don’t want to be hated.

So here’s my guide on how to be the most productive and respected PM you can be – by working with and for your Engineering team – not against them.

Don’t try to out-engineer the Engineers

This should go without saying, but apparently it doesn’t: your job isn’t to impress engineers with your technical depth. And even if you are technically strong, your job is to create space for engineers to own the How — your job is the Why.

The good news? Engineers want help defining the Whys.

This is because they hate building things that don’t matter. They want to know that what they’re working on is solving the right problems.

If you ask smart questions that drive at discovering the Whys – they won’t give a shit that you’re don’t understand some technicals details as well as they do. In fact, great Engineers understand that being able to focus on customers and business outcomes without getting sucked into implementation details is in itself a super power.

And for the love of all that is holy, please don’t pretend to understand technical things that you don’t. Engineers can smell that shit a mile off. Instead, lean into their strengths and ask the important questions about the constraints, risks, tradeoffs that you need to know to do your job.

If you need to ask questions that could risk derailing the conversation or cause a big distraction, look elsewhere first. Some great external resources that even the most engineering-hardened PMs will use are:

• AI chat for the questions you don’t really know how to ask. As it can infer from your (poorly written) prompt and point you in the right direction (although you’ll obviously need to double-check answers for hallucinations).
• Seek trusted technical mentors (outside of your org) for getting more opinionated and pointed answers. Strong opinions will give you richer context.

However, what’s the single worst thing you can do? Block your engineers. That is the number one PM sin. So if you’re blocking, you better have a damn good reason — and ideally, a way to mitigate or workaround it.

Your job exists to help engineers ship the right thing faster. Full stop.

Bureaucracy and politics: Use sparingly, do so transparently

Contrary to popular opinion in 2025 – bureaucracy isn’t inherently bad. The word means “desk for storing rules” — a system for organising knowledge. And engineers love systems.

But what they hate is process for the sake of process. Bureaucracy that exists to justify your job, rather than support theirs.

So if you introduce a framework, explain why. If you ask for a details on something, explain what it will unlock. Only build systems when there’s a genuine, pressing need.

Politics and navigating org dynamics are sometimes a PM necessity and one that a lot of Engineers would rather avoid as they can. So when you can – handle this distraction and be clear about it. Let them know what you’re doing and why.

But keep it classy. Don’t engage in politics for your own ego, or to jump over people. Otherwise trust will break down. Do it to genuinely help your team move forward. Their success is your success.

Build Trust (and then keep building It)

PMs are universally mistrusted — and honestly, it’s well-earned. A bad PM often does more damage than a bad engineer. They can block work, misalign teams, make poor hypotheses …and then somehow disappear when things go to shit.

Some PMs fall into the role not because they love building products, but because (like playing bass!) it’s easy to get started.

Many are attracted to product management because it looks like a position of power. Spoiler: it’s not. And that should be by design.

The best PMs I know:

• Are super transparent with their teams.
• Ask how they can actually help.
• Share context and decisions early and often.
• Don’t mandate anything they can’t clearly explain.
• Make data-informed bets (even when the “data” is intuition + experience — as long as you explain why).

If you’re not sure what to do: default to honesty. Make your work visible. Let engineers opt into it. Be the person they want in the room when hard calls get made. Don’t be the person they have to protect themselves from.

Know that high-level Engineering concerns are your concerns by respecting developer experience (DX), automation, and infrastructure. These aren’t “nice to haves” or backburner work to push aside. They are force multipliers for the whole team. If Engineers are excited about improving CI or automating tests — listen. Understand why that work matters. These kinds of investments make every project faster, safer, and more enjoyable to work on.

If you want engineers to care about the problems you’re solving, you should care about the problems they’re solving too.

Afterthought: AI should be making bad PMs nervous

AI isn’t going to replace all PMs — but it is going to replace the ones who add little value. Especially the ones who mostly pass tickets around or act like middle managers for engineering output. ‘AI’ in 2025 mostly refers to ‘Generative AI’. And you know what it’s really good at generating? Product specs, JIRA tickets and other artefacts that bad PMs have traditionally treated as their main currency for respect and promotion. Give. A. Fuck.

But great PMs? The ones who deeply understand the user and their problems. Or how a multitude of murky inputs combine into solid outcomes and strategies. Those PMs are still going to be valuable, at least for the foreseeable. Anyone can ask an LLM to write a product spec.

Not everyone can look at that spec and say: “this won’t solve the real problem.” Or: “this won’t land with our users.” Or: “this won’t align with that.” At its core, generative AI is a probabilistic machine that might be able to guess the output. But you still need someone who understands the outcomes.

In summary:

• Be a good PM(Bassist), keep your job(place in the band) and have an enormous sense of wellbeing.
• Be a bad PM(Bassist) and risk losing your job(place in the band) to ChatGPT(the Keyboardist).

Here’s the only post from the archive that I actually want to keep for posterity – because it was such a fun experiment at the time and nothing to do with Tech™!

I am was in this band called Cheat Sheet and it’s a pretty lofi affair.

I’m also a big Apple nerd/fanboy. So when we talked about doing some recordings I initially toyed with the idea of recording the whole thing myself on my Mac in Logic. But then I thought – you what? I don’t much like using Logic, it can be clunky and unintuative and as Apple move more and more away from their ‘Pro’ apps, Logic is starting to feel like a bit of a legacy. EDIT - Apple have since released Logic Pro X which is pretty sweet.

You know what I do love making music on? GarageBand iOS. And as Cheat Sheet don’t require anything like Rick Rubin style production, I thought it would be fun to take a shot at recording entirely on my iPhone!

Fiddling about with cables

The sound of drums

I only own one decent microphone: a Shure SM57. Luckily it’s super versatile and what’s more I found a bunch of info about how to get an okay drum sound with just two mics using a method called the Recorderman Technique.

Now I just needed another mic and a way to get both mixed down to one channel - as the iPhone can only record one channel at a time. I planned to do all the recording in a hired rehearsal space (so as not to piss off my neighbours), so I just borrowed a perfectly adequate SM58 microphone off them – the kind you find at most rehearsal spaces and gig venues. It’s not an expensive super-mic, but I suspected it would do the job.

To get both mics mixed into my iRig (an interface for getting audio into your iPhone/iPad) I had them both run though a cheap mixer and balanced them by ear down to a single channel. I knew this was a bit risky, as I wouldn’t be able to go back and make changes to the drum levels, but that’s what happens when you can only record one input at a time!

The tricky part turned out to be getting a decent playback for Matt – our drummer. I had planned to play my guitar through a distortion pedal and split the output out to two sets of headphones so that I could play along with him while we recorded the drum track. However, neither of us had noise cancelling headphones, so the live sound of the drums was too much. He ended up just playing the songs though by memory because he’s rad like that. In hindsight though, proper playback would be nice.

Just two mics into the mixer and then out one channel into the iPhone

Guitar shredding (or lack of)

As incredibly impressive as virtual amps on Logic/GarageBand are, I’ve never been fond of using them for anything other than quick demos. Nothing beats the sound of a nice, loud guitar amp.

So I used my SM57 again and placed it slightly to the side of the speaker-cone on my amp and ran it straight into the mixer - before going into the iRig - so that I could use the mixer to adjust the input level (making sure that it didn’t ‘peak’ red in GarageBand).

Mic placed on the guitar amp -> mixer -> iRig -> iPhone

Bass in da face

When it comes to recording bass, I’m not so down on virtual amps. As a bass has a much more simple signal than guitar, Cheat Sheet bassist Lara just played straight into the iRig and it still sounded cool.

Vox pop

Again, no need to amp anything up here or use the mixer - I just ran my trusty SM57 into the iRig and recorded as many vocal takes on different tracks as GarageBand would let me (considering the 8 track limit).

Using an effects pedal and non-noise-cancelling headphones for playback didn’t work out

Mix-master-me

1) Monitoring (without monitors)

Usually when people record and mix music they use sets of expensive monitors to playback each track and mix accordingly.

I don’t own such monitors. And call me a philistine, but I hardly ever listen to music on anything other than headphones. More specifically… iPod/iPhone headphones. So I thought fuck it, I might as well mix the songs to what 60% of people are going to be listening to it on.

However, I’ve acquired quite a few pairs of Apple headphones over the years, so I thought I might as well give a few different pairs a go.

THEN I HAD MY BIGGEST REVELATION SO FAR. Apparently, Apple headphones don’t all sound the same. Even pairs which were from the same generation device had big differences in sound quality. I couldn’t believe it. So in the end I decided to choose the pair that sounded the most like any of the others - ie. the most average sounding pair. I figured if my recordings sounded good on an average pair then that would cover as many bases as possible sound-wise.

Note: I’ve since compared all these headphones to a pair of brand new EarPods and to my delight they sound very similar to the pair which I picked.

iPod headphones through the ages… I ended up using my oldest pair of ‘third-generation’ earbuds (second from the right) as they had the most ‘average’ sound

2) Effects

I knew I would need to be a little ‘inventive’ when mixing and as I had planned for this to be quite a lofi-style recording, it gave me plenty of room for messing around with the distortions, overdrives and other effects available in GarageBand on the iPhone.

In regards to built-in effects in GarageBand, there are the ‘track’ effects (reverb and echo - found in settings), vocal effect presets and guitar amp effects.

I had originally intended to use amp effects on all tracks, including vocals and drums - as there is a much greater choice of effects and more granular controls. However, I found it really hard to balance the ‘amp sound’ with the effect I wanted. So I ended up only using a virtual amp for the bass.

The vocal effects seemed a better choice but, depending on the given preset, you can only change a couple of sliders for each effect. I got around this by duplicating a track and then applying different presets to different versions of the same track. I would then merge these different versions down to one track for each instrument/vocal line. Hey presto! – multieffects!

Vocal effects in GarageBand iOS - I used the ‘Bullhorn’ preset to add overdrive (and note: very little distortion) to vocals and drums

An additional upside of merging tracks together was that GarageBand automatically ‘normalises’ merged tracks. Normalising means that the peaks in a sound wave are brought to normal levels - not ideal for retaining audio fidelity but perfect for getting balanced levels.

I ended up applying merged vocal effects to both the drum and vocal tracks. The guitar I actually ended up leaving dry because I liked it the way it was. All I did was pan it to one side slightly to make it sound a little more ‘live’.

The downside to tweaking, duplicating and merging tracks for mixing was that I ended up needing to remember lots of settings for lots of tracks and apply roughly the same processes to all of the songs that we had recorded. And even worse, as I wanted to be able to go back and tweak things before they were merged it meant keeping lots of versions of each track - it was a version control nightmare.

Note the ‘Merged tracks…’ version numbers on these tracks. I’ve combined some ‘Bullhorn’ overdrive with the compressor and a little reverb from the ‘Large Room’ presets to my vocals. You can also see the bass with amp-effects

None-the-less I was really happy with the end result of my mixed down songs. If you want to check out one of the songs in its original GarageBand format to see how I did it - you can download it here.

A caveat

As much as I loved the fruits of my iPhone-only labour, I soon realised that there was something that GarageBand can’t do and this includes GarageBand on the Mac. In GarageBand there is no mastering.

Mastering can be contentious and complicated thing. But broadly speaking the end goal (as far as I’m concerned) is to take the mix as a whole and place it at a natural volume without excessively increasing or decreasing the volume of individual instruments. Mastered songs just seem to have a ‘pop’ to them that unmastered ones don’t.

So I’ll admit… I cheated slightly - in that the songs we’ve released still have some outside help. But again, it’s a testament to how awesome GarageBand on the iPhone is, that all I needed to do, was to was copy each song to iTunes – open them in GarageBand on the Mac and use a mastering plugin preset to take our songs from completely iPhone recorded and mixed to something I’m happy to play to strangers.