Getting the Most Out of Investment Time

Plenty has already been said about “investment time”:

• Some engineering teams set aside Fridays each week for their employees to work on something outside the scope of their billable duties.
• For many employees at such companies, investment time is a cherished perk of their employment.
• Setting aside a day each week can reduce stress, since it adds margin to a person’s week (They can use investment time to catch up on a project if it’s running behind).
• Investment time can be a great way for people who usually work on different teams to spend some time together.

Investment time can be a wonderful boon to a company’s health, and I’ll always fight for making it part of a team’s culture. But it’s also possible to undermine investment time if management is careless with its application.

If your company has investment time, but you’ve felt like it isn’t as great as you’d initially envisioned, some of what follows might resonate. I’ll also go over how teams sometime miss opportunities to make the time even more valuable.

(And if none of the below resonates, great! Sounds like your team is doing it right.)

Investment time is an added responsibility for managers (but it’s worth it).

Sometimes investment time is perceived as “free” time for individuals to do with as they see fit–as long as they’re not overtly wasting it. This approach may work for some employees, but it will fail for others. Importantly, it will probably fail silently.

For it not to fail, or for it to properly “raise errors” when it fails, management needs to accept the added burden of helping their team use investment time well. Obviously, employees who are less self-directed than others will struggle with freeform investment time. But less obviously, junior team members who are self-directed might still flounder without guidance.

Allocate enough time, or the investment will not pay off.

I know of some companies that only set aside 2-3 hours per week, or only 1 day per month, for investment. That isn’t enough time.

A weekly block of 3 hours isn’t long enough to make meaningful progress building something (or, if it is, it’s barely enough time). Worse is that your team members probably won’t be fully productive for the remaining 4-5 hours due to the context switching. Commit the full day to investment time, so your team doesn’t have to deal with the afternoon context switching.

Companies that set this little time aside tend to use it for short, hastily prepared presentations about new tools/techniques that someone has recently been learning about. Such presentations can be hard to glean and/or retain value from. This model also encourages breadth over depth–possibly to a fault.

Investment time is an ideal context for pair programming.

Regardless of whether your team pair programs regularly during billable time or not, consider defaulting to pairing during investment.

This is especially useful as a mentorship model, where one developer is paired with a more senior developer. Often, even for teams that aspire to pair regularly, this model can be a hard sell during billable work time. But during investment, the short term loss in speed is more palatable.

It can be particularly effective for the more senior developer to “pilot”, while the more junior developer actively observes and participates by seeking an understanding of the senior’s approach. Senior developers often don’t realize how much they actually know. Some of their best habits are only revealed when a less senior person who’s watching them stops them and asks, “Whoa–why/how did you do that?”.

Prioritize depth over breadth.

Developers don’t seem to need any help broadening their awareness of the tech ecosystem. Twitter, Hacker News, podcasts, and other media fling new topics at us constantly.

Depth, however, can be elusive.

As an experiment, ask the senior devs on your team how they got to be seniors. If they have some vital skill or knowledge, ask how they acquired it. I’ve found that a lot of senior developers were the only developer–or one of a small few–on their previous team. They gained senior-level skills by having no choice but to slowly deepen their knowledge as their product’s complexity grew. Their crucial strategy was probably not building a toy app for each new JavaScript framework they were curious about. (They may well have done that, but so have lots of developers stuck at junior/mid levels.)

In an ideal workplace, billable time might be perfectly balanced to include mid-level devs in higher-level decisions and tasks, so they grow into seniors. In practice, this is rarer than it ought to be.

Begin a long-running project.

Using investment time for tech talks or learning new technologies by building toy apps wastes a precious opportunity to level up your developers. Instead of encouraging your team to learn new technologies, begin a long-running project. Whether it’s an internal tool or public-facing, build its spec based on customer input and plan to deploy it as you would for any other product.

Be ambitious. Intend for the product to demand solutions to complex problems, and expect the project to take months–not weeks. In the beginning, there might be very few challenges with a product of this nature. But over time, maintaining the product will create opportunities for learning that are almost impossible to find elsewhere. And since the product is meant as a side project, your less senior devs can deepen their skills slowly without feeling the pressure of an aggressive timeline.

Watch for pain points.

As work continues on this new side-project, observe what people are asking and complaining about. If a new contributor is trying to get the app running locally but can’t find setup documentation, there’s a good chance your team’s culture of documentation needs improvement. If tests/builds/deploys aren’t streamlined, that’s another part of your team’s culture that you’ve learned about.

Failure to properly operationalize a low-stakes project may be a sign that your team’s core operations need some love. Expect investment time to surface inefficiencies and insecurities. There is a lot to learn from observing dysfunction.

Properly implemented, investment time can dramatically boost your team’s culture of organic skill growth. Just be watchful that some members’ needs aren’t slipping through the cracks and that you’re taking advantage of more than just the obvious opportunities for value.

Thanks to Alexandra Millatmal, Beth Haubert, Michael Herold, and Rahul Gupta for reading drafts of this.