There’s no shortage of answers; what we need are more questions 

There’s a great meme I recently came across, where a wall clock is (insert your own adjective here: intriguingly, maddeningly, hilariously) situated directly behind some sort of pole or support beam that blocks a number of numbers from view. And so, rather than move the clock to another location (because moving the beam seems like far more work, and work which might damage the structural integrity of the building) you can see that someone has painted the blocked numbers 8, 9, and 10 directly onto the beam that’s blocking them. 

The meme’s humorous caption reads, “Bug fixes in production.” A play on the fact that when software bugs slip past the developers and testers, and a quick “fix” is needed, that fix may come across as insufficient, hasty, or sloppy. When this is done, the bug might be gone, but the damage to your reputation or brand can often remain. 

When I saw this meme, I quickly grabbed a screenshot and threw it into our “Corkboard” Slack channel, a catch-all for random water-cooler-type discussions. I then asked what I hoped people would mistake for a “simple” question.

Did this fix the bug? 

I gave people options of “Yes,” “No,” and a shrugging emoji to connote “I don’t know.” 

The final results? 

Yes – 2 
No – 6 
IDK – 3 

I told people not to worry, that there were no “wrong” answers, but I was definitely hoping for more than 3 shrugs. Okay, I was actually hoping for all shrugs. I’m an optimist.

Why was my hope for all shrugs? Because we don’t even know what “the” bug is; how can we confidently determine if it was fixed?  

A variety of comments that some left in response provided a wealth of insight into the types of opinions around problems, and their presumed solutions, that are made in the software world all the time. I picked out a handful that I believe could provide valuable food for thought when brought to light during design, development, testing, and even production at any software organization.

A: “No. The glare prevents me from seeing when it’s ‘5 until the top of the hour.”

I love this answer. It was the first one that came in, and only seconds after I shared the meme with my colleagues. Remember when your teachers would hand you a graded assignment and an answer (or, in my case, many answers) would simply be marked with an “X?” Or, maybe you would ask your parents to review your homework before you turned it in, and they’d say, “You might want to look again at #5.” 

How many times did you stare at that answer and wonder what the determiner of its quality had found so wrong about it? Furthermore, weren’t you so proud of yourself for quickly finding that “bug” within your answer, and then excitedly making what you just knew was the correction it required, and then spinning it back around to your parents, only to have them say, “I didn’t mean that. Look again.” Crushed. 

This is exactly what’s happened in the clock meme, and what happens frequently between those who find software bugs—whether they be customers or employees—and a lack of information or clarity shared with those who are expected to fix bugs. 

My colleague’s issue with this clock was not the 8, 9, and 10 covered up by the pole. His primary issue was the glare that covered up what should’ve been a perfectly visible, unobstructed 11. Someone went through the time, effort, and sunk cost of all that painting, but to the customer, the bug remains. 

A: “The most upsetting part is how wonky the clock is.”

By measure of tacked-on emojis, this was our most popular complaint and bug distinction amongst my colleagues. One replied with a scathing, “I cannot unsee this.” To these focus group “customers,” again, the issue was not the obstructed 8, 9, and 10. The bug is simply the fact that the clock still needs to be turned slightly to the left so that the 12 and 6 are straight up and down.  

How costly would that bug fix be in comparison to the time and money that would’ve potentially been spent on the paint job? We actually can’t say for certain! This picture doesn’t give us a lot of info. Maybe the clock couldn’t just be turned. Perhaps the screw hole on the back of the clock is in the wrong place, and this is as straight as it will hang without some serious modifications, none of which the team has the tools for. Perhaps the clock is not operated by battery and is wired to the building’s electricity (this is very common in schools) and the clock has been bolted to the wall so that the wiring stays undisturbed. On the other side, perhaps this is in an art classroom, the paint was already in plentiful supply, and it took the art teacher not even two minutes to complete the paint job. 

From “the cost of applying this fix vs. that fix,” to “we can apply this fix now…but this fix is going to have to go into the backlog,” to “which fix might break something else entirely,” there are a million discussions to be had and decisions to be made when it comes to determining what actions will improve quality and what won’t. 

A: “We should also make all the small numbers much bigger to improve accessibility.” 

