The “No, But” Engineer

When I was about 21 years old, I signed up for a one-day improv workshop in New York City.

The extent of most people’s knowledge of improvisational comedy probably begins and ends with Whose Line Is It Anyway?, a television show that first premiered in the UK during the late 1980s and, as of this writing, recently broadcast new episodes within the last few months on The CW. During the show’s original run in the US, then-current host Drew Carey was described as a man who “pretends to laugh at guys pretending to improvise.” Jimmy Kimmel, The N.Y. Friars Club Roast of Hugh Hefner (2001) Whether that allegation was fair or not, I can’t say. But I can say that, if you are familiar with the show, you would also be familiar with the way our workshop was run.

Improv isn’t just a collection of screaming jackasses; there are actually a number of rules that each performer should abide by to make the scene work well. Most of these rules boil down to two things: 1) always add new information, and 2) always accept and respect the information added by others in the scene.

If one performer exclaims something like:

“Wow, I can’t believe I made it to a major league baseball stadium! Hey, it’s all-star hitter Neil Blatz!”

The worst thing the next performer could do is say:

“No, this is a pet store and you just let all the hamsters out!”

That’s selfish. It disrespects the premise and the other performers in the scene who worked to put it together. It destroys the momentum of the entire show and kills the audience’s enthusiasm. It basically wrecks the whole afternoon.

The shortest way to express the rules? “Yes, and…”

In the workshop we did, I was paired up with another first-timer named Remmy. I think that’s how his name was spelled. With the help of a suggestion from the rest of the group and a bit of yes-anding between the two of us, we arrived in a scene where I was a stern representative from the company’s HR department and he was an employee coming to my office to discuss the latest complaint lodged by his coworkers.

As the scene progressed, we arrived at the premise that he was way, way too into the Magic: The Gathering card game and would talk incessantly about it to the point where it was harming productivity. I responded yes, and this has been causing a tremendous amount of paperwork for everyone in HR. He then turned his attention to me, where he began prattling off such extremely specific details about the cards and their relative capabilities that I was quite sure he was bringing a deeply authentic part of his actual self into the character. I knew virtually nothing about the game, but I responded to each of his details with increasingly absurd commentary of my own. Yes, and then Joe barricaded himself in the supply closet. Yes, and then half the office quit. Yes, and now I’m the only member of HR that hasn’t run away screaming; it has been a tremendous amount of paperwork.

From the front row of the audience, the workshop leader held three fingers in the air. This was our signal that we had about 30 seconds if we wanted to try to wrap the scene up.

Remmy was still going on about all the different cards, so I slowly turned away, climbed up on the chair, and mimed tying a noose around my neck. I closed my eyes, stepped off the chair, then stood swaying with my tongue stuck out. If you had told me prior to that day that I would get up in front of a room full of strangers, act out an imaginary suicide by hanging, and that I would be rewarded with laughter for doing so, I’m not so sure I would’ve believed you.

I felt a tap on my shoulder. I turned and opened one eye to see Remmy, who had stopped talking. He extended an invisible stack of something, then delivered the final line of the scene: “Don’t forget your paperwork.”

Remmy, if you’re out there reading this, thanks for being such a solid scene partner.

The rules of improv work quite well when you’re making up a comedy scene. They permit each participant the freedom to propose something potentially ludicrous, but with the guaranteed assurance that their contribution will not be rejected. It’s a remarkably safe and supportive environment, and actually one of the least frightening forms of acting that an anxious or shy person can dip their toes into. The yes-and framework lays the groundwork for completely absurd and potentially hilarious situations to blossom. This is exactly what you want in a comedy scene.

This is precisely the opposite of what you want on your engineering team.

Guilty as charged

People go into tech for a variety of reasons. Some see the allure of easy money, others feel as though it may be one of the lazier paths through life. But for a number of us, the motivation is a desire to be useful. Something inside compels us to always look for problems to solve, processes to improve, or simply things to do. The word “useful” is a very deliberate choice; it does not automatically imply that the work is helpful. Perhaps you are the best baker in your social group. That’s an extremely useful skill in the abstract. But when you’re all trapped together inside a stalled elevator car, it is not very helpful. It can be very easy to fall into a trap where it feels like you’re wasting a lifetime of study and practice by not using your knowledge and skills at every possible opportunity. It’s an extremely hard switch to turn off.

Most teams of any appreciable size have a couple of members with this kind of energy. When harnessed well and directed effectively, they can be extremely self-sufficient and productive. They’ll soldier through the thorniest problems to find answers. They will move mountains if given the opportunity. However, get a couple of them together in a conference room without appropriate supervision and they can yes-and each other to unimaginably unhinged designs.

