Empowering Developers: Bridging the Gap with Business Stakeholders

Hey, fellow Leader 🚀,

I'm Artur, and welcome to my weekly newsletter. I focus on topics like Project Management, Innovation, Leadership, and Entrepreneurship. I'm always open to suggestions for new topics, so feel free to reach out and share my newsletter if it helps you in any way.

Thanks for reading The Long Missing SoW! Subscribe for free to receive new posts and support my work.

---

One of the hallmarks of effective leadership is communication. Yet, even in technical roles, we often encounter Tech Leads with underdeveloped skills in discussing technical subjects with business stakeholders. These individuals can easily slip through the cracks, especially in newly formed teams tasked with project delivery where defining a clear structure from day one is paramount.

When I'm involved, I try to delay the decision of nominating a Tech Lead for as long as possible. This allows various Senior Developers a chance to prove themselves and gives me ample time to make an informed decision. However, this luxury isn't always available, and projects sometimes demand an immediate, clear hierarchy and structure for the development team. This is precisely when mistakes can occur.

Even Senior Developers Struggle To Address Non-IT Staff

Naturally, there are exceptions. When managing ERP, CRM, or RPA consultants (or any other developers whose roles have a strong functional aspect), these profiles often excel at engaging with Business Stakeholders. Aspiring senior consultants typically dedicate significant attention to developing both their technical skills and their ability to communicate with non-IT personnel. However, for C#, Java, PHP, and similar developers, a significant portion of the community shows little interest in this area.

The result is that we often have Senior Developers with decades of experience, yet we wince whenever they speak in a meeting with business stakeholders. The root cause is a lack of sufficient exposure and coaching to develop this crucial aspect of their role. This outcome stems from years of keeping developers hidden behind their laptops, with others handling all external communication.

Smooth The Exposure

On short-duration projects, if I notice a Tech Lead struggling to communicate with non-IT stakeholders, I typically step in to cover for them. I try to understand the underlying technical issues or constraints and then translate these into terms understandable by non-IT personnel. While this provides a quick fix, it essentially postpones addressing the core problem. This is a calculated measure, as projects often have tight constraints, leaving little time for anything but execution. Once the project is delivered, we can "flip the chip" and focus on improving communication aspects during the product's maintenance phase.

Developers need to be actively exposed to and coached on how to navigate and articulate technical issues. They require their manager's support, but also hands-on experience. In a previous team, I prepared PowerPoint templates to enable developers to present specific project components themselves. Initially, some developers found it challenging, requiring practice runs before meeting business stakeholders. However, a year later, those same developers had vastly improved their interactions with business teams and gained much greater overall communication confidence.

The Gain Is Priceless

Having a developer (not necessarily the Tech Lead, but any team member) who can understand opposing viewpoints, see beyond purely technical aspects, and propose solutions that might not even require a code change, is truly phenomenal. Some might argue this should be the responsibility of a project or product manager. However, in today's IT landscape, the entire team should be empowered to propose solutions, and many developers' initial ideas in brainstorming sessions are often too far removed from the overall business context.

When we closely examine highly effective technical teams, a common thread becomes apparent: they maintain a strong working relationship with their business counterparts and collaborate proactively to solve problems.

I once witnessed a developer single-handedly present a solution for a complex problem that business analysts, clients, and everyone else were far from resolving. This developer, at the time, was more of an expert on the subject matter than his colleagues working on the project. His solutions were spot-on, directly addressing business complaints with clean, straightforward technical approaches. Given the right conditions, developers can indeed become experts whose insights surpass anyone else's on the project.

---

That's it. If you found this post useful, please share it with friends or colleagues who might be interested in this topic. If you'd like to see a different angle, suggest it in the comments or send me a message.

Cheers, Artur