Five Reasons Why Developers Miss Chances to Create More Value

I started my career as a software developer, and my dream was to become a software architect. The digital world has always fascinated me, and I enjoyed my job a lot; creating solutions lit a fire in me. But at some point, I realized my work wasn’t making others’ lives any better. My solutions were either being trashed or not used, and I didn’t know why until I talked to an actual end-user.

Talking to end-users, I perceived a massive gap in our processes. Management decided what to do, and project managers created a lovely plan full of charts, and we were convinced we knew what we had to do. Unfortunately, nobody talked to real end-users, because managers thought they knew what users needed. I wish they were right.

I learned the pain of GIGO the hard way. Garbage In, Garbage Out.

After some years as a developer, I decided to move to product management because I didn’t want any developer to create trash. I thought I could help teams create value. However, when I became a Product Manager, I faced many challenges with developers... and sometimes went against producing value faster.

I’ve already fallen into the mentioned traps either as a developer or a Product Manager. Hopefully, you can avoid them on your journey. Allow me to share the five reasons developers miss their chances to deliver REAL value.

1 .  Solution Orientation

What matters most, implementing a solution or solving a problem? It makes no sense to talk about solutions without knowing the problem that needs to be solved, yet I often find myself in deep technical discussions where the problem is unknown.

Developers are passionate about creating solutions, and that’s great. But it’s also a trap. Developers tend to ignore the problem if product managers don’t clarify it. Still, I don’t want to generalize because experienced developers ask for the problem before talking about any solution.

The implementation trap is falling in love with the solution and building something extraordinary that nobody needs. Everything starts with understanding the problem and then figuring out how to solve it.

Once I had a great conversation with a developer about identifying the correct size solutions It went like this:

Me: “Three months ago, we were 20 people, and now we are 50. Our internal system needs to have adequate user management.”

Developer: “Sure. Tell me more about it. What do you want to solve with that?”

Me: “I want to ensure that users are limited to doing what is related to their responsibilities. Currently, everyone can do everything, and this is dangerous.”

Developer: “I see. Let me tell you what. Imagine a mosquito is lying on the wall. You can kill it in several ways: I could smash it with my flip-flop, or I could build a bazooka to kill it. What kind of solution are you searching for?”

Whenever I see deep technical discussions, I ask developers, “Are we building a bazooka to kill a mosquito?”

2 .  Segmented Accountability

A few things annoy me more than discussing splitting the stories into back-end and front-end. The issue often happens during refinement sessions. After explaining the problem and adapting the acceptance criteria, a developer asks, “Can we split it into back-end and front-end?” Then, I answer, “Can the user use only the front-end or back-end part of it?” I am more than tired of this.

Gone are the times when everybody does their part in software development. Now, everyone is accountable for the whole. Discussions about splitting the stories into technical boundaries do not create value for the users.

Developers are self-managing and should be able to organize their work and collaborate to solve problems as a team. Segmenting work also ensures a segmented responsibility.

User Stories can and should be divided into smaller items to deliver value sooner. However, be careful how you split them. Take a cake as an example: you cut it vertically and not horizontally; each piece has everything you need to enjoy. The same should be with User Stories: they should contain everything needed to create value.

3 .  Refactoring Obsession

I know code needs maintenance to remain scalable and maintainable. This is natural. However, not everything needs maintenance all the time. What surprises me is the obsession with refactoring. Something annoys developers, and immediately they want to refactor it. The question is, when does it make sense to refactor and when does it not?

It’s not because you have a problem that you must fix immediately. Before deciding upon a refactor, I like asking the following questions:

• What happens if we leave it like it is?
• What would be the benefit of refactoring it?
• How many users are impacted by it?
• What are the side effects and consequences we may have?
• How long do you think it would take to finish?

These questions are not meant to block developers, but to reflect on whether refactoring will pay off. As with everything in life, balance is essential. Understanding the need for refactoring is critical. For example, considering it’s a key part of the product, and it impacts 80% of the users, and without that the product becomes worthless, this case would justify refactoring. But it could just be a simple feature that only 2% of users benefit from.

Great developers know when it makes sense to refactor and when it doesn’t.

I don’t like worrying about a problem I don’t have. Refactoring everything ahead of you is like avoiding all problems you may not even have. This is a risk-averse attitude, and to deliver the value, we need to take risks and learn as quickly as possible.

4 .  Cutting Corners

When the pressure comes, what’s the first thing to cut? Unfortunately, quality is the first to suffer if developers feel pressured. However, once stakeholders get used to receiving more, they won’t accept less. What will happen then? Developers become trapped.

Cutting quality processes is unsustainable and will inevitably lead to major consequences. I’ve already lived through that several times. My suggestion is to set a minimum standard of quality, and not accept going under that bar, which  should preferably be already set quite high.

Let me share some things that work once or twice but can put developers in tough situations:

• From local environment to production: it speeds things up and creates a major unneeded risk
• Execute scripts directly in the production environment: if you love strong emotions, just do it
• Skip test process: no unit test, no automated test, and life of fixing bugs

5 . Lack of Transparency

In many situations, developers are imprisoned by a poor Scrum implementation or whatever framework they use. Developers may get tired and start doing things independently without communicating with other team members. Unfortunately, that only leads to bad results, frustration, lack of commitment, etc.

Lack of transparency is a perfect choice for unpleasant surprises.

Let me circle back to refactoring. I had a developer once ask me to refactor a code for our invoicing process. I asked him why he perceived that as important, and he told me the code looked terrible. I was the Product Manager, and his answer didn’t convince me, but I shared my perspective by saying, “This process has been up and running for a year now. It never presented a problem, and we have no plans of changing it or implementing new features. I don’t see why a refactor would benefit us.” The developer only said, “OK.” I should have known he didn’t accept my explanation.

After this exchange with the developer, he started being unproductive. I talked to him, and he said everything was fine. Four weeks passed, and one day I arrived at work to find an e-mail from an accountant. “David, please look at our invoices asap. The VAT is incorrect everywhere.”

I couldn’t connect the dots. I talked to the team and said we would have to solve this issue. A couple of minutes later, a developer came to me and said, “There are tons of changes in this process. It went live yesterday without QA.” At that moment I connected the dots: the developer didn’t accept my answer and refactored the code on his own volition.

To make a long story short, the whole team had to work late for three days to fix a problem we didn’t have. Transparency is vital for collaboration.

If I were to find myself in the same situation today, I would ask the developer to create a backlog item and bring it into refinement. Then, as a team, we could evaluate and decide how to proceed. This attitude generates commitment because the whole team decides what is best for the product.

Final Thoughts

I am a developer by heart, and the reason I became a Product Manager was to ensure developers would be empowered to create value. I believe developers can create more value if they put their energy into the right things. Here are the attitudes I believe to be helpful:

• First comes the problem, then the solution
• Quality shouldn’t be negotiable
• Worrying about an inexistent problem causes more trouble than help
• Collaboration is more critical than segmenting work