When I had the opportunity to be a Tech lead on a project, I learned that leading people is way more complicated than it appears, and I learned it the hard way. I thought having a title with “lead” in it, years of experience, and taking initiatives, would be enough to gain trust from project members. Damn I was wrong!
After this bittersweet experience, I decided to seek advice and training on the matter (it was not enough to discourage me from becoming a Tech lead!), and I’m sharing my findings in this article. Advice covers topics like ways to communicate in a project, how to gain trust and adoption from team members, handling diverging points of view, and the lifecycle of a project team.
TL;DR
- Balance three roles: Manager (decision-maker), Leader (guide), and Coach (facilitator) based on the team’s needs.
- Tailor communication to each person’s style, keep it honest, and address issues promptly.
- Run a structured kickoff to clarify roles (e.g., RACI matrix), project scope, timelines, and communication channels for alignment.
- Use a mix of conflict-resolution strategies (e.g., collaborate, compromise, or accommodate) as situations demand, and encourage solutions over complaints.
Project management
- Succeeding at project management and succeeding at a project are two different things (the project itself is influenced by external factors).
- Roles and postures:
- Manager: person who makes the decisions and holds responsibilities
- Leader: person who inspires and shows the way
- Coach: person who raises questions to have people reflect and make the right decisions by themselves
- When “leading” a project or a team, you ideally use each of those postures according to the situation and what you try to achieve at a certain time.
- Leadership can be improved but there’s a personal dimension to it that makes it less tangible. Your leadership skills might work better with some people than others for example, because it relies on relationships.
Communication with(in) the team
- The best way to succeed at communicating is by asking openly how each person likes their communication (which channels, do they like direct communication, do they need a lot of details or a global view, everything at once or little by little…). It’s also important to be aware of the different types of communication styles that exist, and how they translate in the day-to-day.
- Be honest in your communication and address issues openly and quickly.
- “Learning how to communicate is the work of a whole life“
- When there is a disagreement, always point the things on which people agree and start from there, rather than concentrating on the things people disagree on.
- When planning meetings, always have a clear agenda with time allocation so:
- the goal is clear,
- it’s easier for meetings minutes,
- people know if they’re needed in the meeting or not.
- Having a kick-off with all project members before starting is really important (if people join afterwards, you have to take the time to onboard them properly so they’re on the same page). Everyone agrees on the things that will define how the project works and feel involved in the success of the project.
The kick-off meeting is done with everyone involved in the project (not only the team members). It describes:- What the project is about (and what is it not about)
- The project team and other actors
- RACI matrix
- Governance
- Timeline/Phases
- Meetings that are already planned (recurring, milestones…)
- Communication channels
- Risks
- Budget
- After each meeting or unplanned discussion, have a written summary of what was discussed and decided, and open topics, available to all.
- Improve your “meta-communication“: observe when people are ready to talk about something or if they need to prepare, if not sure ask if it’s a convenient time for them or not.
Leadership, trust and adoption
- Getting trust from the project members is super important, but it takes time. On shorter projects, this can be problematic because the usual team lifecycle has to happen faster. It thus needs to be provoked early in the project.
- A new team needs time to stabilize, and it resets at each important change (see Tuckman’s stages of group development for reference, link at the end of the article). The team will go through some important steps, one of the earliest being the “storming”, where all the disagreements arise. The way that stage is managed is decisive for the future of the team! The performing stage can only happen when the storming phase is finished, hence the necessity to provoke it early for short projects. One of the points to raise is the level of confidence in the leader. Fears should be heard and taken into account.
- Once you allow people to have an open communication, you have to be open for feedback and take it. It doesn’t mean you must change, and it doesn’t mean you have to accept people being rude to you, but you still need to hear proper feedback, accept it and understand what it means to people. If you don’t accept feedback, you lose the trust and deny open communication principles.
- Trust is the basis of functioning teams (see Lencioni’s pyramid for reference, link at the end of the article).
- If there’s an issue in the team dynamics (some people not acting as team players, someone refusing decisions…), you have to try to solve it, try different ways if needed. However, if it still doesn’t work after several true attempts to solve it, you have to accept it just can’t work. It might happen, and it’s not a project management issue, sometimes the team composition is just not right, or people don’t belong in this kind of project. If they don’t have the will to make it succeed and stay focus on their personal interests or convictions more than on their mission, it’s not for you to change it.
- Only escalated this kind of issue after several committed attempts to solve the problem. Give people a chance to show they want to make it work and will change their mindset.
- Creating and maintaining good relationships plays a role in the motivation of the team members to work towards the common goal.
- RACI matrix to define roles and responsibilities (who does what, who’s informed of what, who’s in the loop of what, who’s validating what) gives clarity about responsibility boundaries in a formal, official way.
- When experiencing resistance to change, insist on the fact that you need everyone to make it happen. Resistance to change often translates a fear to be left behind or to become useless.
- To motivate people, recognition is important: gives kudos!
- To motivate people, you have to be motivated yourself!
- Motivation comes from the “why“, people have to understand why we do things.
Ways of handling disagreements
Based on Thomas Kilmann’s model (link below the article for reference), there are several ways of dealing with disagreement. Each is used according to the situation.
- Competing (you vs them)
For fast and crucial decisions
When unpopular decisions have to be applied
When the leader knows they are right on a crucial topic
To protect oneself from people trying to take advantage of someone who can’t say no - Collaborating (you and them)
To make everyone happy
When we can afford a lot of time and energy to make a decision
When we can accept not to get a decision in the end
When points of view diverge a lot
When different parties are involved and committed - Compromising (part-you and part-them)
To find a temporary solution
To get adoption from everyone although it’s no one’s perfect solution - Avoiding (neither you nor them)
For non-priority questions
When time/energy are needed elsewhere
When there are a lot of emotions at stake and it’s difficult to have efficient communication and work on the topic
When there’s no way to come to an agreement - Accommodating (them)
For questions with a low impact
When the decision has more impact on them than you
When the decision will impact the harmony in the team
When you realize you were wrong
When someone doesn’t agree, we should always challenge them to give their solutions. We don’t want people to just complain, we expect them to make a proposal. If they propose something, hear everyone’s feelings and reactions.
Summary
My experience as a Tech Lead taught me that leadership isn’t just about having experience and making decisions—it’s about trust, communication, and balancing multiple roles: manager, leader, and coach. I learned that a leader should tailor communication to each team member’s style, maintain transparency, and actively listen. Effective project management goes beyond project success—it involves establishing a solid kickoff with clear roles (e.g., RACI matrix) and a structured communication plan. Building trust is key but requires patience; teams go through stages, and handling early “storming” phases thoughtfully is critical for cohesion.
In conflicts, we can use varied strategies like competing for critical issues or collaborating when seeking broad input. Non-violent communication, clear agendas for meetings, and written summaries greatly improves general communication.
Resources
What is the Thomas Kilmann Conflict Management Model? (With examples)
