Should Developers Solve Business Problems?
A few weeks ago I had a hot debate with one of my developer friends regarding quite a controversial topic — should a Developer solve Business problems? Whilst the answer was obvious to me, I was surprised to find out that there are two completely opposite ways of thinking among Software engineers. One half truly believes that development is done for the sake of business hence Developers must be involved in all processes as much as possible. And the second that doesn’t want to cross the line between coding and strategy planning preferring to stay away from “boring” meetings.
In this article I want to share my point of view on this and will try to inspire fellow developers to broaden their mindset.
Involved parties
Before going deeply into the problem let’s first identify the playing parties. I’ll take a classical enterprise example with 3 separate layers:
- Business: mostly Sales department, can also be Partners from 3rd party companies. This layer is responsible for making money out of every released feature.
- Product: aka Analytics, those who are listening to Business ideas and problems, analyzing them, conducting market research and setting the company’s strategic direction.
- Development: those who are making things done via code. QA will be included here as well due to the industry is slowly but steadily moving towards the state where most of the testing is automated and just a part of the regular development process.
One important aspect worth highlighting here — I am a big fan of the all-talking-to-all approach. There should be no strict hierarchy between departments but a circle of constant communication and open feedback:
Next important thing to understand is who are those Developers participating in Business problems discussions. Classically, industry identifies four roles: Junior, Middle, Senior and Team Lead. While it is quite simple to describe the first two, it is surprisingly difficult to provide concrete criteria for the latter two. But let me try my best here.
Junior: can be still a student, someone just starting the career; might have a solid theoretical background, but not enough practical skills. Also can be other way around — quite good practical skills gained from various video tutorials but lack of understanding of what is happening behind the scene. Soft skills are rather underdeveloped. Such kinds of workers are good for non-critical parts of application and work their best under guidance.
Middle: not Junior anymore! The main difference is hours of hands-on experience on a real commercial project with other fellow developers. Interestingly enough, knowledge-wise Middle is usually not very far from Junior as at this level many programming “mysteries” of a language and frameworks are still not faced in practice. On the other hand, such developers are already proficient enough to work independently on a given task within a known environment. You don’t expect them to “shine” and bring lots of changes, but rather work hard and professional. Some of them possess certain skills to grow further becoming Leads or Architects whilst majority happily stays on this level pretty much forever.
Senior: now comes the difficult part. How can one define a Senior? There is no concrete answer, rather a long list of qualifications to fulfill depending on a company’s needs. Just to name a few — multi-threading, SQL query optimization, hands-on Unix experience, proficient UI creation skills, list can go on and on. Practically speaking, it is nearly impossible to have all the required qualifications for each position out there. What makes a Senior stand out from a Middle is the confidence about themselves and their knowledge which comes from plenty of various problems solved over time. As a logical consequence of it — broader industry understanding and wider skill-set. My personal opinion — a Developer cannot become a real-world Senior working for only one company or in the same industry because experience tends to repeat, but to gain seniority one has to overcome various different issues.
Team Lead: this one is basically a Senior with proven ability to lead people. We mostly see this title on top of Senior but in reality those are usually coexisting on the same level. Team Lead represents the team he is in charge of and protects his people from the outside world.
Which grade should actively participate in discussions involving other departments? In my opinion all 4 of them, but with a different level of involvement. Usually, not much expected from Juniors and Middles, but it doesn’t mean they should not contribute. Conversely, Middle will only grow when he starts questioning things. As for Seniors and Leads, they are obligated to be as close to business as possible, actively listening and understanding the needs of their ultimate customers.
Business problems
What exactly are those business problems to be solved? One might think of various KPIs, brand awareness or leading market position. Whilst all of those are business goals I prefer to keep the problem statement as understandable as possible:
The sole crucial business problem is how to earn more money while spending less money on operations.
It all comes down to money. Those bucks paid to every developer at the end of a month, plus, if you are lucky, an yearly bonus. If a company is not doing great there will be less of everything — less conferences, less promotions and probably no bonus in December. That statement alone brings me to one and only conclusion on the given topic — a Developer must solve business problems if he wants his employer to prosper. We don’t write code for the sake of it. If a company goes bankrupt all those lines pushed to Git will be of no use. Instead each of us should strive to take part in business critical discussions and bring fresh ideas. Working closely with the Sales and Product departments, people of utterly different points of view might yield surprisingly great results.
Here comes one not so obvious real life example — working for yourself. If you ever tried, successfully or not, to create apps, games or websites outside of your 8-to-5 schedule you know that being self-employed is hard. Funny enough, coding here is the simplest of all as it is the “comfort zone”, you know exactly how to do it — learn a new framework or develop an efficient algorithm. Difficulties mostly start whenever there is a business decision to be made — what is the best monetization channel, how to find customers, where to do an initial release and dozens of similar questions. Having a trustworthy partner to take care of such hurdles is rather luck than reality. Most of us are either all alone or have another Developer friend-partner. Constantly being there I now have no doubts about whether an Engineer should solve business problems. If you don’t possess similar experience, I encourage you to try it for yourself.
Gains
Interestingly but as a Developer you can also benefit from the process in various ways.
First and the most important one is something that I call “hear the opportunity”. Being present on those high level meetings means to hear in plain human words what Business wants your team to deliver. There will be no statements like “I want this solution to work with constant-time complexity” or “we should definitely have Kubernetes“. No, you will rather learn and understand how this new feature will solve the customer problem. Knowing this will ultimately help you to develop the most optimized and suitable solution. Moreover, taking part in such discussions on a regular basis will broaden the picture of possible required changes in future which might help to build a proper architecture from the beginning.
Next comes “speak your mind”. You have a unique opportunity to speak up and be heard, discuss and find better solutions. You can even completely stop the idea right at the start if it is not feasible to implement or the cost will be too high. It is your opportunity to show them all the smartness of Developers.
The last one on this list is “turn down wrong decisions” which is directly related to the previous one. There can be various reasons why certain features should never be developed. Being that huge operational costs or a need to rebuild the whole system from scratch, it is also a Developer responsibility to prevent wrong decisions from happening. Instead of being passive-aggressive while reading the given task you can stop it right there by just talking business out of it. No coding required.
Responsibilities
Hopefully, by this point I have managed to convince you how important it is to have a synergy between all departments. You might be thinking: “okay, if I’m attending all those meetings and solving Business problems why does a company need so many other people?”. Questions like that arose in my mind countless times, but the answer is quite simple. Developers are responsible for implementation, delivery and operations. We are not involved in brand promotion or market research. In other words, Business will handle communications with clients, legal questions, marketing and positioning, make decisions and be held accountable for success and failures.
Developers don’t carry a burden of company-changing decisions. In the end of a day it matters very little which programming language is used as long as it works properly and generates expected revenues. Don’t get me wrong, big technical choices are indeed important, I’m not implying to use bash for Enterprise back-end, no. It is a Developer responsibility to select the most suitable set of technologies for the given problem. But without Business needs we aren’t even required to make any choices.
There should be no processes in place to prevent Developers from speaking to Business directly. In big corporate companies a huge amount of information is lost in communications and by the moment a ticket appears on top of Backlog it might be quite different from what was initially planned. Such problems are easily solvable if there is no bureaucracy or restrictions and Developers are treated as equal parties rather than coding monkeys.
As per Product responsibilities, I would highlight activities such as market research, crazy new ideas generation, listening to Business needs and validating their problems. In some companies Product will also translate ideas into concrete requirements in a form of tickets or specifications. In other companies Developers will create tickets on their own. Regardless of who takes care of creation, any task should clearly answer three questions:
WHY to build this feature
WHAT is the business value
HOW to validate that it works as expected
Conclusion
The IT industry is changing rapidly. Not so long ago the Waterfall model was the most used one, now Scrum or Kanban prevails. It was impossible to imagine development without a separate QA department, nowadays automated testing is mostly done by developers alongside implementation. Operations were separated from Development for years, today DevOps is shining. Same applies to Business problems — modern Developers cannot avoid being part of a circle and have to participate in decision making processes covering their responsibility area. We should not run away from it rather benefit from it!