This has a tendency to react with another rather unfortunate background element in many workplaces: boredom. Whether we like to admit it or not, a whole bunch of us spend way too many of our days working below our abilities. We have the capacity to calculate rocket trajectories, tackle CPU pipeline hazards, improve open-source libraries that run on hundreds of millions of systems… yet we’re just sitting here bolting another authorization check onto some miserable CRUD app, or trying to shave a tenth of a second off of some ad’s load time. We get bored, then we get antsy, then we go looking for problems to solutionize, then we over-engineer. Pain follows shortly thereafter.

In some ways, the industry actually encourages this. For every piece of software written for fun and released in the spirit of fostering goodwill, there are dozens of other essentially-identical components written as works-for-hire that have been jealously guarded by the companies that commissioned them. Think of how many different e-commerce checkout pages you’ve interacted with, and how they’re all basically the same yet subtly different, like little crappy snowflakes that are each uniquely awful in their own special way. Think of how many account creation and password reset flows you’ve dealt with, how many person-hours have been spent reimplementing duplicate after duplicate of substantially the same thing. At this point it really should be classified as pointless busywork.

But if it keeps us from getting too much free time to conjure up something even worse, hell, maybe it’s actually the better use of time.

No, but…

If the intention of “yes, and” is to kite a given situation to newer and increasingly absurd heights, then “no, but” implies the exact opposite: a default position of rejecting the proposal while simultaneously offering an acceptable substitute. Sort of like the mean mother in the “We Have Food at Home” meme. In a room full of yes-ands, a single well deployed no-but can bring the conversation back down to reality. It is sometimes difficult and often unrewarding, but an incredibly powerful skill to hone.

It should go without saying that the “but” is just as important as the “no.” You don’t want to earn the reputation of being an unsupportive jerk who shoots everything down for no good reason. The Bastard Operator from Hell is not a role model, is what I’m saying. The “no” always comes from a place of rationality, while the “but” serves to share that perspective with others. The heart of the no-but philosophy is a genuine belief that the solution being discussed is not the correct one, paired with an alternative option that is either simpler, cheaper, faster to implement, or superior in some other meaningful way.

Both halves of this response are difficult. The “no,” if deployed indelicately, can lead to unpleasant responses from those who feel deeply invested in the idea or approach they were proposing. Sometimes we put too much of ourselves into our work, and having ideas rejected can easily feel like a personal rejection as well. Instead, a simple redirection in the form of “what about…” or “didn’t we already have…” or “wouldn’t it be more effective to…” can allow the no-but engineer to elide the “no” part entirely. There are dozens upon dozens of ways to phrase it, and doing it well can defuse a situation before it starts.

As for the “but,” that requires hard work over a long time. There’s no special life hack you can employ to accelerate the process. It takes a solid understanding of the problem space, any off-the-shelf solutions that may be applicable to the discussion, some degree of practical experience in using those existing solutions, and a reasonably clear insight into the specifics of the organization and what it values. If some other team has tackled this issue, what did they choose and how did it work for them?

Together, the no-but approach serves to deter that immediate knee-jerk response of “I see a problem, time to immediately roll up my sleeves and go, go, go!” The no-but approach is very much “stop, look around, think.” In any given moment, faced with some new and exciting perceived problem, it’s incredibly easy for a yes-and engineer to forget to do that.

An apparently rare breed

One would think that an employee with seniority—either a literal senior engineer, or principal/lead/staff level—would exhibit these traits. In my experience this is not automatically true. I don’t have a ready explanation for why this is. Perhaps it’s not something that management looks for during the promotion cycle. Maybe it’s because this industry has a habit of slapping the “senior” label onto staff who are barely three years out of college. Yeah yeah, “meritocracy” and all that. You’re telling me that a 26 year old has met all the qualifications to shoot to the very top of the individual contributor ladder at this organization? That seems, I don’t know, preposterously quick. Fact is, engineers at every level seem to be more than willing to jump headlong into these tangled messes of their own making.

An effective no-but engineer possesses a healthy mix of experience and insight, paired with a probably-unhealthy mix of skepticism and distrust. Those are hard things to identify sometimes, and they don’t really lend themselves to any sort of curriculum for self-study. There are some traits, though. Perhaps they can help tune to the no-but wavelength.

The no-but engineer:

Is not a dickhead. If there is one single piece of advice I wish I could give to everybody at every level, I would simply advise them to not be dickheads to each other. Nobody needs that toxicity in their life; it is counterproductive at best and can absolutely trash team morale. If it really permeates the culture, everybody ends up being a dickhead to everybody else and the whole place goes to hell. Don’t be a dickhead. Don’t work with or for dickheads either, if you can avoid it.

Is tactful. It’s easy to blurt out whatever might pop into your head, but it’s important to always be cognizant of how that expression will be received by those around you. Sometimes the way something is said is more important than the actual substance of the message. And sometimes—not always, but sometimes—the best course of action is simply to say nothing at all.

