When I founded my first software company, my mentors asked if I was ready to fall on my sword in front of customers and investors. It didn’t take long to figure out what they meant. In any leadership role, and especially as the founder, you’re a public face of your company. This responsibility is amplified in a small, nimble startup where customers have taken the risk of deploying unproven technology with you. You’ll be the one asking for patience, mercy, and forgiveness when you’ve missed a delivery deadline or when something goes wrong.
I’d heard the expression “fall on your sword” at my previous startups. I remember our CEO and CTO apologizing, then resetting expectations with key customers after our developers couldn’t meet unrealistic deliverables that sales had promised. Those deliverables, in turn, had been set to make investors happy. I hadn’t truly internalized what the idiom meant, though, until I became founder and the bearer of bad news myself. Now I was the one who was expected to throw myself onto the sharp tip of a metaphorical sword. My mentors and other veteran software executives were right. As the messenger, you’ll be shot at, repeatedly. But you do not, must not, and cannot point a finger of blame publicly at any other team member.
As a leader, you have the privilege of sharing successes with your team. And on the flip side, you have the burden of taking personal responsibility for the actions of that team. You must take accountability for failures, even when they’re not directly yours. I’m going to explore the differences between responsibility and accountability, and how you, as a technology leader, can build trust with your internal and external stakeholders by taking personal responsibility for failure. But first, let’s explore those two idioms: falling on your sword, and throwing someone under a bus. Where did they originate and what do they mean, in this context?
Of Swords and Buses
The expression “falling on your sword” goes back hundreds of years. It appears in Shakespeare’s Julius Caesar and the King James Bible, among other texts. Roman military leaders were said to throw themselves on the point of their swords after a defeat in battle. Today, the term is used in both business and politics as a metaphor for taking the blame for a situation that may not be directly your fault.
Throwing someone under the bus is a more recent idiom. Merriam-Webster dates it to the 1980s and defines it as betraying or sacrificing a person, particularly for the sake of one’s own advancement or as a means of safeguarding one’s own interests.
Think of a few examples where you might want to throw one of your teams in the general direction of a bus. Examples might include:
- Your sales team has overpromised to customers without ensuring that the roadmap and product can meet promised delivery timelines.
- Developers are coding too fast for QA to keep up and are releasing sloppy code.
- QA test cases aren’t aligned with customer use cases and environments.
All these examples can impact revenue, renewals, release dates, partnerships, service level agreements (SLAs), and investor funding. They might harm your ability to grow and properly fund your team. Left unsolved, they can even threaten your own job security. You’ll find yourself standing in front of an affected stakeholder — internal or external — explaining why something happened, or why something didn’t happen. Times like this are when it’s most important to avoid the temptation to cast blame and to take personal responsibility instead.
The best leaders I’ve worked with, who mentored me when I started my own software companies, handle these situations calmly and take responsibility. They fall on their swords in front of affected parties. They choose their words carefully and don’t equivocate or avoid responsibility. “I’m sorry. We weren’t able to deliver xyz. I take responsibility and here’s how we are going to make it right.”
Accountability in Practice
Let’s look at an example. My company was preparing for one of our first software deployments with a major international customer. Although we had originally agreed to deploy at a single site, we discovered just days before deployment that the use case would only work if we deployed at multiple sites. This was a major, unexpected blow. We had to re-architect a very early version of our software to handle the change, which wasn’t a minor change for our young, shoestring-funded company. As if that wasn’t enough, the deployment was critical. The customer was a marquee name who’d give us a great reference, we had other customers waiting to deploy similar use cases, and investors were waiting for the deployment as a pivotal proof point. As founder and CEO, I immediately had to own responsibility for the delay with the customer. I hewed closely to the script above and promised to make it right as quickly as possible.
Next, we went into internal damage control mode. How had we missed something so critical? We’d mutually signed off on the deployment topology and architecture, and we’d tested on those environments. One of our developers remembered someone mentioning multiple sites. He hadn’t brought it up again because our signoff showed a single site. The customer presumed we knew that it couldn’t be done without deploying at multiple sites, and that it was a simple oversight on everyone’s part to sign off on the single sight. There was simply no one to blame.
Without blame, we had to move to accountability. We coded and tested the re-architected version as fast as humanly possible. Thankfully, we deployed successfully. More importantly, though, we learned painful lessons for the future. We built redundancies into our internal systems and processes to ensure that we knew exactly what environments we’d be deploying into. Also, although it stretched our bootstrap budget, we always flew a human to each customer site to visually confirm each rack, port, and switch we’d be deploying on. As it happened, the benefits of being onsite so often exceeded simply not repeating the first customer situation. We developed close onsite rapport with each customer, and we learned more about use cases than we would have otherwise. I didn’t expect to have to throw myself on my sword for one of my company’s very first deployments, but in hindsight I’m glad I did. It set the tone for future deployments and taught us a number of critical lessons that increased our institutional accountability.
The Big Picture
Why is it so important to take responsibility externally and not blame your team? A culture where leaders throw team members under the bus leads to a cascade of disastrous consequences. People become hypersensitive and afraid. They fear being punished for honest mistakes like the one that nearly derailed at my company’s first major deployment. As a result, they’re more likely to conceal mistakes instead of being open and honest when they occur. This makes unwinding and repairing damage more difficult when something goes awry. In this type of environment, people are understandably likely to become self-protective. Instead of working collaboratively to improve on the quality of your product, testing, or delivery, those functions will calcify into rigid silos. This stifles everyone’s ability to solve problems and innovate. Finally, when people fear being blamed and shamed publicly, productivity and engagement will drop. Your teams will keep their heads down instead of mobilizing to do their best work.
In contrast, effective leaders don’t fling bodies at buses. They foster a culture of accountability instead. This involves uncovering what happened and why, with an eye toward empowering your team to ensure it doesn’t happen again. A culture of accountability provides everyone with the resources, education, and support necessary to fix mistakes. Rather than merely instilling a fear of failure or a fear of being blamed, encourage the team to take ownership of the results and commit to doing better next time. Fostering this culture allows your team to grow as individuals and improves your product.
Handling situations this way also builds internal trust. The people who report to you trust that you’ve got their back. They know that together, you’ll examine processes, resources, and skills and communications gaps to ensure that problems don’t recur. Since they won’t live in fear of becoming sacrificial lambs, they’ll feel safe to take risks and innovate. This strategy has obvious long-term benefits for your product, team members, and company.
Your external stakeholders will also trust you more when they notice your mature approach to leadership. This style of leadership shows that you understand your responsibilities and take them seriously. Customers, partners, and investors all put time, resources, and money into your company. When you demonstrably take accountability for what falls under your oversight, they know they can count on you to protect their investment. They will continue to invest in you when they know you operate with a culture of accountability and responsibility.
This takes practice. As you learn to take responsibility for your team, you’ll develop a strong stomach for sword wounds. If you’re in the startup world, of course, you’ll be developing a stomach of steel already, for many other reasons! This toughness will become an invaluable leadership strength for your executive career. The rule of thumb: Handle accountability internally and take responsibility externally. It’s part of the burden and privilege of being a leader.
