Scaling down process for software startups
Many large companies have some impressive systems in place for managing their product/software delivery organizations, processes and teams. One of the more common systems used is SAFe. Without going into a lot of detail, SAFe is a powerful framework for how all of the moving parts of your organization should work together.
Because I’m a sucker for well-oiled systems, it’s great to think about, but for a startup, there are never enough bodies to turn all the cranks in the machine. Everyone has to wear a lot of hats. I enjoy this type of systems thinking specifically because it helps keep the responsibilities separated from the person. At the startup level, this sets the team up for scaling into a large organization.
In the startup phase, it’s really easy to get focused on the “next thing.” The next bug, the next feature, the next customer, and while you have to start there, and grow through pure tenacity, you can’t scale it. I love to tell folks I work with that you scale a process, not a person.
Why SAFe?
I like thinking about this framework because it is rooted in the software development activities we are all familiar with, and also because it comes with an amazing flow chart. There are other frameworks that can work for this, but I’m just going to pick one, and talk about how to scale it down.
Whoa, That’s a Lot
It is. Just counting the number of people icons on there, you see 15 people, with 5 developers. If you’re a 5 person COMPANY, you’re most likely not going to have the bodies to fill all the roles. The other side of this is that, even in larger organizations, these roles may be shared across teams, matrixed, or combined with other roles in the organization.
So, let’s start small. Following the framework, your entire company is one “program”, so it gives us a good opportunity to see how the wheels would turn adapting this to various levels. I’ll start by talking about the hats in the framework, and then give three examples of how this could work at various levels.
The Hats
The following is a base set for tracking the work on/in a team
- Business Owners
The owners of the whole process. The Business owners are setting the “why?” for this project. For a startup, this is the founding team, and will continue to be the founding team until more executives are brought into the company. - UX/UI
Users have to interact with your product in some capacity. This interaction should be designed, planned, and managed. - System Architecture
When planning, both for new product directions, possibilities, and directions, you need someone in the room who both understands what’s possible, and the limitations of the technology and technologists. - Release Engineer
In this process, ownership and verification that all product is correct, everyone is aligned for product delivery, and the end product is shipped on time. - Product Manager
Product Managers are the key communicators from the customer to your development process. They map and plan features that solve the problems your customers are facing. - Developer
They write the code. - Product Owner
Product Owners typically manage the more day-to-day delivery of stories and features, while both planning the next items for the developers to work on, as well as accepting work from the developers. - Scrum masters
Scrum masters are there to keep the developers happy, on-track, unblocked, and free from interruptions. - Dev Ops
The dev ops role is generally responsible for getting the software into the hands of users. Through either automated means, or simply through managing a server in a closet. - QA
This role is both responsible for assuring the final product is well-made and free of bugs. This person is generally also responsible for creating and managing test data and testing plans.
That’s a lot, I know. In the next section, let’s break it down a bit, and see how this ends up netting out at different levels of growth.
Startup Stage 1: The Beginning
At this stage, it’s just the founders, and *maybe* a few others if you can scrape up the funding to pay them. Let’s say you have three founders: a CEO, a CTO, and a COO. While there are many other hats, I’ll just touch on how they interact with the product process:
- CEO
As the prime sales role, the CEO serves as the key liaison between customers and the development team. The CEO at this stage, will be a Business Owner, as will the rest of the founding team. The CEO will also most likely play a large part in the Product Manager role. Product [and sometimes UI/UX] at this stage is a highly collaborative role between all of the founders, especially the founders that are the most customer facing. The CEO will also be a key person in the QA role. As the person giving all of the demos, and showing off the product, they may have the the most interaction with the platform as a user, starting off. - COO
A more nebulous role, but very key in this process. The COO will be helping with the shared roles, like Product Manager, UI/UX, and Business Owner, but will be more involved with QA than the CEO. The COO will also start to take on some of the more operational roles of product delivery, such as the Release Engineer and the Product Owner. While the COO may be entirely non-technical, they can help make sure features are correct, schedule work, and make sure all of the required pieces are in place for each product release. - CTO
The CTO is most likely the developer. At this stage, the CTO is most likely the only one, and has to handle both the deeply technical advisory roles, as well as the actual hands-on-keyboard work of development. The CTO is also responsible for taking the product from a local dev environment and delivering it to customers. The CTO will also participate in all of the shared roles, but, may pull back on some of the more strategic shared roles, to allocate more time for writing code.
You’ll notice I didn’t include scrum master here. You don’t have a team at this stage, so scrum generally isn’t practiced or needed.
Startup Stage 2: First round of hires
At this stage, you’re getting a real team in place. Some of the hats are starting to shift around, and you’re finding that some of the roles that didn’t really have much to do, suddenly become much more important. Your orchestration and planning roles start to grow in workload at this stage, but generally remain with management
- CEO
A little more hands-off with the day-to-day operation, but still critically involved in the Business Owner role, and most likely in the Product manager role, though at a more strategic level. - COO
Further removed from the day-to-day concerns about cards and code, the COO will still be involved in coordinating release activities, and the strategic product decisions. - CTO
The biggest change will be here. the CTO will probably go from writing code 95% of the time to only getting 5–15% time with the code. The rest of the time will be spent on work for System Architecture, Product Owner, QA, and Release Engineer roles. - Developers
At this round, you may have 3–5 developers with various skillsets. This is critical for helping share the load of the Dev Ops and Scrum Master roles. At this stage, it’s a good idea to bake in Quality controls into the development process to help manage the QA work. - Designer
The designer role will be another voice in the product conversations, and will help define items as part of the Product Manager and Product Owner roles. This can range from large page redesigns to individual concerns about specific cards. They will also be the voice in the room for producing high quality interactions.
Stage 3: Stepping on the Gas
At this stage, you’re starting to get a sense of how the process works in your organization. You have a number of people in place, and may even be starting to bring in multiple people for some roles.
- CEO
Mostly participating in the strategic product development at this stage, the CEO should expect product delivery to be hit, and should have a sense of the roadmap and when items will show up for customers. - COO
The COO will be helping at the strategic level, and will be helping other roles coordinate with the rest of the company, but will be more hands off, especially as a lot of the manual coordination becomes automated. - CTO
The CTO again moves further away from the code, and becomes the prime architect for the product, as well as picking up a lot of the release engineer work. - Engineering Manager/VP Engineering
As the dev team grows, a lot of the day-to-day management of the development process moves to a VP of Engineering or an Engineering manager. In lieu of a formal product owner, this role will pick up a lot of this work, as well as the Scrum Master, QA, and Release engineer roles. - Designer
Depending on the work, this role starts to become set, and potentially grow to more than one individual. You may have two people: one for UI design and one for UX design, but they continue to serve the same role. - Developers
You’ve got a number of people [10–20] of all different skillsets and levels of expertise. You’re starting to have team leads, squads, and focus areas, as well as some people serving the scrum master role. You should have a strong code review and internal QA process baked into development at this point as well. - Product Manager
Bringing on your first dedicated product manager is a big leap. It’s one of the most strategic roles for a company that is filled by a non-founder. This person will have a large amount of influence on the direction of the product, and, as a result, the company at this point. - QA Engineer/Lead
Your QA Engineer or lead will help make sure you have a complete and well-tested product. While the QA process is not a single person, this role will play a large role in making sure this process is running, and unblocked. - Dev Ops Engineer
The specific title here depends a bit on the type of product you have. Generally this role will be the primary point of contact for ensuring uptime and delivery, but will also be managing and building automation to make sure releases are frequent and working.
Wait, what if I don’t…
The above is just an example of how it could work. You may be a solo founder [may the force be with you], or you could have two strongly product-minded or UI/UX minded founders. That’s great! You can still take a large framework like SAFe, and break it down into roles, and assign those to the people best fit for taking them on.
You scale a process, not a person.
While you may have the best, most capable three founders in the world, at the end of the day, they are only three people, and between them, only have 240 hours per week. [Those are founder-weeks, I did the math!]
To be successful, you will have to bring on more people, and keeping a systems mindset as you hire and grow will set you and your company up for long-term success. By constantly thinking about what role the next hire will play, you will hire the right people, and by thinking about how that role fits into your organization in the future, you will build a sustainable company.