Business driven mindset

While working at Mercadona Tech I started considering myself a Product Engineer. Miquel Torres wrote a nice post about it. Gergely Orosz, arrived at the same conclusions on his own and he also wrote a post explaining it in detail.

But then I started working at Creditas. And I realised a product mindset wasn't enough. I always thought Creditas was a bit different because of how innovative its business models are: a business driven company. But a few days ago Creditas' CEO told me something I'll never forget:

All startups are business driven companies. - Sergio Furio

This is the kind of phrase that has deep consequences. But what does it actually mean? Because a startup is not only business. It's also technology. And it's also people. How technology and people can be driven by business? And what are the implications of this mindset at scale?

From pirates to navy

Reid Hoffman talks in his book Blitzscaling about what happens when a company has been in blitzscaling mode for long enough. At some point it needs to go through a transition: from pirates to navy. Go and listen to his podcast episode from Masters of Scale about the same topic if you don't know what I'm talking about.

But the metaphor has been highly misinterpret. Let me explain ☝️! Here is what appears on people's minds when they hear about pirates and navy:

These are all misconceptions. Reid talks mostly about ethics, morale and culture at scale. He doesn't talk about changes in quality, speed, planning, goals, empowerment or ownership. He does talk about changes in structure though. Which is easier to get wrong while scaling up. But what does structure have anything to do with Business? And what is structure actually?

In the same book he talks about the 5 stages of a startup: family (1 to 9 employees), tribe (10s of employees), village (100s of employees), city (1,000s of employees) and nation (more than 10000). I've never been in a nation size company so I don't have anything to say about it. But I've been in all the others and went though a couple of transitions. So let's see how a company evolves its structure from family to city.

Structure

Have you already seen the Snyder's Justice League Cut? Then you know about the three boxes and what happens when you bring them together. Destruction. With structure is exactly the opposite. If you haven't seen the movie, don't worry. Let me explain.

Structure can be decomposed in three fundamental parts: business or product structure, social structure and systems structure. Systems structure is also know as architecture. The degree of synchronisation of these three is an indicator of a company's health: social structure needs to match architecture, architecture needs to match business and business needs to match social structure. Theoretically there are many ways in which the structure can change. But remember: business driven.

In the family stage these three parts almost always match. Even unintentionally. One team with one business goal. Led by the founding team. The people keep their focus on achieving that goal. Most of the time if it is not achieved, the company dies. There is some specialization: backend, frontend, mobile, design, product, etc. which is not ideal but it works at this stage. It's also cheaper and easier to find specialized people than generalists. Despite this, Conway's law doesn't work against achieving the business goal. Yet.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. - Melvin E. Conway

One mistake I've seen founders make quite often is treating non-founder members as mere executors. Not involving the rest of the team in Business decisions is the starting point for a culture without any real ownership over the outcome. Ownership only over the output is just an illusion that unintentionally creates a separation between business structure and systems structure. But from this point on, a startup can go two ways. It either corrects their course and grows towards a healthy city or continues with their bad habits going through a chain of unfortunate events that lead to a culture without real ownership. Let me paint both for you.

Towards a healthy city

The value of a startup lies in its growth. And after some moderate success a startup needs to accelerate that growth. That means more ambitious business goals. Which naturally leads to breaking those goals into smaller ones that should be decoupled but aligned. This is just diversifying investment and reducing risk. Diversification means multiple focuses. And everyone already knows that those who follow two hares catch neither. So suddenly multiple teams are created through Dynamic Reteaming; each one with their own business goal. At the same time, the architecture evolves iteratively based on the same business goals. Business is like gravity for People and like a compass for Technology.

Over the years, in System Design we've learned the consequences of separating responsibility. Focusing on a single business goal keeps the complexity of each team small but, at a higher level, the social structure starts looking more and more like a distributed system. This is one of the reasons startups start to set up some standards for how people communicate, how they document their decisions and how they collaborate. It helps the business, social and systems structures to be synchronized.

And so a startup reaches the tribe size. Matthew Skelton and Manuel Pais in Team Topologies use the term Stream Aligned Team to define a multidisciplinary team with a clear business goal. They are usually focused on external clients. But at this stage other types of teams whose clients are internal start to appear. Platform teams act like mini SaaS companies whose clients are people from within.

A day in the life of a team with a clear business goal may look strange to most people in our industry. Why? Because there's nobody dictating what to do. The only thing they have from upper management is a business goal which is sometimes tied to a vision. They have to research, design, test, document, implement, deploy, release and measure impact all by themselves. This has a lot in common with Design Thinking. It doesn't mean everybody needs all the necessary skills to do everything on their own. It just means everyone is involved in the whole lifecycle of the product. The team is formed by people with T-shaped skills. Everyone communicates in their day to day without any barriers and they make decisions together. This doesn't mean it is a democracy either. It just means the team works in a high collaboration mode all the time. People still have responsabilities over some areas.

