How to Say 'No' as a Software Engineer
One of the hardest lessons I learned as a software engineer was to say ‘no’ to various requests. I was always saying ‘yes’ to all sorts of requests; “Sure, I’ll come to check out your computer.”, “Yes, I can add that feature in.”, “Yep… not a problem.” Then, I’d get in trouble with my manager or the Director of Software Development… “You have to tell them ‘no’.”
Troubleshooting
Starting out as a junior developer, you know enough to code up some stuff and can troubleshoot some bugs. You may have even been part of software deployments and have experienced issues with the deployments. Issues like the CDN cache for web applications wasn’t purged, a new Windows update killed the application after installation or the corporate anti-virus software flagged a DLL and you can’t complete the installation. These days, we deal with web-based applications, so there are so many things we have to troubleshoot and so many enhancements that the company or customers want.
When I first started over 20 years ago, this was one of the most time-consuming things I had on my plate. We had a client-server desktop application that we had to deploy to all of the computers in the company starting at midnight and finishing up around 3 AM. The next morning and for the next few days; since I was a junior dev and didn’t know how to say ‘no’, I went around troubleshooting any issues people had… none of them were due to the application we installed, but everyone thought it was.
The lesson learned was that if I just wrote down the issues people had, I could take it over to the network admins/tech support to work on. I would later tell people to email me the issue (a covert way to say ‘no’) to get it on a list to fix and then just forward those issues to tech support. I would blind copy (bcc) my boss of these requests so that he could talk to those department heads about asking the tech support department and not software development.
I just never said no to the CEO of the company… she yelled at and scared a lot of people.
Documentation
Documentation will identify what a feature does, how it functions, and why we’re adding it.
I’ve worked at places that allowed for documentation to be done upfront as part of the waterfall methodology, and places where all I got was an abstract drawing with some verbal explanation and told, “Build that.” Documentation will be key to every project’s success as you’ll know exactly what to build and QA will know how to test.
I once had a project where I was rewriting an old MS Access DB application with ASP and VBScript… yeah, that’s right; I’m old-ish. I knew how the Access DB worked as I had built various features into it and had created some reports, so everything was going perfectly. The problem came when I took a verbal explanation on a report from the VP of International Recruitment and built what she wanted. I went back and forth with her as politely as I could and she kept getting frustrated with me, yelled and berated me in front of her entire department, and demanded to talk with the Director of Software Development.
I set the meeting up with everyone. At the meeting she vented and I defended my work with her explanations. Long story short, things got really heated, I was told to leave the meeting, and after another hour my boss came to me and said “Next time, get everything in writing.” There was no documentation to explain how the report should have worked and the VP of International Recruitment couldn’t document how she pulled pieces of data from different sources, put them together, and make sense of them knowing what was right and wrong.
Huge lesson when starting out… get it in writing. If you have any problems understanding what someone wants or how it’s supposed to work; work with them to document it. This way, if they complain that it’s not working as they envisioned, you can refer back to the document that they worked on with you and signed off on. This is the most diplomatic way of saying ‘no’ to verbal explanations.
Scope Creep
When you’re working on building certain features, there’s a time constraint as the company wants to push that feature out as soon as possible. During that development time, you may get requests to add and/or change things that can prolong the development and affect the deployment. Everyone’s timelines get messed up.
This is scope creep. Developers try to avoid this at all costs, but there will always be that one project or person in leadership that won’t budge or compromise. They want it all and they want it done on time. There’s no getting around this one.
You. Will. Encounter. It.
The lesson to learn about this and the best way to say ‘no’ and hopefully put it on a backlog for the next release is to give them the estimate on time and provide some alternatives.
- Be honest; tell them how much longer it will take to complete
- Offer to remove certain features to accommodate the change
- Ask for the minimal viable product (MVP) — enough to make them happy
- Can it be done in phases… similar to the MVP
- Swarm the problem… can more devs help build it in?
- Let them know if it requires a new library or tech stack and you have to learn what’s out there and how to build it in
- Lastly, remind them of the time to dollars… how much will it cost?
Final Words
In time, you will learn how to say ‘no’ to various requests and demands… just don’t be an asshole about it. Ultimately, if you’re building software for internal or external use; the stakeholders (i.e. CFO, CMO, or client) are going to get what they want.
Know your limitations, set boundaries, and get it in writing.