A short story
A few months ago, in my coaching conversations with engineering leaders at startups, I started tossing around this idea of an anchor and a vector for growth. People want some level of stability — something to tap into when everything around them is changing. But they also want a challenge, and a feeling of growth and improvement. I liked the stabilizing aspect of the anchor, but was unsatisfied with the imagery of a boat that goes nowhere, so I was pondering what a more effective metaphor might be.
Meanwhile, at home, I experienced what I consider one of our biggest parenting wins. We used to have to drag our daughter, who is 4 years old, through her bedtime routine — brush teeth, floss, bathroom, etc. Then we said, if she did it all by herself super fast, she could play Minecraft. Which actually meant she could watch us play Minecraft 😂. But then she started to play Minecraft and build houses and awesome structures in the sky.
So these two professional and personal situations merged in my brain and suddenly it came to me: engineers need a home base, and they need a mission.
This extended metaphor for engineering leadership has been marinating in my brain now for a few more weeks, so I decided to write a series of posts on the insights gleaned from Minecraft (which is in fact, not a game just for kids, and all the cool adults were playing it far before the kids started). I also really just want to write down some ridiculous ties between Minecraft and engineering management. I have no clue how much this will resonate with people who have not played Minecraft, but I’ll try to include lots of screenshots of my “research.”
Getting started
When you start to play Minecraft, you get plopped into a newly generated world with so many unknowns. Are you on an island? What sort of biome is it? Are there resources nearby? Food?
If it’s your first time playing Minecraft, you’re probably just very very confused, and have no idea what to do. I recommend watching a youtube video: just search for “minecraft first day.”
If it’s not your first time playing in a new world, you know there are things you need — wood, stone, coal, and if you’re lucky, food. Those are the raw materials you need to build your first basic home — a safe place you can hunker down in when the sun starts to set. If you’re stuck outside in the dark, zombies, spiders, and skeletons come and attack you, and you die.
Similarly, when you join a new company, there are so many unknowns and things you don’t even know are unknowns.
For my first job out of school, I hadn’t talked to anyone on the team before my first day. I had spent some time brushing up on C, and the codebase was in Java. I felt massive imposter syndrome for getting in via an internship rather than a grueling 8-hour interview process.
New grad hires have probably never been a full-time employee before, anywhere! What’s the equivalent of the “how to survive your first night” youtube video that you can give them in onboarding so that they’re not left outside with no resources or expectations?
Physical safety and Psychological safety
In minecraft, whenever it’s dark, dangerous creatures spawn.
To survive the first night, you need to build something to be in where the monsters can’t get to you. Usually that’s carving out something in stone, or building a small basic dirt structure. There’s not much time, and you need something urgently!
It sounds scary, and it is. The sun starts to set, and you don’t have the necessary resources to survive the night.
But the alternative is a little demoralizing. I’ve tried to onboard people to Minecraft by saying “just play in our world, it’s already set up and has tons of stuff, feel free to take any resources you want from the chest.” It’s sort of fun, but it’s lacking in that thrill of starting from nothing and building something from scratch.
Startups struggle with providing enough structure in on-boarding, training, and general processes such that people feel a sense of psychological safety, but enough freedom to capture that sense of open exploration. Most often, companies either are too chaotic in every aspect (product, people management, process, hiring, etc) — leading to some people feeling they can do anything, and others feeling unsupported and excluded, or they’re too prescriptive in how anything gets done — there’s no room for creativity and the thrill of identifying a gap to fill.
When I revamped the process for onboarding engineers at Medium, I made two small but powerful changes. The first is that I went out and bought the nicest fanciest cardstock I could find; for each new engineer, I edited and printed out a letter from the engineering team, which included the schedule for their first day. I signed each by hand, “Medium Engineering.” The second change I made was to explicitly pair each new hire with an onboarding buddy. And I sat down with the onboarding buddy and said, “the most important thing you can do is to tell _____ that onboarding them is your top priority, and that they shouldn’t hesitate to interrupt you from whatever you’re doing to help them.”
Those small changes were the onboarding equivalent of “here watch this youtube video before you start playing” — just enough to provide them with enough support to get started and feel welcome, but not too much that they felt overwhelmed.
What’s the forcing function?
The first home base is built urgently, sloppily, out of necessity. There is the real (well, virtual) danger of zombies that will appear and kill you. So you must slap something together so you have a place to be safe.
What would the first day look like if there weren’t monsters that come out at night? There’d be no forcing function. I imagine some players might wander the terrain for hours or days before deciding to build something. It might take them longer too to figure out the mechanics of the gameplay.
What are the expectations when you onboard someone? Maybe it’s “Feel free to explore and read, but every single engineer submits their first product PR by the end of the first week.” Otherwise, a new engineer may explore for weeks before contributing code.
In speaking with engineering leaders at many different companies and in my own experience, there’s a common pattern that emerges when on-boarding more senior engineers. The default expectation is that they’ll ramp up easily, so they aren’t provided the level of clear support and expectations that an intern or new grad might receive. In some ways, they need more initial support or at least calibration. New grads are much more malleable, but senior engineers have had years to acclimate to other companies’ values and ways of working that may or may not be aligned with yours.
The sun sets in Minecraft no matter what, and the monsters show up, so you can’t be stuck outside. Figure out what the non-negotiable expectation is for your team, and communicate it clearly. People will be relieved to have a target to shoot at.
No place like home
So now you have a home base. It’s not very beautiful, but it works. It’s the not-really-urgent useful bug fix that you dug out of a backlog as a starter project for your new hire to learn some of the codebase. It’s learning the team’s git workflow and adding your name to the team page. It’s having that first one-on-one with your manager where you’re both sort of awkwardly getting to know each other.
You might have scoped out even better places to go in the morning when the sun comes up. Or an even more ideal location for a really amazing architecturally beautiful structure by a waterfall or on top of a mountain. You might even feel brave enough to go outside and see the stars at night, knowing that your home is just a few steps away.
But for now, this is good enough. You’ve survived your first night.
