“Maxine’s one of the most senior engineers in the company, and she’s been assigned to us for a couple of months to help us. She’s the lead architect for the manufacturing ERP systems. Can you show her what she needs to know to get productive around here?”
“Uh, hi, Mrs. Chambers, nice to meet you,” he says, holding out his hand, looking puzzled. He’s probably wondering how he ended up being responsible for someone who could be his mom, she thinks.
“Nice meeting you,” she says, smiling. “Please, just call me Maxine. And my friends call me Max,” she adds, even though it usually irks her when her daughters’ friends call her by her first name. But Josh is a work colleague, and she’s glad to have a native guide who can show her around. Even if he’s not even old enough to drive, she jokes to herself.
“Okay, let me know if there’s anything you need,” Randy says. “Maxine, I’m looking forward to introducing you to the rest of the team. Our first staff meeting is next week.”
Randy turns to Josh. “Tell me more about the build failures.”
Maxine listens in on the conversation. The more she hears, the worse she feels. All those stories about caveman technical practices in the Phoenix Project are actually true. She’s learned over her entire career that when people can’t get their builds going consistently, disaster is usually right around the corner.
She looks around at the entire floor. Over a hundred developers are typing away, working on their little piece of the system on their laptops. Without constant feedback from a centralized build, integration, and test system, they really have no idea what will happen when all their work is merged with everyone else’s.
Josh spins his chair around to Maxine. “Mrs. Chambers, I’ve got to go show Randy something, but I just emailed you what we’ve got in terms of documentation for new developers—it’s the wiki pages where I’ve assembled all of the release notes we’ve written and the documentation from the development teams. There’s also links to the stuff we know we need to write. Hopefully that will get you started?”
Maxine gives him a thumbs up. As they leave, she logs in with her new laptop and is able to get in and open her email, miraculously working the first time. But before looking at what Josh sent, she pokes around to see what else they’ve installed on her new laptop.
Immediately, she is mystified. She finds links to HR systems, network shares to company resources, links to expense reporting system, payroll, timecard systems…She finds Microsoft Word and Excel and the rest of the Office suite.
She frowns. This configuration might work for someone in finance, she thinks, but not a developer. There’s no IDE or code editors or source control managers installed. Opening up a terminal window, she confirms that there aren’t any compilers, Docker, Git…nothing. Not even Visio or OmniGraffle!
When they bring in a new developer, what do they actually expect them to do? Read emails and write memos?
When you hire a plumber or carpenter, you expect them to bring their own tools. But in a software organization with more than one developer, everyone shares tools to help the team be productive. Apparently here on the Phoenix Project, the toolbox is empty.
Not giving up, she opens her email to find the link Josh sent. She smiles when, as promised, it takes her to an internal wiki page, a tool many engineers use to collaborate on documentation. (It always amazes her friends that the term “wiki” predated Wikipedia by over a decade.)
Her smile quickly disappears as she scrolls up and down the wiki page. Is this all of it?
If so, she is really in trouble. The “documentation” is only one page.
This excerpt by Gene Kim first appeared in NEXT magazine, issue 6.
Ken Kaplan is Editor in Chief for The Forecast by Nutanix. Find him on Twitter @kenekaplan.
© 2019 Nutanix, Inc. All rights reserved. For additional legal information, please go here.
