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