Rob Zuber
One of the biggest factors in the success of a startup is its ability to quickly and confidently deliver software. As more consumers interact with businesses through a digital interface and more products embrace those interfaces as the opportunity to differentiate, speed and agility are paramount. It’s what makes or breaks a company.
As your startup grows, it’s important that your software delivery strategy evolves with you. Your software processes and tool choices will naturally change as you scale, but optimizing too early or letting them grow without a clear vision of where you’re going can cost you precious time and agility. I’ve seen how the right choices can pay huge dividends — and how the wrong choices can lead to time-consuming problems that could have been avoided.
As we know from Conway’s law, your software architecture and your organizational structure are deeply linked. It turns out that how you deliver is greatly impacted by both organizational structure and architecture. This is true at every stage of a startup but even more important in relation to how startups go through rapid growth. Software delivery on a team of two people is vastly different from software delivery on a team of 200.
Decisions you make at key growth inflection points can set you up for either turbocharged growth or mounting roadblocks.
Founding stage: Keep it simple
The founding phase is the exciting exploratory phase. You have an idea and a few engineers.
The key during this phase is to keep the architecture and tooling as simple and flexible as possible. Building a company is all about execution, so get the tools you need to execute consistently and put the rest on hold.
One place you can invest without overdoing it is in continuous integration and continuous deployment (CI/CD). CI/CD enables developer teams to get feedback fast, learn from it, and deliver code changes quickly and reliably. While you’re trying to find product-market fit, learning fast is the name of the game. When systems start to become more complex, you’ll have the practices and tooling in place to handle them easily. By not having the ability to learn and adapt quickly, you give your competitors a massive edge.
One other place where early, simple investments really pay off is in operability. You want the simplest possible codebase: probably a monolith and a basic deploy. But if you don’t have some basic tools for observability, each user issue is going to take orders of magnitude longer than necessary to track down. That’s time you could be using to advance your feature set.
Your implementation here may be some placeholders with simple approaches. But those placeholders will force you to design effectively so that you can enhance later without massive rewrites.
Very early stage: Maintain efficiency and productivity
At 10 to 20 engineers, you likely don’t have a person dedicated to developer efficiency or tooling. Company priorities are still shifting, and although it may feel cumbersome for your team to be working as a single team, keep at it. Look for more fluid ways of creating independent workstreams without concrete team definitions or deep specialization. Your team will benefit from having everyone responsible for creating tools, processes and code rather than relying on a single person. In the long run, it will help foster efficiency and productivity.
This is the awkward stage where you are trying to manage your ability to work independently without creating unnecessary complexity in your operating environment. During this phase, you have some practices in place and you’re trying to keep your software simple. You’ll be tempted to build services, but it’s too early. You’d be adding unneeded deployment complexity that you’ll pay for later. Create boundaries and stability with components or libraries. This will give you room to operate with more independence while keeping your deployment simple.
The benchmark during this phase is finding the product-market fit. Before reaching that point, everything you build has the potential of being thrown out. So build as simply as possible to give the flexibility to pivot and throw things out easily. Once you finally have a fit, you can invest in it.
Early stage: Automate culture
At this stage, you likely have 20 to 50 engineers separated into well-defined, independent teams. You might be tempted to embrace those team boundaries as a chance to accommodate different engineers’ language preferences, but don’t do it. Choose a standard and enforce it. Although it may seem like you’d be optimizing for speed, you’re actually generating long-term overhead. More code is more surface area for maintenance and bugs. It’s tempting for engineers to optimize for their own velocity when it’s the velocity of the organization that matters. The simpler you can keep it, the faster your organization will move.
Every early-stage startup must identify and evaluate a strategic advantage
Language choice is definitely not the only place you’ll see a desire to take independent approaches. Invest in fighting team fracturing. There’s an expression in developer productivity circles known as “paved roads.” It means that you could hike up the mountain and chop down trees, or you could drive over the freeway. The tooling you provide should make it easy for your engineers to choose the well-paved paths.
Your job and the job of your engineering team is to provide value to customers. That’s the bottom line. Keep your system simple and your tooling strong and let your team focus on what matters.
Midstage: Invest in consistency
When your company has reached midstage growth, your software is likely to be complex enough to tip the balance in favor of truly independent work units. To prevent creating chaos, focus on identifying commonalities in your delivery pipeline before branching out altogether.
Continue to manage the fracturing as much as possible as you move into services. Choose one thing and master it. Figure out what a build-and-deploy pipeline for a single service looks like, not 10 services at once. The key to success is consistency. Create a standard, then apply it to all delivery pipelines.
The trick is to strike a balance between assigning true ownership and preventing the rest of the team from believing it is someone else’s duty. Maintain a culture in which everyone feels that good software delivery is an integral part of their job and then assign responsibility for making that a reality. Otherwise, everyone solves their own problems, duplicating work and losing out on shared lessons.
Also, treat your pipeline design as you would any other piece of software. Build it once, test it out, build it again, and copy-paste some code. Figure out what’s causing it to fail. Use the Rule of Three: In the third case, you can build an abstraction. Before that, trying to build a “perfect” abstraction is a waste of time because you don’t understand it yet. You’ll burn cycles and be wrong anyway.
Growth stage: Transition from investments in people to systems
This is the point at which all of the placeholders you’ve established and the culture you’ve instilled throughout the process begin to pay off. You’ve passed the point where you can figure out what’s going on just by looking at everything. Now systems keep things working, not people.
As you are completing the transition from personal relationships to systems, you’re going to need to level up your operational tooling. Some of these transitions will seem daunting, but this is the time where your scale is going to need a new level of maturity. At least in spots. Start small. Do a little every day. Keep going.
You’re also at a scale where it’s critical to ensure clear team boundaries so that teams can deploy their own services regardless of what’s going on elsewhere in the system. The overhead of collaboration is increasing exponentially, so the true advantages of autonomy will be realized. Those clear boundaries allow teams to focus on their own delivery, trusting that their pieces can move independently.
Don’t get caught in slow legacy processes
As your firm grows, new stakeholders, such as auditors, will place expectations on you. Recognize the outcomes they require, but don’t think you must follow their advice on how to get there. They aren’t working on cutting-edge software development.
Don’t get off the train because you’re afraid to operate at your current size. You are a successful startup with all of this expansion under your belt. Create technologies that allow you to maintain your status as an outstanding software team.
Finally, keep in mind that every other software organization that’s bigger than you is trying to operate like you, so don’t get caught into their world of slow legacy processes; continue to be the model.
Practice agile, iterative change to refine products and build company culture
Comment