Reckless Bias for Action — A Tale of Immaturity and Impatience
Bias for Action has long been one of my favorite leadership principles. Not just because it's a critical leadership skill, but because I'm quite impatient.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
I was a young software engineer, around a year out of college. That youth and inexperience is the best excuse I have for my behavior in the situation below.
My friend and I were the two primary software engineers for a B2B publishing company. Looking back, it’s relatively insane they left their websites in the hands of two new college graduates.
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
We had spent a couple of months redesigning one of the websites, and were ready to launch the changes. Company employees had tested all the features. We had demonstrated the new design to the editors of the website, our management chain, and had our deployment steps ready.
“We need to figure out the right timing for the deployment,” the chief editor said, “We don’t want to confuse our customers by having the whole website change on them.”
“Maybe we should do an announcement that the website is going to change?” another editor asked. “We could ask customers if they’re ok with the timing of the change? Make sure they’re ready for it?”
The conference call continued, as various leaders across the business debated how they might stage the website change to not shock our customers.
My friend and I quietly rolled our eyes. In our minds, our two-month project to redesign the website had taken far too long, and we wanted to move onto our next project. Instead, these old guys (they were probably in their 40s or 50s. Gasp. So old.) were afraid to make a small website change. This was the second day of multiple conference calls debating how to launch our website design.
This was in the early 2000s, so many of our co-workers were still figuring out how to market the website as it related to our venerable newspaper. Our publication was more than 100 years old, and the prior web design mirrored the print publication design, to keep things familiar. We were preparing to making a break with tradition by launching a *gasp* original website design. And this scared all these non-technical leaders.
Later in the day, my co-worker and I were discussing the snail’s pace of our office.
“Just wait, we’ll be sitting here twiddling our thumbs in two weeks while they debate how to make this small change.” my co-worker said.
For the engineers in the crowd, we had essentially a single source control branch, and a single staging environment. We literally didn’t have a way to continue new development until we launched this design. And yeah, that was our fault, but we were too inexperienced to do anything about it yet.
I rolled my eyes. “We’ve launched things mistakenly before, we should just mistakenly launch it.” I said, laughing.
This was true, we’d launched things accidentally before. No one should leave a production system in the hands of a couple of college hires. We’d repeatedly launched things accidentally, including jokes we’d never intended to release to the public. If you had viewed source at the right time on our websites, you would have noted that we’d centered all of our source code horizontally. While that worked fine in Netscape, playing with the source code formatting broke the page in IE5 (of course it did, that browser was horrific), so we had to turn it off.
My friend’s eyes got big, and he smiled wickedly.
I smiled. “Ohhhhh! But would it work? Wouldn’t we have to roll it back?” I asked.
He shrugged. “As long as it’d been in production for a while before anyone noticed?”
I nodded and smiled. “This afternoon, after everyone goes home, we mistakenly push it to production, and no one is likely to notice until tomorrow.”
And so that’s precisely what we did. We waited until the end of the day, and launched our redesigned website. We were running a business website. Our traffic fell to almost zero once business hours were over. We double-checked that everything was working correctly, and went home. Like techno hoodlums.
The next day, when I arrived at work, I received a frantic call from our editor. “Dave! The new website design is in production!”
“Oh no!” I said in horror. “How did that happen!? I’ll look into it right away! Is there anything wrong with the site?”
“No, it’s working fine so far.” he said, a bit calmer.
“Ok, I’ll call you back ASAP, once I know what happened.” I said. I smiled, and took a few deep breaths. We made mistakes often enough, but it was a bit scary to purposefully make them. I called him back a few minutes later.
“It looks like when we were fixing a small bug last night, we mistakenly released our test site to production. It was challenging to keep our test and production sites separate, and it got pushed out accidentally.”
“Oh yeah, that again.” he said sagely.
He remembered other similar mistakes we’d made. We had an embarrassingly bad operational setup, where it was sincerely easy to launch things into production without intending it. We didn’t know how to set things up better (yet), but thankfully no one else at our company knew better either. So they were ignorant of our ignorance.
“Well, would you like us to switch back to the old design?” I asked helpfully. “I think we can probably revert the changes if you’d like?”
“Oh no, no, most customers used the site already. We can’t confuse them by undoing the changes. We didn’t get any complaints, so I think things are fine now.” he said. “And actually, this might have worked out well. We can just move forward now! No more debating how to do the change.”
And we did. No customers complained. We got a couple of compliments that we had finally updated our design of our website. And that was it. A big deal about nothing.
Facebook had a motto “Move fast and break things” when I was there (they got scared into changing it), and Amazon’s Bias for Action leadership principle emphasizes the need to move quickly. It’s interesting how two major technology companies have a primary interest in moving quickly.
Was my story a great example of bias for action? Oh heck no, this was an example of what happens when you put inexperienced, immature young men in charge of important software. It was unprofessional on our part.
However, it does illustrate the benefits of bias for action. When you’re confronted with a problem, you have two major options. You can plan and debate things, or you can take action.
When you take action (as we did), you either save time, or you learn something. Those conference calls were people collectively repeating their worries to each other. They weren’t learning anything, they were just afraid to take the leap into the unknown.
Once you’ve listed your concerns, it’s time to decide. We were unprofessional, but we got the roadblock eliminated.
Making decisions at scale
I was a bar raiser on a level 7 (Senior Manager) hiring loop. We were 25 minutes into a 30-minute debrief. We had me, the hiring manager, 3 interviewers, and a recruiter in the room.
“How about we schedule more time to continue debating?” the hiring manager said to the recruiter. We’d been waffling back and forth for the previous 5+ minutes.
The recruiter nodded. “I can find some time-”
“Please hold on.” I said. “We don’t need more time if we don’t have any more information to share. I believe we’ve covered everyone’s feedback. We know the risks, and the benefits of this candidate.”
The hiring manager nodded, “But we still can’t decide, so we need more time to discuss.”
“We don’t need more time.” I said. “We have said literally everything which needs to be said about the candidate. You and I need to decide if we want to hire this candidate or not. My vote is yes. You can say yes, and take the candidate, or you can say no, and reject the candidate. Either way, it’s your choice, and you have to make it now.”
That sounds a bit harsh, right? Except that part of the bar raiser’s job is to get loops to decide. You gather information, listen to everyone’s perspective, and then decide.
What’s fairly common is that people feel stuck deciding. It’s not a clear decision because the candidate has some good qualities, and at least one risk they’re concerned about. And we find ourselves repeating the same arguments back and forth endlessly.
My job as a bar raiser was not to remove people’s emotional stress. It was to help Amazon by keeping our loop costs low and quality high, help the candidate by getting them an answer quickly, and help the hiring managers make a high-quality decision efficiently.
I had to ensure that everyone had shared their data, and opinions. I had to ensure that we knew the risks and benefits of the decision, and then ensure that the decision maker stops avoiding the hard decision.
It’s a big part of any leadership role. Recognizing when there is value in debate, and when there is more value in deciding. Often any decision will do.