Rediscover the Power of Simplicity

• March 1, 2025

In an era where tech stacks grow ever more complex and teams become increasingly specialised, there’s profound wisdom to be found in looking back at simpler, more effective approaches.

I’ve been meaning to write about my experience at Trade Me for years. Earlier this week, I attended the launch of Rowan Simpson’s new book, How to Be Wrong. Rowan hired me into his team at Trade Me back in 2006, and to my delight, I even earned a mention in his book! That unexpected recognition, along with recently reading this article about Trade Me’s journey toward a “thinnest viable platform”, finally motivated me to reflect on what remains one of my best professional experiences to this day.

For those unfamiliar, Trade Me is an online marketplace - New Zealand’s version of eBay. In the early 2000s, it was the go-to online marketplace for Kiwis, long before global platforms like Facebook Marketplace or AliExpress were established. Trade Me isn’t just an auction site - it’s a cornerstone of Kiwi internet culture, connecting buyers and sellers across the country and becoming an essential part of daily life for millions.

Reflecting on my time at Trade Me has me thinking about something I consider often: the power of simplicity in building effective systems and how much we can learn from those simpler times.

The System That Worked

Despite the modest size of the company, when I worked at Trade Me in 2006-07, the platform was operating at a scale that many would find daunting even today: over 3.4 million active registered members (equivalent to 75% of New Zealand’s population at the time) and up to 60,000 users online during peak hours. This was no small feat for the infrastructure of the time, and it was a testament to the simplicity and efficiency of the systems we built.

Working at Trade Me was an incredible experience. Building a web app that millions of people used daily was exhilarating. Trade Me is such a beloved and recognisable brand that wearing the company t-shirt felt like a badge of honour. It was at Trade Me that I learned how to build and ship features that customers loved, and for me, it remains one of the best, most effective examples of how to do it right. W. Edwards Deming would have been proud of our approach - we were like “The Little Team That Could” - tackling challenges with enthusiasm and a sense of fun that made even the toughest problems seem solvable when approached with the right mindset.

The development team was tiny - just six software engineers, supported by a handful of DBAs, sys admins, and testers - yet we delivered an astonishing amount of work with a pace and quality that feels almost mythical compared to modern standards. There was one designer and no formal product management layer - ideas and direction came straight from Sam Morgan (the founder and CEO), Jessi Morgan and Rowan Simpson, flowing directly to those building the features.

We didn’t have the sophisticated tools or complex architectures we see today. There was no Jira, no CI/CD pipelines as we know them now, no automated testing, no cloud services, and no microservices. Trade Me was a monolithic web app written in ASP. We were migrating it to ASP.NET gradually - every page we touched had to be split into frontend and code-behind files. Deployments were automated through a custom tool: zip up the application, copy it to load-balanced web servers, unzip it, and restart IIS app pools. And yet, despite - or perhaps because of - this simplicity, we deployed to production twice daily (except for Friday afternoons which were reserved for socialising) with very few exceptions or incidents.

Looking back, I believe that success was driven by the “system” of how we worked. The team structures, culture, and decision-making processes were all incredibly well-aligned. This alignment also influenced the technical architecture, which was simple, efficient, and easy to maintain. The simple monolithic architecture, that powered a web app used by 75% of New Zealand’s population, was a direct result of our organisational structure and the way we worked, not the other way around.

Conway’s Law and Our Bias for Addition

Look at any modern tech organisation chart and you’ll see a dizzying array of specialised roles: Frontend Engineers, Backend Engineers, Fullstack Engineers, Mobile Engineers, Product Engineers, DevOps Engineers, Site Reliability Engineers, Platform Engineers, Data Engineers, Quality Engineers, Business Analysts, Product Owners, Scrum Masters, Agile Coaches, Delivery Leads… the list goes on. Now look at their system architecture diagrams - they’re often just as complex.

This isn’t a coincidence. Conway’s Law tells us that organisations design systems that mirror their communication structures. At Trade Me, the simplicity of our organisational structure directly influenced the simplicity of our software systems. With just six engineers, a few DBAs, sys admins and testers, and one designer, our communication paths were clear and direct, and the systems we built were just as straightforward.

Today, we often justify our complex organisational structures as necessary for “scaling” or “specialisation”. But what if we’re getting it backwards? What if our complex systems are a result of our complex organisations, rather than the other way around?

There’s another factor at play here: our brains are wired to solve problems by adding, not subtracting.

