I’m Known for Saying No at Work

A client once asked me to add a button. I said it should be easy, which was my first mistake.

When I worked as a full-stack developer, I did a lot of front-end work for clients. This meant I spent a fair amount of time answering questions that began with “Could we just,” followed by something that looked very small on a screen.

One client wanted a button added to their site before a launch. It would stay at the bottom of the screen as visitors scrolled, so they could request a quote without going back to the top. Perfectly reasonable idea. I looked at the mockup, saw a rectangle with some words in it, and said, “Sure, that should be easy.”

I would like to formally apologize to the version of me who had to do the work after that conversation.

Adding the button was easy. Getting it to behave on the actual website took considerably longer. On mobile, it covered part of the cookie banner. Once I moved it, it competed with the chat widget. Opening the quote form brought up the phone keyboard, which left approximately four pixels for the person to see what they were doing. Meanwhile, the rest of the launch work continued to exist, despite my strong preference that it wouldn’t.

The client hadn’t done anything wrong. They’d asked for something useful, and I’d told them it was easy. They had no reason to know their button was going to fight three other things for custody of the bottom of the screen. That was the sort of thing they were paying a developer to think about. Unfortunately, their developer had been busy trying to sound helpful.

I got it working, but it ate into the time I’d set aside to check the rest of the site. Then, during the review, somebody asked whether the form could slide in from the side instead. They’d seen it on another website and liked how it looked.

I wanted to say yes. Partly because I could see how to build it, and partly because saying no to an animation after you’ve already built the entire form feels petty. How long could it possibly take? I had apparently learned nothing.

This time, though, I looked at what was left before launch. We still needed to check the forms, fix a couple of mobile layout issues, and make sure the site worked for people who weren’t viewing it on my exact laptop. I told them we could revisit the animation after launch, but I wanted to finish those checks first.

They said okay. We moved on. I had spent more time worrying about how they’d take it than they spent being disappointed.

That’s the part I try to remember now, because I have a reputation at work for saying no. I ask what a request involves, whether it needs to happen now, and what we’re going to put aside to do it. Occasionally I ask whether we need to do it at all, which is a good way to briefly stop being the fun person in a meeting.

I’m not under the impression that every request is secretly a disaster. Most people are asking for something that makes sense from where they’re sitting. The client could see an improvement to their website. I could see the unfinished work and the deadline. If I agreed to everything without mentioning that, they’d reasonably assume we had time for all of it.

And I know how tempting it is to make that assumption work. You stay a little later, skip a proper review, or tell yourself you’ll catch up tomorrow. You might pull it off, too. That’s what makes it such an easy habit to keep. The person asking gets what they need, and you get to feel useful right up until you look at everything else you haven’t finished.

I’d rather give someone enough information to choose. We can add the animation, but it means moving the launch. We can keep the launch date and come back to it afterward. If the animation matters enough to delay things, fine. At least we’ve agreed on that before I’m trying to explain why the site isn’t ready.

Sometimes the answer will disappoint somebody. I can live with that more easily than telling them on Friday that the thing I promised isn’t coming. By then, they may have made promises of their own.

I still like being the person who can figure something out. That was a lot of what I enjoyed about development, and I don’t want to lose it. I just try to ask a few more questions before volunteering future me for an evening of debugging.

Especially if it’s just a button.

I’m writing a book about this called Default: No, on the simple practice of protecting your time, energy, and attention.