When I began my career as a software engineer, I suffered the misconception that software development was a straight-forward, unidirectional, two-step system:
This misconception led to a series of pernicious beliefs in how I approached daily work.
Pernicious Belief 1: Shipping == Value
Engineering is only responsible for shipping as shipping is the most visible mechanism for realizing an engineeringâs value. An engineerâs value to the organization is worthless until they smashed that âMerge pull requestâ button.
Pernicious Belief 2: Engineers Are Paid to Code
The majority of an engineerâs time should be spent inside their IDE. After all, this is why engineers are paid: to produce text files full of variables and functions that, taken together, comprise a feature that product determines valuable. Anything beyond the scope of code is the domain of product.
Pernicious Belief 3: Say âYesâ
Pushing back against the straight-forward, unidirectional, two-step system is akin to heresy. The product team understands the problem the best and engineering is there to build productâs vision. Engineers are supposed to say âyesâ.
The Ease of âYesâ
As a software engineer, you are inclined to code. There is a lot of pressure to ship and âdeliver valueâ. Product is always looking to move forward on their roadmap. Users are always waiting for new features and bug fixes. It becomes extremely easy to say âyesâ to everything - especially when you align shipping with value.
Yet, there are few pitfalls to being so amenable. By constantly saying âyesâ you:
- Treat the product organization as a boss instead of a teammate
- Surrender your personal input on the productâs vision
- Fail to ask why a feature should be built
- Most likely ship WRONG features
- Unintentionally signal your apathy or, worse, laziness
Such an approach is the path of least resistance when it comes to software development. It is hard to step back, thoroughly assess a proposal, and say ânoâ.
The Challenge of âNoâ
It can be difficult for engineers to say ânoâ to features as they are ostensibly paid to build features. Saying ânoâ means value will not be delivered; it interferes with productâs roadmap and planning; it might nullify significant design resourcing or another teamâs investment.
Saying ânoâ can be difficult especially when senior leadership is driving an initiative. Attempting to stop such organizational momentum probably appears more troublesome than it is worth.
It takes confidence to say âno - this feature is not worth itâ.
But, the first time you do, and successfully argue why, you will want to say it more often. Saying ânoâ means you have taken an active role in the product roadmap and are asking why features should be built. Saying ânoâ means you believe the return a feature promises does not justify the cost of its implementation. Saying ânoâ means you care about your product, your team, and your users.