Welcome to DevChat #18!
Here's what's we've got for today:
- 🧵 Slack time
- ⚙ Typescript template
🧵 Slack time
One of the practices we've settled into at Bscotch is to ensure "Slack Time" for our full-time employees. The idea is pretty simple: if we keep piling responsibilities onto a person, such that every moment of their day is going into production, then they don't have time to improve their work processes or learn new things, and whenever the workload spikes due to a change in studio needs no one has enough time available to deal with that.
Let's take QA as an example. We're always doing QA, since we're constantly updating old games and working on the next one. But just how much QA we need varies every week and by which part of the dev cycle we're in.
If we're in early development on a new game (like we are right now) and have a heavy design week, there might not be any new builds to test. If that coincides with a week where we aren't updating an old game, or the update is super minor, then there aren't many testing needs for the old games either.
By contrast, in the lead-up to a launch we're making builds constantly while we work out final kinks. Since we sim-ship to all platforms, any change to the game generates at least 6 different builds that all need testing. And in the lead up to a launch we have to get through platform cert, which often includes a handful of rejections and consequent tiny updates.
The point being, QA in our studio can range anywhere from "OH NO THERE ISN'T ENOUGH TIME IN THE UNIVERSE" to, "Hey... uh... anyone have any builds for me?"
The same is true of administrative and marketing work. In the 6 months ahead of a launch there is an enormous amount of work to do in those domains. And it just keeps getting heavier until launch day. In contrast, in early development of a new game there's very little to do in those domains at all.
One way that companies deal with this is to hire up and fire down at each stage of development based on what kind of roles are in the heaviest demand. The games industry is notorious for this. While this approach, if somewhat disturbing, makes a sort of business sense, it is super short-sighted. If you don't keep employees around for the long haul, you're constantly losing institutional knowledge and industry goodwill. Plus, onboarding new employees is extremely costly and risky.
Another way is to move people around to different projects. For big companies that work on multiple games at once, staff can instead be shifted to different projects as their roles become more or less in-demand based on what's going on in each project. This can be a solid approach for companies that have a lot going on, though creates a lot of inter-project conflict about personnel allocation. Management would have to be very good to keep the whole company from descending into chaotic in-fighting.
Yet another way is to cross-train. For example, when your QA needs are low you could have your QA team shift some of their time over to other aspects of the work. This helps to deepen institutional knowledge, and people having awareness of multiple aspects of the work is always a good thing. Cross-training can also create some redundancy, and thus stability, because people can fill in for each other even with relatively small team sizes.
There are some sneaky problems with cross-training, though. If you take people who have slack and have them learn how to assist at the bottleneck, there's a good chance that you'll find yourself in a Jevons Paradox: you get used to having more human hours at the bottleneck, and then you adapt to that, and now the bottleneck gets even worse if you move people back to their other roles when those needs get higher again. Now you've suddenly got two bottlenecks!
Also, what roles do you cross-train into? Many roles become bottlenecks simultaneously at certain points of the product cycle. Namely, launch. In the lead-up to launch everyone is working at their roles at full capacity, so they won't be able to help out in those places they cross-trained for. So now, suddenly, at the time when everyone needs the most help, many people are getting less than usual!
Further, having people slowly learn how to do some other role, part-time, when they aren't doing their main role, is an ineffective way to create additional efficacy for that role. If you really need more people in some role, first try to fix the work so that you don't need more people, and then hire people who will require minimal onboarding!
So where does that leave you, as a person/company trying to manage ever-changing work over the long term?
We've variously tried and/or believed in each of the approaches above, finally settling on something that embraces slack time as something that isn't a problem. If an employee has more time than they need to perform their role right now, this is only a real problem if that will always be true. In fact, it's also a problem if an employee is always working at capacity without any slack time, because that means that they cannot increase capacity if needed!
Having some slack is essential for the long-term viability of a company. I could probably write a whole book about all the things that make it important, but here are some bullet points:
- If the work is designed to include slack, you have room to expand into that space at no extra cost when needed. No one has to get trained up, you don't need to take person-hours away from some other role. The time is just... there.
- If someone never has slack, you know that your project is at-risk in that role. The absence of slack is something to look for when evaluating project management and workflow.
- People without slack are likely to get increasingly stressed and then burn out. They're likely to work more hours than they signed up for (a.k.a. "crunch"). While this can be okay on occasion (depending on the workplace), it doesn't actually address the problem. People who work too much burn out quickly, make more mistakes, and have trouble maintaining positive social relationships. Collectively, it's likely that (on average) even a short period of crunch results in less productivity than if it hadn't happened at all. All the downsides for the overworked person also create splash damage on the rest of the team.
- Ensuring slack time requires constant re-evaluation of the work to ask why slack can't get generated for some role. It reveals process, workflow, and staffing problems early.
- Thinking about slack forces management to think both long-term and short-term.
- Slack time creates a positive feedback loop: the more of it you have, the more of it can be used to improve processes so that you can get even more.
- Slack time allows intrapersonal knowledge to be converted into infrastructure and institutional knowledge, with the paradoxical outcome that the more a company comes to depend on a person the more stable they'll be if that person is gone (either temporarily or permanently).
As I said, I could go ON AND ON.
So what does "slack time" mean for us?
For those roles that have huge swings in demand through the product lifecycle (QA, admin, BizDev, marketing, etc) we have the people in those roles spend their down-swing time learning more and more about those roles and things adjacent to those roles, doing experiments, building tools and pipelines, and more.
For those whose roles are just sorta always in high demand (programmers always seem to be a bottleneck) we do exactly the same thing. We just have to do it in a more structural way. One way is to have everyone spend e.g. an hour a day on "Slacktivities" while also enforcing strict we-really-mean-it expectations about work hours. If we didn't do that latter part, Slack Time would just get tacked onto the regular workday.
On top of protected slack time, we've made expectations explicit that quality and learning are almost always more important than quantity. We expect our programmers to refactor their code, write tests, and write documentation while they work. If someone isn't sure how something works, they should dig in and find out.
The goal of all of this is to make it so that the next upswing becomes far more manageable. Knowledge and action are converted into improved processes, products, and infrastructure. Those pesky peaks and troughs of demand get flattened out.
So, let's say you believe that slack is important and you manage people. What do you do when someone is out of slack? Here's a rough worksheet:
- Protect People Check in! If someone is getting stressed and overburdened there could be external stuff going on. Treat people like people.
- Make the work visible! Do a waste analysis. Where is the time going for this role?
- Waste Analysis How is this work being managed? Are there lots of moving parts? Lots of errors? Things falling through the cracks? Unfinished or extra features? How can the work be managed better?
- Can we not? What work can be thrown out? Most things are way less important than you think.
- Good enough? If the work must be done, can you reduce its scope?
- Sneak Attack? If someone suddenly ran out of slack, how come no one planned for that? What could have been done to predict this and mitigate by doing something earlier? Can any of that help now? How can you prevent this from happening again?
- Robots? Is there software, or are there process changes, that can be made or bought to mitigate this problem?
- How Long? How long can your team and the slack-less person go on like this? How much risk to them and to the project does their absence of slack create? Have open and honest discussions with all stakeholders.
- More People? If everything above has been dealt with and the end result is that the person in this role will rarely or never have slack, it's probably time to staff up. But do so with a plan for slack so that you don't Jevons Paradox your way right into the same problem. And remember that adding people is the riskiest, costliest, and most difficult way to solve problems.
If you run an organization or manage a team, how do you deal with the changes in demand for each role over time? Do you create protected slack time, or have other strategies?
⚙ Typescript template
I did a stream on Friday walking through a Typescript template project I was updating, followed by reading someone else's code from an open-source project on GitHub. The goal there was to see if it would make sense for me to add a new feature I wanted to that code (and then submit a pull request to the original project), or if I should just do my own thing.
The video will be up on Twitch for another 10 days or so, and then it'll be gone forever. So if you're into that sort of thing go give it a watch soon!
The Typescript template is up on GitHub if you want to use it for your own projects. Just hit that big Use Template" button. It's set up to make it (relatively) easy to create a project that:
- Uses Typescript
- Uses modern Node.js (v14+)
- Uses modules instead of CommonJS
- Has a CLI (command-line interface)
- Will be published to npmjs.com or some other package repository.
It's a template, so you can do whatever you want with it!
Until next time
That wraps DevChat #18!
I've been having a great time hearing from readers. If you haven't said hello, please do!
Share with others by forwarding, or link directly to the archived post.
Have a great week!
Get early access to new Dev Chat content with our newsletter!