Cut Scotty some slack
Although I never watched much of the original series, I was a huge fan of Star Trek: the Next Generation when I was a kid. The series has a lot of memorable moments, but one of my favorites is from “Relics” (Season 6, Episode 4).
In the episode, James Doohan reprises his role as the Original Series’ Chief Engineer Scotty—but now older, retired, and barely relevant. Predictably, the writers use every opportunity to contrast him with Next Generation’s chief engineer, Geordi. After an exchange in which Geordi tries to shake off Scotty’s “help”—saying that he doesn’t have enough time to get Scotty up to speed—Scotty chooses to reveal the secret behind his reputation . (43 second YouTube clip; you should absolutely watch it)
Scotty: Do you mind a little advice? Starfleet captains are like children! They want everything right now and they want it their way. But the secret is to give them only what they need—not what they want.
Geordi: Yeah, well, I told the captain I’d have this analysis done in an hour.
Scotty: How long will it really take?
Geordi: An hour!
Scotty: Oh, you didn’t tell him how long it would really take, did you?
Geordi: Well, of course I did!
Scotty: Oh, laddie, you’ve got a lot to learn if you want people to think of you as a miracle worker!
Despite the humor of this scene, it can be tempting to dismiss Scotty’s advice: his smug air and conspiratorial delivery make him appear contemptuous and dishonest towards his colleagues. However, underneath these attitudes is an important organizational principle:
Any well-designed system needs some slack.
What do you mean by “slack”?
Consider an example that’s a little bit less sci-fi: an estimated 78% of Americans live from paycheck to paycheck . While these folks may have enough cash to make ends meet, their expenses are so close to their income that little or nothing remains for long-term considerations like savings or investments.
A household in this state can function normally—and with apparent health—for quite some time. However, because there’s no extra room in the budget—no slack—relatively small setbacks can turn catastrophic. One consequence of this is that nearly 40% of Americans would struggle to cover an unexpected $400 expense . When families find themselves in this position, the result can be spiraling debt or even homelessness.
Systems of all kinds—budgets, schedules, factory production lines, starship maintenance, etc.—exhibit the same property. When run at—or near—full capacity, even small errors snowball into catastrophic failures. Deliberately running at less than full capacity is the key to avoiding this fragility. That’s slack.
Scotty’s secret
And this is where Scotty’s strategy comes into play: he takes responsibility for his own slack by always providing inflated estimates. Most of the time, these estimates sound reasonable and pass without being challenged, leaving him with additional discretionary time. However, in a crisis, he has the capacity to deliver well under his estimate.
But the secret to this strategy is what Scotty does with his slack: he invests it in maintenance tasks and self-improvement. (Case in point: when confined to quarters for insubordination, he once gloated about how this would give him time to catch up on his technical reading ) This sets up a virtuous cycle: over time, these activities allow him to complete his assigned work even faster, allowing him even more discretionary time without needing to adjust his estimates1. Ultimately, he gains the ability to complete tasks much faster than an “ordinary” engineer, leading to dramatic2 results in a crisis.
That’s what gives Scotty his reputation as a “miracle worker”: not simply inflated estimates or scheduling sleight of hand, but rather jealously guarding and intelligently using his slack time outside of crises.
But doesn’t that seem…sort of dishonest?
Perhaps the biggest weakness of Scotty’s advice is that he positions it as some sort of deception, but this is not an inherent part of the strategy.
Early in my career, I worked at a company where the engineers had daily contact with the ceo—who was, himself, a former engineer. One day, in a sort of impromptu mini performance review, he instructed me to start spending time—at work!—reading technical blogs, and told me to start by asking the senior engineers to share their opml3 with me.
I’ve spent some number of “work hours” learning nearly every week since then, and I’ve never had a discussion in which I’ve explained, justified, or negotiated this number: I simply managed others’ expectations so that I would have enough time to do it. Over time, I even expanded my interpretation of the original charter by including things like learning by engaging in unassigned maintenance and refactors of existing code. There’s nothing remotely dishonest about this: as long as I was at that job, I was literally following the instructions of the ceo; since then, I’ve made no secret that I maintain quite a bit of discretionary time.
One could argue that in many contexts, discussing the specifics of how much time you need for personal development and maintenance may even be counterproductive. Often, you’ll be the one with the most insight into how much effort is necessary for those activities (especially personal development). In such cases, asking for feedback or permission regarding how much time to spend adds no value: you’re better off claiming the time for yourself and managing others’ expectations accordingly. An additional benefit of this approach is that it pushes you away from focusing on “output” (how much time you’re spending on tasks) towards “outcomes” and “impact”. (the value you produce with your time)
How much time is too much?
One potentially intimidating aspect of this strategy is that it forces you to claim a lot of responsibility for how you spend your time. How do you know if you’ve struck the right balance?
Ultimately, there’s no way to know with complete certainty whether your current time allocation leaves too much or too little time for assigned tasks—and this is true even if you’re spending all of your time on assigned tasks. You should expect to get this balance wrong at least some of the time, and it’s important to frequently re-evaluate your choices. Are you heading into the busiest time of the year? Do you have looming, externally imposed deadlines? Maybe turn your discretionary time down a notch. Is there a period in which lots of folks take time off and no one expects much progress? Go play with something new!4
Through a lot of experimentation, I’ve developed a pretty strong internal sense of whether I’m making “enough” progress on assigned tasks, and I’ve tried to tune this sense so that it’s just a bit more pessimistic than that of anyone that I work with. (meaning that if I feel comfortable with my rate of progress, then I probably have more room for learning and maintenance) The sentiment of your teammates—as well as formal performance reviews—can be useful trailing indicators to help you train this sense.
Start building slack
“Won’t my team notice if I suddenly block out a large chunk of discretionary time?”
Yes, they will. And that’s why the best play here is to start small: spend a little bit of extra time reading an engineering blog this week. Go a little bit further out of your way with a refactor than you normally would. Not only are these little changes unlikely to generate much notice, they also give you the opportunity to start communicating about the outcomes of the time that you spend this way, which will generate trust with your teammates—allowing you to “get away” with taking slightly larger blocks of time and to start your own virtuous cycle.
If you need some more specific ideas, try some of these:
Ask a more senior coworker about the books, blogs, or social media accounts that have had the greatest impact on their thinking.
Find an extensibility point in a module you’re working on that’s no longer used—and get rid of it.
Clean up some inefficient database query patterns that are just slightly out of the way.
Investigate the history of a confusing bit of code, and either add some comments or improve its design.
Create a long Slack thread about something you’ve learned—or something that confuses you.
Start claiming your own slack, and keep experimenting with learning and maintenance. Given enough time, folks might even start to think of you as a “miracle worker”.