Tom Critchlow makes a distinction between fast and slow consulting. Fast consulting goes with the grain — you clarify what already exists, you execute, you deliver. Slow consulting goes against the grain. You try to change how people think. And you don’t do that with a project. You do it with a campaign.

Projects have an end date. You deliver something, everyone shakes hands, and three months later the organisation is doing exactly what it did before. One presentation doesn’t undo years of bad process. A new system won’t be used if nobody changes their behaviour.

A campaign works differently. It’s the same message, again and again, from different angles, over a longer period. Not because people are stupid, but because beliefs shift slowly.

There are a few ways to do this. A weekly message works well — a short email or Slack post with an observation, a data point, a relevant article. Not to persuade, but to stay present. By week eight people expect it. By week twelve it influences how they think.

You can also bring the outside in. Critchlow calls it “bring the outside in.” Customer conversations, user research, reactions on Reddit or forums — it is easier to change someone’s mental model by showing it than by telling it.

Language helps too. If you consistently use the same words for what needs to change, others start using those words. That sounds subtle, but language shapes culture. After twelve weeks you hear your own phrases in meetings you weren’t part of.

And then there is something Critchlow emphasises: internal blogging. Not a manifesto or a big report, but short, shareable pieces. Published over time. The point is not that every piece is brilliant, but that it creates a constant drip of ideas. And it needs to be shareable — not buried in an email thread or lost in Slack, but in a place with a permanent URL people can forward.

The tricky part is that this is harder to sell than a project. A project has a scope, a timeline, a deliverable. A campaign does not. But quick fixes don’t stick. If you leave and everything reverts to the old way, you changed nothing. Changing how people think is the only change that lasts.

Collison’s advice runs counter to standard career wisdom.

Go deep on multiple things early. The question “specialist or generalist?” is framed wrong. Do both. Become very good at two or three things rather than okay at ten. Early expertise compounds. The options it creates can’t be built later.

Status lags reality. The safe career paths of today are based on the world of yesterday. Banking, then consulting, then big tech. Every generation thinks their safe choice will last forever. That is rarely true.

Build networks online. The best opportunities come through people you meet digitally, not through local coffee meetings. Remote work has changed the geography of opportunity. Don’t limit yourself to your city.

Avoid rail-track thinking. Degree, master’s, corporate, promotion. It feels safe because everyone does it. But that is exactly why it’s risky — you’re competing with everyone on the same track.

The interesting opportunities are on paths fewer people walk.

Slootman runs companies differently. No consensus culture, no endless meetings, no keeping everyone happy. Focus and execution.

The sharpest point is about behaviour versus performance. Performance is something you give time to — someone can grow into their role. Behaviour is a choice. If someone behaves badly, that is not a development point. It is a decision they are making.

The same goes for prioritisation. Not choosing is the worst thing you can do. Then you compromise everything. Doing everything a little means doing nothing well.

His view on ambition is also interesting. It stems from a lack of adaptation. A perfectly balanced person would have no ambition — why would they? They are content. But people with ambition have a gap between where they are and where they want to be. That gap drives them.

And on hiring: hire slower but better. The cost of a wrong hire is enormous. Not just in money, but in time, energy, and team dynamics. Waiting for the right person is almost always better than quickly hiring the wrong one.

Many people speculate about AI replacing coding. Fewer talk about what it actually looks like today. This piece describes what’s happening at a 12-year-old SaaS with around 40 developers using Cursor and Claude Code.

Productivity is up, maybe 20 percent, but unevenly distributed. Agents are great for refactors, chores, and unblocking ideas. They are weaker at subtle bug fixes and don’t write beautiful code.

The biggest gain is not in speed but in ambition. Solo developers are now shipping projects that used to require a team. And the costs are modest — the heaviest Claude users spend barely fifty dollars a month.

The hard part of programming stays the same: deciding what the software should do. Translating ideas into syntax just keeps getting faster.

You have coordinates: 52.3676, 4.9041. You want an address: Amsterdam, Netherlands. Simple, right?

Not really. Which address? The nearest building? The street? The neighbourhood? The city? The country? It depends on what your user needs, and that differs by context.

Trickier still: boundaries are fuzzy. Are you in Amsterdam or in Amstelveen? The municipal boundary sometimes runs through a car park. Postcodes don’t always map neatly to neighbourhoods. Some addresses don’t officially exist but are still used.

The technical challenge is not the algorithm. It’s deciding what “correct” means for your use case. And that is a product decision, not an engineering decision.

A nice reminder that seemingly simple features often hide political and UX questions nobody thought through in advance.

Horowitz wrote this in 1996. It is still relevant.

The distinction is simple. A good product manager behaves like the CEO of the product. Not in the sense of authority, but in the sense of ownership. Everything that goes wrong is their problem. Everything that goes well is the team’s.

A bad product manager has excuses. Engineering didn’t deliver. Sales promised things that couldn’t be done. Marketing didn’t understand the positioning. Always someone else.

The strongest point: good product managers focus on business outcomes, not technical specs or feature checklists. A product with great features that nobody buys is a failed product. The question is not “does it work?” but “does it solve the problem we built it for?”

OpenAI’s guide cuts through the hype. Agents are not magic. They are loops that call tools until a task is complete.

The core: give a model access to tools, let it decide which tool to use, execute the tool, return the result to the model, repeat until done. That is an agent.

Where it gets interesting is orchestration. When do you give the agent freedom and when do you enforce structure? Too much freedom and the model hallucinates paths that lead nowhere. Too much structure and you might as well have written a script.

The practical lesson: start small. One tool, one task, clear boundaries. Add complexity once you understand where things go wrong. Most agent projects fail not from too few capabilities, but from too many.