How not to let your Tech Lead drown? 🛟

I want to start by clarifying that have no doubt our tech leads are excellent swimmers, but when I was a kid, my mother used to remind me that “you can drown in six inches of water”. With that in mind, I’d like to share how I strive not to be one of those six inches for the tech leads I work with.

^{Image source: ‘Baywatch’ Remake In The Works At Fremantle As Buyers Circle by Peter White}

Communication flow 🤝

When you join a new project, it's time for “onboarding”. This is the point at which you get to know the team members and begin to get familiar with the technical and business logic of the project. After the initial familiarization with the project, the time comes for the first tasks. As you work on your first tasks, you are likely to have questions for the rest of the team, these first interactions lead to the formation of what I call “communication flow”, which I understand as habits in the way you communicate with other team members. As it happens with people, each of us has some habits, and on this point I wanted to encourage you to start paying attention to your communication habits and consciously control them.

💬 Real-Life Example:

While working on one of my previous projects, during one of our retrospective sessions, the project's tech lead pointed out that it makes his job much easier when I leave a reaction emoji under each message, so he can always be sure that the message has been read by me.

^{Image source: How the Evolution of Emojis Changed the Way We Communicate by Aoife Markey}

As you can see, even something as trivial and simple as an emoji can make a difference. 👀

📚 Explore More:

Asynchronous communication: Best practices and tips

The team 👩‍💻👨‍💻

In addition to the tech lead, many other team members are there to support you, including Product Managers (PM), Quality Assurance (QA) specialists, Product Owners (PO), Business Analysts (BAs), and Designers. Each of these roles plays a vital part in the team's collaborative effort.

^{Image source: Communications Strategies Are Like Ogres, Like Onions by Kim Ronkin Casey}

Think of these roles as layers of an onion 🧅 — each one represents a team or subgroup that contributes to the overall project. Being mindful of these layers and ensuring effective communication between them is essential for maintaining alignment and avoiding gaps that could lead to delays or misunderstandings.

📚 Explore More:

How to improve team communication: 6 strategies and tips
Best Communication Practices We Use To Keep Our Clients In The Loop

Knowledge sharing (documentation, updates, notes) 📄

Documentation is a crucial part of a programmer's work, serving as a key source of knowledge about the project. It goes beyond code-related details and should also be designed to support non-technical team members, such as product owners, project managers, and quality assurance specialists. To ensure that everyone stays on the same page as the project evolves, every team member should keep an eye on the documentation to keep it updated and clearly communicate any changes that may impact others' work.

💬 Real-Life Example:

I made it a habit with every task I work on to include clear instructions on how to test the specific changes, pointing out where technical support might be needed, and specifying where to find the latest changes (e.g. staging). This has become my standard approach, helping reduce confusion and ensuring smoother collaboration throughout the testing and review process.

I believe that clear communication and well-organized documentation are the cornerstones of effective and seamless team collaboration.

💡 Tip:

Visuals like diagrams can greatly enhance clarity and improve organization. For more on this, be sure to check out my article - Visualize to organize: How diagrams improve project documentation.

^{Image source: reddit.com/r/ProgrammerHumor}

📚 Explore More:

Diátaxis - A systematic approach to technical documentation authoring.
Creating technical documentation for non-technical people: tips from our team

Learn how NOT to make decisions 🚦

As a programmer, you will often be faced with situations where you will have to make decisions that can affect an important part of a functionality, the behavior of a specific component, or even the entire project. It is important not to make these decisions in a hurry, without consulting your team.

^{Image source: The Innovation & Transformation case story of Maersk Line by Henrik von Scheel & Mads Clausager}

When making important decisions, it's essential to think through all the details before acting. Involving your team in the process can uncover valuable insights, and help spot potential problems or overlooked risks. This avoids costly mistakes during product development, such as bugs leading to delays, which in turn can lead to lost sales which directly affects the client's business.

🚨 Warning:

It’s crucial to understand the client's business needs in order to be able to estimate the so-called "Cost of Delay", since it can significantly affect the client’s outcomes.

^{Image source: The Innovation & Transformation case story of Maersk Line by Henrik von Scheel & Mads Clausager}

📚 Explore More:

Software Engineer: The Art of Decision-Making Delay
Cost of Delay – Decision Making Framework
Project Managers: Your New Weekly Client Call Agenda

Grow 🌱

The best way not to drown your tech lead is to become one. Learn, gain experience, actively participate in the life of the project and the company, contribute in the way you feel most comfortable. The more experience and knowledge you have, the more responsibility you can take on.

🚀 Ideas:

• Volunteer for complex or unfamiliar tasks, which will allow you to learn by doing.
• Spend time with more experienced engineers, observing how they solve problems and make decisions.
• Write blog posts or internal documentation about the challenges you faced and how you solved them, following the principle - "if you can't teach/explain it well, you don't understand it well enough".

^{Image source: The Failure of Power & Responsibility by Ed Berliner}

True development comes from exposing yourself to new experiences, and as you gain knowledge and skills, you naturally take on more and more responsibility.

Conclusions 🎯

The purpose of my post was to raise awareness of how important each team member is, and how you, as an individual, can contribute to the effectiveness of the entire team.

By understanding that you can bring the greatest value to the team, not through your technical skills, but through your communication skills, because before you write the first line of code, you need to know what, how and when it should work. Because we don't write code for code's sake, but to solve problems, and to solve any problem long-term, we have to start by understanding the nature of the problem.

^{Cover image source: DeepAI}