As soon as a product starts to establish its fit in the market, both the CEO and investors are going to start ramping up growth. That means lots and lots of hiring, often in the product and engineering teams.
When the heat on hiring is turned up, CTOs and VPs of engineering often seek to improve one of the most important (but difficult to track) metrics in their teams: time to productivity.
In tech startups, it's imperative to track key metrics as you build a team and prepare to launch a product or service into the world. But how do you know which to track? And, more importantly, why?
What Is Time to Productivity?
Considering that developers’ time to productivity has a direct impact on an engineering team’s velocity — which has a direct impact on how quickly a product can ship to market — it’s imperative to learn how to measure and improve this metric. The alternative is a headache at best: The company is ramping up, hiring attempts to keep up with demand, and then the engineering team’s velocity takes a steep dip at precisely when it should be increasing as new hires get up to speed.
Time to productivity is often an elusive piece of information to qualify, or at the very least it’s one that isn’t well understood or easily quantifiable. We can’t have hard numbers for everything, even if they’re important, but we can pinpoint what is or isn’t working simply by paying attention to a few key metrics.
There are many ways that people try to measure time to productivity, but many of them look at the wrong metrics, which can be misleading or demotivating. Counting lines of code is a fairly recognized form of quantifying the rate at which a developer gets up to speed, but there’s an inherent flaw: More code is not necessarily better.
While it is easy for non-technical managers to understand workflow from a high level, it’s an abstract metric that encourages practices like copy-and-pasting and discourages refactoring to simplify bloated code. In the right hands, it’s good to track, but it isn’t an effective way to measure time to productivity.
What Isn’t Working?
Historically, it’s difficult to even figure out what exactly causes slow time to productivity.
-
Is it a junior person that should be replaced by a seasoned engineer?
-
Is it simply a bad culture fit?
-
Is it lack of proper onboarding?
-
Is it all of the above?
I’ve frequently heard the argument that hiring better, smarter people can fix this problem. But it can also lead to an unhealthy, unusually non-diverse team as people reach into their direct networks and connections rather than opening up to a wider pool of talent. It can also result in bad engineering practices like knowledge hoarding or ego-driven engineers who don’t work well on a team.
So what can we do to optimize for faster time to productivity? The answer is simple, but it requires building the proper infrastructure for success. That means developing better onboarding, dynamic documentation and asynchronous communication.
But let’s look back a few decades first. In the 1950s, Dr. Donald Kirkpatrick developed a model for “training to the business,” introducing a four-level pyramid for analyzing and evaluating educational programs. It may seem overly simplistic by today’s deeply analytical standards, but the results are notable: The Kirkpatrick model provides a simple, useful framework for assessment by matching output to outcome and checking for success.
Since 2014, I have architected and developed onboarding systems for large companies, and I’ve worked through the complexities of technical organizations, pinpointing what each individual team member needs. Kirkpatrick’s model is useful because good onboarding will get you to Level Four — and a positive impact on the business — more efficiently. Good, well-structured onboarding helps a new hire get productive faster by giving software engineers the right scaffolding.
The Dismal State of the Engineering Industry
If onboarding is directly related to time to productivity, it’s important for us to recognize the dire state of onboarding across the entire industry. The average turnover rate of software engineers is roughly 15 percent, and the churn driven by onboarding is a roughly $22 billion problem in the engineering industry, according to the Bureau of Labor Statistics’ data on the average salary for engineers. One-third of engineers seek alternative employment before onboarding completes, and the average tenure for a software engineer is 18 months. It’s dismal to put it in those stark terms, but that’s where the industry stands.
How does your organization handle onboarding? According to a 2010 study by the SHRM Foundation, a successful onboarding program can provide greater job satisfaction, lower turnover and higher performance. We’ve got to build better onboarding systems.
Getting software engineers up to speed requires a lot of information. I’ve seen teams take seven to nine months to get new hires up to speed. That hurts the team’s velocity, which is critical when ramping up toward launch. When we can get new hires up to speed in one month, rather than seven, teams are happier and healthier — and they ship better products much faster. Here are three things you can do to optimize for faster time to productivity.
1. Developer Onboarding
This is one of the most important aspects when it comes to optimizing time to productivity, and it can also be the lowest-hanging fruit with intelligence tooling. Getting a new hire up to speed quickly is nearly impossible if you don’t have the scaffolding or learning model to support them as they acculturate to new concepts and expectations. Onboarding at the functional level is much more than simply saying, “Welcome to the workplace, here’s your employee manual.”
Consider this: The onboarding process, which is often unfairly left in the hands of HR departments, has to cover four unique areas:
-
Product
-
Process
-
Tooling
-
Professional expectations
HR and L&D aren’t typically equipped to source, build and maintain the right context at the right level of technicality for function, developer-centered onboarding.
The topics in these four areas can range from breaking down communication barriers for new hires — with a buddy system to set proper expectations around processes and goals. How successfully a new member is onboarded directly reflects the likelihood that they will learn quickly, feel comfortable and stay with the company longer. You don’t want your new hires looking to leave while they’re getting caught up.
2. Dynamic Documentation
When was the last time you updated your company’s documentation? If you’re like most companies, it’s probably been a while. It’s natural for documentation to get “stale,” frequently because things in engineering change rapidly, and it’s tough for engineers to remember or find the time to keep everything updated. Internal docs often take a backseat to more exciting work — like sprinting toward a product launch. Dynamic documentation allows for constant change by integrating underlying code into the documentation (instead of the other way around), and it ensures that when changes are applied to date — or the code itself — documentation is always up to date.
Despite these concepts having been introduced in the early 1990s — forming a through line from Jon Claerbout’s “Reproducible Research” and Donald Knuth’s concept of “Literate Programming” — it’s still rare today that companies take the time to develop dynamic documentation rather than a more common “pile” of always-slightly-out-of-date onboarding checklists.
New ways of thinking around keeping documentation updated automatically helps engineering teams build scalable processes like onboarding so that their team can run quickly. The plus side? You’ve only got to build out dynamic documentation once, where standard documentation is out of date the moment you hit “publish.”
3. Asynchronous Communication
Office culture is going through momentous changes. As tech companies embrace remote and hybrid workplaces, developing new styles of communication between team members is crucial. Remote-centric communication processes and systems can help foster a strong sense of culture at the same time that they help teams maintain the healthy velocity they need to get to speed quickly.
Remote team-management requires more communication than in-office team management does, because when you’re working in person, communication happens organically (by the water cooler, walking by someone’s desk). But in remote teams, communication becomes more intentional. You don’t accidentally end up in someone’s Zoom room for a five-minute chat that leads to real problems being solved.
Learning great communication without constant video chats or real-life meetings helps teams normalize over-communication that keeps everybody on the same page. It's easy for new hires to get trapped in a silo with their heads down over the keyboard for hours, so it’s imperative that we focus on the big picture rather than the daily tasks.
If you want to foster a positive, empowering work environment, you must create a social structure. We’re adapting to asynchronous communication, but it’s not our natural state — it takes practice and requires a shift in company culture, but it bridges the gap between engineers feeling isolated and thriving with a team. Mastering asynchronous communication can keep everybody on the same page, communicating happily and avoiding burnout from too many distracting Zoom calls.
The Takeaway
Time to productivity is the key to ensuring that there’s no dip in velocity in the road toward a product or service launch. When the stakes are high — and they always feel high during a product launch — you’ve got to understand what you’re trying to improve before you can improve it.
Streamlining the developer onboarding process, embracing dynamic documentation and mastering asynchronous communication are three of the most successful ways a company can improve time to productivity and build a team that is not only more efficient, but happier, healthier and more likely to stick around for the long haul.
