Simple sabotage for software

You were employed as a CTO behind the front lines and you wanted to destroy productivity without getting caught

Hello! 👋

Thank you for your support and kind words in 2023. I hope you learnt something new and you’ll stick around in the next year. This is the last issue before Christmas. Let’s dig in. 🎅🏻🎄

Simple sabotage for software
6 minutes by Erik Bernhardsson

Let's say you were employed as a CTO behind the front lines and you wanted to destroy productivity for as long as you can without getting caught. You can of course make a series of obviously bad decisions, but you'd get fired quickly. The real goal here is to sap the company of its productivity slowly, while maintaining a façade of plausibility and normalcy. What are some things you can do?

If you've tried to build automated test coverage in-house, you know it takes years to scale. Try QA Wolf instead - they get web apps to 80% test coverage in just 4 months. They will create and maintain your test suite in open-source Playwright (no vendor lock-in, you own the code), and provide unlimited parallel test runs on their infrastructure. Schedule a demo to learn more.

Who Should Rule the Product?
7 minutes by Itamar Gilad

Who should decide which products and features to launch? The answer is neither managers, nor business stakeholder, nor PMs.

How to ship fast
4 minutes by Ben McRedmond

My principles for shipping fast and protecting momentum developed over ~12 years of building software.

Handling process debt
14 minutes by Vadim Kravcenko

Process debt is the accumulation of inefficient, outdated, or redundant processes within an organization. It manifests as cumbersome workflows, leading to increased developer frustration and the feeling of “this seems wrong” when you look at how things are done. Similar to technical debt, this kind of debt subtly erodes the operational efficiency of a company, often going unnoticed until it significantly hampers progress.

Speed determines victory for technology companies. Since the internet was invented, the fast have killed the slow. And out of all the ways that speed matters, product velocity – the pace at which you evolve your product – matters most of all. This post contains my go-to steps for debugging slow product velocity, particularly in SaaS.

how did you like this issue?

Login or Subscribe to participate in polls.


Would you like to become a sponsor and advertise in one of the issues? Check out our media kit and get in touch.