13 ms·

Few things I would like to say: It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, te

Few things I would like to say: It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself). Ask your team to write out everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in assessing what they were planning to build. (It also makes for a great log of what we did and why we did it. This will be the product documentation for your entire product tomorrow.) Treat your team like your family. Do not stress them out with too much work. Be respectful of their time and effort. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task. You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance for your business team too. Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently. There is a lot to add to the above list but in general the idea is to help your teammates grow, help them think critically, stand for your product - make the tough calls. All the best!

mywittyname 7y ago
The pre-formatted text is really hard to read.
- leetrout 7y ago
  It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself). Ask your team to write our everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in accessing what they were planning to build Treat your team like your family. Do not stress them out with too much work. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task. You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance or your business team too. Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
- jaspal747 7y ago
  Srry about that. Just updated it to regular text.
tensor 7y ago
I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.
- dillonmckay 7y ago
  I don’t know. It is important to listen to your users, but not necessarily do what your user’s want. Especially in the context of the user’s role. Adding a thousand requested features also has its drawbacks.
  - tensor 7y ago
    It's definitely a balance. I should have phrased it as "make sure the product satisfies your users needs" rather than their wants. And this isn't to say you should add a thousand features, but I do believe it's important that tech leads goals line up to users, not only to the technical excellence of the code. You can't make good decisions on technical improvements or debt reduction without balancing users needs. It's easy to build a straw man example that is on the extreme end to demonstrate this, so I won't do that. The day-to-day is more nuanced.
- jaspal747 7y ago
  As a tech lead, you bother about building the features that the business has identified - and building it in the best way possible, thinking long term about the product. While as a business decision maker, you focus on what your users want - else you will be out of business fairly quickly.
  - nevertoolate 7y ago
    Tech lead is responsible for maintainable code, somewhat anticipating changes in business, so tech lead is a Jedi :)
  - rorykoehler 7y ago
    They go hand in hand unless you plan to quit within a year and leave someone else to clean it up.
crimsonalucard 7y ago
If you find yourself teaching your team take a step back. The best managers build super star teams and gives the teams ownership and autonomy. You are in a good position if the team is teaching you, not the other way around. Try to build a team made up of people technically superior to you. And give them ownership, this is key. It is not just about finding engineers who take ownership. It’s about giving engineers ownership and getting out of their way.
- deleted 7y ago
  [deleted]
- UncleChis 7y ago
  This is exactly what I'm experiencing with my boss and I love that!
- frant-hartm 7y ago
  That depends on what tech lead role means in OP's context. It might me a team lead, in which case you are right, or something like coding architect which is usually one of the most senior members of the team with additional soft skills. Such person is expected to teach others.
- rorykoehler 7y ago
  I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design? On the subject of teaching your team you're right however. Instead aim to create an environment that fosters sharing. In my team I created a weekly tech share which the team does on rotation. It's been great for harmonising the team.
  - crimsonalucard 7y ago
    >I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design? I'm just talking about the ideal you should strive for. Given the opportunity this is what you should try to do. Of course like many ideals, you rarely have the ability or resources to fully implement the ideal.
sub7 7y ago
Respectfully disagree on the "write it out first" advice. I'd argue "think it out first" or "talk it out first" is sufficient. I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.
- cyode 7y ago
  If you have remote teammates or may have any in the future (i.e. if your company allows remote engineers), a culture of writing things down is imperative.
- fest 7y ago
  Consider that a successful product will be maintained for years. It is highly likely that a people will come and go. Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.
- dharmab 7y ago
  My team has a rule- if it's not in writing at a permalink it doesn't exist. A simple 2-3 line github issue is often enough. what and why.
- jugg1es 7y ago
  I disagree with this. Writing a set of "technical objectives" that say how a thing will work takes an hour at most and it helps you think through it better than a conversation. It also helps you pass information to QA. If someone asks what the thing does, you can just send them the link. Ultimately, taking an hour to write it down pays dividends later on.
- navyad 7y ago
  I would like to disagree here. Got into a team which has working prototype but not a single word on document. Which makes this hard to follow up with prototype. Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
