My 22 Rules to Build Faster in a Post-AI World
Everything I've learned about shipping products faster.
If speed is the moat, it doesn't mean that the conversation about moats & strategy is over. It means that it has shifted to a different question: how to achieve more speed.
While AI has reduced the demand for replaceable knowledge work, the new paradigm has an insatiable appetite for A-level talent that can move companies forward faster and learn by doing.
An “acquihire” used to be a low-status exit and suggested that the Founders got a bad deal to help land permanent jobs for their people. In AI it now means the opposite: a high-value exit for the Founders and uncertainty for the team.
The OpenAI/Meta/Google talent wars are indicative of the demand for technical talent that help companies navigate these emergent idea mazes.
There is clearly some “strategy” here in making targeted offers with large bonuses to senior technical staff or just communicating the vision of the company in a compelling way and talent strategy would be a fun topic for a future issue, especially if we see similar trends developing in crypto (we don't yet).
Instead, I wanted to touch on some tactics that everyone can apply without needing to make a $100M offer.
My curiosity for how to write software fast started in high school where I was doing 75-minute programming competitions. Then as an IC in consulting, I wanted to get home at a decent hour. Later, as a Product Manager I helped engineers get more done without burning out.
On balance, I'm far less productive than people who are “all-in” on work. Instead, I use productivity to allow me to be a dad, get a healthy amount of sleep, etc.
Here's some stuff that has worked well for me to build faster without burning out.
INDIVIDUAL TIPS
1. Use Apple Notes. Trust me, don't overthink it. If you need a “methodology” to structure your Apple Notes, do this.
2. Spend your tokens. In Magic: the Gathering we have a saying “spend your mana”. The same applies for LLM systems. Even if you don't have a budget, at least spend your free credits (e.g., Perplexity).
The point of this is not necessarily that you are well positioned to take advantage of this compute immediately. The point is that spending your tokens forces you to figure out ways to automate more value.
I don't care if you use your research credits for strategy research or finding your next t-shirt (I did the latter). Same with coding credits, just figure out ways you can spend them.
It's dangerous to have no ideas in this world.
3. Declutter. Cut as much stuff out of your visual periphery as possible. More importantly, no notifications on your computer and iPad. Aggressively minimize notifications on your phone.
4. Focus. Prefer to work on 1 big thing a day or reserve a 4 hour focus block. Try to close out the task for the day. Batch low-impact but distracting things like meetings, checking email, etc. in your calendar.
5. Use parallel processing. Think carefully about dependencies and make sure you trigger things that can work in parallel. These can be requests you need help with, long-standing AI jobs and more. My first question when starting research is what Deep Research queries I need to run.
6. Always queue content. Don't let algorithmic platforms decide what you consume. Separate curation from consumption by using queues. I use Instapaper for articles and YouTube “Watch Later”. Prioritize long-form content that helps you achieve a current objective.
COMPANY CULTURE
7. Use Linear. Ideally you don't need a project management tool. But if you do, use Linear because it’s opinionated and helps you ship on time (which is 2x faster than you otherwise would).
Here’s a project the Auditless team is working on right now. Can you imagine a better way of tracking progress?
8. Hire people who don't want to waste their life. Culture is infectious. Hire people who love making progress, learning and getting better.
9. No politics. Avoid politics at all cost. Examples: “X doesn't like working on Y”, “we should consider implications for this other department”, “X doesn't get along with Y”, “we can't share stuff like this”.
Politics is an expression of incentive misalignment between an individual and the team (company). If the incentives are misaligned, time will be wasted pursuing the wrong objective.
10. Clear priorities. This seems obvious but is really hard to do. Priorities should be clear and agreed on by each team. They should materially move the company closer to its objectives.
11. Clear ownership. No one does it better than Peter Thiel:
12. Demo culture. If demos are encouraged over ideas, it’s much more likely things get done. And a demo eliminates a lot of unnecessary planning/design work by presenting a working concept. So more things get done and they get done faster.
TEAM GUIDELINES
13. Clear communication. Obviously people should communicate clearly. The other part of this is knowing what the topic of the conversation is. Especially in meetings, I've seen too many meetings drop off into irrelevant topics.
14. Small tasks. Split the same task in two smaller tasks and the whole gets done faster. I'm not sure whether it's the extra dopamine, smaller context load or that there is some intellectual activation energy required in task decomposition. But either way this is major and often overlooked way engineering managers or product managers can contribute to velocity.
15. Small backlogs. Big backlogs are demotivating and won't get done anyways. Bugs should be fixed quickly before they accumulate into a backlog. Future ideas shouldn't be put in a backlog by default but only when prioritized for implementation.
16. Limit regular meetings. There is no better way to break 7 people’s focus by asking them to jump into a 5-min standup meeting. Same goes with unnecessary planning meetings. It’s much more efficient for individuals to use one-off meetings for quick alignment or unblocking. Regular meetings also tend to delay important work “until the next meeting”.
17. Clear definition of done. Managers can be lazy with details leading engineers to start work without clear requirements. The risk is that work moves a lot slower and extra scope gets introduced. This doesn't mean that work has to be perfectly scoped, just that goals and non-goals should be clearly established.
18. No technical discovery. The most valuable thing engineers can help with is not necessarily the coding but technical discovery. Engineers should be finding shortcuts to get work done with existing libraries or third-party tools. In most teams it’s the opposite, PMs fight to cut scope and engineers end up over-engineering systems.
19. Think short term. The long-term doesn't exist anymore. Focus on the fastest path to revenue and the benefit is the learning, not the asset you produce.
20. Cadence determines productivity. The 6-hour days thing has become a bit of a meme but I think it's true on a larger scale.
Obviously you can't pack more hours in a day than other people. The point is the urgency at which you address outstanding tasks.
Do you get everything done in a day? In a week or in a month?
Operating on an ambition to close out loose ends daily can be stressful and I'm personally not able to do that but I try to operate on a weekly schedule.
This is even more important for teams. A common problem is using qualitative goals for quarterly planning so work ends up pinned against a quarterly rotation.
21. Automation. The best tasks to use automation for are regular tasks that may require a small time investment but have a high price of context-switching. I suspect AI tools will get a lot better at supporting these types of tasks in the next two years. Continuous delivery is a great example for teams where it changes the psychological impact of delivering code not just saves time.
22. Measure things. My favorite part in Lambda’s engineering philosophy:
Measuring also helps with identifying priorities, helps create a short-term focus, provides a clear definition of done, etc.
These are just some of the simpler principles which can be applied without any tradeoffs.
What has helped you move faster?