We’ve all seen promising ideas and companies that failed to scale. There are many reasons growth phases are difficult, but not having the right technology at the right time is a critical one.
Even if a company has the right business strategy and team in place, achieving scale can often come down to how technology is managed.
I’ve led a number of successful technology renovations and transformations and found there is a dearth of useful content on the subject, and wanted to share what I’ve learned over the years.
There are a few dimensions that need to be addressed to prepare for and execute a scaling play successfully from a product engineering perspective. I will outline each one, the key patterns, anti-patterns, and illustrate them with personal examples. Over the next several months, I will deep dive into each area in follow up articles.
I hope this can act as a guide for others navigating these exciting and challenging phases of growth. So if you have had scaling experience and see anything missing or that you disagree with, please let me know!
Let’s start with some context — the most prevalent reason for a large renovation or transformation, especially at a startup, is to support rapid growth the existing platform is unable to support, or to pursue opportunities that cannot be grabbed with the existing architecture.
Build and Operate an Exceptional Growth Team
In order to achieve anything excellent, you need an exceptional team operating in a high performance culture. Chances are you’re either inheriting a team or have a team in place that may have been great for the previous phase of the business but cannot scale.
You may also have insufficient resources, the wrong mix of resources for the next set of milestones, or both.
Being very clear on the capabilities and therefore, the organization you need for the next 12–18 months of the business plan is critical. With this in place, you can map out the roles you need to achieve the mission. Comparing existing team members to these profiles can be painful as you realize you have less of what you need than you thought, but being intellectually honest is important. If you attempt to move forward on things beyond the capabilities of the team you have, you will not succeed.
Loyalty is supreme, but it’s not great for anybody involved if you fail because you like someone on your team even though they’re not able to move things forward. And setting people up for failure is never good. So transition the people that have to move on with a high degree of dignity and respect. And don’t lose the great relationships you’ve built. Help them find their next opportunity and warmly invite them back if there’s a fit in the future.
At Axial, the largest online capital market empowering the growth and success of private companies, I had to transition almost half of the team I inherited to prepare for the next level of the plan. The people who transitioned added a lot of value to the business during their tenure and were good people — both of which made this difficult. But it was necessary. And the resulting team was excellent after about 8 months of recruiting.
Identify and Remediate Major Scaling and UX Problems in the Current Platform
If you don’t look under a particular rock, you’re going to get bitten by what’s lurking below. I’ve been caught by unexpected performance bottlenecks on at least one occasion. In that example, it slipped my mind to conduct performance testing when I joined the team and of course, we had a domino effect system outage due to too many concurrent users. This was despite the best intentions of my inherited team which had high confidence in the robustness of the system’s ability to handle a larger volume of users.
When you take responsibility for a new platform, be sure to conduct your due diligence. Everything from understanding the existing architecture and where it’s brittle, to load testing the system and testing the breaking points. Then based on the business plan, it’s relatively straightforward to map out when you need to tackle fixing each of them to support projected growth.
And don’t forget about any large user experience problems that might be negatively impacting conversion, renewals, or whatever is critical for your particular business model.
Define a Business Driven Target Architecture and Technical Roadmap
Beautiful technical architectures are pretty worthless if they don’t deliver the necessary business outcomes. This is a common pitfall and one which should be avoided at all costs. It’s a very expensive mistake to make and you’ll end up delivering something that you could give a nice technical presentation on but completely misses the goal.
So start with the business goals and architecture. Prioritize with your business colleagues the various bets you want to make. Then — and only then — craft a target technical architecture which allows you to deliver on the business roadmap.
Build flexibility in the areas with the highest degrees of ambiguity, but not too much flexibility or cost and time to market will go through the roof. Try to put constraints around each area of ambiguity to allow for easy pivoting within reason. And be clear with your stakeholders that if you end up going outside the constraints, it will cost more and take more time to make the change. When you frame this properly, I’ve never seen reasonable people not understand. You’re essentially de-risking expected pivots and being clear that unexpected pivots will cost more. The benefit is much faster and a lower cost delivery.
At Hello Alfred, we just completed a Component Business Modeling exercise which helped bring crystal clarity to our business and product roadmap. It’s now an invaluable tool as we make both high level business decisions and day-to-day micro-decisions. What at first may appear to be a engineering specific assessment can actually prove to guide the company at large and provide a clear language to talk about the business. A few very vivid examples are identifying places in the business that are performing redundant work, areas that could greatly benefit from manual process optimization, and discovering where there are major gaps in providing services you thought were covered. Returning to this map to discuss decisions keeps everyone directionally aligned and prevents functional cul-de-sacs.
For information on Component Business Modeling, see https://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf, a great overview.
Execute a Platform Migration
One of the most challenging things you will tackle is executing a platform migration without compromising existing business operations. And also while not having to build an entirely new platform at functional parity with a “big bang” approach in order to perform a magical (and almost never successful) cutover.
Instead, take a measured and thoughtful approach to building the new platform in parallel, vertical piece of needed functionality, by vertical piece of needed functionality — and with an insulation layer that allows both architectures to happily coexist for at least 18 months. Don’t fool yourself into thinking you will depreciate 100% of the soon-to-be-legacy system in less time than is practical under your current circumstances. It will be very tempting, but don’t do it! Being on the new platform is not the goal, enabling scale, or other key business objectives is. Don’t forget that.
At TravelClick, a provider of innovative solutions for hotels around the globe that increase revenue, reduce cost, and improve performance, we developed an entirely new architecture and implementation for some of our most business critical systems. And they had to cohabitate for a long period of time given the complexity — these systems handled nearly 1 billion transactions a month. Using the above pattern allowed us to do this very successfully, and also rapidly improve performance in a way that was immediately felt by our biggest customers.
As you determine the sequence for cutting over, keep at the center of your thinking how to deliver business results early that create tangible value for your customers. This not only benefits your customers but also creates accretive value for your company. Some examples are to start with the worst performing parts of your platform, the parts where you have concrete ideas on how to expand functionality but are constrained by the current system, and the parts where you can deliver an improved user experience for a core feature simultaneous with the migration.
Continuously Experiment, Test, Measure, and Evolve
No matter how well you visualize and plan; put constraints around expected pivot points; or execute on your platform migration, things will change. If you’re not familiar with the lean startup movement, study it. Whether you’re at a startup or not, it’s an excellent way to approach anything that’s not well established. And for that matter, it would be good to apply a lean, iterative approach to innovations on top of things that are well established.
Experimentation, continuous A/B testing, rapid customer feedback, focusing on the key metrics that genuinely matter, and taking action quickly to evolve your thinking and plan when things don’t go the way you expect are now table stakes for extreme success.
It’s very important to balance having a good upfront visualization of where you’re trying to go and to recognize the plan will change a thousand times before you’re done. If you do one without the other, you’re at best going to come up short relative to the potential.
This is an ongoing process and so my best example is right now. Both the product and the technical roadmaps at Hello Alfred bake in experimentation, tests, measuring results, and revising anything and everything as needed. All within the context of a very clear and shared ideal state that we’re moving to synchronously across all areas of the business every day.
Howie Altman is the Senior Vice President of Engineering at Hello Alfred. Alfred is a technology and hospitality platform focused on evolving the most important space in people’s lives: the home. The platform combines building management software with highly trained “Alfred” Home Managers to handle an extensive suite of services, allowing residents to focus on the things that matter most. Buildings get a differentiated experience in competitive urban environments; residents get a home that anticipates their needs and saves them time. Our Hello Alfred team has been publicly recognized by The New York Times, The Financial Times, Monocle, and Fast Company as thought leaders in the on-demand economy, following the decision to employ our Alfred Home Managers, complete with benefits, training, and the ability to move up in the organization, rather than hire 1099 contractors.