A growing company is a great place to be. It’s fun to see customer acquisition rates and revenue increase. You’re excited for each new day, each new customer, and each new employee that joins. You’re working like crazy, but it doesn’t feel like it.

And then it happens.

Your team isn’t getting as much done. Quality drops. Employees feel stuck in maintenance roles. It’s a very common occurrence in a growing business and it’s one that you can’t solve with technology alone.

You’re heading down the straightaway and it feels great. That corner you’re approaching is going to be a challenge. The good news is that you can prepare for it. The bad news is that everyone may not make the turn with you.

Below are the top three things that you as a CTO must do — all non-technical — to help a company survive rapid growth. By the way, they’ll help you survive it, too.

Pay Attention to Process

I used to think process was boring. That it stifled creativity. I was a young man, a software developer. And I was quite wrong.

It wasn’t until I worked for a great manager, one that understood techies and was one herself, that I learned. Process is not only necessary, it enables growth.

[The article was adapted from Kevin Carlson‘s original blog post]

Defining a process takes the guesswork out of knowing when something is complete. At a meta-level, each process should mesh with the next stage of work so that handoff errors are minimal.

Here are a few places where processes can usually improve:

• Development: How does a story, a bug, an enhancement flow through your team? Who handles a task and when? When is it done?
• Communication: What events do we need to communicate? When? To Whom?
• Hiring: What roles do you need? How are they approved? Who is interviewing which candidate and when? How are we communicating the each candidate and hiring manager?

Process is nothing more than describing how things move from concept to completion. It’s also not static. Review the effectiveness of a process and make changes, as needed.

Process helps teams align on how things work and will help the entire team function in a focused way.

Define Metrics and Share Them

Every development team I’ve worked with has shied away from publishing metrics. It’s a common theme.

Here’s how development teams learn to dislike providing data:

• Development publishes a release date.
• There are unforeseen technical difficulties or unplanned additions.
• Development misses the release date.
• The business blames development for being late.

Common result? Yes, but the on-time metric doesn’t tell the whole truth. Metrics can tell the entire story, if you track a holistic set and report on them.

I worked with a team in the past that was being criticized for Sprint velocity decreases. When we began tracking hours, it was evident that the decrease in velocity was due to the unplanned. Bugs, enhancements, and other issues were devouring an increasing part of each Sprint.

When the management team had the entire picture, it was clear that a lot of people played a role in the delay. So they took steps to make things better.

Anyone can stand on the accelerator and get a car to top speed. If speed is your only focus, good luck getting through the next turn.

Everyone wants to track velocity. The problem is that, in and of itself, it’s meaningless. You should also track metrics that uncover issues with quality, bottlenecks, and unplanned events.

It’s true — what you measure is what matters. So measure things that tell the whole story, not a fraction of it. Then, tell the story to everyone.

Hire for the Long-Term

It’s normal to have a cafeteria-style list of skills when looking for a new hire. It’s important to make sure you hire people that have the skills to do the job. But watch out for the pitfalls with taking only that approach.

I’ve participated in many interviews with clients that are more like a pop quiz than an interview. If your goal is to figure out how much someone knows about a given technology, sure, ask the questions. But if that’s your only goal, you are focusing on short-term benefit at the expense of long-term value.

Yes, they have to be able to ramp up in a reasonable time frame. No, they don’t have to have encyclopedic knowledge of an SDK (they publish that stuff online, you know).

Focusing on the skills of problem solving and communication provide longer term benefit. Avoid the temptation to skip this bit when technical needs are critical. Also critical, make sure your recruiting process is communicating your values.

During the recruiting process, ask questions that drive inquiry. Find out if the candidate asks thoughtful questions or if they jump right into code? Do they prefer the details of NodeJs or do they ask about the user?

Make sure to ask questions that can uncover problem solving ability. Experiencing how a candidate thinks through a problem, and how they communicate with others, is the best indicator of long-term success I have found.

Enjoy the Ride

Hard work, great colleagues, investors, and advisors contribute to building toward rapid growth. Enjoy that and realize that rapid growth may require a shift in focus.

A CTO’s role is one that needs to change as the company moves from one stage to another. You may have been the superstar coder and founder that built everything in the early days. Now, you have a team that requires a different focus and skill set.

Focusing on these non-technical tasks will help ensure you survive the transition.