Are you looking for the next thing to learn to advance your skill as a software developer? Maybe you’re considering to dig into that new functional language? Or that new front-end framework? Perhaps take the time to really understand machine learning, like, the algorithms, not just using a ready-made black box solution…?
No.
Most likely this is not what will benefit you the most. Sure, being up to speed with that new framework may help you run faster. However, running even faster in the wrong direction will not get you closer to the goal.
You need to learn something different — your business!
Because at the end of the day, your job is not to write code. Your job is to create business value.
Why We Write Code
A way to describe business value is that it is any value that contributes to the success of the company and the long-term health of the business. Often it cannot be measured directly in economic terms, sometimes it may even be intangible, like customer goodwill. In other cases, like a performance improvement that reduces server costs, it is much more easily measured.
As a software developer, you use code to create business value. Your purpose is never to write code for its own sake, in the same way as a carpenter’s job isn’t to drive nails into wood, but to construct buildings with a purpose. Code, or a hammer, is a tool to create business value.
Hence, understanding your business domain, and what makes your company tick, is essential to be able to use your skills to create business value.
There are many benefits to learn how your company’s business work — motivation, communication, productivity, implementation and the solution itself.
Motivation
When you understand the objective of a request to implement something and what values it is set out to accomplish, you will be more motivated. Understanding the underlying objective will make you see the impact of what you do, and you see how it is aligned with the business as a whole.
It will become more clear where you and the specific task at hand fit in in the organization and how it does contribute to the vision and North Star of the company. Knowing other roles’ and departments’ objectives, and what business value they are set to create, does not only allow you to support them better but also see how you have a shared vision and how different parts in the organization contributes to it.
Communication
A technical writer or an analyst does not only need to master her own profession, but she also needs to have an, often profound, understanding of the domain she is working in as well. The same goes for a software developer. The minimum is to have enough knowledge of the domain to know the vocabulary, to communicate effectively with clients and other developers using the same terminology and language.
Besides, the communication need is significantly reduced by better understanding the details, seeing the context and knowing the inferred information. More often than not, this knowledge will decide if a specification or feature description may be fully grasped, or if you are left to blindly implement something you hope is correct.
Instead of spending all communication bandwidth on addressing misunderstandings and the gaps of inferred information, it can now be much better spent on being proactive. Proactive communication across disciplines with a focus on sharing knowledge from multiple perspectives will not only enable quicker iteration of ideas but also result in a better solution in the end.
Productivity
Us developers love shipping stuff — the pinnacle of productivity!
Following how communication is more efficient, better business knowledge does also help a lot with hands down coding. While developing you are faced with a never-ending flow of decisions. Most of them come down to two different things; when and what to implement and how to implement something.
The big tasks may have been prioritized and assigned among team members; still, once you design the detailed implementation and start coding, you will discover new implications and edge-cases that affect the design. The better you understand the business-related dependencies on the feature you are working on, the more you will see upfront. Moreover, when you discover the exception to the rule, you are more likely to already know that answer instead of having to research it in your organization or reach out to a domain expert.
You will also use this knowledge to micro-prioritize how you go about your implementation to tackle possible uncertainties first, instead of discovering something later when you already introduced dependencies, making refactoring more complex.
With better business knowledge it is easier to prioritize, almost subconsciously, the decisions every day when coding. With reduced communication and greater understanding comes confidence in taking more own decisions and autonomy. In turn, autonomy leads to productivity.
Implementation
As a developer, it is easy to go too far when it comes to making things generic, abstract, flexible, extendable and reusable — sometimes resulting in excessively complex implementations. More often than not, these implementations will never be extended nor reused.
The key is to balance when to design an implementation based only on the needs of today, and when to take into consideration how it may potentially be evolving over time. With domain expertise, you are set up to be able to make a much better call on what approach would be able to create the most business value. If the window of opportunity is next week, the implementation will be different from the one that would require a month (but by then, be utterly worthless regarding generating business value).
Often a feature request is made by suggesting what to implement, typically described in detail with some kind of specification. However, a specification is virtually never sufficient. You could argue that a specification sufficiently detailed that leaves no room for interpretation is the source code. Hence, there will be unclear details, not to mention all the unwritten assumptions the specification is based on and possible errors it may contain.
By understanding the reasoning behind the actual “needs” and “wants” you will be in a much better position to convert those into concrete problems and solve them.
A specification typically does not include the more vague domain knowledge not directly related to the feature request itself — knowledge that may be crucial for making the right design choices during implementation.
For example; in a finance related application, it may be evident to someone with basic knowledge of accounting that a specific variable may never be negative. Usually, those self-evident truths don’t make it into a specification but are picked up with some domain knowledge.
Knowing those “obvious” constraints may impact what data structure to use, the database model or even what algorithm that would be relevant. Is that dataset sparsely populated or not? Further, trivial things like allowing you to make more defensive checks in the code, even adding test-cases that would prevent bugs (since “…it wasn’t in the specification!”) may have a considerable impact on the quality of the final implementation.
Solution
By human nature, we often jump to conclusions too quickly. Often thinking ahead and suggesting a solution based only on what is known to us. As a developer confident in the business domain, you can take a step back and have a dialogue about the objective and what values the solution should create. Knowing this underlying need will allow you to use your technical expertise and knowledge about the existing code base to possibly, in cooperation with the requester, identify an even better solution.
Seeing the reason behind a request does allow you to think about it rather than just accepting it as given, identify possible flaws and point out errors.
Getting That Business Knowledge
So how do you go about understanding your business?
No one answer that will fit every organization; however, a good start is to raise your perspective and start to look at how the things you are working on does fit into the business. Again, what is the objective of the application you are working on, and what business values should it create? How does that fit into the larger organization, and ultimately the business model of the product or service?
Do also take a top-down approach. What is the company vision? How does the business model work? What is it that makes customers/users become active in the product? What KPIs are relevant on a company level? On a feature level? How does what you do help to change those KPIs in the right direction?
Most importantly — talk to your colleagues! How does the sales process look like? What marketing is successful, and which isn’t, and why? What are the most common questions for customer service? How is market behavior changing and how is the product strategy aligned to take advantage of that?
Those are just a few conversation starters that will help you become a significantly better software developer.
Does this resonate with you? Check out the current job openings at Relatable. We’re a marketing technology company based in Stockholm, Los Angeles and London specialized in creating large-scale word of mouth marketing with the most creative and influential people around the world.