jugg1es 7y ago
This is about as comprehensive as you can get in terms of what really matters in a good tech lead broken down into a few paragraphs. Who needs a book?! :)
wsinks 7y ago
Thank you!! I'm moving into a tech lead role as well only managing 2 people, but I need these cheat sheets.
billman 7y ago
I like the part about writing things down. There is a lot of mental organization that needs to happen when you write it down. It also forces you to make decisions.. which is also hard.
- serial_dev 7y ago
  At my current company (small startup) I wanted to convince people to talk through the issues and write things down or write down at least something. Think of user stories, requirements, personas, product vision, company vision, sprint goals. In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue. They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.
  - kohtatsu 7y ago
    Finding a way to show them might be difficult, but rewarding. (unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience. I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions. However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them. Doing so, things end up feeling more like trade-offs than compromises. Good luck!
- VectorLock 7y ago
  The only time I write anything with a pen and paper now a days, for the most part, is when I do 1:1s and check ins with my team. No computers for me. If I need to schedule something it comes after. The team member gets my full attention, no phones, Slack, email, or anything getting in the way.
derekchiang 7y ago
I think your advice is great for tech leads at big companies, but for tech leads at startups, I have to disagree with the point about "Work for your product - not your company." At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind. "Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.
- bransonf 7y ago
  I see where you’re going, but I think the advice still sticks. If you’re at a startup, your product is your business. The point about not hesitating to move fast is the biggest difference between startups and mature companies.
  - luckyscs 7y ago
    Depends if the product is a key profit center. If your startup is making a product and it's not a profit center, it might get binned, it might get pivoted, it might postponed. The advice is great, just don't die on a shortsighted engineering hill when the decision come from emotional attachment to your work rather than what's best for the companies positioning and financial health. You can always put that love and energy into a new/pivoting of the product.
  - tomnipotent 7y ago
    > If you’re at a startup, your product is your business. Your product is whatever you end up with after the long tenuous period of being startup, which often evolves/pivots drastically over time. Your product is your ability to execute.
  - unlinked_dll 7y ago
    The problem is if you're at a startup you probably don't know what your product is, because you don't know who your customers are. My last startup died because we committed too hard to the product and the business model, which while innovative and one that I still believe could have succeeded - we utterly failed because we didn't understand our customers and we didn't pivot fast enough, ran out of runway and then everyone but the founders got laid off. Waiting on hearing about the equity.
enz 7y ago
I agree with your comment and particularly this part: > It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself). When I had a TL job, I basically relearned the word "team" during my very first weeks. It was an amazing experience.
geoffchan23 7y ago
Don't forget that each member of your team is a unique individual. Just like raising kids, there is not a one size fits all formmula. Get to know each member of your team on a personal level. This will go a long way in building trust and being able to lead them effectively.

mywittyname 7y ago

The pre-formatted text is really hard to read.

leetrout 7y ago
It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself). Ask your team to write our everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in accessing what they were planning to build Treat your team like your family. Do not stress them out with too much work. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task. You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance or your business team too. Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
jaspal747 7y ago
Srry about that. Just updated it to regular text.

tensor 7y ago

I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.

dillonmckay 7y ago
I don’t know. It is important to listen to your users, but not necessarily do what your user’s want. Especially in the context of the user’s role. Adding a thousand requested features also has its drawbacks.
- tensor 7y ago
  It's definitely a balance. I should have phrased it as "make sure the product satisfies your users needs" rather than their wants. And this isn't to say you should add a thousand features, but I do believe it's important that tech leads goals line up to users, not only to the technical excellence of the code. You can't make good decisions on technical improvements or debt reduction without balancing users needs. It's easy to build a straw man example that is on the extreme end to demonstrate this, so I won't do that. The day-to-day is more nuanced.
jaspal747 7y ago
As a tech lead, you bother about building the features that the business has identified - and building it in the best way possible, thinking long term about the product. While as a business decision maker, you focus on what your users want - else you will be out of business fairly quickly.
- nevertoolate 7y ago
  Tech lead is responsible for maintainable code, somewhat anticipating changes in business, so tech lead is a Jedi :)
- rorykoehler 7y ago
  They go hand in hand unless you plan to quit within a year and leave someone else to clean it up.

crimsonalucard 7y ago

If you find yourself teaching your team take a step back. The best managers build super star teams and gives the teams ownership and autonomy. You are in a good position if the team is teaching you, not the other way around. Try to build a team made up of people technically superior to you. And give them ownership, this is key. It is not just about finding engineers who take ownership. It’s about giving engineers ownership and getting out of their way.

