Lessons From Leading and Developing Product Engineering Teams - Part 1



The WFH period gives me extra time to think and reflect back on the lessons I’ve gained throughout my 15+ years career. I spent most of it leading others and I've gathered a lot of practical knowledge. I want to share it to help others learning to take up leadership. So, here are some important lessons about leading people based on my experience. It's a long read, so please bear with me, I'll split it into 3 parts.


#1 - It all starts with trust


Hire people you can trust. This brings a world of difference to the team dynamics. On every interview, I always ask myself the following questions.


Can I trust this person?


Will this person help the other team members?


When I am confident to hire someone, it means that I trust that person enough to work with the other team members. The mindset I establish would always be


Trusted, until proven otherwise.


I mean, why would you even hire someone you can't trust? I've seen a lot of people hiring people but are too afraid to trust them. You should hire them because you trust them, not the other way around.



What will you gain from this mindset? Two main benefits, I would say. 


The obvious first one is that the person would feel more welcomed by the team. Engineers are unique in a way that usually they have that introverted part in themselves. This makes it harder for them to mingle in a new environment. Having a trust-first culture helps them get onboarded better. This enable them to show their skills faster and contribute to the team sooner.


The second benefit is the person will have more confidence and feel respected. This is important as without confidence, it will be harder to perform your tasks. Especially in a fast-paced, high-pressure environment.


In the long run, the two benefits may contribute a lot to a more harmonised team environment. People would feel safer to work with each other, knowing that everyone gets each others' back.


Usually the question is, "So that's it? You trust the person just like that?"


My answer is, you still need to put your fingers close and watch. Can they maintain that trust? Remember the "until proven otherwise" part? You need to maintain that given trust. Once the person break the trust, you need to have an open conversation with the person. Reiterate the expectation and what went wrong. Examine if the trust can be re-established or not. If not, then it's better to let the person go for the good of the team. Yet, please make sure that you put efforts to re-establish the trust before letting go of the person. And you also need to make sure that you identify the condition as early as possible. This way, you can still try to fix the condition before it affects the team as a whole.


#2 - Empower teams


The reason why I put trust as the first lesson is because it will help you a lot in empowering your teams. A company will always have plenty of teams. And it's for a good reason, to be more focussed and move faster. Engineering teams in particular, should not be a very big one. I would argue that the ideal size of a team is no bigger than 10 people. Bigger than that, you would need to break it down.


In my career, I've seen a lot of managers fail, because they can't put their trust in their team. Those managers have the need to micromanage everything. They have to decide everything and will feel powerless without it. This is bad for 2 reasons. One, the manager becomes the blocker. Things can get stuck because decisions have to wait for the manager. Two, the people in the team can't grow and provide the best contribution because they rely on the manager. They will also have the tendency to only do things to please the manager, not what they're supposed to do.


As managers, you need to trust your team members and be a coach instead of a boss. Each team members have their specific abilities. Those abilities combined are what will generate value. A coach is someone that will combine the skills to achieve a goal. Ask opinions, listen to inputs and assess what other people in the team think. Your job as a manager is to set your team up for success. Not to prove that you're the one who is always right and knows everything. If your team is successful, then you are successful.


With trust, you let the team own the problem. Think about it and come out with a solution. Your job is to make sure that the solution aligns with what you need to solve. Assess, discuss and let the team come up with the solution. Never be afraid to delegate. It frees you up and let others improve and level up.



Challenge their solution to make sure they come up with good reasoning. This way your team learns to think end-to-end including the edge cases. So in the end when you let your team own the problem, you also make them grow. In turn, they will one day be leaders and will do the same thing. So in the long run it will be a culture in the organisation.


Another thing that comes out of empowering teams is the bottom up innovation culture. When teams own problem, they develop expertise in that problem. With expertise comes out innovation. Having a culture that does not block source of innovation drives better solution.


I also like this mantra of hiring people smarter than you are. Then you hire them to tell you what to do, not the other way around. Otherwise, why do you even hire them in the first place. What you need to do is assess whether what they're telling you makes sense and solve the problem or not. This will also push you to be a better leader. You would need to improve and have a point of view that matches the team's collective wisdom.


Empowering teams for first time managers usually comes with a scary feeling. But, sometimes this also happens to seasoned managers. What you need to remember that in a team setting, you're all in it to succeed together. This way you need to have each other's back.


#3 - Provide Clarity


Leading means showing the team, which direction to go and what to achieve. In most cases, clarity on these two things can be an advantage and will drive teams to move with enhanced focus.


The first thing a leader needs to communicate is the vision. What is it that the team want to achieve. This will be the starting point. When you communicate, your team will ask you questions. Please explain well. When there are things you don't know, admit it and discuss with the team until everyone is clear. You'll gain respect this way since the team will see that you're willing to listen well.


The next thing to communicate is the direction. What do the leader think needs to be done to achieve the vision. Again, after communicating, get input. There might be things you miss when you plan. Your team might see it and have a better alternative. Again, you're in it together with your team to achieve success.



Now that vision and direction is clear. Set objectives and KPI. It is important that the team has a map and way to measure their efforts. Let's take an example:


A SaaS product has a target of reaching $10,000 Monthly Recurring Revenue (MRR). This is the vision. 


The company sells the subscription at various price point but the average value is $300. So, more or less, the company would need to make sure that at least 33 subscriptions are being sold every month. I say at least because there will be churn as well. The direction is achieving the MRR target by selling 33 subscriptions.


From the direction, we can see that to achieve it we need at least 3 objectives:


1. How to market the product to these 33 potential subscribers.


2. How to get these subscribers to go live


3. How to retain these subscribers.


These three objectives are the problems we need to solve together with the team.


For objective number 1, the team identified that to get the required numbers, we needed as many leads as possible.  The team proposed scraping social medias for targeted leads since social media can be used to profile users. Another solution is to improve SEO so search engine traffic can be used to drive potential subscribers to the website. An alternative solution is to use paid ads. As the leader, you need to decide which one will be the required solution to getting more subscribers. Set the number of quality leads as the metrics to measure the impact of solutions. This way the team has a clear view of the results of their work.


When trying to solve objective number 2, the team identified that to go live, each subscribers needed 10 steps. Another team that the team identified is that the average integration time is 20 days. Based on user interview, the team also identified that the way subscribers integrate with the product is hard. Since you can only achieve MRR if the subscriber goes live, you need to come up with the solution to the 3 problems. Again, set the metrics. Remember that the metrics should cover the problems faced.


Objective number 3 is needed so that the churn numbers go down as much as possible. This way when you add more subscribers, the closer you are to your target. When you lose a customer, you’re further away from the target. You need to decide how you can maintain the customer subscriptions using metrics that tells the performance. For instance you need to know on whether your subscriber is engaged with your product or not. If your product affects their revenue, is there a significant improvement to their revenue after using your product. These things can identify how well the team is performing and can be a red flag for your team if you’re losing a lot of subscribers.


When you set clear vision, direction, objectives and metrics, the team knows what to expect and what to deal with. You’re setting the team up for success. Another thing to note is you need to be able to balance the objective. Don’t make it too easy, it will make the team stuck. If it’s too hard, the team will be affected as they might think that it’s impossible. Understand your team’s capability and you should be able to set the right amount.


---


That is part 1. I know it’s a lot but I hope you can learn from it. In part 2 we’ll see how we take care of people in the team and handling toxic people. You can find part 2 here.


Regards
-E-

follow @femmerling on twitter

Comments

Popular posts from this blog

LDAP Login Authentication Using Python LDAP

My Take on The 10X Engineer Myth

Android TDD Using JUnit, Robolectric and Mockito