This answer…hits a little too close to home. Anyone else? I can’t tell you the number of press releases, blogs, speaking sessions, etc. that I’ve written countless drafts of, and sought so much feedback on during development…only to be told by someone after it was published, “You know what would’ve been awesome? If you’d said…” 

And, they were exactly right.  

Furthermore, even if I’m able to incorporate their feedback so that missing component is there the next time someone reads or hears a piece that I’ve authored, there’s no recreating the original experience for those who received v1. 

When should we discuss, determine, and build quality, accessibility, security, etc. into our products? Before we release them? Or, only after we’ve built, pushed to production, sold, and distributed our products to our customers? That way, they can then tell us, “I wish I’d have known the numbers were going to be this small. The wall this clock has to go on is so far from the students that nobody’s going to be able to read them. How long will it take to get my refund?” 

We hear all the time how the mean-time-to-repair (MTTR) in pre-prod is exponentially cheaper than once software is in production. That will always be true, whether we’re talking about baking in quality, performance, scalability, security, and accessibility from the start, and not only after our customers have pointed out their absence. 

A: “It’s a ‘workaround,’ but an unnecessary and unwanted one. I could tell the time anyway and it’s just made it apparent that you are aware that there is a bug and couldn’t be bothered to fix it properly. As a user, I’m also very bothered that the clock wasn’t at least straightened in the course of making the bodgy workaround and I’m left wondering what other sloppy shortcuts have been taken on quality.” 

This is my favorite response of the bunch. I’ve always loved getting into heated discussions around, “Who should ‘own’ quality?” but my favorite debate is around a far more important question, “Who gets to define, or determine quality?” For anyone who would like to begin preparing your retorts, I am staunchly in the “Your customers,” camp. 
 
Not the business, not management, not your developers, not testers, not analysts, nor anyone else who looks at what you’ve built, and who then establishes a score, ranking, or even just a general level of satisfaction, or a lack thereof with your products. 

It’s your customers whose voices and opinions matter most. As my colleague stated here, your customers may not view your repair as a “fix” at all. It’s merely a workaround in their eyes, and a “bodgy” one (used in Australia to mean “worthless or inferior”) at that. This customer is not only not impressed with what you’re telling them is a “fix,” they’re even further bothered by the fact that you didn’t straighten the clock while you were up there painting that “unwanted” addition. 

Did you tell them you couldn’t straighten it because the clock is bolted into the wall? Did you ask them if the paint job would fix the problem before you went to the trouble of slapping it on there? As they said, “I could tell the time anyway,” so who was this fix even for? 

How many times has a bug made it into production, where the immediate directive in an organization is, “Just get some (fix, workaround, edit, statement) out there ASAP.” Many of you may have experienced this painful reality firsthand. As my colleague so brilliantly points out, while we might think we’ll win the customer over with how quickly we responded, that customer may think to themselves just as quickly, “As a user…I’m left wondering what other sloppy shortcuts have been taken on quality.” 

How often do your customers provide you with feedback? More importantly, how often, and when do you ask them for it? And, maybe most importantly, what do you do with that feedback when you receive it?

Let’s all start asking more questions. 

Thanking a Storyteller: It’s not easy

I recently had the pleasure of delivering a one-hour keynote speech at SmartBear’s 2022 Go-to-Market Kickoff, and…it went really well! That is, outside of the migraine and near panic attack I suffered through immediately after it was over. While I’ve given what feels like a million 30-minute presentations and co-presented one-hour talks, this was my first one flying solo. Just me, and my story, and slides. When it was all said and done, before I even got off the stage, and after 100+ hours of preparation spread across three months, there was a sudden, jarring adrenaline dump. My brain just went into safe mode and basically told my vision, emotions, and overall sanity, “Yeah, ya done,” sending me dashing up to my hotel room for some dark silence I was in much more need of than a catered lunch.

When I returned to the event about an hour and a half later, and in far better shape, I was thankful for, and ego-boosted by, a number of very generous “Great job!” and “That was excellent!” sentiments from my awesome coworkers. But then came two other types of praise. One was probably given a dozen times, and don’t get me wrong! I know, especially based on the quality of the people who were giving it, that it was fully intended on being a compliment! It just…well, it’s complicated.

The other was expressed to me by a single person and left me feeling far more proud, appreciated, and seen than all the others combined.

