We Call It 'Run the Business'
Tags: learningculture, lean, agile, softwareengineering
Published: 2019-04-05 23:31:52

---
title: We Call It 'Run the Business'
published: true
description: Run the Business is all about an organization's professional growth.
tags: learning culture, lean, agile, software engineering
cover_image: https://thepracticaldev.s3.amazonaws.com/i/6wq2me7ex2zh5y4q5hyh.jpg
---

## TL;DR
`from current_employer import run_the_business`
**Run the Business**: *Explicit time given to a creative worker that is dedicated to sharpening the professional capabilities of the organization during core business hours.*

> “The only sustainable competitive advantage is an organization's ability to learn faster than the competition." - [Peter M. Senge](https://en.wikipedia.org/wiki/Peter_Senge)

## What Is **Run the Business**?

In other tech companies, it is referenced as "[Saw Time](https://dev.to/dev3l/we-call-it-saw-time)" (OnShift/2.5%), "hack time" (Spotify/10%), "20-Time" (Google/20%), and "10-Time" (Explorys, an IBM Company). These organizational efforts typically focus on individual contributions towards company innovation.

It's not working on technical debt stories or spikes...

**Run the Business** is all about the organization's professional growth. Every week, employees are given time to pursue learning and other activities related to increasing organizational capacity in some means. Providing professional creative thinkers with opportunities to learn is akin to giving geniuses brain steroids.

We have top down management buy in. This is the linchpin that creates a fertile safe zone in which a learning culture can begin grow and prosper. The **Run the Business** is fully approved and endorsed by engineering.

> Outside of actively resolving a Sev1 or Sev2 ticket, individuals will not to be pressured to work on his/her day-to-day tasks during **Run the Business**.

## Why **Run the Business**?

My current employer is a startup based in Cleveland. We are in the middle of a fundamental shift away from reckless speed, now steering towards craftsmanship and delivering value.

I imagine all companies go through ranges of similar growing pains. In the beginning, speed to market is the key. It keeps the company alive. Then, at some point in the future, outsiders to the engineering department, like marketing or upper management, begin to wonder, why do simple features take days/weeks instead of hours like they used to.

Failed products, unsuccessful application rewrites, surviving turnover, and launching semi-successful products well beyond target dates, become battle scars that tenured employees wear with pride. It's only been one year...

Then something magical happens. We realize the "legacy" application we play in needs to be handled differently. We learn to how to relentlessly write automated unit tests, refactor safely, and work (add features) within the codebase by keeping in mind concepts like the strangler pattern, feature toggles, and lean validated learning.

*Imagine with me*:
- That time you tried to describe how a field in the database could toggle code execution flow for enablement of features post application deployment? ([Feature Toggles](https://martinfowler.com/articles/feature-toggles.html))
- The pain you feel every time a you write a comment that feels like a hack to describe a messy algorithm. ([Clean Code](http://ricardogeek.com/docs/clean_code.html) - [My Moment](https://twitter.com/dev3l_/status/873998216819347456))
- When you tried to explain what legacy code means in a objective way? ([Legacy Code](https://en.wikipedia.org/wiki/Legacy_code) => Modern interpretations)

These are a few of my specific experiences.
I know you have similar stories of your own.

With my fifteen years of relentless professional development, I still have so much room to grow. Thanks dad for letting me have the afternoon off to make *us stronger*!

## What Is The Length of **Run the Business**?

*4 Hours*

We decided that 5% of each team member's work time one week company growth and innovation. Individuals work 40 hours a week. As a result, we conduct capacity planning with this diminished capacity in mind.

## When Is **Run the Business**?

*Friday*

For us, this is a common sweet spot for all teams. Closing the week then planning for the next tends to typically wreck productivity that day already. In addition, it enables opportunities for collaboration against **#ourgoals** if we can all agree on a consistent cadence.

## What Is Within Scope of **Run the Business**?

Anything and everything about learning and skill development that can be tied back to the individual's profession such that it enriches the company.

I am working on machine learning engineering capacity to predict the head count required to meet yearly objectives! **#20190405**

## Tracking **Run the Business**

*The individual is not required to officially track this time, yet accountability in some form is encouraged.*

We encourage radiation of activities to increase knowledge sharing and opportunities for group activities. Make it a topic of conversation around the (remote) office!

There is a Trello wall, in which people can post sticky notes on what they intend to do, what they are doing, or what already has been done.

## Conclusion

This is an experiment. We tried to imagine the shortest amount of time in which someone could truly do more than scratch the surface of any individual topic while not having a critical impact in business commitments.

We state we are professionals. We act in such a manner that is professional.

*We learn because we love solving problems.*


NOTE: All opinions expressed on this blog are solely those of Justin Beall and are in no way affiliated with any other organization or institution.