Is well aware of the broader organization, its needs, strengths, and bottlenecks. It can be easy to think of your team and its direct stakeholders as your entire known universe, but you all exist within a larger organization that has objectives and problems. The no-but engineer is well-poised to notice cases where the team seems to be moving in a direction that doesn’t help reach an organizational goal. Further, the no-but engineer is at least somewhat aware of the expertise and institutional knowledge available from other teams. There’s a good chance that somebody on the same payroll has something to offer.

Knows what’s going on under the hood. Just as important as understanding the organization as a whole, it’s also very important that the no-but engineer has a deep understanding of the technologies and practices used by the team. This can help cut through the fog of higher-level arguments and come to the realization that it’s all just different ways of pumping the same bytes through the same TCP socket. They are well aware of what’s in the language’s standard library. They know which third-party packages they would reach for when necessary. They know what kinds of tasks to avoid touching with ten-foot poles.

Has seen some things. Wide-ranging experience gives a substantial amount of perspective. It becomes easier to see patterns as you live through more and more situations. If the goal is to be able to identify instances where history is repeating itself, it would be a good idea to be well versed in those historical events. This also helps build empathy, and the ability to step into a different individual’s shoes and perceive the situation as they do. Sometimes it’s helpful to simply think back and recall times when you yes-anded yourself into something regrettable, how that felt in the moment, and what you wish somebody had said to you at the time. Sometimes a mildly traumatic experience outside of a work environment can help with this kind of perspective. I once had a fluorescent tube burst in my face. Now I’m not afraid of CMake. True story.

Is pragmatic. The no-but engineer accepts that sometimes it’s better to copy/paste a 50-line function rather than set up another goddamn private Git repository with another goddamn deployment key that we’ll have to keep remembering to rotate for-goddamn-ever.

Does not seek glory, and accepts responsibility for failures. Part of this ties nicely into not being a dickhead. This is not the kind of work that should be undertaken by those looking for a way to stroke their own ego. When successes come, the praise goes to the team. When things go south and fingers start pointing, the no-but engineer doesn’t try to argue, deflect, or gaslight anybody into thinking it was somebody else’s fault. If they screwed up, they screwed up. Learn and move forward. It should also go without saying, but “I told you so” is never anything that anybody wants to hear after a failure.

Hears what others mean, not just what they say. This is sort of the inverse of the tactfulness trait. Sometimes requesters don’t know what they want. Sometimes they know what they want but they don’t know how to phrase it. Perhaps they’re afraid of flat-out asking for something, so they dance around it. The no-but engineer knows how to set aside the letter of the request while looking for the spirit of it. Restating this interpretation back to the requester thus frees them from the responsibility of having to have done that difficult bit themselves. Lightly pushing back on a complicated thing and offering a more manageable substitute might save a huge amount of not-that-necessary-in-hindsight extra effort.

Is absolutely not a “rockstar” in terms of productivity. The no-but engineer would probably confess that they don’t have any idea what they’re doing half the time. Of course this is probably not objectively true. What’s likely actually happening is, the no-but engineer has a long list of topics they’re quite sure they don’t know enough about. It’s good to be aware of your own limitations, and impostor syndrome is a real devil sometimes. The best benefit the no-but engineer could bring would be to convince people (including themselves) to not write any code if they can avoid it. Code is a liability. Eradicate it whenever you can.

Embodies the spirit of “The Gambler” from that Kenny Rogers song. As hokey as the sentiment might sound, there is a certain wisdom in realizing that the outcome of so many situations depends on how we play our hands moment to moment. Know when to speak up, when to accept the impossibility of changing a situation, and when to just get the hell out of there. The gambler in that song is a role model of sorts, although for your own good health you probably want to ignore the bit about getting drunk and dying on a train.

I will now take no questions

You might very well be thinking, wait, why do we need such a strong contrarian voice here? Shouldn’t most professional engineers with some amount of experience have enough of a sense of restraint to prevent these issues? Failing that, shouldn’t part of management’s responsibilities involve ensuring that things don’t go too far off the rails? Why can’t we simply extrapolate from the corporate values set forth by senior leadership to stay aligned at every level?

You would think that, and yet here we are.

It’s not that you work alongside childish fools. Probably. It’s not that everybody is jockeying for the latitude to build some preposterous pet project using a hot new technology that they can sprinkle over their résumé in the hopes of getting some other job at a company that pays better. Probably. It’s not that management hires warm bodies to do nothing of value all day and none of it matters. Probably. For the most part it really just seems like a group of well-intentioned but slightly bored engineers have goaded each other into following a less than ideal but slightly more interesting path through their day-to-day work. Because if that isn’t the reason, then what are we all even doing here?

It really does seem as though every team can use no-but engineers to some extent. Even teams that already have one, that person could always use another set of eyes and ears. I believe that anybody who wants to become one, can become one. It takes time and effort, you’ll have to find ways to make it rewarding, and it can also drive you crazy if your organization doesn’t value that way of thinking. But you know what? Somebody else out there does, and they would be lucky to have a no-but engineer like you.

Oh, and do improv if you get the chance. It’s a blast.