I recently joined the HEY bandwagon, a new app by the folks over at Basecamp. After all, it’s not every day that email gets reinvented. I’ll leave it for you to explore it, but this caught my eye:
Simple.
Effective.
I remember once, many moons ago, reading some code from one of my university teachers, my mouth agape with how clean and elegant it was. It made me fall in love with simplicity right there. Since then, it informed the way I myself programmed, doing multiple passes at my own code, striving for its simplest and most elegant version. The same goes for any other type of writing I do. Not always successfully, I might add.
Complexity, on the other hand, is insidious. It accumulates silently, slowly but surely. Left to its own devices, it sprouts everywhere. With so many technology options out there (AWS alone currently boasts more than 200 different services) it’s never been easier to build a Frankenstein. Too many teams pride themselves in building incredibly complex architectures where all the benefits get dwarfed by the overhead of maintaining, extending and even understanding it.
But, hey, microservices, right?
Most problems worth solving are indeed complex. But that doesn’t mean the solution has to be equally complex. The best solutions are simple, though not necessarily easy to get to. That’s what caught my eye about HEY — tackling a complex problem (reinventing email, no less) through a simple solution (in both technology stack and UX). Try it and see for yourself.
I think Engineering, Product and Design folks — particularly leaders and managers — have a collective responsibility here. Tech should be an asset, not a liability, and that depends on constantly minding and taming complexity. The more complex products, codebases, and processes get, the harder they are to change and the slower learning becomes. If you don’t learn, you stagnate. Game over.
With this in mind, three habits to consider:
Run towards the simple and away from the complex. Complexity is not about what’s easy or hard but about multiple layers, components and concerns interacting in unpredictable ways. Be critical: How can it be simpler? What can be dropped? Is there really no way to solve this problem without adding something new?
Fall in love with subtraction. Antoine de Saint-Exupéry once wrote, “perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” Product and software development is like sculpting, mindfully chipping away until the essential emerges. Instead of asking “what are we not doing that we should be doing?” ask “what are we doing that we should NOT be doing?”
Reward simplicity. There’s no use preaching if in practice you tolerate unnecessary complexity, don’t reward simplicity, or both. Publicly praise the simple and elegant solutions. Make it part of the expectations for personal growth on your career ladder. Run internal learning circles where great case studies in elegance are dissected. Habits don’t change if the incentives aren’t right.
Remember the famous quote attributed to Einstein: “Genius is making complex ideas simple, not making simple ideas complex.” Now, that’s an idea worth millions.
So, I’d love to learn: how are you managing complexity in your work?
3 Articles
✍️ Chasing The Agile Rainbow
Last week, I had the chance to ask a few questions to my friend Riz, a Senior Product Manager at Hotjar. We're both fascinated by what makes high-performing teams, what Agile really is (and what it's not), technical and product debt... the list goes on. So we geeked out about it in Q&A format, the first of a series on Product & Engineering collaboration over at my other place. #ShamelessPlug
✍️ Why (Some) Leaders Become Workaholics
The danger of overwork and "workaholism" is that we are awful at noticing it in ourselves. And the more exhausted we are, the less self-aware we become. In this thoughtful and beautifully written post, through a very personal story, executive coach Suzan Bond digs into common reasons behind workaholism, how dangerous it can be for ourselves and others, and what we can do to prevent it.
✍️ The Evolution of HEY: From Humble Beginnings to a Multi-Platform Email Service
In the introduction above, I mentioned it was a glimpse into the simplicity of HEY’s tech stack that caught my eye. Here, we get a behind-the-scenes design perspective at the making of this product over the last 2 years. Two things stood out to me: what’s possible when you discard the notion of how things “usually work”; and how creative and autonomous teams can push an initial idea to become a much better one.
2 Videos
📺 Find, Vet and Close the Best Product Managers
If you're in Engineering, don't skip this one just yet. This talk by Todd Jackson's really is about the anatomy of great Product Managers — a role most engineers work with directly. It's insightful in terms of recruiting in general, how to best assess resumés and how to build meaningful interview loops. It's even helpful for you to enhance your own resumé layout and content. I love smart, multi-layered talks and this is a great example of that, all in under 20 minutes.
📺 Creating a career ladder for engineers
Developing and implementing a career ladder is not easy. Done well, though, it underpins everything from hiring, to individuals’ professional growth and engagement. This talk by Marco Rogers is an excellent primer into the why, the what and the how of career ladders.
1 Book 📚
Being part of a great team is an amazing feeling. But creating an environment where great teams can exist is not easy. Part of it is clarity of purpose, strategy and objectives. Another part is how teams work, from idea to production, and how well their process enables flow and learning without running everyone into the ground.
To finish off the HEY extravaganza here this week, I was reminded of the 2019 book Shape Up. It outlines the product development process the team at Basecamp honed over many years.
But before we proceed, a disclaimer.
Baudelaire has this line “the greatest trick the Devil ever pulled was convincing the world he didn't exist”. Let me twist that a little: the greatest trick Spotify ever pulled was convincing the world they practiced what they preached. This is my silly way of saying that no good comes from mindless copy/pasting other companies’ processes and structures. This book is no exception to this “rule”. I’ve been guilty of it myself.
Shape Up features clear answers to most of the major pain points of software development: lack of predictability, scope creep, estimates, schedule and capacity planning, top-down control from management. Estimates, for example, are historically a sore topic for developers. This process completely sidesteps them by fixing not a (bloated) scope, but the time per cycle (a maximum of 6 weeks). The question becomes, what’s the most useful and reasonable piece we can build within our time budget — what Basecamp calls their appetite for a given idea.
A typical pitfall is rushing to solutions and being caught off-guard way too late in the game. Or working in silos and hoping for things to magically add up in the end (they rarely do). Shape Up resonated with me as being about de-risking software development: raw ideas are shaped into “bets”, some of which turn into actual projects. And projects are sensibly broken apart into scopes in ways that front-load discovery of the unknowns. No one likes bad surprises, right?
Being explicit and unambiguous every step of the way, and by featuring a common language for all its stages, everyone can explain the process in simple terms. A lot of teams don’t have an actual software development process to speak of — things just sort of happen haphazardly. In which case, how can you iterate and improve on what doesn’t exist?
Critically, burnout is a systemic problem that demands systemic solutions. If you’re familiar with the company’s values of seeking calm and happiness at work, Shape Up definitely speaks to that. And if you’re in the almost two thirds of tech workers who feel overworked or downright burnt out, it’ll probably speak to you too. It certainly resonates with me.
There’s a lot to discover within Shape Up and I can’t do it justice in just a few paragraphs. While it certainly won’t fit most companies 1-to-1, I do think the principles behind it are sound. Using them to challenge the status quo would benefit many dysfunctional teams stuck in the usual failure modes.
🙌🏽 Thank you for reading! Enjoyed this week’s edition? Have feedback on how I can make this more valuable to you? I’d love to hear from you — my DMs are open on Twitter or just write a comment below.
👉 You can follow me on Twitter @prla
To manage complexity, I use several activities with a product team I am leading. I mainly use the open-source meeting framework Liberating Structures. First, the builders need to understand and simplify the user's core Job To Be Done. This is sort of like the orthogonal mapping in Shape Up. After that, the team can leverage their collective intelligence for building a Minimal Loveable Product. :) Of course, this process should be iterated on frequently. But finding that core magic of a product or service is really the only deep work worth doing IMO. I appreciate you highlighting material that I also find value in.