Software Engineers: Maximize your value. Reduce your frustration.
Disclaimer: This article aims to highlight what I often see as being the main driver for individual frustration in software engineers working for organizations who’s core business is not necessarily tech.
You graduate. Write up your very first CV and cover letter and start looking for your first professional adventure.
You get a job and you start developing. You’re happy.
Then one day that happiness starts to fade away, motivated by one or multiple factors. You don’t always understand the decisions being made and you find yourself having conversations with your peers where statements like “it makes no sense”, “this is not how you build software” or “if I was in charge, I wouldn’t do it this way”.
Granted there’s an element of purpose and context (“Why?”) lacking in scenarios like the one I briefly described above, there is also something else.
There’s a brutal painful truth, that software engineers in general have a hard time realizing when they are engulfed in the mindset of a “good software engineering” and all the principles and guidelines taught during their academic years.
The world isn’t fair.
We’ve all heard this so many times and as we go through different experiences and become older, we start to relate more and more to this sentence. And what’s funny about it is that you probably realize this even more the moment you get into the professional world.
From a engineer’s perspective, it often boils down to things like:
- Lack of innovation or experimentation
- Constant focus on new features
- Neglecting the technical debt
- Focus is always on business demands, hardly ever on technology
- Our feedback is not heard / not valued
The painful truth.
One aspect most software engineers don’t understand is that they are not being paid to build amazing, perfectly written software. Yes, it’s important the code works, is well written and documented so that the engineer next to you can pick it up in the future. But let me break it to you: if you find yourself pursuing this, you’re bound to fail.
The amount of frustration and disappointment this misconception generates is quite significant and has a growing effect over time. Often, it leads to quitting your job.
Your mission is to translate business needs into workable software. How you do it can be quite irrelevant when you throw elements into the mix such as timelines, budget and risk.
Failure to do this, leads to the never ending discussion of priorities and why this and not that. It will affect the overall morale of the team, the velocity and ultimately make stakeholders unhappy as they are constantly hearing and getting some push back from the Tech team.
Being Agile. As an Engineer.
One of the principles of Agile, is to be adaptable, flexible. Being able to adjust to change as it happens is probably the most sold aspect of Agile.
On the other hand, understanding the business, making trade off's and being flexible as a software engineer is the least sold aspect of Agile.
This means that you will have to write code that is not optimal, that is not covering all of the use-cases, that is not scalable or that is hard coding certain parameters that should otherwise be configurable. It means you will have to work on features that you don’t fully understand the value of (although you should — again, ask “Why?”) or that you would deprioritize and swap with something else that speaks closer to your techy engineering heart. It means all of these things and many more.
What you must understand is that this does not make you a bad engineer. It makes you someone that is capable of making concessions for the benefit of creating value when the business, market or customer needs it.
Don’t forget to not forget it.
These decisions have to be documented. They must be followed by the immediate creation of an item on the backlog to revisit it and rework the solution so that some — if not all — of the concessions made are corrected. (Tech debt)
Every principle taken to an extreme will have a detrimental, if not opposite, effect. It’s important to keeps things balanced. If you’re flexible and adaptable, it will be easier to make agreements and commitments with your Product Owner and Stakeholders.
Maximize your value
The world isn’t fair and it certainly isn’t perfect, but if you as a software engineer, understand that your value is maximized when you partner with your business counterparts, it makes your ride so much easier.
A Software Engineer understanding software and technology is expected, but when he also understands the business, then that’s the perfect combination.
