The my previous post on Engineering craftsmanship and getting value out there
Table of contents
Open Table of contents
How we solve problems
Last week I was watching a great video from Daniel Terhorst-North called The Best Programmer I Know, where he discusses a brilliant programmer who, rather than solely focusing on craftsmanship, prioritizes delivering value. It struck me how often, in the tech community—especially with the rise of SaaS and micro SaaS businesses—engineers, myself included, can lose sight of the real problem we’re trying to solve with technology.
You might have experienced this or know someone who has: at the start of a sprint or a milestone, tasks are assigned in Jira, complete with mock ups and, if you’re lucky, well-written user stories. From there, the focus shifts to writing the code, pushing it through QA, or shipping it to production. But in this process, we often finish and deliver features without fully understanding the deeper motivations behind them. Many times, we’re left unaware of how our work impacts the users or the business. This disconnection between engineers and the product or business side I consider being one of the biggest challenges in software development.
Software is made to solve people problem, no machines problem
Lets take a high latency problem, at first you might think: This is clearly an “Engineering Problem”, but I would ask back what is high and why is this bad? A high latency problem is only a problem if this is affecting the value we want to provide, take for example a dashboard page. If the dashboard page takes 5 seconds to load every time a user click in a table filter this is a problem, the customer is sometimes spending more time on loading screens rather than doing what its supposed to do.
Now lets take an async flow that sends an email to the same customer, after a status change the server takes 5 seconds to send a message to the customer. You might think: This might be a lot of time but for the customer or the flow this doesn’t affect the final value we want to achieve, thus not requiring us to change, even as we feel it could be faster.
As software engineers are a scarce resource, we should be very mindful of our time and where we allocate our efforts.
Solving real world problems
When solving problems in the real world we should be always remembering the following points:
Being close to the users
So in order for us to be effective and good engineers we should be close to our final users. As solvers of their problem we should strive to understand as much as we can and design the solution that best suits them.
When we understand the user pain and, if possible, see them going through it, becomes way easier to design a tailor made solution for them.
Understanding the business and the impact, and your role in it
Another point to always pay attention to is business impact, if you want to quantify how much money you’ve saved or X % conversion you’ve improved. If you’re working to write code that is going to be present for maybe years to come better to understand the value it brings and what is expected from it in the long run.
So one good thing is to always be in sync with the business person and getting to understand all the flows that compose the solution that you’re participating. This not only brings clarity and sense of ownership as well as creates a good view of your impact (your brag document likes it).
So, “adding new button on the screen to increase conversion” can become:
Participated in an effort to improve conversion by 30% in the hiring flow. This change will bring 1Mi USD in revenue due to the more intuitive and accessible flow in the app.
You might be asked just to add a button but when you know why it becomes a big task.
One famous quote during a visit to NASA, President Kennedy noticed a janitor with a Broom going down the hallway and asked what he did for NASA and he answered:
I’m helping put a man on the moon.
Avoid creating problems just to solve them
As engineers we love to create stuff and solve problems, sometime even we create problems just for the sake of solving them. One funny content creator called Matty Benedetto created the unnecessary inventions that he creates inventions that as the name say its unnecessary. When you see them, they are cool and funny and sometime even questionable helpful. In engineering we often create solutions and recurrently automate works that doesn’t need to be automated. So if you find yourself in a place of I think I’m running out of things to do or maybe I could solve this X thing, stop and go back to the current business focus and ask yourself
This will make me get closer to delivering this?
Conclusion
So be there more with your PM, get to understand the user behavior sit beside them. And focus in how will you make your team move closer to the end goal. And be aware of the self made problems, we already have lots of problems to solve! Don’t create new ones just to solve them.