A study of 1,585 people found that humans default to addition when addressing challenges, often without even considering subtraction. This cognitive bias manifests in countless ways: more meetings, more tools, more processes, more people, more systems, more code. It’s no surprise that over time, our software systems have become increasingly complex - layer upon layer added in the pursuit of better outcomes.

At Trade Me, we didn’t have the luxury of adding endlessly. Limited resources and small team sizes forced us to think differently, often leading to pragmatic and simple yet elegant solutions. By keeping the system simple, we avoided the pitfalls of “more is better” thinking and achieved results that, ironically, were better because they were simpler.

What Made It Work?

So, what about the “system” at Trade Me made it so successful? Here are a few observations:

• Clear Ownership and Accountability - Each project was run by a small, cross-functional team with clear responsibilities. Each software engineer was given an opportunity to lead a project, regardless of their seniority. They got to choose their teams, and were trusted to deliver. This trust fostered ownership, pride, and accountability, and allowed us to experience what it meant to lead a software team (which I think is really important but a topic for another post). Much of this culture was driven by leaders like Rowan, whose vision and focus on getting the fundamentals right played a big part in creating an environment where simplicity thrived.

• Small, Focused Teams - Projects were staffed with just enough people - a couple of software engineers, a DBA, a sys admin if needed, and a tester. The small size forced focus and collaboration, and the simplicity of the structure kept communication overhead low.

• Pragmatism Over Perfection - We delivered value quickly and iterated as needed, avoiding over-engineering and staying focused on what truly mattered.

• Continuous Deployment Culture - Deploying to production twice daily created a feedback loop that allowed us to learn and adjust rapidly. It was an early version of the DevOps as we know it today, and it worked because we kept it simple.

• Direct Customer Insight - Many of our testers had come from customer support roles and deeply understood the end users. This close connection to the end user meant that what we built was always grounded in real needs.

What Can We Learn Today?

The Trade Me of the mid-2000s thrived on simplicity, pragmatism, and alignment. Today, we’re surrounded by tools, frameworks, and architectural patterns that promise to make our work easier, but instead, they often add complexity. So how can we apply the lessons of Trade Me to modern software development?

• Focus on the System, Not Just the Tools - Fancy tools and microservices won’t save you if your organisational system is broken. Start by defining a clear purpose and aligning teams, roles, and communication structures.

• Embrace Simplicity - Keep simplicity at the heart of your decision-making. Sometimes, the simplest solution is the best one - not every problem requires a new complex process, framework or tool. Ask yourself, “What is the simplest way to achieve the desired outcome without adding unnecessary overhead?”. Simplicity and pragmatism ensures your systems remain efficient, understandable, and maintainable over time.

• Enable Small, Cross-Functional Teams - Small teams with end-to-end ownership are still the best way to build software. Ensure they have the right capabilities and context, then empower them with agency and accountability. Crucially, ensure that software engineers are not just participants but leaders in this process. They are the ones with the technical expertise to make informed decisions on how to build the thing so their perspective matters, a lot.

• Streamline Feedback Loops - Shorten the time between idea and delivery. Whether it’s through CI/CD or daily deployments, keep your deployments small and often. Address small issues before they become big ones.

• Bring Back the Generalist - As specialisation increases, we lose the magic of software engineers who can see and build the whole picture. Let’s rediscover the value of being a “full-stack” team member. The rise of AI tools could really help here, making it easier for engineers to learn how to work effectively across different technologies and domains.

This last point is particularly relevant in our AI-driven future. While AI coding assistants are making it easier than ever to generate specialised code, they’re simultaneously lowering the barriers to becoming a true generalist. With AI handling the syntax and implementation details, engineers can focus more on the holistic understanding of systems and user needs – precisely the kind of thinking that made Trade Me so successful.

Final Thoughts

Trade Me’s approach to building software in the mid-2000s was remarkable because it was so simple and it worked so well. Our little team accomplished things that seemed impossible given our size, proving that with the right approach, small teams can achieve outsized results. Our system was capable of achieving incredible outcomes. By understanding the system as a whole and keeping things simple, we delivered exceptional quality with minimal resources.

Today, as we navigate ever-growing complexity in software development, perhaps it’s time to revisit those principles. Let’s simplify. Let’s align. Let’s recapture that spirit of small teams doing big things. Let’s build systems that enable us to do our best work, not just add layers of abstraction.

The question I leave you with is this: What would happen if you thoughtfully simplified the unnecessary complexity in your organisation and systems? What if, instead of adding more specialists, more processes, more tools, you focused on building a simpler, more aligned system where small teams could thrive? The results might surprise you.

The tools have changed, but the principles remain timeless. It’s time to rediscover the power of simplicity.