Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from 42!
In our early days of my startup, I would try to enter as many pitch competitions as was feasible, just to try and get our project in front of as many eyes as possible and get our names mentioned in the popular startup press. I used to give everything in these competitions, and we were finalists in several, including the prestigious Australia Post Pitchfest even in 2017. These competitions were crucial in getting us to hone our messaging, and to highlight what we needed to focus on. We learned a lot during this process. But we never won one. In fact, here is the results summary we got from one local pitch competition we entered: As you can see, we scored a woeful 60% overall. We failed in 3 of the judge’s criterion. One of the key judges was highly critical of my HR platform startup during the on site judging, and this email further sunk the boot in. But I saved this email. Because it only served to spur me on and to prove them (him) wrong! Today, we have achieved 7 figures in ARR, and most of the winners in the pitch events I entered are no longer around. Persistence and belief in yourself matters…
Our very earliest marketing copy for our HR SaaS was “Replace your spreadsheet nightmare with a nice clean HR database…” We thought it was a cute and quirky tagline, and that it would immediately relatable to our target audience of business and human resource managers. After all - who love working on large spreadsheets with thousands of rows, tabs and formulas? Well, as it turns out - LOTS of people still do love working in spreadsheets! Who knew. When we looked at how our early customers were using HR Partner, many of them came from large complex spreadsheets, for sure. However, one of our most requests features early on was: “Can we please export all this information into Excel so we can do more complex reporting?”. You see, in our hubris, we had assumed that our customers would eschew their ‘old fashioned’ spreadsheets in preference for a slick, well designed app. But we were wrong. The biggest problem with spreadsheets is that they don’t enforce a strict formatting or control over the data being input. Things like ensuring mandatory information was entered, or the exact layout of that data, is by the very nature of spreadsheets, inherently difficult. A database (like ours) on the other hand, is very good at regimenting the data being entered and ensuring that everything is collected in the right order, however it is very bad at outputting that same data in a flexible manner - something that spreadsheets are remarkably good at. All our customers were looking for was for a system that would curate and ensure clean data was entered. Then they wanted to get at that data and slice and dice it up in all sorts of ways to meet their reporting requirements, with the complete confidence that the initial information was all clean and reliable. So we had to reframe our marketing to make our app seem more of a complement to their existing spreadsheets, rather than seeking to replace them altogether. We expanded upon this by also releasing our open API that allows our customers to access their data in all sorts of other platforms like Zapier and Merge.dev to generate the reporting they need.
A recent conversation on Twitter with a colleague has reminded of this dilemma that we faced in our early days of launching my SaaS. You see, In 25 years of consulting to small businesses, I had learned that business owners and managers were faced with the challenge of recording and maintaining a LOT of information about their staff. Things would often get forgotten or lost, being recorded on multiple spreadsheets, word documents and paper notes all over the place. I thought that if we could build a system to aggregate all that data in the one place, then we would be solving a real issue. As a bonus, we would add reminders into our system so that important renewals and anniversaries would not be forgotten. Well, that is exactly what we built with version 1 of HR Partner. It was essentially a huge database that would contain all ancillary data related to your employees, such as training they had done, their past education history, a history of their absences from work, contracts and documents relating to them, and much more. As we didn’t get any eager customers. At all. You see, we weren’t really solving any issue. Our customers would be recording just as much data as they would have been doing before in Excel, or a notepad, or on a whiteboard, except now we were just asking them to do it in a system that was unfamiliar to them. No wonder we didn’t have any takers. We weren’t providing a huge amount of value to them for all this work (sometimes a little extra work) that they would have to do to store all that data in our app. Sure we had automated reminders, but this wasn’t compelling enough for them to make the switch and pay for our service. It wasn’t until we added the ability for their employees to submit leave requests for approval by upper management. NOW we were on to something. The managers didn’t have to do as much work, as that was now delegated to their employees. It was up to the employees to submit a leave request with their leave type they wanted, their start/end dates etc. and then all the manager had to do was to literally click one button and the process was completed. Any approved leave would be automatically added to the company calendar so that everyone had a ‘helicopter view’ of who would be away and when. This was the turning point where we started to see traction in the market. Just by focusing on one niche area that actually cut down on work that the business stakeholders had to do. Also, we were repurposing all that collected data to give different perspectives on team movement and activity. Finally, our customers were seeing real value in our system. Incidentally, we have since added many more features in our HR app, but the leave requests module is still our most popular and widely used feature - 7 years later!
So, last week I got removed from one of my company’s Slack channels… and it was probably the best thing that could have happened for me, and my company. You see, like most companies, we have ‘global’ chat channels that everyone participates in, plus each team has distinct channels usually for just those team members to discuss operational matters. Some of our company Slack channels Our Customer Success team has their own #customer-success channel where we would all discuss customer related issues such as onboarding new signups, and how to solve certain issues on the customer’s behalf. As the original founder of the company, I naturally included myself in ALL our company Slack channels, because, well, I thought that is what founders had to do in order to help the team and keep a finger on the pulse of how the company was going. But instead, that proved to be NOT a good thing. You see, I was pulled in so many different directions, and involved in so many side conversations that I couldn’t actually get my work done, which was to manage our growing development team, and set long term goals for our product. Also, team members were getting too used to bringing problems to me directly via those channels, which meant I was the one solving a majority of them, or having to de-escalate situations depending on how important they were. This wasn’t helping our team to grow and trust themselves to make good decisions. So my co-founder and I decided that it would be best for me to step out of the #customer-success channel. Not just mute the channel, but be removed entirely so that I am not even tempted to ‘check in’ on conversations happening there (as you can see from my screenshot here, that I can’t even see that channel any more). It has been just over a week, and I can already see the difference. Sure there was a period of FOMO where I felt anxious that I was missing out, but based on feedback from other team members, conversations between my customer success team have increased in that channel, with a lot of questions going back and forth between each other, and ideas been thrown about with gusto and everyone is chipping in more to help each other out. From my perspective, I have been able to focus back on pure product and leading my engineering team, and I have felt much more in control, and focused since doing so. Don’t get me wrong - very difficult customer scenarios are still escalated to me (via other channels), but by the time that it is escalated, I know that the team has already explored all the alternatives, and it is only coming to me because it is either a bug or problem within the app itself that I need to be involved in. A wise mentor once told me that the hardest thing for a founder to do is to make themselves obsolete in their own business, but I realise now that for a growing business, it is a necessary thing to do - and that is is major factor in building a business that can scale without you having to be involved in every minutiae, but rather be able to work on the bigger vision. It is early days, but I think the experiment is working. Now to work on my goal of slowly get myself booted out of some of our other team channels this year. ;)
More in startups
The explanation is so simple that it’s almost funny.
One problem with AI is that it’s pretty stupid. I mean, sure, the current models are wildly useful. But out of the box, they overcomplicate, take undue shortcuts, and compound deficiencies to the moon. To get from default Claude or ChatGPT to a fast, affordable software loop – one that reliably zaps bugs, backlog items, and security vulnerabilities in your product in particular – it takes some real work. Increasingly, this is the work. So it’s past time you shared that work with your team. Guidelines and guardrails There are two main ways to get coding agents to behave consistently and correctly: steer them with guidelines, and redirect them with guardrails. Basically a union of “Please go do the good thing” with Error: You did the bad thing, try again. Sometimes, this means fighting models’ non-determinism with better non-determinism. We build and refine Markdown instructions: rules, docs, skills, and the like. Then at PR time, AI reviewers, classifiers, and human review workflows can non-deterministically ask Claude to go back and do better. But while this informed guidance is helpful, deterministic rules are gold. Instead of “PLEASE don’t make 10,000 line files”, a lint script can simply reject overlong files before they’re pushed1. When practical, moving Markdown rules, checks, and guides into deterministic code like this is a big level up. Checks in code are harder, better, faster, and stronger than prompting – and a hell of a lot cheaper. Similarly, if you set up a local environment so models can verify how their code works in practice, you’ll get less speculation and fewer unnecessary fallbacks. Step by step, you can tune your laptop into an instrument for turning brilliant slash idiotic tokens into good PRs. Before long, you’re building at a pace never before seen, with architectural consistency no less. Your team is in awe of your productivity, and… wait. Your team. Some of them need to understand your work too. And you still need to review their agents’ work– OH GOD WHAT IS THIS PR?! Sharing is caring The history of software development is the story of sharing. At first we shared just code, once its author was done with it. Then we grew into sharing commit history, say with SVN. We’ve seen with everything from Makefiles to Jira, Slack, GitHub Actions, Terraform, and more recently code formatters and linters, that engineering improves with more sharing within teams. But when coding agents debuted, it made little sense to standardize how they were prompted. Hell, they barely worked in the first place. Nobody had any idea what it meant to use them well, and they lent themselves to experimentation and highly custom setups. But 2024 was a long time ago. We’ve learned a lot about good agent guidance and guardrails, and models have gotten far better at working within them. Yet many teams still work in repos with no shared agent instructions at all. These teams still use AI. But they rely mostly on models’ instincts, developers’ prompting skills, and reviewers’ discipline to keep agents in check. More industrious team members might email around skills they find helpful. Using their personal setups, a few folks on these teams elicit well-engineered PRs from Claude – but these get jammed up alongside other developers’ mystery slop in the review queue. Fortunately, this is beginning to change. In-repo AGENTS.md files are now common. Reproducible dev environments, consistent for every team member, are including more lints, sandboxes, MCPs, and other tools that make agent output more consistent. CI, previously the realm of unit tests, often now runs review agents – preferably steered by in-repo instructions. And teams are putting checks, constraints, and formatting rules on PRs, making them easier to review and trust. As Thoughtworks’ Rahul Garg said on martinfowler.com: A prompt on an individual machine is a personal productivity hack. The same prompt in the team’s repository is infrastructure. So from this, we now have two primary goals: work to make our agent instructions more deterministic, and more useful for the whole team. Before the work: Setup and guidelines After the work: guardrails Deterministic, shared 😀 Reproducible dev environments and sandboxes, verifiable structures (types, schemas, boundaries), shared tools and hooks Typechecks, lints, tests, builds, CI, blocking hooks, ratchets Nondeterministic, shared 🙂 AGENTS.md, in-repo docs, shared skills, existing coding patterns, guidance returned from shared tools, shared agent sessions PR review agents, shared classifiers, human reviews Deterministic, personal 🙂 Personal tools and MCP servers, local permission setups, local env config Personal lints and hooks, local pre-commit Nondeterministic, personal 🫠 Your prompt, local memories, personal skills, CLAUDE.local.md, a bespoke dev environment only on your laptop Yelling at Claude for being a complete doofus The job, increasingly, is not producing code. It’s iterating a system – guidelines, guardrails, and tools – that helps your whole team produce good work. And as more teams run coding agents in the cloud, spun out of Slack conversations, Linear tickets, or incident reports, ensuring your agents do the right thing regardless of where they run is even more essential. While a tuned software factory like this is a boon to generalists working in it, working on the system is where domain experts – perf wizards, database pros, and so on – can really shine. Instead of just running interference, trying to review and reject problematic PRs in their domain of expertise, they can iterate docs and guardrails that improve how every change, whether kicked off by a PM or a principal engineer, is written. PJ Onori, a design systems veteran at Sanity, responded to an increase in agent-authored code that didn’t comply with their design system not with derision, but with a spec. Basically, in-repo rules turn expertise into leverage. Note: The shared rules need to actually be good In 2024, models’ worst failures were not following instructions. In 2026, we also get agents failing because they do follow instructions, even overly absolute ones. Many a CLAUDE.md (or, now, AGENTS.md) has collected slop like: IMPORTANT: Every fix must start not with code, but with failing tests. Make the fix, then honestly verify it against the new tests. This is not busywork—it’s discipline. 1000 PRs merged later, agents have gifted you 9999 new unit tests, many of them useless, like a cat delivering its owner dead birds. “Oh great, thanks Codex, tests that enshrine every copy edit we’ve ever made to the UI, how thoughtful of you.” Let this herd of tests run on hundreds of pushes to GitHub every day, and in time your CI bill will gain an entire digit. While having at least some agent docs and guidelines in-repo has become standard, there is wild variation in how well-maintained these instructions are. Often they get so long, agent harnesses truncate them. Multiple teams I’ve helped have said they still required humans to read and review code changes, but not AGENTS.md instructions. That is, the root set of rules followed by every agent working in their codebase.2 Now, you definitely want to add in-repo guidance and guardrails for your team’s agents, but with great leverage comes great responsibility. If your one doc or tool can now affect thousands of nondeterministic coding runs across a team, it’s worth the effort to iterate and improve it over time. At the minimum, this means building a culture of standards for this shared infrastructure, and people who own its effectiveness. How do we actually do that? Closing the loop While surely you tested your AGENTS.md overhaul personally, how is it working for everyone else? You see that your agents aren’t adding overlong comment blocks anymore, but this new PR from Steve did. Had he pulled your new instructions before he wrote this? And come to think of it, is your new guideline now causing places where explanation really would have been merited to be under-commented? Of course, to maintain code well that runs on various other machines requires a measure of observability – doubly so when the flows are non-deterministic. What skills are people using? Are they working as intended? Are agents spinning needlessly on missing context or verification capabilities? Are they now yelling at Claude when it was actually your doc or skill that caused the problem? You need to be able to fix mistakes and waste. Not just on your laptop, but across your team’s agents. On some teams, this just means having developers send bug reports and traces to team members when a skill or doc goes wrong – if they notice it and know who can fix it. Other teams move to a coding environment like Amp that shares session transcripts and their telemetry by default, or our Powerplant tool that supports session debugging in a harness-agnostic way. Meanwhile, Entire wants to be GitHub but for agents’ session logs as well as code. Session sharing comes with its own challenges. As with observability tools like Honeycomb and Datadog, giving your coding agents access to log and telemetry data from other agents is both very useful and potentially risky. Shared context needs thoughtful security, privacy, and accountability controls. Meanwhile, social conventions on teams around working with agents in the open are still developing. Some companies are overtly skeptical of transparency with agents, while others are all-in. No matter how this all plays out, one thing is clear: the early scramble of siloed experimentation is ending. It’s time for teams to be building shared agent infrastructure, guidelines, and guardrails, and to be iterating them together. To be learning not just from some confident poster on X, but from how one another are working with AI. And to help us all do less yelling at Claude, and more building useful software. While simply failing lints for a file that exceeds limits is helpful, we can do better. If your lints emit graduated feedback, e.g. flagging when a file is close to, at, or beyond the threshold, then you can give models useful feedback without halting a critical change because a file got pushed one line too long. Another useful graduated approach is the ratchet: if you find a bad pattern in your code you don’t want agents copying, a ratchet counts how many instances of the pattern currently exist, and only fails if that number goes up. A helpful tool for longer-term migration projects. Also worth noting: deterministic checks can give agents just-in-time remediation guidance. It’s better to put “New endpoints should use the typed Result pattern instead” in the lint error when somebody copies the old pattern, rather than in global AGENTS.md clogging every session’s context. ↩ /claude-api prompt-audit may be helpful if you need to dig out of this hole. ↩
Look Mom I’m famous on French Linkedin
The company has not yet achieved the success of your logo for it, but we are still trying.
