Looking back on my career in Software Engineering, I believe that the most challenging issue I’ve had to overcome is not technical but people-related and organisational. I believe engineering leaderships biggest challenge is widespread in our industry, as I’ve encountered it in every company I’ve worked in. Early in my career, I struggled with it, but over time, I developed strategies to navigate and resolve it constructively. The problem I’m referring to is the buildup of tension and friction between engineering and business stakeholders. At a minimum, this tension leads to a lack of trust between the groups but at its worst, it can escalate to a breakdown in working relationships and dysfunction within the group.
Understanding the root cause of this problem is straightforward. Successful businesses face intense competitive pressure to maintain and grow their success. Struggling businesses must urgently adapt and pivot to find success. Both scenarios demand more from everyone, but in technology companies, complexity can make it challenging to meet these ever-increasing demands. This often leads to friction between business and engineering teams. Despite the friction, because there are usually really smart people on both sides, the organisation can still produce quality output, but the resulting dysfunction comes at a significant cost to the organisation and its people.
As friction grows, negative stereotypes and entrenched beliefs about the other group, as shown in Table 1, can develop. Once these beliefs exist, breaking the cycle can be difficult without attrition or personnel changes. Given the difficulties in finding good people for your organisation and in order to generate a better environment for creative people to work in, it would be better to simply avoid the escalation of friction in the first place.
| Engineering Beliefs | Business Beliefs |
|---|---|
| The business makes excessive demands. They are so unreasonable. | Why does everything take so long? Where are my features? |
| They don’t understand our complexity. It’s really hard to know when we will be finished. | All they care about is code. This is a business with real customers. |
| They don’t understand technology. They are not smart enough. | Our engineers are difficult to deal with. They are terrible communicators. |
| This place is impossible. I just want to code. | Engineering doesn’t get it. Maybe we should make some changes. |
Recommendations
As with a lot of people related issues, the core of the problem is communication. Either a lack of it or a poor version of it. In this article, I am going to discuss three key communication tips for engineering leaders when dealing with this problem. I say leaders but realistically, developing these skills and attitudes would benefit software engineers at every level in your organisation. In follow-up articles on process communications, I will focus on what we should be communicating to our business stakeholders. That is, the details of our current work and process. For now, let’s focus on why and how we should communicate with our business stakeholders.
Engineering Communication Recommendations
As an engineering leader, your role involves facilitating engineers in creating value for the business and its customers. Therefore, addressing the friction between engineering and the business is crucial.
1. Don’t Wait, Be Proactive
Both parties are responsible for creating the tension but if you are waiting for somebody else to resolve the problem, you could be waiting a long time. The tension between engineering and the business won’t resolve itself. As an engineering leader, you should hold yourself responsible for fixing this for several reasons:
- You straddle both groups. Fixing dysfunction between engineering and the business is not defined in your job role but leading engineering and working closely with stakeholders is.
- I don’t like this statement but, business stakeholders often hold more senior positions in the hierarchy you are operating within. Waiting for them to resolve the issue will result in sub-optimal outcomes for engineering.
- Participants are unlikely to gain new insights on their own, and top-down approaches can exacerbate the problem. Taking responsibility and being proactive is essential. Even if you fail, you’ll gain valuable insights for the next time you face this problem.
2. Understand Introversion in the Group
Research shows that a higher-than-average population of introverts exists in the software development industry. This makes sense, as people who are energised by thinking, problem-solving, and other introspective activities are naturally drawn to this field. In contrast, extroverts are energized by engaging with others and thrive in group situations. This dynamic means that while introverts often gravitate towards engineering roles, business stakeholders tend to be extroverts. This contrast adds a layer of complexity to the interaction between engineering and business stakeholders, posing additional challenges for engineers at all levels.
Being an introvert doesn’t mean you cannot communicate effectively. However, engaging with individuals on challenging topics or speaking in front of groups is not something that excites you. You can do it, but it is draining. If you are an engineering leader and an introvert, you have probably already developed some ability to cope in these scenarios. However, you should be aware that not all communications go through you and most likely, your team is stocked with introverts.
Unfortunately, there’s no magic solution other than awareness and practice. The more you put yourself in such situations, the more comfortable you will become. Continue to develop your own skills but also provide guidelines for your team for when they communicate with stakeholders. You don’t need to be a world-class communicator; you just need to listen and to be heard.
3. Communicate and Speak Business
The process communication recommendations provide strong guidance on the content of your communications. However, before we dive into them, I have a tip that makes a lot of engineers uncomfortable: speak in business terms when engaging with business stakeholders. As an engineering leader, you represent the technology team when talking to stakeholders, but I suggest you focus on “business” language rather than “technical” language when doing this. This means discussing topics in terms of revenue, value, growth, customers etc. While you may need to address technical concerns, it’s your responsibility to translate these into business terms that stakeholders can understand. This helps them appreciate the concern or value of your proposal and fosters shared responsibility for necessary actions.
Your ability to translate from “technology” to “business” is crucial but I urge you to go even further than this: think with a business mindset. Your business mindset should slightly outweigh your technology mindset (but only marginally, 51%-49%). While this might provoke some reactions from engineers, here’s my reasoning: your team is full of smart people who predominantly focus on technology. They know what needs to be done from a technical perspective. By adopting a business-oriented approach, you enhance the chances of building alignment and achieving success for your team.
This topic is incredibly important and often underappreciated by engineers. It’s vital for all engineers, not just leaders. Aligning with the business helps build confidence and trust. It maximises the possibility that the code you write will impact real people in the real world. It’s powerful when business stakeholders look at the engineering team and think, “they get it.”
Process Communication Recommendations
While this article focused on some of the softer skills that engineers must develop, the next in the series will focus on practices that address software delivery processes and how this can be used to create a transparent narrative around our work, reducing friction and creating alignment between engineering and the business. These insights were not only invaluable in my past experiences but also served as the key driving force behind the creation of Delivery Flow.
These following topics will be explored in upcoming articles over the coming weeks:
- When Engineering is a Black Box – Make Work and Workload visible.
- Demand vs. Capacity – The Laws of Physics Must Apply.
- Balancing Delivery Investment – Where Does the Time Go?
- Improving Software Delivery.
Addressing the negative friction between engineering and business stakeholders is challenging but essential. By developing the right skills and insights, you can foster a more collaborative, efficient and productive environment that will set your team up to succeed.