Scaling Your Software Startup On The Cloud (part 1 of 3)
Software startups today have a significant advantage over ones even five to ten years ago, in part because of the proliferation of hyperscale cloud hosting providers like Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure. With a plethora of managed services available at the click of a button, they can rapidly prototype their solution and get it to market in record time, and at nearly infinite scale. While it may seem simpler today, preparing a startup for scaling on the cloud still takes careful consideration.
I’m fortunate to have been part of various technology organizations for over twenty years, from greenfield bootstrapped startups, to venture-funded and private-equity-funded companies, and even global conglomerates with IPOs. Learning from so many talented people and mentors along the way, I “cherry pick” lessons learned, tools, techniques and processes to carry forth.
In an effort to “pay it forward” I’d like to share some lessons learned. This first article in the series will introduce concepts and resources I find useful for building and scaling software startups. In the second article, we will design a fictitious online dating startup to illustrate how these pieces fit together. In the third article, we illustrate how they ultimately inform your cloud architecture using GCP.
- Part 1: background and methodology introduction
- Part 2: implementing methodologies with fictitious startup
- Part 3: designing and scaling cloud infrastructure
From cloud consumer to cloud service provider
Early 2020 I decided to try something new; instead of building and growing software startups, I began advising and supporting them by joining a cloud partner with roots in Israel named DoiT International. Our company is fully remote and has since grown from around 50 people to nearly 500 globally in just over two years, supporting over $1 billion in annual cloud consumption. I’m constantly in awe of how well we’ve preserved our culture through such rapid growth while attracting and retaining so many talented people.
Thousands of organizations choose DoiT as their cloud service partner. They benefit from no-cost advisory and support, and state-of-the-art software tooling designed to deliver on the original promise of the cloud — focus on your product and customers, and don’t worry about the rest. While we’d love to think it’s that simple, it typically is preceded by our customers having deeply-skilled technical teams.
One trend I’ve recently noticed is growth in earlier-stage software startups adopting cloud technology who may not have large teams or deep cloud expertise. As a software entrepreneur myself, I’m hoping that sharing lessons learned both from my “past life” and at DoiT will make your journey even more successful.
The early days
Taking a step away from the technology, let’s first explore the journey from identifying a problem, to building a company dedicated to solving it, and beyond. There are some popular methodologies and frameworks beyond cloud best practices you may appreciate as your organization matures.
Each technique illustrated above is iterative itself, but as we’ll see in the next article in this series, the output of each informs others.
TL;DR; Helpful online resources
Rather than explaining the techniques and concepts above, I recommend watching these videos to fill in the blanks and serve as a primer for us putting them into action.
- Should I build a startup (14 min)— Michael Seibel, Y Combinator
- Strategy vs planning (9 min) — HBR [use a 1-page plan like OGSM]
- Lean Startup summary (13 min)— Eric Ries
- Validating your business idea (9 min)— Eric Ries
- Lean UX (60 min)— Jeff Gothelf
- Using Lean UX canvas (15 min)— Jeff Gothelf
- Building Product (59 min)— Michael Seibel, Y Combinator
- How to plan an MVP (13 min)— Michael Seibel, Y Combinator
- User Story Mapping (50 min)— Jeff Patton
- Ultimate Guide to User Story Mapping — Nick Muldoon, Easy Agile
- Software Architecture with the C4 Model (35 min)— Simon Brown
- Building a culture of experimentation at Spotify (47 min)— Ben Dressler
- DevOps vs SRE (44 min)— Seth Vargo, Google
Vision and strategy
Once you’ve recognized a problem you feel compelled to solve, it helps to paint a picture of where you’re going, and some key indicators you’re on track to deliver value. This is similar to how Amazon required teams to draft the press release that described what they were building in the future, before they were approved to build it.
About 10 years ago during a daylong planning session, a mentor who had taken his company public, and then sold to Oracle for nearly $2 billion, introduced me to the OGSM Framework. It stands for Objectives, Goals, Strategies, and Measures. It forces you to concisely paint a picture of where you’ll be 3–5 years in the future, some measurable goals along the way, while drilling down into strategies and near-term tactics to accomplish them.
You end up with a single-page business plan, a living document you revisit and refine, that the entire team can rally around and align focus of all activities. For example, if some activity doesn’t map to a strategy defined to achieve a goal, you question whether it’s really worth doing, or whether you update your strategy.
Some may wonder what the difference is from another popular framework Objectives and Key Results (OKR). OGSM looks out years into the future, whereas OKR mostly focuses on short-term goals. Depending on the stage of your company, introducing OKR may make sense, but often a single longer-term vision everyone can rally behind is that needed “North Star”.
There are many other techniques like SWOT analysis, Porter’s 5 Forces, Balanced Scorecard, or McKinsey’s 3 Horizons, that may feed into your overall strategic plan, but OGSM remains my personal go-to tool for narrowing a team’s focus on what matters and sharing the bigger vision.
Ideation
Guiding principles and processes early in your journey can help align the teams as you grow. I believe that a data-driven culture, and measure-everything mindset, must be part of your culture and come from the very top, and evident in every interaction.
A couple of my favorite resources that reinforce this experimental culture include Lean Startup (and the Lean Canvas) by Eric Ries, and Lean UX by Jeff Gothelf. Nearly every advisor and startup incubator advises founders to measure everything, iterate quickly, and build a minimum viable product (MVP) to test their idea against the market. These all resonate with “Lean” principles.
Jeff Gothelf takes the “Lean” principles in a direction I love because it applies to every team, department, and idea in orgs of any size. The premise is “we know nothing” and in order to learn [what customers want], and what truly solves a problem, we apply the scientific method — form a hypothesis statement, test it while measuring, analyze results, and course correct as needed. The value of this approach is minimizing wasted effort and validating you’re solving the right problems faster.
Design
When I witness people neglecting to document their systems and software architecture, it reminds me of someone trying to build a house with a pile of lumber. Sure you can figure it out eventually, but you would be much faster with fewer mistakes if you had a plan. Two of my favorite techniques for product design include User Story Mapping, and the C4 Model.
By writing things down, you ensure a shared understanding and hold everyone accountable for delivering what was agreed.
A few years ago I was invited as a speaker to the annual CTO summit for private equity (PE) firm, Francisco Partners. I sat in on other sessions and one of the most intriguing was one of the partners advising other portfolio CTOs and executives about tracking metrics in their product organizations. One of the metrics that surprised me, but now totally makes sense, is measuring the amount of rework to assess the effectiveness of product managers. I’ve asked other engineering leaders since if they measure rework, and most appreciate it but don’t yet.
Rework is a key metric you can impact by taking time to understand the customer, and prioritize delivering the most immediate value to them. This is exactly what the user story mapping exercise helps facilitate while forcing collaboration amongst various stakeholders. My argument for it, at any company stage, is that it’s much cheaper and faster to move around a few boxes on a shared whiteboard than it is to kick off development cycles that later result in rework.
I am first to admit that I’ve had some ugly architecture diagrams in my day; I’ve witnessed even more. It is important to take time to write down your architecture, and its relation to other systems. The C4 Model is one of the best ways to do it in a standard way without requiring UML knowledge. As described in the video links above, the standard practice is to design up to 3 levels deep (component view). There are products such as IcePanel that make this easier, or various plugins or tooling on other platforms. It’s faster than you might think, and we illustrate this in the next article in this series.
Build
Let’s assume your team is well versed in this phase. As you grow, adopting a well-defined framework to implement Agile ideologies can help you scale. If you follow “Lean” principles, and change your priorities based on learning, you are already well on your way. As organization focus shifts from speed and innovation, to growth and stability, be mindful of inflection points and team composition along the way.
Operationalize
Along with maturing your product development practices, you also will want to maintain a culture of shared responsibility. This is where DevOps principles come into play. Google has shared their implementation of DevOps called Site Reliability Engineering (SRE), and many organizations have adopted these practices.
While it may not be necessary to have a separate team or function, minimally staffing teams with engineers who have the propensity for operations, monitoring, and automation will pay dividends. We will explore these concepts in further detail when we dive deeper into the example startup, and defining its architecture and cloud infrastructure.
Planning for growth
As a startup grows beyond the small founding team, so does the complexity of communication, and governance, as illustrated below.
Companies have solved these scaling challenges by recognizing inflection points of their business, and forming dedicated, mostly-autonomous, teams to tackle specific challenges.
A great resource on scaling your software team, for example, is this blog post by Seth Blank, which I’d highly recommend reading. Blank warns that processes, and in some cases even the people, who helped get the company off the ground can at some point become a hindrance to its future growth and scalability, or are best pointed towards “the next thing”. This is where McKinsey’s 3 Horizons becomes relevant toward future strategic planning. Conversely a different Blank, Steve Blank, argues why it’s no longer valid today.
There is another resource called “Team Topologies” that provides a practical, step-by-step, adaptive model for organization design and team interaction. The focus is on streamlining the organization, and platform, with what they refer to as thinnest viable platform (TVP).
Another concept I find useful for scaling an organization, or product, is AKF Partners Scale Cube. I first learned about this many years ago when it was referenced in a book titled “The Art of Scalability” I purchased for my team leads at a prior startup — it’s also another useful reference any time, jumping to relevant chapters as needed.
Nearly everyone can agree, however, as your company continues to grow, and forms dedicated teams, the necessity for governance and well-defined processes, documentation, mentoring and training grows with it. I’ve witnessed many organizations at this stage recently also seeking guidance on how best to structure their cloud infrastructure to efficiently accommodate their multiple teams. We will address that later in this series.
In part 2 of this series, we explore putting these pieces together to design, build and scale a fictitious online dating software startup.
Thank you for reading this far, and I hope you enjoy part 2.