A completely fine thing to say

Any variation of “Great job,” “That was excellent,” or “I really enjoyed that.” These are very nice things to say to a storyteller! (Or presenter, host, moderator, panelist, interviewer, etc.) I think I can safely speak for most storytellers in that when we’re in the process of telling a story, sometimes we can gauge the audience’s reactions and level of enjoyment, but sometimes we can’t. Maybe the lights are in our eyes and the audience is darkly lit. Maybe it’s on Zoom and people’s cameras are off, or their camera is at a poor angle or mounted to another monitor aimed at the side of their face. Maybe we’re pacing a stage, looking down at our feet to make sure we don’t step off the stage or trip on a cord. Maybe it’s the first talk of the day and everyone is half-awake, or maybe it’s the last talk of the day, and the audience is, again, half-awake.

We, as storytellers, for the most part, tell stories because we love doing it, but knowing that you love when we do it, too, is often a great motivator for us to keep wanting to tell more. Letting us know after the fact that you enjoyed a story/presentation/webinar (psst, they’re ALL stories) is a very nice thing to do, even if you think a million other people might’ve already told us that, go ahead and let us know, too. For all you know, your opinion might be the one we’re going to be the most excited to receive. 🙂

A…not as fine thing to say

I’m not going to try to speak for all, or even a majority, of the storytellers in the world because I’ve done zero research to confirm who else feels this way. But, there’s one expression of presumed praise (I know these people mean well!) that I, personally, “literally cannot” with. The dreaded “You make it look so easy!”

Storytelling—and I’m talking about the really good, left you shook, opened your mind, changed your mind, blew your mind, stories that made you feel like personally thanking the storyteller for their time—is anything but easy. It is 0% less of an art form, craft, or lifelong pursuit than any other skill or talent on the planet. I promise you. The world’s best stories, whether authored by anyone from Toni Morrison to David Sedaris, or presented on stage at a tech conference or Broadway, or shown in dazzling HD colors from Activision to Disney (Encanto FTW!), all of them went through countless combinations of drafts, copyedits, rewrites, dry runs, rehearsals, test screenings, table reads, beta tests, chopping blocks, and cutting room floors.

On top of that, for some, and no matter how much they enjoy doing it, nor how many years they’ve been doing it, storytelling can be exhausting. Mentally and physically.

If, the next time you’re watching a story be told, and you truly are sitting there thinking, “They make this look so easy!” and you find yourself reeeaally wanting to say that to the person afterward, would you be willing to try out the suggestion below?

A wonderful thing to say

Whether you’re able to speak to a storyteller in person after their speech, or presentation, or performance, or you’re shooting them a quick note on Slack, or social media, at least think about being one of the few who will also say something like, “That had to have been a ton of work,” or, “You clearly spent a lot of time creating that.” I think you might even be able to get away with “You make it look so easy!” if you immediately follow it up with “…but I know that’s because of how much work you put into it.”

I’m in no way a student or scholar of human behavior or sociological wiring. But, doesn’t it feel like it’s almost second nature for us to, unintentionally, write off or discount other people’s impressive feats and accomplishments by attaching that “they make it look so easy,” label to them? We do this or hear this being done to athletes all the time. Describing Steph Curry’s jump shot as “effortless,” when we know that he’s been training his whole life to be as good as he is and that he continues to train to get even better! Or when an announcer says, “It’s like she’s just having fun out there!” about Chloe Kim as she dominates yet another snowboard run. She probably is having fun. How many globally recognized, generational athletes hate their sport(s)? But, to convey that they’re “just” having fun, and not, you know, also at work, work that includes things like “not dying in a horrific accident,” all while being watched and judged by millions across the world, is disingenuous and completely dismissive of the time and effort you know they’ve put in and which are worthy of recognition.

I love telling great stories, it’s in my blood (more on that in the next blog!), but I love the work that goes into them just as much. One truly doesn’t happen without the other, and that’s thanks to you, and every other audience I’ve ever had. The next time you watch and/or hear a great story and you get the chance to speak with or write to the presenter afterward, remember that they didn’t just give you the time they held the mic, faced the camera, or walked the stage. They felt like you were worth a lot more of their time than that one moment that the two of you and their story spent together.