Being A Tech Lead

Notes on reading Camille Fournier’s The Manager’s Path.

Mentoring

Chapter 2, covering mentoring, was a insightful piece into how and why we should place value into mentoring engineers in our working life, whether it is the intern, new hire, or just an engineer in our team trying to learn new skills.

In the case of the intern, give them a structure involvement in a project which they will be able to contribute to, but give them more than enough time to do this (i.e. double the time you would expect a new hire to take). Make sure you can make time to regularly catch up with the intern to provide feedback, and get to know their ways of working. The main value of this is to give the intern an interesting experience in the aim that they will strongly consider applying to work for the company once they complete their degree. As with all the people you mentor, this gives you a perspective on how people will learn and integrate into the teams, and help you learn how to help people grow.

For new hires, it was a similar case; Spend regular time working with them to ensure they are able to log into the systems, checkout code bases and have access to repositories etc. It was also important to spend time with them to help them understand the unwritten rules of a company, things which people just know but can take falling foul of a few times to find out.

Keeping regular and planned meetings to help mentees organise their thoughts and questions before the session, and have targets and goals to work towards each week.

A important point was that you should not be taking on a mentoring role if you are not going to have time to commit to it. It helps neither you or the mentee to have unstructured relationship like this and just delays progress on both parts, as the time you do end up spending has less tangible benefit.

Questions on Mentoring

• What aims should you be providing to a mentee?
  • Make sure the work is meaningful, but if the mentee is new to the company, not too intimidating so that they can contribute successfully to the team.
• What differences should you provide a mentee vs an experienced team member?
  • For say interns, you may want to give 2-3x longer to complete a project - this will generally mean dividing the time they are in your team by 2/3.
  • This should probably be 2x for a new team member, as they will generally need to learn the context, go through onboarding tasks, learn the culture of the company etc.
• How involved should you be in their development?
  • If the mentee is reasonably good at engineering, the role may be to help them understand the domain they are working in, or particular work practices they are new to (i.e. managing people).
  • This could be helpful even just to initiate them to the “known” culture in the office, the things that everybody just knows. It might even be interesting to see what you “know” and where this knowledge has actually come from.
• What frequency of meetings should you have with a mentee?
  • Regular enough for you both to be engaged in the project, but not too much to inundate the mentee.
  • The best way is likely to ask the mentee how often they would like to meet, and review this somewhat regularly. If you work closely in a team and that covers most of the mentoring, you’ll likely want less regular formal catch ups.
• What work exposure should you give a mentee?
  • Aim to try and give them exposure to people in higher levels of management or importance, such that they can get experience of presenting or meeting people, and also let them see what kinds of roles these people play and the attributes they exhibit.
• What factors should you consider when deciding to become a mentor?
  • Do you have enough time? It is not going to be healthy to commit to mentoring someone if you are going to be half-arsed in helping them, as neither of you will gain anything out of it and it may be damaging to the mentee if they struggle to get good mentorship during the early phases of their career/new role.

Is this like being a fitness coach?

As a fitness coach you want to help someone learn how to train effectively, either by learning new training skills, or by using the equipment around them in new ways. You need to keep the trainee at a level where the exercise is not overwhelming to the point they injure themselves and can’t come training the next day, and you want to teach them the fundamentals such that they are able to train whilst they are not in a session with you.

You want to help the trainee achieve their fitness goals, so being aware of these is important so you know the direction they will want to go in, and how you can help them achieve that.

Building a fitness plan and helping them learn new techniques helps you learn how to train people better, and helps your problem solving skills in how to teach someone a particular technique where they were previously struggling. By helping one person out, you improve your ability to help others and expand your own career to more trainees.

Tech Leads

What is it

Being a tech lead doesn’t need you to be the best engineer in your team, but it does need you to be able to influence, delegate, listen, and manage where a great engineer may want to focus on the technical details of the project.

It’s not critical that you understand the lowest level of the code, but that you can understand the concepts when they are being discussed and that you understand their place in the wider framework of the software architecture. This is something I have regularly found when stepping in to help on projects where my understanding of the core technology was not brilliant, but working with the team to understand the core patterns of the technology and it’s setup we could understand it’s place in the platform and how we would integrate it correctly.

