Stop Hiding Your Developers
Especially From Business Stakeholders
Hey, fellow Leader 🚀,
I am Artur, and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.
One of the trademarks of Leadership is communication, and even for technical roles, sometimes we get Tech Leads with very poor skills in handling subjects with Business stakeholders. These Tech Leads slip through the cracks, especially on newly assembled teams to deliver a project where it is important to define a structure from day 1.
When I am involved, I try to delay the decision of nominating a Tech Lead as much as possible, to give the different Senior Developers a chance to prove themselves and give me time to make a good decision. However, sometimes I don’t have the luxury of waiting, and the project demands a clear hierarchy and structure for the development team. This is when mistakes can happen.
Even Senior Developers Struggle To Address Non-IT Staff
There are, of course, some exceptions. When managing ERP, CRM, or RPA consultants (or any other form of developers who have a very functional aspect to the role), these profiles tend to be good at handling the Business Stakeholders. The wanna-be senior consultant assigns the same attention to building the skills to handle non-IT stakeholders, as well as to their technical skills. When it comes to C#, Java, PHP, or other types of developers, there is a significant portion of the population that is not even interested in the matter.
The result is that we end up having Senior Developers with decades worth of experience, but we cringe every time they open their mouths in a meeting with Business stakeholders. The root cause is that they weren’t exposed and coached long enough to train this part of the job. This is the result of years and years of hiding developers behind their laptops and having other people do the talking.
Smooth The Exposure
When I have a project of a short duration, and I notice the Tech Lead has challenges communicating with non-IT stakeholders, I typically cover for him. I try to understand the technical issues or constraints behind them and try to translate those to non-IT personnel. However, this is a quick fix at the cost of postponing a problem to be solved in the future. This is a calculated measure because projects might have tight constraints, and we only have time to execute. When the project is delivered, we can “flip the chip” and focus on improving some communication aspects for the maintenance part of the product.
Developers should be exposed and coached on how to navigate and expose technical issues. They need the help of their manager, but they also need hands-on experience. In a previous team, I had prepared PowerPoint templates so the Developers could present some components of the project themselves. In the beginning, some developers struggled a bit, and we needed to prepare practice runs before meeting the Business stakeholders. However, one year after the fact, those developers had immensely improved their interactions with the Business, and they were much more confident in communication in general.
The Gain Is Priceless
Having a Developer (not necessarily the Tech Lead, I mean, any developer) with the ability to understand an opposing view, see beyond the technical aspect, and offer solutions that might not even require a code change, is phenomenal. Some might argue this should be the job of the project or product manager. However, in today’s IT landscape, the team should be able to propose solutions, and many developers’ solutions are too far from the overall picture in brainstorming sessions.
When we look closer at very good technical teams, one commonality is clearly seen: They have a good working relationship with their business counterparts, and they collaborate to work towards fixing their problems.
I once witnessed a Developer who himself presented a solution for a complex problem, where the business analyst, the client, and everyone else weren’t even close to solve. The 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, addressing the complaints from the business with clean, straight-to-the-point technical solutions. Given the conditions, the developers can become the experts that nobody else in the project can even dream to reach.
That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.
Cheers,
Artur
It's absolutely common and unavoidable that certain specialists don't automatically understand each other because they use different thought patterns and terminology. Some of this can be resolved through education and training, but at some point it becomes inherent to the expertise itself—and then somebody needs to be there to bridge the gap.
Although there is a merit to that, most people are not notoriously bad at talking in a business environment. From my experience, it's better if I handle the non-technical discussion since my role is a product manager, while I can leave the engineering side of things to our engineering lead.
I don't need to hide the person, or push them forward unnecessarily, and although coaching can help, we shouldn't forget that they are engineering leads, not heads of engineering or engineering managers. It's expected from them to handle engineering-level conversations and people conversations within their own teams, not as much in business environment.