Last night I gave a talk on pressing the big scary red reset button at the NY CTO School. The first talk before me was by @malcolmcasey, CTO of Skillshare, another awesome NYC startup. It’s a great meet-up for early team leads that want to learn from other technologists that have been doing this for a while.
I’ve reset a few projects in my life. None as big as Microsoft Windows Longhorn (Vista), which was a fun example of failure of monumental proportion. In 2006 Jim Alchin wrote in the Wall Street Journal: “Longhorn was crashing into the ground.” While he was credited with ultimately shipping Vista following a successful reset, it was one of Microsoft’s worse operating systems. Developers just no longer cared. You can see how a reset is by no means a guarantee of success. In fact, anecdotal evidence shows that 7 out of 10 projects that are reset still fail. And when projects fail there’s plenty of wrongs to be pointed out. Marketers will blame the product, product managers the technology and everybody will blame other people. A few will cite failure all around or an unstoppable death spiral.
I interviewed several CTOs when I was preparing this talk. It was really fun to hear about their experiences. They would usually start with a gasp and use a particular project reset vocabulary. “We slammed the brakes.” “Changed the wings on an airplane.” This might actually be a silly analogy – have you ever seen anyone attempt such a feat? No wonder most projects fail after a reset – taking the wings off in-flight means crashing into the ground, guaranteed. But if your reset is going too smoothly, feel free to add some drama as in this amazing video.
I think that pressing the reset button on a clearly failing project is always the right thing to do. Put some numbers in perspective by measuring what value the project is yielding vs. what it costs. You may have sunken a ton of money into it, but you’re just bleeding more. To execute, get rid of all the chickens (people who aren’t committed to the project with their flesh and bones), trim some fat and time-box the reset. Use all the brownie points that you have earned until now with the rest of the company (that’s why it’s so important to invest in relationships inside an organization when things are going well, both up and down). Successful resets are very rewarding and have a long tail, but people tend to block out negative emotions associated with violence and doom that occurred in the past, so few will actually remember. You’re not a hero, you’re just doing your job.
Finally, things don’t need to reach the dire straits. Personally, I try to foster a culture where we experiment with everything. Want to build the new system with a different data store? Try it. Want to rewrite our entire UI with anotherframework.js? Go for it. You don’t need buy-in from me – you just need to be transparent and let everybody know what you’re doing. You’ll get plenty constructive criticism from others - make your own decisions. The job of a tech lead is to keep the output of the entire team massively positive, not to micromanage individual’s minutes. For every one developer stepping out of doing visibly productive feature work for a sprint another will step out to find a multiplying factor of 10 for something you’re building next. It’s a small price to pay for being awesome, as a team.
Slides: https://www.slideshare.net/dblockdotorg/pressing-the-big-scary-red-button