Tonatiuh Núñez
Jan 26, 2021
Becoming a Tech Lead: 5 Concrete Guidelines
Tonatiuh Núñez
Jan 26, 2021
Becoming a Tech Lead: 5 Concrete Guidelines
Tonatiuh Núñez
Jan 26, 2021
Becoming a Tech Lead: 5 Concrete Guidelines
Tonatiuh Núñez
Jan 26, 2021
Becoming a Tech Lead: 5 Concrete Guidelines
Tonatiuh Núñez
Jan 26, 2021
Becoming a Tech Lead: 5 Concrete Guidelines
Introduction
During my career as a software engineer, I have played the role of Tech Lead different times, as I've played that role I've learned more and more mainly through practice.
In this blog-post, I want to share with you 5 takeaways that have been key for me, as well as some concrete action items you could implement.
(1) Listen to your People.
This is the lesson I consider the most important as a Tech Lead. Before asking anyone to do something or trying to motivate them you first need to know their context: what are the ideas and motivations that drive them.
Once you know what drives and motivates someone you'll be better at coordinating with that person. You'll probably know what type of work that person likes the most, what work that person might be better at, what type of learner that person is. All that will help you to get the best of that person positively impacting the work and the development of that person.
All that will increase your knowledge of the people in your team, improving your criteria to better assess what work should be assigned to who, and also help keep your team motivated.
Action item:
Before telling someone to work on something, explain why performing such task is important for the project, ask the person what thinks about the task and how will solve it. Pay full attention to the person comments, then using that information and your thoughts come up with a final plan that both agree to.
This will make that person feel empowered, more related to the task, and you'll learn more about that person’s skills level.
(2) Assign Time to Plan.
I once heard a very experienced software engineer say this phrase: "In my experience, I’ve learned two things about planning: 1. You always need to plan and 2. You always need to update your plan."
I agree with that phrase. There might be some resistance to the plan, maybe because of thinking that the plan has to be perfect and building a perfect plan is almost impossible. However, once you get into the mindset that a plan will always need to be updated, the perception of the complexity of planning decreases a lot.
As a leader you are a strategist, you have resources that were assigned to you and you have work to be done with those resources in a timely manner. Thus, building those strategies through planning is super important, usually planning time is very small compared to the amount of resulting work that it will positively impact.
Action item:
Leave at least one hour per week to plan your strategies to solve the challenges that need to be solved with the resources that you have (the skills of your team and their available time).
Document your strategies and their results to track how effective they are.
(3) Define Processes.
Documented processes are an amazing thing, once they're defined they can scale automatically with no need of someone permanently leading them. That's super helpful compared to activities where no process is documented and someone needs to spend time just leading the process again and again.
The other great thing about documented process is how much clarity they can bring to the team. For a team member it's way simpler to see the explicit list of steps related to a process, making it much easier to perform those chores. Also, it's very likely team members will get a clearer idea of why a process is required when there is concrete documentation about it.
It's super important to keep in mind that processes should be created by people for people. They should be as simple as possible and as friendly as possible. That will help people to get more empathy with the processes and be motivated to participate in them.
Action item:
Think about an existent activity or a new activity you'll like to implement in your team (for example learning a new technology among the team).
Think about what are the steps involved within that process and how the people participate in them.
Document the steps, outcomes and dependencies of the process. Then share the documented process with your team, with their feedback get to an agreement and start implementing that process.
(4) Learn to Delegate.
There is a huge difference between telling someone what to do vs delegating work to them. Sometimes we think that giving someone super clear instructions about what to do is all that needs to be done, and that's not the case, we can do that but that won't guarantee the person is really on board and motivated with the work. Also, that doesn't leave space to get to know if the person has a better idea or complementary ideas to perform the work better.
I heard a phrase some time ago that made a lot of sense to me: "if you hire someone to do a job then let them do that job". It's ironic how sometimes people with great talent or great potential are hired to be told what to do instead of letting them shine doing the work and building the solutions they were hired to do. Trust plays a big role here, as a tech lead you need to look for opportunities for your people to contribute with their talent; support them with your experience, and help them grow as much as they can, everyone wins there.
Action item:
Next time you see an opportunity, avoid telling someone what to do and instead explain to them what the challenge to solve is, ask that person how they will solve the problem, and move from there with that and your experience.
You'll see how you get to know that person better by leaving room for her to share her thoughts. This can eventually help you to identify other people who can be leaders in your team.
(5) Be Aware that Leading Requires Time.
When we move from an individual contributor position (for ex. a software developer or QA) to a managing position such as Tech Lead. It's easy and almost instinctive to think you'll maintain the same performance you previously had as individual contributor plus the new work as Tech Lead. It's very helpful to learn that such is not the case.
As Tech Lead you'll need to split some of your time between leading the team (talking to people, planning, etc.) and your individual contributor work.
Action item:
Monitor the total time you spend leading the team and the time you spend on your work as an individual contributor.
Try arranging your time so that you keep it under control. My recommendation is to shoot for no more than 25-35% of your time Tech Leading, in my experience that should be enough in most cases.
Conclusion
When playing roles with activities that are very dynamic such as leading a team, is very important to have concrete guidelines that help you stay in the right path as you gain more and more experience. The takeaways I shared above are thought to be guidelines to help you stay in that good path as Tech Lead.
What do you think? Do you find these guidelines helpful? Are you planning to implement any of them?
Introduction
During my career as a software engineer, I have played the role of Tech Lead different times, as I've played that role I've learned more and more mainly through practice.
In this blog-post, I want to share with you 5 takeaways that have been key for me, as well as some concrete action items you could implement.
(1) Listen to your People.
This is the lesson I consider the most important as a Tech Lead. Before asking anyone to do something or trying to motivate them you first need to know their context: what are the ideas and motivations that drive them.
Once you know what drives and motivates someone you'll be better at coordinating with that person. You'll probably know what type of work that person likes the most, what work that person might be better at, what type of learner that person is. All that will help you to get the best of that person positively impacting the work and the development of that person.
All that will increase your knowledge of the people in your team, improving your criteria to better assess what work should be assigned to who, and also help keep your team motivated.
Action item:
Before telling someone to work on something, explain why performing such task is important for the project, ask the person what thinks about the task and how will solve it. Pay full attention to the person comments, then using that information and your thoughts come up with a final plan that both agree to.
This will make that person feel empowered, more related to the task, and you'll learn more about that person’s skills level.
(2) Assign Time to Plan.
I once heard a very experienced software engineer say this phrase: "In my experience, I’ve learned two things about planning: 1. You always need to plan and 2. You always need to update your plan."
I agree with that phrase. There might be some resistance to the plan, maybe because of thinking that the plan has to be perfect and building a perfect plan is almost impossible. However, once you get into the mindset that a plan will always need to be updated, the perception of the complexity of planning decreases a lot.
As a leader you are a strategist, you have resources that were assigned to you and you have work to be done with those resources in a timely manner. Thus, building those strategies through planning is super important, usually planning time is very small compared to the amount of resulting work that it will positively impact.
Action item:
Leave at least one hour per week to plan your strategies to solve the challenges that need to be solved with the resources that you have (the skills of your team and their available time).
Document your strategies and their results to track how effective they are.
(3) Define Processes.
Documented processes are an amazing thing, once they're defined they can scale automatically with no need of someone permanently leading them. That's super helpful compared to activities where no process is documented and someone needs to spend time just leading the process again and again.
The other great thing about documented process is how much clarity they can bring to the team. For a team member it's way simpler to see the explicit list of steps related to a process, making it much easier to perform those chores. Also, it's very likely team members will get a clearer idea of why a process is required when there is concrete documentation about it.
It's super important to keep in mind that processes should be created by people for people. They should be as simple as possible and as friendly as possible. That will help people to get more empathy with the processes and be motivated to participate in them.
Action item:
Think about an existent activity or a new activity you'll like to implement in your team (for example learning a new technology among the team).
Think about what are the steps involved within that process and how the people participate in them.
Document the steps, outcomes and dependencies of the process. Then share the documented process with your team, with their feedback get to an agreement and start implementing that process.
(4) Learn to Delegate.
There is a huge difference between telling someone what to do vs delegating work to them. Sometimes we think that giving someone super clear instructions about what to do is all that needs to be done, and that's not the case, we can do that but that won't guarantee the person is really on board and motivated with the work. Also, that doesn't leave space to get to know if the person has a better idea or complementary ideas to perform the work better.
I heard a phrase some time ago that made a lot of sense to me: "if you hire someone to do a job then let them do that job". It's ironic how sometimes people with great talent or great potential are hired to be told what to do instead of letting them shine doing the work and building the solutions they were hired to do. Trust plays a big role here, as a tech lead you need to look for opportunities for your people to contribute with their talent; support them with your experience, and help them grow as much as they can, everyone wins there.
Action item:
Next time you see an opportunity, avoid telling someone what to do and instead explain to them what the challenge to solve is, ask that person how they will solve the problem, and move from there with that and your experience.
You'll see how you get to know that person better by leaving room for her to share her thoughts. This can eventually help you to identify other people who can be leaders in your team.
(5) Be Aware that Leading Requires Time.
When we move from an individual contributor position (for ex. a software developer or QA) to a managing position such as Tech Lead. It's easy and almost instinctive to think you'll maintain the same performance you previously had as individual contributor plus the new work as Tech Lead. It's very helpful to learn that such is not the case.
As Tech Lead you'll need to split some of your time between leading the team (talking to people, planning, etc.) and your individual contributor work.
Action item:
Monitor the total time you spend leading the team and the time you spend on your work as an individual contributor.
Try arranging your time so that you keep it under control. My recommendation is to shoot for no more than 25-35% of your time Tech Leading, in my experience that should be enough in most cases.
Conclusion
When playing roles with activities that are very dynamic such as leading a team, is very important to have concrete guidelines that help you stay in the right path as you gain more and more experience. The takeaways I shared above are thought to be guidelines to help you stay in that good path as Tech Lead.
What do you think? Do you find these guidelines helpful? Are you planning to implement any of them?
Introduction
During my career as a software engineer, I have played the role of Tech Lead different times, as I've played that role I've learned more and more mainly through practice.
In this blog-post, I want to share with you 5 takeaways that have been key for me, as well as some concrete action items you could implement.
(1) Listen to your People.
This is the lesson I consider the most important as a Tech Lead. Before asking anyone to do something or trying to motivate them you first need to know their context: what are the ideas and motivations that drive them.
Once you know what drives and motivates someone you'll be better at coordinating with that person. You'll probably know what type of work that person likes the most, what work that person might be better at, what type of learner that person is. All that will help you to get the best of that person positively impacting the work and the development of that person.
All that will increase your knowledge of the people in your team, improving your criteria to better assess what work should be assigned to who, and also help keep your team motivated.
Action item:
Before telling someone to work on something, explain why performing such task is important for the project, ask the person what thinks about the task and how will solve it. Pay full attention to the person comments, then using that information and your thoughts come up with a final plan that both agree to.
This will make that person feel empowered, more related to the task, and you'll learn more about that person’s skills level.
(2) Assign Time to Plan.
I once heard a very experienced software engineer say this phrase: "In my experience, I’ve learned two things about planning: 1. You always need to plan and 2. You always need to update your plan."
I agree with that phrase. There might be some resistance to the plan, maybe because of thinking that the plan has to be perfect and building a perfect plan is almost impossible. However, once you get into the mindset that a plan will always need to be updated, the perception of the complexity of planning decreases a lot.
As a leader you are a strategist, you have resources that were assigned to you and you have work to be done with those resources in a timely manner. Thus, building those strategies through planning is super important, usually planning time is very small compared to the amount of resulting work that it will positively impact.
Action item:
Leave at least one hour per week to plan your strategies to solve the challenges that need to be solved with the resources that you have (the skills of your team and their available time).
Document your strategies and their results to track how effective they are.
(3) Define Processes.
Documented processes are an amazing thing, once they're defined they can scale automatically with no need of someone permanently leading them. That's super helpful compared to activities where no process is documented and someone needs to spend time just leading the process again and again.
The other great thing about documented process is how much clarity they can bring to the team. For a team member it's way simpler to see the explicit list of steps related to a process, making it much easier to perform those chores. Also, it's very likely team members will get a clearer idea of why a process is required when there is concrete documentation about it.
It's super important to keep in mind that processes should be created by people for people. They should be as simple as possible and as friendly as possible. That will help people to get more empathy with the processes and be motivated to participate in them.
Action item:
Think about an existent activity or a new activity you'll like to implement in your team (for example learning a new technology among the team).
Think about what are the steps involved within that process and how the people participate in them.
Document the steps, outcomes and dependencies of the process. Then share the documented process with your team, with their feedback get to an agreement and start implementing that process.
(4) Learn to Delegate.
There is a huge difference between telling someone what to do vs delegating work to them. Sometimes we think that giving someone super clear instructions about what to do is all that needs to be done, and that's not the case, we can do that but that won't guarantee the person is really on board and motivated with the work. Also, that doesn't leave space to get to know if the person has a better idea or complementary ideas to perform the work better.
I heard a phrase some time ago that made a lot of sense to me: "if you hire someone to do a job then let them do that job". It's ironic how sometimes people with great talent or great potential are hired to be told what to do instead of letting them shine doing the work and building the solutions they were hired to do. Trust plays a big role here, as a tech lead you need to look for opportunities for your people to contribute with their talent; support them with your experience, and help them grow as much as they can, everyone wins there.
Action item:
Next time you see an opportunity, avoid telling someone what to do and instead explain to them what the challenge to solve is, ask that person how they will solve the problem, and move from there with that and your experience.
You'll see how you get to know that person better by leaving room for her to share her thoughts. This can eventually help you to identify other people who can be leaders in your team.
(5) Be Aware that Leading Requires Time.
When we move from an individual contributor position (for ex. a software developer or QA) to a managing position such as Tech Lead. It's easy and almost instinctive to think you'll maintain the same performance you previously had as individual contributor plus the new work as Tech Lead. It's very helpful to learn that such is not the case.
As Tech Lead you'll need to split some of your time between leading the team (talking to people, planning, etc.) and your individual contributor work.
Action item:
Monitor the total time you spend leading the team and the time you spend on your work as an individual contributor.
Try arranging your time so that you keep it under control. My recommendation is to shoot for no more than 25-35% of your time Tech Leading, in my experience that should be enough in most cases.
Conclusion
When playing roles with activities that are very dynamic such as leading a team, is very important to have concrete guidelines that help you stay in the right path as you gain more and more experience. The takeaways I shared above are thought to be guidelines to help you stay in that good path as Tech Lead.
What do you think? Do you find these guidelines helpful? Are you planning to implement any of them?
Introduction
During my career as a software engineer, I have played the role of Tech Lead different times, as I've played that role I've learned more and more mainly through practice.
In this blog-post, I want to share with you 5 takeaways that have been key for me, as well as some concrete action items you could implement.
(1) Listen to your People.
This is the lesson I consider the most important as a Tech Lead. Before asking anyone to do something or trying to motivate them you first need to know their context: what are the ideas and motivations that drive them.
Once you know what drives and motivates someone you'll be better at coordinating with that person. You'll probably know what type of work that person likes the most, what work that person might be better at, what type of learner that person is. All that will help you to get the best of that person positively impacting the work and the development of that person.
All that will increase your knowledge of the people in your team, improving your criteria to better assess what work should be assigned to who, and also help keep your team motivated.
Action item:
Before telling someone to work on something, explain why performing such task is important for the project, ask the person what thinks about the task and how will solve it. Pay full attention to the person comments, then using that information and your thoughts come up with a final plan that both agree to.
This will make that person feel empowered, more related to the task, and you'll learn more about that person’s skills level.
(2) Assign Time to Plan.
I once heard a very experienced software engineer say this phrase: "In my experience, I’ve learned two things about planning: 1. You always need to plan and 2. You always need to update your plan."
I agree with that phrase. There might be some resistance to the plan, maybe because of thinking that the plan has to be perfect and building a perfect plan is almost impossible. However, once you get into the mindset that a plan will always need to be updated, the perception of the complexity of planning decreases a lot.
As a leader you are a strategist, you have resources that were assigned to you and you have work to be done with those resources in a timely manner. Thus, building those strategies through planning is super important, usually planning time is very small compared to the amount of resulting work that it will positively impact.
Action item:
Leave at least one hour per week to plan your strategies to solve the challenges that need to be solved with the resources that you have (the skills of your team and their available time).
Document your strategies and their results to track how effective they are.
(3) Define Processes.
Documented processes are an amazing thing, once they're defined they can scale automatically with no need of someone permanently leading them. That's super helpful compared to activities where no process is documented and someone needs to spend time just leading the process again and again.
The other great thing about documented process is how much clarity they can bring to the team. For a team member it's way simpler to see the explicit list of steps related to a process, making it much easier to perform those chores. Also, it's very likely team members will get a clearer idea of why a process is required when there is concrete documentation about it.
It's super important to keep in mind that processes should be created by people for people. They should be as simple as possible and as friendly as possible. That will help people to get more empathy with the processes and be motivated to participate in them.
Action item:
Think about an existent activity or a new activity you'll like to implement in your team (for example learning a new technology among the team).
Think about what are the steps involved within that process and how the people participate in them.
Document the steps, outcomes and dependencies of the process. Then share the documented process with your team, with their feedback get to an agreement and start implementing that process.
(4) Learn to Delegate.
There is a huge difference between telling someone what to do vs delegating work to them. Sometimes we think that giving someone super clear instructions about what to do is all that needs to be done, and that's not the case, we can do that but that won't guarantee the person is really on board and motivated with the work. Also, that doesn't leave space to get to know if the person has a better idea or complementary ideas to perform the work better.
I heard a phrase some time ago that made a lot of sense to me: "if you hire someone to do a job then let them do that job". It's ironic how sometimes people with great talent or great potential are hired to be told what to do instead of letting them shine doing the work and building the solutions they were hired to do. Trust plays a big role here, as a tech lead you need to look for opportunities for your people to contribute with their talent; support them with your experience, and help them grow as much as they can, everyone wins there.
Action item:
Next time you see an opportunity, avoid telling someone what to do and instead explain to them what the challenge to solve is, ask that person how they will solve the problem, and move from there with that and your experience.
You'll see how you get to know that person better by leaving room for her to share her thoughts. This can eventually help you to identify other people who can be leaders in your team.
(5) Be Aware that Leading Requires Time.
When we move from an individual contributor position (for ex. a software developer or QA) to a managing position such as Tech Lead. It's easy and almost instinctive to think you'll maintain the same performance you previously had as individual contributor plus the new work as Tech Lead. It's very helpful to learn that such is not the case.
As Tech Lead you'll need to split some of your time between leading the team (talking to people, planning, etc.) and your individual contributor work.
Action item:
Monitor the total time you spend leading the team and the time you spend on your work as an individual contributor.
Try arranging your time so that you keep it under control. My recommendation is to shoot for no more than 25-35% of your time Tech Leading, in my experience that should be enough in most cases.
Conclusion
When playing roles with activities that are very dynamic such as leading a team, is very important to have concrete guidelines that help you stay in the right path as you gain more and more experience. The takeaways I shared above are thought to be guidelines to help you stay in that good path as Tech Lead.
What do you think? Do you find these guidelines helpful? Are you planning to implement any of them?
Introduction
During my career as a software engineer, I have played the role of Tech Lead different times, as I've played that role I've learned more and more mainly through practice.
In this blog-post, I want to share with you 5 takeaways that have been key for me, as well as some concrete action items you could implement.
(1) Listen to your People.
This is the lesson I consider the most important as a Tech Lead. Before asking anyone to do something or trying to motivate them you first need to know their context: what are the ideas and motivations that drive them.
Once you know what drives and motivates someone you'll be better at coordinating with that person. You'll probably know what type of work that person likes the most, what work that person might be better at, what type of learner that person is. All that will help you to get the best of that person positively impacting the work and the development of that person.
All that will increase your knowledge of the people in your team, improving your criteria to better assess what work should be assigned to who, and also help keep your team motivated.
Action item:
Before telling someone to work on something, explain why performing such task is important for the project, ask the person what thinks about the task and how will solve it. Pay full attention to the person comments, then using that information and your thoughts come up with a final plan that both agree to.
This will make that person feel empowered, more related to the task, and you'll learn more about that person’s skills level.
(2) Assign Time to Plan.
I once heard a very experienced software engineer say this phrase: "In my experience, I’ve learned two things about planning: 1. You always need to plan and 2. You always need to update your plan."
I agree with that phrase. There might be some resistance to the plan, maybe because of thinking that the plan has to be perfect and building a perfect plan is almost impossible. However, once you get into the mindset that a plan will always need to be updated, the perception of the complexity of planning decreases a lot.
As a leader you are a strategist, you have resources that were assigned to you and you have work to be done with those resources in a timely manner. Thus, building those strategies through planning is super important, usually planning time is very small compared to the amount of resulting work that it will positively impact.
Action item:
Leave at least one hour per week to plan your strategies to solve the challenges that need to be solved with the resources that you have (the skills of your team and their available time).
Document your strategies and their results to track how effective they are.
(3) Define Processes.
Documented processes are an amazing thing, once they're defined they can scale automatically with no need of someone permanently leading them. That's super helpful compared to activities where no process is documented and someone needs to spend time just leading the process again and again.
The other great thing about documented process is how much clarity they can bring to the team. For a team member it's way simpler to see the explicit list of steps related to a process, making it much easier to perform those chores. Also, it's very likely team members will get a clearer idea of why a process is required when there is concrete documentation about it.
It's super important to keep in mind that processes should be created by people for people. They should be as simple as possible and as friendly as possible. That will help people to get more empathy with the processes and be motivated to participate in them.
Action item:
Think about an existent activity or a new activity you'll like to implement in your team (for example learning a new technology among the team).
Think about what are the steps involved within that process and how the people participate in them.
Document the steps, outcomes and dependencies of the process. Then share the documented process with your team, with their feedback get to an agreement and start implementing that process.
(4) Learn to Delegate.
There is a huge difference between telling someone what to do vs delegating work to them. Sometimes we think that giving someone super clear instructions about what to do is all that needs to be done, and that's not the case, we can do that but that won't guarantee the person is really on board and motivated with the work. Also, that doesn't leave space to get to know if the person has a better idea or complementary ideas to perform the work better.
I heard a phrase some time ago that made a lot of sense to me: "if you hire someone to do a job then let them do that job". It's ironic how sometimes people with great talent or great potential are hired to be told what to do instead of letting them shine doing the work and building the solutions they were hired to do. Trust plays a big role here, as a tech lead you need to look for opportunities for your people to contribute with their talent; support them with your experience, and help them grow as much as they can, everyone wins there.
Action item:
Next time you see an opportunity, avoid telling someone what to do and instead explain to them what the challenge to solve is, ask that person how they will solve the problem, and move from there with that and your experience.
You'll see how you get to know that person better by leaving room for her to share her thoughts. This can eventually help you to identify other people who can be leaders in your team.
(5) Be Aware that Leading Requires Time.
When we move from an individual contributor position (for ex. a software developer or QA) to a managing position such as Tech Lead. It's easy and almost instinctive to think you'll maintain the same performance you previously had as individual contributor plus the new work as Tech Lead. It's very helpful to learn that such is not the case.
As Tech Lead you'll need to split some of your time between leading the team (talking to people, planning, etc.) and your individual contributor work.
Action item:
Monitor the total time you spend leading the team and the time you spend on your work as an individual contributor.
Try arranging your time so that you keep it under control. My recommendation is to shoot for no more than 25-35% of your time Tech Leading, in my experience that should be enough in most cases.
Conclusion
When playing roles with activities that are very dynamic such as leading a team, is very important to have concrete guidelines that help you stay in the right path as you gain more and more experience. The takeaways I shared above are thought to be guidelines to help you stay in that good path as Tech Lead.
What do you think? Do you find these guidelines helpful? Are you planning to implement any of them?
Guadalajara
Werkshop - Av. Acueducto 6050, Lomas del bosque, Plaza Acueducto. 45116,
Zapopan, Jalisco. México.
Texas
5700 Granite Parkway, Suite 200, Plano, Texas 75024.
© Density Labs. All Right reserved. Privacy policy and Terms of Use.
Guadalajara
Werkshop - Av. Acueducto 6050, Lomas del bosque, Plaza Acueducto. 45116,
Zapopan, Jalisco. México.
Texas
5700 Granite Parkway, Suite 200, Plano, Texas 75024.
© Density Labs. All Right reserved. Privacy policy and Terms of Use.
Guadalajara
Werkshop - Av. Acueducto 6050, Lomas del bosque, Plaza Acueducto. 45116,
Zapopan, Jalisco. México.
Texas
5700 Granite Parkway, Suite 200, Plano, Texas 75024.
© Density Labs. All Right reserved. Privacy policy and Terms of Use.