Learning to Say No

Among all the code, all the frameworks and SDKs, all the programming patterns, all the agile project management that I’ve learned over the years, I think one of the most valuable skills I’ve learned in my career as a professional developer is the ability to say No.

Validation Through Lines of Code

When I started as a young developer I was anxious to prove myself. Although I was hired as an ASP.NET web developer, I would take on any project I could get my hands on. This soon gave me a reputation as someone who could get anything done in a short amount of time (although it was easy to look that way compared to working in the legacy codebase most of my co-workers were confined to). While this boosted my ego and confidence considerably, it also left me open to being the “go-to guy” for anything and everything.

Distributed Failure

Before I knew it, at the peak I was responsible for the development of 13 different applications in the company – these ranged from lightweight console apps to a full-fledged eCommerce and CMS application. One immediately thinks “talk about job security!”, but the reality was that my focus was so distributed that I could barely get anything done in any project, and what I could accomplish was so hacked together that it required even more support after the fact.

Not surprisingly, the quality and use of those projects started to drop substantially. The bugs that were introduced weren’t being fixed in a timely manner, and the lack of new features started to drive existing and new users away from the products. In addition to hurting the business bottom line, I was hurting myself as a developer – I had no time to develop any new skills or even invest in processes that may alleviate the situation. Hiring someone else to help with the workload was also an issue – I had no time to train additional staff.

Saying No to Get More Done

That’s when I started to learn to say no. Despite all of the above I was still being approached for new projects – I said no. One-off feature requests that would come in from individual users of the software – I said no. Even some new opportunities within the company that I was offered – I said no.

I also started using some project management approaches such as iterations and velocity to help me say no. If others would approach me with a request I’d show them my iteration plan and ask them if their request was more important than any of my sticky notes – more often than not it wasn’t, but in the odd case where it was they worked with me to re-prioritize other tasks. My web team of one eventually was able to refocus, gain some new employees, and knock out a few really important apps well.

Saying no allowed me to refocus as a developer on the things that are really important – not only to myself, but also to the business and the end user. Focusing on one or two products allowed me to spend time on scalability and deployment issues so I wasn’t pushing to live on my own laptop by myself at midnight. Since then I’ve had the time to grow into a great C# and JavaScript developer, learn some new skills, work on my presentations and public speaking, and start some great community initiatives. When new opportunities come up, I have the resources to at least evaluate and prototype them, instead of being so stressed out that I can’t even consider it.