deleted 7y ago
[deleted]
UncleChis 7y ago
This is exactly what I'm experiencing with my boss and I love that!
frant-hartm 7y ago
That depends on what tech lead role means in OP's context. It might me a team lead, in which case you are right, or something like coding architect which is usually one of the most senior members of the team with additional soft skills. Such person is expected to teach others.
rorykoehler 7y ago
I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design? On the subject of teaching your team you're right however. Instead aim to create an environment that fosters sharing. In my team I created a weekly tech share which the team does on rotation. It's been great for harmonising the team.
- crimsonalucard 7y ago
  >I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design? I'm just talking about the ideal you should strive for. Given the opportunity this is what you should try to do. Of course like many ideals, you rarely have the ability or resources to fully implement the ideal.

sub7 7y ago

Respectfully disagree on the "write it out first" advice. I'd argue "think it out first" or "talk it out first" is sufficient. I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.

cyode 7y ago
If you have remote teammates or may have any in the future (i.e. if your company allows remote engineers), a culture of writing things down is imperative.
fest 7y ago
Consider that a successful product will be maintained for years. It is highly likely that a people will come and go. Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.
dharmab 7y ago
My team has a rule- if it's not in writing at a permalink it doesn't exist. A simple 2-3 line github issue is often enough. what and why.
jugg1es 7y ago
I disagree with this. Writing a set of "technical objectives" that say how a thing will work takes an hour at most and it helps you think through it better than a conversation. It also helps you pass information to QA. If someone asks what the thing does, you can just send them the link. Ultimately, taking an hour to write it down pays dividends later on.
navyad 7y ago
I would like to disagree here. Got into a team which has working prototype but not a single word on document. Which makes this hard to follow up with prototype. Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.

jugg1es 7y ago

This is about as comprehensive as you can get in terms of what really matters in a good tech lead broken down into a few paragraphs. Who needs a book?! :)

wsinks 7y ago

Thank you!! I'm moving into a tech lead role as well only managing 2 people, but I need these cheat sheets.

billman 7y ago

I like the part about writing things down. There is a lot of mental organization that needs to happen when you write it down. It also forces you to make decisions.. which is also hard.

serial_dev 7y ago
At my current company (small startup) I wanted to convince people to talk through the issues and write things down or write down at least something. Think of user stories, requirements, personas, product vision, company vision, sprint goals. In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue. They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.
- kohtatsu 7y ago
  Finding a way to show them might be difficult, but rewarding. (unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience. I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions. However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them. Doing so, things end up feeling more like trade-offs than compromises. Good luck!
VectorLock 7y ago
The only time I write anything with a pen and paper now a days, for the most part, is when I do 1:1s and check ins with my team. No computers for me. If I need to schedule something it comes after. The team member gets my full attention, no phones, Slack, email, or anything getting in the way.

derekchiang 7y ago

I think your advice is great for tech leads at big companies, but for tech leads at startups, I have to disagree with the point about "Work for your product - not your company." At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind. "Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.

bransonf 7y ago
I see where you’re going, but I think the advice still sticks. If you’re at a startup, your product is your business. The point about not hesitating to move fast is the biggest difference between startups and mature companies.
- luckyscs 7y ago
  Depends if the product is a key profit center. If your startup is making a product and it's not a profit center, it might get binned, it might get pivoted, it might postponed. The advice is great, just don't die on a shortsighted engineering hill when the decision come from emotional attachment to your work rather than what's best for the companies positioning and financial health. You can always put that love and energy into a new/pivoting of the product.
- tomnipotent 7y ago
  > If you’re at a startup, your product is your business. Your product is whatever you end up with after the long tenuous period of being startup, which often evolves/pivots drastically over time. Your product is your ability to execute.
- unlinked_dll 7y ago
  The problem is if you're at a startup you probably don't know what your product is, because you don't know who your customers are. My last startup died because we committed too hard to the product and the business model, which while innovative and one that I still believe could have succeeded - we utterly failed because we didn't understand our customers and we didn't pivot fast enough, ran out of runway and then everyone but the founders got laid off. Waiting on hearing about the equity.

enz 7y ago

I agree with your comment and particularly this part: > It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself). When I had a TL job, I basically relearned the word "team" during my very first weeks. It was an amazing experience.

geoffchan23 7y ago

Don't forget that each member of your team is a unique individual. Just like raising kids, there is not a one size fits all formmula. Get to know each member of your team on a personal level. This will go a long way in building trust and being able to lead them effectively.