Beyond Work has been an experiment from day one. We chose to treat our entire organization, go-to-market strategy, and product development the same way a startup would search for product-market fit. In fact, we considered all these components part of our “product.” Now, one year later, it seems worthwhile to look back and evaluate how these experiments have been going. We started by tossing out all the usual playbooks and paradigms. Our assumption was that, with zero interest rates gone and a post-AI world upon us, most conventional wisdom about building a startup no longer applied.

In tech and software development, the concept of “technical debt” is (most often) well-respected. However, another challenge has become more important than ever: “legacy debt.” Where technical debt is the debt you accumulate through specific software development decisions, legacy debt is the broader concept of costs and risks that come with keeping outdated systems running. Many outdated computer systems, ancient programming languages, and legacy software still form the backbone of critical industries like finance, healthcare, and government. This was underlined by the recent CrowdStrike scandal in July 2024. A faulty update to their Falcon Sensor security software caused about 8.5 million Windows devices to crash with the blue screen of death. This revealed that many companies had system-critical infrastructure running on Windows, where most developers would heavily recommend Linux-based operating systems. This quickly established a lot of legacy debt, leaving companies out of business for days.

Beyond Work started with a very simple, but ambitious question. Could you run a Fortune 500 company with 150 people using AI and technology? Business today is bloated and inefficient, locking up human potential to innovate and create meaningful impact. This is largely due to how companies are organised and the software they use. For 50 years, Enterprise software has remained unchanged despite the transition from mainframe to desktop to browser. It is static, expensive and hard to learn. As a consequence, most of it is a tax and friction on doing business, not an enabler of better business.

Being a senior software engineer comes with many challenges, but one of the main ones is probably the conflict between spending energy on high level discussions and hands-on engineering. I already touched on some of this in the Life as a Senior Engineer post, but I thought it might warrant a bit more discussion, something I hope is useful both for senior and junior engineers. Small note: there’s a lot of sausage in this post. I don’t hate sausages, I like them a lot, and if you work at an actual sausage factory: sorry, I mean no disrespect. First let’s cover the sausage factory. My view on software engineering, and life in general, is that it’s mostly a mess. You try to package as much of it as you can in something that looks nice, but when you poke it a bit it turns out that it’s not all pretty - which leads to the sausage factory.

Uber’s success is often considered a given now and a master class on building the world's most successful startup. People often only point to the technology as the thing that made Uber successful. While no doubt the idea and technology were pivotal, Uber was not alone in the “push button, get ride” space. What Uber also had going for it was good timing and a world-class ground game. Of course, in the same breath people talk about the heavily subsidized rides, the toxic “brogrammer” culture, questionable ethics, the ousting of a maverick CEO, and so on. But that also misses the point.

Why did Blackberry’s market share go to zero? They went from perfect product-market fit to zero market share in less than a decade. What can we learn from this as AI transforms technology now? Blackberry was a product of its time, specifically the economic constraints of the infrastructure, technology, and consumer demand. These constraints created Blackberry's success - and later doomed it. Blackberry became a success because they found a way to circumvent the limited bandwidth of mobile networks. Inventing a server-client architecture instead of a single channel per user disrupted the economic model with unlimited messaging vs. pay-per-message texts. This empowered and freed business users to work from anywhere.

As the first transformer-based AI models started scaling, I remember moving from those awkward chatbots that kept forgetting what you just asked, to the jaw-dropping moment of talking to ChatGPT4 and wondering if the singularity was just around the corner. I realized that AI-driven enterprise automation would radically alter how companies work - not because AI is about to pass all existing and future versions of the Turing test as doomers claim, but because most enterprise work is neither that complex nor important. It made me think about what kind of company you could create if generative AI became your foundation. Most businesses grow large because they have to, with huge teams dedicated to accounting, admin, finance, customer service, and so on. If you scale your customer base linearly, you usually end up scaling your employee count cubed - right until you reach that ~5% profit margin typical of many Fortune 500s. Even tech companies are massive now. They haven’t escaped the gravity of traditional scaling laws when serving consumers or businesses at scale.

I recently met up with a couple of fellow engineers, and in passing I mentioned that I always tried to do some amount of coding every day, even when I was a distinguished engineer at Uber. For some reason it came as quite a surprise that I was “allowed” to code at that level. Thinking more about it, it probably shouldn’t be a surprise. As a senior engineer you’re constantly pulled into design discussions, reviews, planning meetings, interviews, status meetings, and much more. And there’s just no way there’s time for all of it, so you end up having to say no to a lot of people. Saying no can always be hard, but I personally have always prioritized being close to the actual code. That is probably harder than it sounds, and people often ask me how I have planned my career to get to where I am, so I thought I’d give my take.

What is a user interface? It’s a way to translate our intent into action. The first tools were as simple as stones used to smash nuts so we could get the nutrients inside, but developed into sticks and axes and so on. The better the tool, the better its design to make us more efficient and translate intent into action. With computers, the stone-to-stick evolution came from Douglas Engelbart and the mouse, heralding the graphical user interface so famously borrowed by both Steve Jobs and Bill Gates. Bytes became commands, commands became clickable pixels, and the personal computer revolution was born.

Salesforce is just an Oracle database with a few thousand buttons stuck to it. But let me take it one step further, all enterprise applications are just databases with a poorly designed UX. This is because most enterprise software vendors have captive users who don’t have a choice in what application they use. I once became (in)famous for saying that SAP Ariba doesn’t have customers, they have prisoners, but to be honest, that is the truth of most enterprise software.