As an engineering leader in your company, you have a heavy burden. Your teams should not only build great products technically, but also deliver great products that customers love, that they want to pay for, and that the rest of the organisation is able to sell. You are building a team, making technical decisions, and scaling the organisation, all the while things are uncertain on the customer and market side. You cannot expect your sales and marketing peers to come up with the answers, you need to find them together.
My thinking over the years have always continuously moved between individuals and their motivation and skills, through team dynamics and how to build high-performance teams, as well as to the organisational level and how to build start-ups and scale-ups that are capable of tackling the challenges that come as you go through the various stages of a growing business. My experiences and thinking around this latter area have resulted in a series of blog posts that go beyond individual teams and that focus on how to build structures and processes across the organisation.
1.In my experiences from Cisco many years back, I noticed that we had a tendency to either over-architect technical solutions to take into account future possible requirements or get stuck in discussions over decisions that maybe were not that important from a product point of view at the time, but that had a big impact on the technical implementation. I thus introduced the concept of “pivotal assumptions” as a way to unblock technical progress, while still keeping the option open for pivoting.
2.Later, when I bootstrapped Hudya, a consumer services company, as it’s CTO, I had the need to ensure that a 25-person team as quickly as possible iterated over the same deliverable (an electricity service with signup, my page, and billing) instead of building things in isolation. I used the concepts of a Minimum Workable Product (MWP) and scaffolding to quickly get to an end to end service that barely was hanging together, but that forced getting everything to work together much earlier than you usually get in bigger project.
3.When I worked on Minimum Workable Product and scaffolding techniques to drive end to end views in the organisation, I realised that I got the most speed if I was able to define a small part of the functionality end to end (touching all components and all employees) and focus on that part until we had a deliverable. I called this “slices”. When I joined Cxense as it’s CTO, I introduced the concept of a slice through the organisation in order to make everybody involved focus on the same things at the same time. In my post Are You Lost In All The High Priorities? I introduce the concept of slicing, as well as pacing and themed releases. These two techniques go well with slicing to get a “hyper-focus” in the organisation and quickly deliver high value.
4.After experiencing how larger organisations (i.e. 2-300 people) typically meet the suggestion of using slices to make sure that everybody focus on the same things at the same time (“this is too important for the organisation, but we also have too many high priorities to just focus at one at the time”), I wrote a post more specifically on how organisations that have not been set up to innovate themselves continuously fail when they try to rebuild their entire business model, operating model, and organisation at the same time. The effort typically involves too many people and triggers too much resistance. The post Don’t Try to Innovate On Your Entire Business Model In The Existing Organisation makes the case that a sliced approach to innovation is more likely to succeed.
5.On an even higher level, when organisations move from being a start-up and into the scale-up phase, a lot of things happen. There is a need to introduce more “professional management”, processes, structure, and people need to specialise more. It is tempting to bring in people from larger organisations, not people who have done scale-ups before, and they will quickly introduce what they believe is the right thing for the growing company. Knowing what is the right amount of process and structure is hard, and there is no silver bullet that works for all. Doing it wrong, and you drown the smart people you relied on for the start-up phase with things they hate. In The Three Deadly sins of Scale-Ups, I describe the three biggest and most common mistakes that I have seen scale-ups do.
6. Scaling up a product organisation is hard. Marty Cagan argues that there are two ways to scale: through strong product leaders and processes. He focuses on the product leaders, who are absolutely essential, but how do these product leaders build an organisation with the right ownerships and the right processes? How to Scale a Product Engineering Organisation? covers these challenges and describes a thought process and action plan for mobilising and creating the right context for your product leaders and engineers to thrive and build great product.