At a CTO Roundtable in NYC, I sat with several other technical leaders. During our session, we listened to each other’s current challenges and responded with empathy and advice. When I responded to one of the concerns with the advice “influence the CEO to adjust the schedule,” I was caught off guard by everyone’s response. Our former respectful and inquisitive dialog broke down into sneers, laughs and eye rolls.
In that moment, I realized that, as a group, we needed to raise our chops (and our hopes) when it comes to how we influence the business side of things.
With our words, we have the power to get a lot more done than we give credit. Sometimes, we can have a greater impact on business returns with a single conversation than in a week of uninterrupted coding.
However, when communication breaks down, our words can cause more harm than good. We may end a conversation only to find business running in the opposite direction into a perfect storm of bugs, missing features and failures.
It is critical to communicate with business effectively. We need to know what to say, who to say it to and when to say it. This is no easy task. It is not something you will learn overnight. It also takes some homework, digging around and perspective shifting.
Luckily, there are a few tricks that can help you get a quick start.
One of those ways is to leverage metaphors. Metaphors help business understand and empathize with your challenges. It also helps them understand how the decisions you make influence the outcome of initiatives. As touched on in a previous post by Andrea, our CEO, beyond the impact on business, metaphors can help you align on decisions more clearly and be consistent in quality controls.
Sounds great, right? Well, like most useful tools, a good metaphor can be hard to find. Thankfully, many metaphors for technology are universal and can be applied across domains.
In this series of blog posts, I will be introducing several example metaphors as well as detail what it can help influence, when to use it, and how to tweak it.
It’s important to note that when you read the metaphors they will be conveying ideas that seem simple and obvious. Whether it’s our attitude around their lack of this specialized knowledge or our own ignorance to it, our communication breaks down when we forget that basic, mundane ideas, like test coverage, are complex, overwhelming and untouchable to “non-technical” folk. Until we’re able to make it mundane and simple to our business allies as well, we will be limited in our ability to drive decisions and influence direction.
As well as any metaphor can capture a real-world experience, chances are there are aspects that do not reflect truths in the real world. There may be times when you’ll need to mention the gotchas, or there is a good chance someone will come up with a great idea that is based on baloney (maybe quite literally depending on the metaphor!).
The last aspect of each metaphor are limitations. Not only do they help prevent assumptions we can see beforehand, they also plant a seed in the person’s head that the metaphor is not true to life. This will help them keep the metaphor limited to the intended areas.
Let’s start with the seat belt metaphor.
- Communicate current test coverage to business without using a percentage.
- Get business to push for test coverage instead of against.
- Create team unity and process around test coverage.
- Resist reactionary decisions based on internal and external drivers that interfere with test coverage.
Imagine you’re in your car wearing a seat belt. In the event of an accident, you trust the seat belt will keep you safe.
Your test suite is like a seat belt.
If there is a bug introduced during development, the test suite will let you know and prevent major damage like bad things that happen when shit goes down at your company.
Be Smart About Bad Things
The closer you can align “bad things” to sources of decision-making in your company, the more impact this statement will have. While you can make progress with standard stuff – lost customers, invalid data, failure to meet market demand –, it will be more impactful if you liken it to something more subjective to the people you’re trying to influence. Observe the drivers behind the decision-makers in your company and find the patterns.
Discussions Around the Metaphor:
Communicating percentage of test coverage
If you want to talk about the status of test coverage without going into actual percents, play around with the material of the belt. Here are some examples:
- Low coverage (< 30%): Tissues – they ain’t doing shit.
- Good coverage (80-90%): Standard Order – it passes the safety inspection.
- High coverage (91%-99%): Kevlar – uncommon and uncomfortable.
- 100% coverage: Lead – we’re even safe from x-rays (rarely required and pretty much impossible to pull off in automation).
These are only examples – it’s your metaphor. If you find yourself in between these percentages, work on communicating appropriate metaphors. You could use nylon (pantyhose) for instance, which is stronger than tissues.
Deciding how much test coverage is needed
In an ideal world, business wants to operate with “standard coverage.” Whenever someone on the dev team mentions they could make the deadline if they could skip writing tests, the response is something like “What are you cuckoo? You want to take this for a spin without seat belts?”
It would also be good if you respond as such when someone from business asks you to deliver faster and pushes to cut corners. “Have you seen that video on YouTube with the car up a tree? No way I’m going to let you go out there without protection!”
In the real world, chances are you’re getting pushback from every angle to use something like a lap belt on a motionless merry-go-round bench. We all know it’s pointless, but put it on anyway. It can be easier to fake it than face the potential fallout of refusing business (this experience now a thing of the past with your magical seat belt!).
Sometimes, there may be a valid reason to avoid tests all together or strap yourself in with a box of Kleenex – that’s totally cool, more power to you! Solutions that fall into this category are spikes, experiments, (very) short-lived applications, non-critical internal apps. These are the things you aren’t thinking about testing (unless you’re me).
On the other side, unless you are working on a hard-fail, real-time, shit blows up (for real) solution, you can drop the lead.
When in doubt, simplicity is divinity – use the standard.
What seat belts look like in the real world
Here are some examples:
In my first job, I worked on an embedded system that quantified fuel quantity for airplanes. You know what couldn’t happen? Mistakes. Seat Belt Material: Lead
A few years later, I developed a video-clip player for on-air, broadcast TV operations. Seat Belt Material: Kevlar
Client-facing application for planning and organization (think Pinterest, but better and in 2006). Seat Belt Material: Standard
Client-facing application for portfolio managers to trade black pools of liquidity (big money, big money, no whammies!). Seat Belt Material: Standard
Internal application nobody really cared about to get account manager to stop complaining. Seat Belt Material: Tissues
What if you and business can’t agree on material?
You think your app needs Standard Coverage, but business is standing firm with Kleenex. This is your opportunity to make Uncle Bob proud. Instead of buckling into an unsafe situation, you can push back in a way they can empathize with: “I’m sorry, but I’m uncomfortable doing this with anything less than standard. It just isn’t safe. If I were able to describe the dangers I know exist better, I’m sure you would agree. I’m your expert in the field and I need to make sure we’re safe. I won’t have it any other way.”
Drive your points home by playing with the vehicle, passengers, and seat belt type. Have fun – ride in roller coasters, put a five point harness in a buggie. The more lighthearted and descriptive, the more it will resound with people. Just be sure it stays in line with the original intention and actually mirrors the real-world situation.
Having these conversations early in development has many plusses. First, you can include testing practices into your culture and process. Make sure your “done done” criteria has a safety belt check. An added bonus is that it can help prevent ad hoc decisions to change the expected coverage for various reasons. You know what I’m talking about. These decisions happen when we hear things like “We need this yesterday,” or “I really want to get this out in the next release.” It also happens when we think things like “This is taking longer than I expected,” or “I’m tired and want to go home.” We’re vulnerable to these statements from various stories, conditions and past experiences that tell us the more code we churn out and tickets we finish, the more valuable we are. Think of the seat belt as a step in creating a new story. For you, your team and your relationship with business.
Remember the Purpose
Even if this metaphor seems silly or obvious – which it most likely does to you –, chances are a few light bulbs will pop up above some of your business folks’ heads.
In this seat belt example, I couldn’t think of any gotchas. I usually can think of a lot, but I couldn’t come up with any on this one. So, if you think of something, please feel free to play devil’s advocate and leave me some ideas in the comments below.