Emmanuel Micard, Developer Frontend Senior at Golem.ai
In the latin etymology, the word “confidere” is the addition of two words: “cum” and “fidere”, that could be translated as “with” and “rely on”. It means that you entrust something precious to somebody. How accurate it is when becoming a manager you have to entrust your reports with responsibilities that will have a huge impact on the company.
As a manager depending on our background, we have a varying experience in software engineering as a developer (Individual Contributor). You might be a Veteran with 10 years of experience or a less lucky one pushed into the management world: we can agree that managing people is a complex science.
What is trust?
So, trust is the expression of confidence between your reports and you. I define trust as the level of confidence you have in someone to take care of, assume or handle a responsibility according to your (or common) expectations. At first, the concept of trust might be hard to grasp. You might find it hard to measure the expression of confidence between you and your reports. That it’s not something tangible. Well, I’d say, start asking yourself some concrete questions and see what is your level of confidence from answers.
Can I let this collaborator handle that super complex feature? Can I trust this person to resolve this incident? Can I let her handle this sensitive task? Can I trust this guy to take care of this project for 2 weeks? Naturally, you sense when you can trust someone. But be aware, trust goes both ways, your reports should also have trust in you. As a manager, it is also your job to be trustworthy in order to become an effective leader.
Hard skill?
When you reach managing positions you probably honed your engineering skills: programming, planning, learning… Your experience makes you trustworthy to build software. From my experience, I do believe that managing a team requires minimum experience. You don’t have to know everything about engineering domains, backend, frontend, DevOps engineering, best practices, theory about obscure stuff... Yet you need to have a shared understanding of your reports’ issues and needs. If trust is core to any relationship at work, it’s also a great fallback between you and your reports when your hard skills reach their hard limit.
Combining trust with hard skills to manage
From my experience, I can describe four situations where a manager can end up depending on their background. So let’s draw this trust/hard skill relation graph.
- The Trust axis represents the trust between the manager and their reports
- The Hard skills represent the manager’s hard skills and knowledge in software engineering
Low trust / Low hard skills
Well, if you have no trust in your collaborators and you don’t have experience and hard skills, it will be difficult to manage your team. Maybe there are good or bad reasons why you became a manager, in the end, if you feel uncomfortable with this position, you should ask yourself how you ended up here rather than finding solutions.
Low trust / High hard skills
You may have ended up as manager because you were the best IC in your team and you were promoted to “manager” or “team lead” because you showed great hard skills. Showing hard skills is great to build good software but it does not require the same skills to manage people.
“Being a good developer doesn’t necessarily make you a good manager.”
As a good IC, most of the time you know better than your collaborators what to do and how to do it. Sometimes knowing better than others doesn’t help you get things done, also thinking you know better is purely toxic. If you feel that you can’t trust team members, then you may not enjoy your job. One of the risks of low trust in your team is becoming a micromanager.
The micromanager
A side effect of micromanagement is that the manager becomes the bottleneck and the single point of failure of the team. Which is totally in contradiction with its main goal: scaling the efficiency of their team. The manager is added to a team to bring a multiplier to every IC. The micromanager forces everyone to come to him before making decisions because they just can’t be trusted to make the right decisions and they don’t want to pay the price of their mistakes. They find it hard to delegate work to them and must have control over everything they do. He probably sits in every meeting and asks them every hour if they are “on track”.
This situation is frustrating for everyone because it costs a lot of energy for the micromanager to have enough control over their collaborators, and for ICs not to be autonomous. When the team underperforms (because of the micromanagement) or with the growth of the team, usually the manager falls into hyper process to keep control.
The Process monster
As said by Cate Hudson in Leading your engineering team with ‘experiments’ not ‘processes’ A "process monster" is a manager for whom the answer is always, always "process".To avoid failure, they add more and more processes until everything is under control and no one can make mistakes. All of this sets up a mistrustful environment that is unsustainable and frustrating for everyone.
Ask yourself
If you feel that you can’t trust your reports, I suggest you to consider working on it and sort this out. Start by asking yourself:
- Are there cultural or structural deficits in my company that explain this situation?
- What are the root causes of such an unsafe work environment?(5 whys method should help you here)
- Or simply what can I do better to gain my collaborator’s trust?
High trust / Low hard skills
You have good trust in your collaborators, meaning you can easily delegate work. This is a good start! But sometimes it could mean that you struggle to follow them when they talk about deep engineering theory, patterns, or tech language you don’t know. Don’t worry, communication is your friend here.
Continuous communication
If you cannot understand what an IC is doing, this is a great double opportunity: for them to improve communication adapted to the good audience, for you to improve your hard skills. Communicating early and often is key to prevent misunderstandings. I don’t mean being behind their back all day long, but more like daily check-ups. Find what fits best your team's needs. Establish recurrent check-ups with your collaborators to see if they are on track and to understand what they are building.
With time and with self-formation on your part you will get better and grow your engineering hard skills. This will leads you to the right position where you have enough trust and hard skills to manage them. The only risk when you don’t have enough hard skills to understand your IC’s work and you trust them too much, is to be fooled.
“Fool me once, fool me twice”
I’ll talk from experience as a young developer slowly becoming a manager. It happened to me during projects, that not having enough information about my reports work led me to uncomfortable situations.
It happened because of two reasons:
- Not enough communication.
- Not having enough hard skills to understand what they were building.
It ended in frustrating situations where I was not aware of the progress of my team member on their tasks. I was not able to tell my manager if the project was on track or if we were late.
Trusting your reports is essential, but assuming that all is going to be fine just because you trust them is not enough. Establish continuous communication (as we talked about before) and ask them to simplify to you what they are building. You should always be comfortable with your report's work.
Each time you find out you got fooled or missed an estimation, take it as an opportunity to learn and avoid this situation next time! With time you’ll get better at scoping, estimating, and understanding what your team is building. It needs experience and bonding with your team to find your pace.
High trust / High hard skills
If you’ve reached that point, it means that you are in a very good position to be a good manager. You have the experience and skills to lead your team’s decisions and you trust their performances. But you might ask yourself, how can I improve my management skills?
How to develop more trust?
Being a manager, in opposition to software engineers that deal with code, means that you have to deal with people. It’s a completely different set of skills. Depending on your position in the company, your influence, and if you were promoted or recruited as manager :
“Trust is not assumed, it takes time and skill to earn it.”
Establishing trust with your team members should be your main driver to becoming a successful manager. Trust is important, I encourage you to try building a tech culture revolving around it. But it takes time to build, so you should start to consider it ASAP. Here are a few tips, from my experiences, to increase trust as a manager, in other worlds: being a better manager.
Being a better manager
Disclaimer: Those tips are not listed by importance.
- Set up a safe work environment with clear feedback, mainly when reports make mistakes. It’s hard enough for an IC to handle failures. Don’t put too much pressure on top of it. Talk through it, help them learn, and move forward from their mistakes with proper feedback.
- Give responsibilities. One of the clearest markers of trust is giving responsibilities or delegating. By doing that, you express direct interest in your report. Showing them that you can count on them.
- Congratulate the success and give rewards. Most of the time this step is forgotten by bad managers in project management. When one of your reports (or the team) did a great job, please them! It’s always rewarding to be congratulated when achieving great work. Find the best way to reward them, some of them prefer to stay discreet while others want to share it with the team.
- Clearly define what you expect from your report, to avoid frustration (on both sides). If you have clear expectations for your team member, they should be described to them. Your reports shouldn’t need to find out by themselves how to perform
- Provide mentorship. When necessary, it’s important that you participate in your report’s growth by mentoring them. It could be improving their hard skills, sharing knowledge, helping them with soft skills… Mentoring can come from you or another developer.
- Protect your team (aka “the shield”). Avoiding distractions to keep your team focused is key to being an effective manager. It’s your job to create a safe work environment and space for your reports to perform. Avoid as much stressful work and crunch periods to happen. But sometimes, and for good reasons that you shared with your team, crunch time may come. In this situation be supportive…
- Be supportive. As a manager, it is important to show your team that you care for them. You have to help them in crunch periods and commit yourself to ease their stress: tell them you appreciate their hard work, order pizzas, make it clear you’ll give them break time after the push... They have to remember that their manager was supportive during stressful periods.
- Manage performance and career growth. Find what motivates your team member and talk with them about their career growth. Define a clear path to success with them and the milestones to achieve it. If you don’t have a Career Ladder, I suggest you work on it right away. Career Ladder I suggest you work on it right away.
- Get things done! It’s always important to do what you say. It brings you good credibility and shows that your team can count on you to help them. When difficult situations happen and have a direct impact on your team’s performance, it’s your job to find a solution and sort this out.
- Get to know your reports as a person.It might be obvious but knowing a bit more about your report's personal life and hobbies can only bring you advantages. It gives a special connection that will ease the collaboration when difficult times come.
- Adapt your managing style. Because each person is different you just can’t copy/paste your managing style and hope it will work. Feedback, 1-1s format, mentorship, rewards… Shape them to fit the person you’re managing.
To conclude, I simply like to think that a manager is not a boss that uses their report to their own ends, but a leader serving their team to perform well.
Building trust requires effort but, in the end, it pays off. It can help to compensate for hard skills limits and creates a safe work environment for everyone to perform.
