Why Transparency Is Critical in Times of Crisis, Part 2: Decision vs. Discussion

Image for post
Image for post
Image by David Travis via unsplash

As the economy declines, an increasing number of companies are pivoting from peacetime management to wartime management. Renowned entrepreneur and venture capitalist Ben Horowitz wrote a blog post “Peacetime CEO / Wartime CEO” in which he lists the many differences between the two types of company management. In particular, the following caught my eye:

Most management techniques and principles are catered towards peacetime, to which most of my previous blog posts are no exception. During wartime — or when the company is fending off existential threats — rules tend to be broken. When I served in the Taiwanese Marine Corps, there was a saying: “Getting everyone marching together towards the second best option is better than sitting around and debating what the first best option is.” The same is true for companies fighting an existential threat: sometimes quick decisions are more optimal than perfect ones.

A common mistake I’ve seen leaders make (during both peacetime and wartime) is to invite a discussion around a decision that has already been made. Those who become invested in the discussion may feel betrayed when they realize the decision was already made and their ideas had no impact on the outcome. In my previous post, I noted that transparency is especially important in times of crisis. Today, I want to specifically discuss communicating an already-made decision and the importance during times when the company needs to act quickly.

Discussion or Decision?

During peacetime, organizations are usually afforded more time to make decisions, and leaders prioritize empowering employees by advising thinking things through rather than being hasty. During wartime, decisions have to be made quickly so people can start executing them, which comes at the expense of employee autonomy. This is when clear communication makes a big difference for your employees.

A few years ago, I was on the hiring committee in search of a new VP of Engineering. The committee, chaired by the CTO, defined the job requirements and interview process. Among them were two requirements highlighted by the CTO:

  • The candidate must be highly technical.
  • The candidate must have had substantial experience managing engineering teams at a tech company.

The search went on for a few weeks, but none of the candidates we interviewed were qualified. One day, we received a referral for a candidate whose demographic and career background was very similar to that of the two co-founders. The CTO instructed the committee to “go easy on the technical portions, because they may not pass it.” While it was odd, we obliged.

During the post-interview debrief, the CTO asked for the hiring committee’s recommendation. While the candidate seemed solid, two concerns emerged:

  1. We asked the candidate easier technical questions, so we could not properly evaluate their technical abilities against those of other candidates in the pipeline.
  2. The candidate spent their entire career in finance and consulting, and their only stint at a tech company lasted merely 10 months.

The first concern was quickly dismissed, since it was the CTO’s direct orders to have us go easy on the technical portion. The second one stirred a debate: the startup had few people who came from the tech industry, and we wanted someone who had experienced high growth at a tech company.

Despite the committee’s concerns, the CTO argued that the candidate had sufficient tech company experience, citing their 10-month stint at a “tech” startup and experience as a CTO/co-founder of another startup. However, upon further inspection, the CTO/co-founder experience completely overlapped with their full-time job and was really a side project the candidate undertook alone. Surprisingly, the CTO kept repeating his original arguments and insisted that we were being too strict. As time for the meeting ran out, the CTO finally disclosed, “Actually, I already gave [them] a verbal offer, so if there are no other concerns, we’ll move forward with this candidate and wine and dine [them].”

The members of the committee were in shock. We had spent the last 30 minutes debating whether or not we should hire this candidate, yet it turned out that the CTO had already made the decision without us. In the ensuing weeks, people were visibly less vocal in hiring committee meetings. We weren’t sure if we were discussing a possibility, listening to the broadcast of a decision, or being asked to give our opinions which may or may not meaningfully influence the final decision.

These types of management-driven decisions are commonly seen across organizations of all sizes. Leaders are certainly justified in making executive decisions during critical wartime. However, not disclosing that a decision was made and inviting a discussion not only makes people feel cheated, but also causes them to lose trust in the system because they don’t know if their opinions still matter.

Decision, Not Discussion

In wartime, it is important to identify when a decision has been made and notifying the team. Being transparent that a decision has already been made allows you to maintain trust, which serves as the foundation for everyone to concentrate on steering the company away from crisis.

Recently, at Airbnb, I was notified of a strategic and urgent project. The deadline was two weeks away, but I was told that since the scope was sufficiently small and they had already found engineers to work on it, all my team had to do was consult on and review code. I told one of my team members to represent our team for this project and provide guidance when necessary. In other words, I let the project team discuss and decide on how to proceed with the project.

Two days later, when no progress was made, I reviewed the product spec and realized there was no way the pre-selected engineers could complete the project in time because they had no prior experience in our codebase. Furthermore, the product scope was actually quite large, and even if my team took it on, we couldn’t have completed the project in two weeks. I had made a mistake by allowing a discussion (between the product manager and the engineers found from other teams) instead of making a decision and implementing it down the line. This cost us two days, leaving eight working days until launch.

I immediately told the product manager (PM) that I was bringing in three of my engineers — pausing their existing work — and cutting project scope to ensure that we could deliver on time. After some back-and-forth with the original project team and the PM, we agreed to a reasonable scope, set up the engineering plan, and were able to deliver the project on time.

When I talked to my engineers, I explained that because this project was critical, I wanted them to pause their current work to ensure this project’s delivery. While I needed their buy-in, I clarified that the decision had been made and that the discussion needed was around how to build these features on time — not whether their existing work should be paused.

One of my engineers noted during a one-on-one that it was “uncharacteristic of [me] to be so heavy-handed in decisions and execution details.” While he was not happy with the decreased autonomy, he appreciated that I explained upfront the criticality of the project, understood why I intentionally “micromanaged”, and agreed that the project would not have succeeded had I let it run its natural course.

Transparency is one of the most effective ways to build trust, even if it means not inviting discussion like you would during peacetime. During wartime, trust is even more important as we need everyone aligned to turn around the company. Ultimately, employees will already be unhappy during wartime due to macro environmental factors, but preserving trust via transparency allows you to rebuild the company and its morale quicker. The military’s approach is a good example of the benefits of such crystal-clear transparency: it’s almost always a decision and never a discussion!

Image for post
Image for post
Image from Tenor

If you enjoyed this article, check out the other articles in this series:

For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.

Written by

Product-minded Engineering Leader. Organization & Cultural Builder. Traveler. Martial Artist (Muay Thai & Pekiti Tirsia Kali).

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store