Until the tribe size, the main social structure was the team. But towards the city size, bigger structures start to appear. Some call them Business Units other call them Tribes. It doesn't matter. The founding team starts acting more like a Venture Capital firm and the Business Units start acting like independent startups. The company starts looking more and more like an ecosystem; a hub of startups. Platform teams can be internal to a Business Unit or external working for a bigger market: the whole company.

Company wide initiatives still appear from time to time. Which are solved through Streams of Work: collaboration between people from different teams or even different Business Units. They come together to form a short lived team. They reserch, design, diverge, converge, implement and measure the impact. Once the goal is achieved they go back to their teams.

A chain of unfortunate events

The wrong approach to accelerated growth is trying as many features as possible. Most startups go on that path. Wanting more features always leads to hiring people: starting with more Engineers favoring specialization; and at some point inter-managerial roles like Product Owners who take requirements from founder members, write pseudo user stories and put them into a backlog. The division between Business and Engineering starts growing.

We are social animals. We have a tendency to come together and join into groups. In a healthy startup, people usually organize around business goals. But without them, people organize around whatever they have in common. So suddenly backend, frontend, mobile and design teams start to appear. They establish their own goals and start optimizing for their own well being. And sometimes, unconsciously, technical decisions are made emotionally. Business, social and systems structures start to desynchronise.

A day in the life of such a team looks pretty waterfallish. A Business Analyst decides what to do but only at an abstract level because they don't have knowledge about the technical constraints. The Product Owner goes back and forth with a Product Designer to create a proposal that both Business and Engineering agree on. Frontend Engineers focus on the frontend side while Backend Engineers create the APIs. Backend Engineers add a task to the Infrastructure Engineer's overloaded backlog; who doesn't have much time to implement their requirements. But suddenly the Business Analyst talks to the CTO. Who goes to the Infrastructure Engineer and uses authority to change priorities. Frontend Engineers need to make some changes to the APIs. Which isn't possible because it would require a lot of re-work. The feature is finally released way after the original estimation. The cycle starts again while some Data Engineer and Data Analyst manage to somehow collect data that only correlates with the deployed feature.

And then, somehow, the company reaches the tribe size. And Engineering starts using bizarre vocabulary that has nothing to do with the Business. They don't work in an empirical way and surely they don't measure their impact. Hyper specialized teams for infrastructure, security, data or quality assurance start to appear. Business is now only a distant and faceless entity who demands features. While Engineering is a feature factory who always works on projects nobody understands. Product Management becomes only Project Management at a smaller scale.

We all know by now that the Spotify model failed even for them. But companies who are too far gone still use it as an inspiration because they don't know what else to do. Bigger social structures start to appear. But they look more like consultancy firms than Business Units. Some are more specialized than others.

By this point the systems, social and business structures are highly desynchronised. Few people understand the Business anymore. If 10 random people are asked about the impact on the business of their latest task, they wouldn't know. Teams are just feature factories. It would be cheaper to hire consultancy firms because the company wouldn't spend time and money on management. Good people are leaving the company while the good people who come, leave shortly after joining.

The company is now so big that chaos is a day to day thing. Chaos is not bad. But everyone feels lost because they don't have clear objectives.

Iterative Business Goals. Evolutionary Architecture. Dynamic Re-teaming

Let's say you want to create a human colony on Mars. Your first thought may be to start designing the Starship that will take the crew to the red planet. But wait. That's too risky. You don't even know how to go to Earth's orbit. So instead you first start by putting small satellites into Earth's orbit with small rockets. Then you go for bigger sattelites. Your first goal is to make this business model sustainable by reusing boosters.

Ok. But you've never had people aboard. Transporting people is very diferent than transporting cargo, believe me. So you use part of the economical benefits to research what is needed to put people into space. And after many failed attempts you finally do it. You finally can get astronauts to the International Space Station.

But what about longer rides? How are they different? So you plan a trip to the moon. Which should teach you more about how to transport people without many risks. And it will allow you to test the Starship before doing longer routes.

You see where I'm going with this. Most startups have a vision of where they want to go. But they fail to break that vision into smaller iterative steps. They start working directly on the colony instead of putting satellites into orbit. They start talking about scalability instead of evolvability. They design huge systems, do pointless reorganizations while constantly missing business opportunities.

The Nature of Software Development is to keep it simple, make it valuable and build it piece by piece. And having a business driven mindset is just another way of saying that a startup needs to work empirically and colaborativelly. End to end. There is no other effective way of measuring impact.

Business is like gravity for People and like a compass for Technology. - David Stanete

By this point you can imagine how to avoid the sad story. Or maybe not. If not, reach me. My DMs are always open. Everyone working at a startup, any startup, needs a business driven mindset. Put a lot of effort into defining iterative business goals. This is the one thing you can't get wrong. Remember that Business is like gravity for People and like a compass for Technology. Building Evolutionary Architectures and doing Dynamic Re-teaming are only possible if you pay special attention to having iterative business goals.