Planning

Planning a project is important part of being a tech lead. Managing the pieces of a project and designing how they will come together in your delivery plan is important to understanding the whole piece of how and when the project will come together. It doesn’t need to be perfect as we know things will go wrong, but even agile setups need a project plan which can be adjusted and manipulated regularly to keep the delivery on track. Agile methodologies generally just break this down into small enough pieces that they would be parts in the stories and sprint planning.

Being a good tech lead

This section mainly revolves around taking your expectations to be a burning light in the technology world and being able to lead the charge of developing exciting software with a strong team around you, and understand that most of being a strong tech leads is taking the time to understand your team, working with them to make sure the whole team gets to work on the parts they are interested in but also have coverage of both the boring and exciting work so that the team have a good holistic understanding of the code they are working.

Being a great communicator also comes heavily into this, through talking or documenting, as you will now be the voice of your team in a lot of situations. This means you will have to be able to communicate the technology and issues you are facing to a wide range of people, which may include talking up or down the company hierarchy and being able to frame the work being done in ways that seem simplistic from a technology point of view. This is important in getting buy-in from the people who will fund or support the projects you want to implements, and also becomes an important way of understanding if the work you want to do will have tangible value to your “customers”.

Managing People

“New engineering managers think of the job as a promotion, giving them seniority on engineering tasks and questions. This is a great approach for ensuring they remain junior managers, and unsuccessful leaders at that. It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading” - Marc Hedlund

Managing people is something I have not yet really come across directly - I have led teams where I was almost a pseudo-manager to some colleagues as their manager was not always available. If I had read some of the thoughts in this book I think I would have been able to be much more effective at helping my colleagues and creating a better culture within the team.

Regular 1-1s are a good way of establishing a good relationship with your team members - if you are catching up with them regularly outside of a 1-1 setting anyway it may be less critical to do this as you may end up just repeating things. Make it a time you are both likely to miss (i.e. not Monday/Friday as people are likely to take long weekends).

Feedback meetings should happen at regular points to track progress without making it a chore. Work with a to-do list or fluid style as suits you both - to-do might work better if you have certain tasks to go through, fluid if you want a more informal catch up where you get to know your team and talk through some problems. Keep notes in a shared document where you can look back on what has been discussed in the meetings!

Avoid micro managing, trust your teams. Ask you teams regularly where the might need some help so you can “micro”-manage those sections, i.e. ask what meetings you think you should attend, what details to escalate to the manager. Establishing coding standards and systems/processes is a good way to allow team members to have autonomy of the code whilst not allowing standards to slip.

Find out details without bugging teams - i.e. use dashboards to track progress, instead of constantly pestering someone. Make sure any negative news is taken in a neutral to positive way - i.e. if people are struggling, make sure that it isn’t seen as a bad thing to let this be known earlier next time as it will help the team be able to help the member out. This can be the difference between helping someone through a tough time at work and them becoming a great employee, or helping them fade out and face their own internal issues. There are countless stories of stress and anxiety causing people to suffer at work, and when faced with mangers who pressure them into feeling under fire it only pushes them further into isolation, where they can work from home more regularly, provide less frequent feedback due to fear of negative feedback etc. A more positive approach could be integral in allowing your team member to get through a tough period and leading them to flourish in their role. This might be especially true of under-represented cultures in your team / workplace, particularly if you as their manager are from the over-represented culture, where you are less likely to be able to empathise with the difficulties your employee may face on a day to day basis - asking your team member about any difficulties they think they are facing can help as a starter, or speaking to any friends in similar under-represented communities to understand what difficulties they regularly come up against in the workplace can give you the context of things to look out for which may make your team member feel out of place in the team.

On Continuous Feedback, get to know your team so you understand their strengths and weaknesses. Take notes of when they do things well and let them know.

Performance reviews should be taken seriously by the manager, gathering feedback from across the teams that the members have been working with, amalgamating to get a holistic view of how the person is doing on top of any more tracked progress (i.e. projects delivered etc).