Breaking Silos: Why Software Engineers Benefit from Departmental Dalliances
As software engineers, domain knowledge is a crucial aspect behind being able to deliver business value to the organisation. Unlocking business value, continually, is one of the best ways to grow as an Engineer, get promoted and serve your team.
Having a solid base of domain knowledge will help when debugging code, mentoring other software engineers, prioritising work, build vs buy decisions, quick solution or more longer term planning and nearly everything you do in your day to day work.
What I have come to expect from a strong, high performing team is the ability to question until understanding. So when we are working with our product manager to understand what should be prioritised, a high performing team, will want to fill in their gaps of understanding by questioning why this is needed, and if this is the best approach to solve the problem.
We should not settle to engineer solutions that we are not in complete understanding of why we are doing this and how it moves the needle.
Typically, I have experienced software engineers building domain knowledge in 3 ways:
Tenure.
Code exploration.
Product.
Software engineers will know about what customer success are driving towards or what sales might need through product or some other non-direct source.
The most effective way to enhance your domain knowledge is to spend direct and quality time with several departments across the organisation on a regular basis outside of technology.
You should go and spend a week a couple of times a year working for a day, shadowing someone in different departments. This will give you a real insight into their struggles and strengths. What they really care about and what is just a meaningless buzzword to them. You will be able to spot gaps in their workflow where engineering can help them and many others on a daily basis.
Some examples:
Go and shadow someone taking calls in customer success for a day or two. This will not only get you closer to customers, you will build sympathy to their real pain points.
See if you can go along to some client meets with Sales, or at least spend some time with the department working with them. This will help you picture key client archetypes and what parts of the technical estate actually sell, and what features and capabilities might level them up.
Work with Marketing on learning how they go about promoting a new feature. What insights are they looking to gain? How do they approach a/b testing? What is their playbook for tone of voice and copy?
These are only a few examples, hopefully it paints the picture of what can be gained. If you are worried about time away from coding and delivering, it could be argued that is a red herring as gaining a deep appreciation for the organisation as a whole will increase the business value you deliver over a much longer term.
gaining a deep appreciation for the organisation as a whole will increase the business value you deliver over a much longer term.
I would take it a step further and make these departmental dalliances part of a new software engineers onboarding process. From month 1 they could be armed with relationships across the company and a way to discover information they need.