Hope you have all had an awesome first half of the year. It’s been an exciting 6 months with the addition of our son to our family in January.
Seeing him develop every day has reminded me how adaptive we are and also how inquisitive we are when we first arrive. But having a baby in the house has also reminded me how fragile life is at the beginning.
Projects and products have a lot of the attributes of a newborn. In the beginning, they need care and nurturing, there’s a massive amount of learning happening, and if you’re lucky they won't keep you up all night!
I look back at the start of the year and think about how unprepared we were and how little we knew about being parents (and still do!). We’re making lots of mistakes, but with every wobble, lost moment of sleep, and cry comes a chance to learn. It’s a fun time, and we’re enjoying every moment.
When was the last time you celebrated a failure? It’s time to visit your local f’up night!
Astro Teller from Google X talks about what happens when you celebrate failure.
In this issue of the makerlab, I look at some of the common traps that early stage projects within an enterprise fall into.
Every now and then you’ll hear about a fast-moving startup doing amazing work, only to get acquired by a bigger organisation. The team slows down, stops innovating, and over time becomes a shadow of its former self.
I’ve borrowed the title of this newsletter ‘the baby and the beast’ from Ed Catmull’s book ‘Creativity Inc.’ where he describes the relationship between Pixar and their parent company Disney after their acquisition.
Through proper planning, they were able to influence Disney and bring fresh ideas to their parent organisation which revitalised their creative process.
Pixar made some critical changes at Disney which led to an increase in risk-taking and improved storytelling by the larger Disney team. Several successful films later and Disney had returned to success.
Their story is a good example of how to handle mergers. With 70% of mergers found to fail it’s important to take learnings from their success.
It’s a story that has resonated with me, experiencing a similar situation a few years back.
I was part of a successful tech consultancy and had the luck of joining when it was still small. It was the sort of place you would describe as having a “family” feel to it. Everyone on the team knew each other well and had similar values.
We experimented, made quick decisions and when required changed the org structure and our ways of working. We adapted to changes in technology landscape and dropped/renamed services when they no longer made sense. We were a tight-knit team which knew how to work hard but also have a bit of fun along the way.
We had a simple recipe that was very successful. The best people, using the best technologies, on the best client projects.
Enter the beast
After years of success, the founders decided we needed support to continue growing at the same rate… In the 6 years I worked there we had grown from 20 people to around 280.
And so, an international company looking to expand its footprint in Australia acquired us. We became a small fish in a very, very big pond. At the time of our acquisition, the parent company had 240,000+ employees globally.
The acquisition changed our ability to make decisions. Where before we could work autonomously, we now needed external sign off.
The founders left, and we started making compromises in the way we worked which started to change our culture. It started to feel less like a family and lots more like a corporate.
To describe our parent company as a ‘Beast’ is a little unfair. They were working as they knew best, and for them, it was business as usual. Their ways of working and organisation structure worked for a company of their size.
These pains are not unique. They are also felt by many organisations which experience rapid growth. No doubt our company would have hit similar challenges without the acquisition.
It’s likely many of you reading this have also seen these behaviours in projects starting in enterprise incubation.
A new project starts up, and a small tight-knit team is able to make fast decisions resulting in progress and early success. Suddenly the beast takes notice of the baby making noise and wants to get involved.
But with all the support the beast brings, it can also introduce undesirable side effects as the enterprise mindset take over. “Oh no, we can’t do that until legal have reviewed it”, “brand will never sign off on that!”. Blockers become the norm, and the efficiencies of before are lost.
Communication Overhead
So, how do enterprises get to that situation in the first place?
When teams grow beyond the ideal “2-3 pizza”^ size of 6 or 7 people, you need extra management layers to ensure delivery of strategic objectives.
But with every extra team member, the burden of communication increases. In his book “The Mythical Man Month”, Fred Brooks observed that adding more team members to a late software project actually has an adverse effect due to the combinatorial explosion of communication channels within a team. You may have heard the saying… “9 women can’t make a baby in one month”.
^ I’m not sure 2-3 pizzas would feed my team. Pizza is my diet arch nemesis.
Dunbar’s number
In the 90s, British anthropologist Robin Dunbar identified a correlation between primate brain size and the average social group size. He proposed that humans can only comfortably maintain between 100 - 250 stable relationships.
It’s argued that the maximum size of a cohesive group is around 150, and that larger teams require more restrictive rules and enforcement to maintain the team norms. If you have worked on a project implementing the Scaled Agile Framework, you might be aware that the framework recommends a largest release train team size of around 150.
What is often missed in Dunbar’s research are his comments on the level of motivation required to remain functional as a group of that size. He argued that a 150 person team would need an extreme level of incentive and would need to dedicate a whopping 42% of their time to “social grooming”. That is a massive amount of waste.
To minimise maintenance cost, it is logical that we keep team sizes as small as possible whilst still being able to deliver the required outcomes.
Risk Management
Eventually, mistakes made within the team create policies to stop them reoccurring.
As the quantity and complexity of policies increase, they need extra enforcement to ensure the team don't make the same mistakes again. The team continues to grow, and additional management and communication increase the burden.
Teams start to specialise in work functions and introduce new gatekeeper functions such as the “brand police” to ensure any new work meets the required standards.
Groups who before collaborated with each other now start to ask who will pay the bill for the work, and introduce cost centres and cross-team billing to track expenses.
I’m painting a bad picture, but this way of working has become the norm in large organisations. We need to find a better way to manage risk given the need to test, learn, and adapt to new ways of working in the future.
Unfortunately, rules are often introduced to manage the outlying scenario without thinking about the long-term impact on the majority. We are starting to see change happen in some organisations, but we still have a long way to go.
In ‘Rework’, Jason Fried proposes addressing rule creep by introducing a “don’t scar on the first cut” practice to their people management. As individuals test the cultural norms, he suggests having a conversation rather than creating a blanket rule.
By taking a minimalist approach, their team have kept rules and processes manageable without creating a chaotic or oppressive work environment. In fact, it has resulted in an innovative and fun workplace which gives their team the space to experiment.
Experimentation will always create anxiety for gatekeeper functions such as brand, marketing, legal, and finance. There are a few strategies that can help such as implementing guard rails for experimentation. I’ll leave that topic for another day.
Too fast, too soon
A temptation that enterprise adopted projects often fall into is growing too fast too early. The luxury of being well funded encourages more speculative feature development, and teams grow fast to support a larger set of features without understanding the problems they are building solutions for.
Enterprise projects are often allocated funding based on a 12 month (or longer) business case. Instead of a focus on showing validated learning to secure funding, the incentives drive a behaviour of blindly shipping features from a long-term roadmap full of assumptions.
This leads to a team culture focused on the delivery of new features rather than a culture focused on product success. “Build it, and they will come”… or not.
By contrast, an early stage startup is under pressure to succeed from day one, and finding product-market fit as soon as possible is critical to the success of the company to secure further investment. You do not have the runway to carry speculative risk in your organisation. Showing validated learning is the only metric that matters.
Searching & Executing
Given the vast gap in agility, team size, and risk appetite between the baby and the beast, what can we do as innovators to ensure the success of fledgeling projects?
Remember the squiggle?
To begin we need to start thinking about initiatives in two distinct phases, searching and executing. Steve Blank wrote in 2010 that a “startup is a temporary organisation designed to search for a repeatable and scalable business model.” This is true for any product.
The two phases need very different mindsets and different ways of working.
Steve Blank: Search vs. Execute
Searching
At the start of a project, your business model is unknown. All you have is a collection of untested hunches. Last year I wrote about searching/executing, and the three stages of fit that any project will go through. In the search phase, your focus is on understanding your customer’s world and proving out the components of your business model. You keep your team small, often relying on the skills of the founders to get the job done.
Executing
Later in the project, you have found product-market fit, and you are starting to create value. You’ll have a clear target market with validated pains and gains. The focus is now on implementation and delivery. Your team will likely have grown by this point and will start to form around job functions.
Do things that don’t scale
When discussing this topic recently with my manager, we spoke about the need to keep the ability to be scrappy during discovery.
Most organisations now have a reasonable understanding of agile development, but we have almost got too good at “the process”. Perhaps we’ve optimised too far and are prioritising perfect sprint planning, retros and tracking story points over shipping products that customers love?
We need to approach searching differently. Instead of making products like a symphony orchestra, we need to keep it tight, break the rules and have a jam to find the next hit.
Stripe, the payment platform, is famous within the Y Combinator community for the way they approached sales in the early days.
Having a small team built around the founders, they all had to get their hands dirty with sales. Where other organisations would wait for customer acquisition to happen, instead, the two Stripe founders would be out hustling potential customers to sign up. Once they agreed, instead of the customary “we’ll send you a signup link”, they would grab the laptop off the customer on the spot and manually sign them up.
In Airbnb’s case, the founders literally went door knocking to build up one side of their marketplace.
Another area you can stay scrappy is by maintaining the ability to get raw 1 to 1 feedback from your customers. Customer interviews can provide some of the richest insight you will receive.
Resist the temptation to jump straight to focus groups and quantitative data from surveys. Whilst it can be more convenient to organise, you lose the specificity of insights, and the opportunity to explore tangents outside of your initial assumption.
Roman Pichler sums it up in the above diagram. Search for product-market fit, and only then seek scale and efficiency once you are into execution. Stay scrappy as long as you can, you’ll benefit in the long run.
So, next time you start a new project, I encourage you all to evaluate the need to grow. Question every extra person, and ask whether the amount of value they will add is worth the cost of maintaining the additional relationship and risk.
Stay scrappy, do things that don’t scale, and spend every moment you can with customers learning their needs. Then, when it all falls in to place, scale and conduct that beautiful symphony! Enjoy the search.