Making the choice to scale your technology platform is a journey, not a destination | Part II

In the technology world, ambitious and innovative teams often reach their capacity. Successful companies have no shortage of asks. The answer is scale. Here are five steps to scale your technology platform.

Check out the first installment on scaling your technology team.

Step 1: Establish a foundation of continuous delivery.

This step is a foundational prerequisite: a continuous delivery, continuous integration (CI/CD) release process capable of handling parallel versions simultaneously.

Have you ever read a book about investing that starts out, “first pay all your debts. If you have debt, then you don’t have money to invest.”

It’s the same with CI/CD. If your software team is not able to handle multiple code branches to orchestrate consistent, iterative releases of your product then they aren’t ready for any of the other steps.

If you have CI/CD pipelines, try to shorten the time and breadth of features in each release. The goal is to automate the release of each encapsulated feature, every completed piece of code, as it finishes.

Extensive literature exists on this topic from experts in the field and they are worth reading.

Step 2: Measure capacity, velocity, quality and scope changes.

I was thinking about Elon Musk’s request that government workers email him a summary of what they accomplished that week. The US government employs 2.3 million people.

Fortunately, there’s a better way to do this with technology teams.

Using Agile methodologies, we measure the feasibility of the story, its complexity and effort, in story points. We look at the story point trends every sprint: Is velocity up or down? Why? If it’s down, was anyone on vacation? If it’s up, was there an increase in bugs for that release? We measure the number of times stakeholders change the scope (see the step 4 for more on that).

Technology leaders need a data-driven way to measure output. It doesn’t make sense to scale a team if the output isn’t increasing commensurate with the resources.

Coupled with CI/CD release data, this step builds on the data-driven foundation to align people metrics with the technical metrics.

Step 3: Eat your own dog food. Drink your own champaign.

Steve Yegge’s Google Platforms Rant is my favorite blog post of all time. He explains in plain terms why scaling a platform is a combination of great customer experience, what he calls accessibility, and great developer experience.

Scaling your team’s delivery has a logical cap at the level of resources your company can commit. Once you’ve hired all the available headcount, added contractors to the limit of your budget, the only way to increase productivity is to make a platform attractive for others to build on top of.

Facebook is successful because they built an entire constellation of products by allowing other people to do the work. – Steve Yegge

There are lots of ways to do this. You don’t have to work at FANG company. It can even be done with internal or back-office software.

Bezos realized that he didn't need to be a Steve Jobs in order to provide everyone with the right products: interfaces and workflows that they liked and felt at ease with. He just needed to enable third-party developers to do it, and it would happen automatically. - Steve Yegge

In Steve’s article, Amazon did this by making all their data available via API. You can also welcome other engineers in the organization to develop on your platform, similar to the open-source model.

The CI/CD process is critical here because once development expands beyond your team, the automated quality and security testing you baked into your pipelines in Step1 will save you from having to troubleshoot other people’s code.

Step 4: Identify flexible and adaptable features and start on the next logical capability.

Do you ever feel like your team is doing the technology equivalent of moving furniture around a room until your business users are happy?

“Put the couch in the corner… no wait, put the couch in the middle and the TV in the corner… hold on, can you put the TV on the wall? … no wait put it back on the stand…”

One of my teams tracked business user change requests during each sprint and the average was 87%. A technical team can’t deliver one capability in that environment, much less scale.

When this happens, step back from the capability details and imagine building for the user to leverage in multiple ways. To go back to a furniture analogy, a home builder would not build a bedroom to only be a child’s, single-bed, room. They build it so it can be a guest room, an office or a playroom.

In step 3, the technical team is anticipating what other builders need. This step is about anticipating what your customer needs.

Don’t wait for users to spell out each step. Anticipate the logical next ask from the user. Build it in from the get-go. It will save your team time later and improve user adoption.

Step 5: Drive adoption and remove friction at scale.

You’ve got a release train updating your product consistently. You’re measuring the output, ensuring quality in each release, even as you increase velocity. Your heaping dog food on your plate: Opening your platform for other developers and sharing your data transparently. You’re anticipating users’ needs and proactively building solutions.

Hopefully, this step drives itself.

When software -- or idea-ware for that matter -- fails to be accessible to anyone for any reason, it is the fault of the software or of the messaging of the idea. – Steve Yegge

Put yourself in your user’s shoes.

Literally.

If you are a retail company, work in the store for a weekend.

A software company? Hold the support pager for two weeks.

Use the direct interaction with your users to foster a sense of community.

I led a product and engineering team for an internally facing content management tool. We did all the standard training, videos, run books and support. But our most effective strategy for adoption was the community of users who loved the product.

We created a Slack channel where anyone could ping the team for help. We would all take turns responding with screenshots or jump on a call with the user and walk them through the solution.

The white glove support generated a sense of community amongst the early adopters. As more and more people used the platform, our early adopters graduated to power users. The power users began answering the new users’ questions.

We had scaled our fanatical support by fostering a sense of authority and ownership amongst our power users.

Conclusion

Scaling a technology platform is a journey, not a destination. By following the five steps outlined in this article, you can put your team on the path to success. Strategically scaled platforms are the engines of sustained innovation and competitive advantage in the modern technology landscape. Celebrate your milestones, learn from your setbacks, and keep building.