Less is Much Much More

I've been mulling over Just the two of us by Jason Fried. As with many ideas from 37 Signals, this sparks almost violent agreement from me.

If it takes more than two people, it can't. We won't let it. We'll clear it up, simplify it down, make more tradeoffs, find more elegance. If it can't fit into two, it's not ready to do.

The only change I'd make here is to prefer three (2 engineers, 1 designer) over two when pair programming is an option. While it can be daunting for engineers not used to pairing to start, if they're open to the idea and try it within a safe, collaborative space, there are measurable, tangible benefits to be gained.

That said, I have worked with engineers for whom pairing was simply not enjoyable. Though I personally love sleuthing through a problem together, I get that not all people feel the same. Also, this makes no difference to the point Jason's making.

That's the discipline, and it all has to start there. Two people. This starts at hiring, of course, but it goes back further. It starts with desire: The desire to move real quality very quickly out the door to customers. And not to get caught in the corporate quicksand that swallows so many organizations whole.

I'd like to extend this further. Setting up teams of 2-3 and working across features in small teams gives results only if the organisation's desire to simplify overcomes its own inertia. This desire to move real quality quickly out of the door to customers extends far beyond small teams to the entire organisational structure as well.

Most enterprise organisations I've worked at have grown organically into sprawling organograms reminiscent of modern cities, with districts and neighbourhoods, distinct cultural norms, ideas, habits. Teams in these complex environments are often responsible for a set of services and/or applications. In my experience though, these organograms are seldom aligned to delivery of customer value. To deliver a change or build a new feature along a specific customer experience (making an international payment or onboarding a new customer to our product) need teams across very different parts of the organisation to work on some part of the solution.

Just like any city worth its salt though, these neighbourhoods have different priorities, different things that are important to them right now. Some are keen on cycle lanes, others more worried about education, yet others about the rising cost of living. In an organisation, these are reflected as muddled or even conflicting priorities - teams along the same value stream have different organisational goals informed by their reporting lines in a needlessly complicated organogram. Some are focussed on compliance work, others on Key Objective 1, yet others on Key Objective 48...

So, how do you untangle the mess? The better organisations I've worked at knew how to simplify the organogram, how to focus. I'd recommend starting with Team Topologies if your organisation doesn't know how to start this conversation - it gives you a common language to understand and talk about teams and how they interact with each other. Maybe in baby steps, perhaps in one fell swoop, keep Conway's Law in mind and work towards aligning the organisational structure and communication lines to customer value.

Ideally, pare it down, simplify it, make it smaller. This is the hard part - to simplify.

Big teams not only slow shit down, they expand the surface area of discontent. Talk to any large team, and you can feel the heat of frustration radiating outward. A similar heat radiates down from management — frustrated by the lack of progress.

The same applies for overgrown, tangled organisational structure.

Accept that everything cannot be done. All too often, working at the ground level of a large organisation can feel like a self-delusional game of "everything, everywhere, all at once". Make tough choices so teams can focus on delivering the desire. Do not lay out conflicting priorities and expect the teams to sort it out themselves - they can, but it will be painfully slow as they negotiate prioritisation, dependencies, funding; sprouting its own industry to manage the quagmire of large enterprise busywork. To be fast, as leadership, your role is to provide that clarity, to focus the organisation on key objectives. Identify the objectives that really shift the needle and deliberately ignore those that won't.

• All objectives and goals are not equal, they don't all add value - the less you have, the more focus the organisation has, and it can move quickly to reach those goals.
• Align organisational structure with customer value - keep it small, concentrated, avoid sprawl.
• Keep the teams small, dedicated to the goals.
• Embrace slack - efficiency is the enemy.
• As leadership, set direction and vision, and then get out of the way. The teams decide how to meet the goals. Trust them to do so. Empower them to do so.
• As engineers / designers / product managers, make decisions and move quickly, err on the side of getting something simple working, learn from it and iterate on the solution. This doesn’t mean that you have to launch your something simple to customers. Have a skeleton of the simplest version of the feature working, then drape on more and more capability, allowing the architecture to grow as you need it - avoid building the all-singing, all-dancing, perfect solution from day 1.

With clarity, focus, trust and autonomy, I've seen and worked with small teams achieving remarkable things. Jason sums it up perfectly:

Small is not less than. It’s greater than. It’s faster than. It’s better than.