One frustration as an early career developer can be suggesting a change you think will make developing software faster but not being able to convince your lead or manager to allow time for doing it. One frustration as a lead developer or engineering manager is early career developers suggesting changes that will need a lot of work for a small benefit relative to other work they could be doing.

Thinking about how much of the bigger picture each person can see can help with figuring out how to handle these situations.

The early career developer usually only has a view of the part of the codebase they work on. The changes they want to make could indeed make them faster. They most likely have underestimated the amount of work involved and overestimated the amount of time saved though. They also may not realise that the proposal will save some time for them but add extra unplanned work to other teams that makes the total engineering team slower.

The manager or team lead receiving the proposal can see more of the business and engineering picture. They can see that the developer working on a new feature, or a different piece of code, will likely have a larger ROI for the company. They have better knowledge of the opportunity costs of doing the work the developer is suggesting.

Lets take an example. The team works in two week sprints and the proposal is to spend a sprint working on something that’s thought to save half a day per sprint. There is an upcoming big sales opportunity that the company needs to be ready for. The developer is working on a feature that will help with that.

For a single developer it will take twenty sprints, or nearly an entire year, for the work to “break even” in terms of time saved. (I rarely see any proposals like this that have calculated how long it will take to pay off the investment in time.)

Lets say getting the sale means the company can hire another developer for the team. Not only will the team have helped land the sale but they will have more capacity post hire so even if their process is a half day slower per sprint they will be able to get through more work.

So is it worth the risk of the feature not being ready in time and missing the sale? From the companies point of view probably not. Saving that half day per sprint for one developer isn’t worth the risk of missing the sale.

My examples are straw man arguments but the point is to show that different people in the same company can have very different views of what is important to work on.

While you might not want to explain the bigger picture every time you say no to a suggestion, it’s worth taking the time to explain it occasionally. Understanding how the work they do fits into the wider organisational picture is one of the things that makes a developer more effective. If you can understand how much of the bigger picture they can see right now you can show them a bit more and teach them you’re not just saying no because you don’t like change.