4 ms·

Note of caution on point 2. If you still do a lot of coding, this can really impede on your productivity, and break you out of any flow state. When an employee

by erlich 11y ago

Note of caution on point 2. If you still do a lot of coding, this can really impede on your productivity, and break you out of any flow state. When an employee asks you a question, you will feel like you don't want to be abrupt and will find yourself taking a few minutes each time. I find a lot of the time employees will come with questions they could have asked over slack/chat that would have not broken my flow, and could be resolved quickly with a link, etc. Its much better to develop a consensus on how to best use productivity tools asynchronously, and optimise your flow. E.g. - Instead of walking over - ask on slack first. - If something is less urgent, link to Trello card/Github issue/etc. with more details. On Slack, using the right channels/rooms is important too. Serendipity and collaboration from overheard conversations is really really important. Physically overhearing discussions that you could weigh in on can save huge amounts of time and catch problems early on, but can be a distraction. In flow/with headphones you lose this ability to overhear. Having public chat rooms you can monitor regularly is the best. Avoiding employees private messaging each other is the goal.

nostrademons 11y ago
It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it. You should also be coming up with good ways to use productivity tools asynchronously. But remember that the natural impulse for many employees will be "Oh, the boss is busy, I better not disturb him. Guess I can't do any work until then!" You need to make sure that whatever communication mechanisms you agree on have buy-in from the rest of the team, and that they'll be comfortable interrupting you if they're really blocked and unable to get work done.
- jghn 11y ago
  This. As a relatively new technical lead I'm finding myself coding less and less because of these sorts of things. I don't enjoy that aspect but at the end of the day what my job really is is to make the rest of the team as productive as they can
- hinkley 11y ago
  The second most important thing is to make sure the guy with the checkbook agrees with this. Worked myself out of a job once by not doing that, not on my timeline. Actually both leads did the same thing, and I have no idea how they solved deep technical problems after that since the two of us were handling 75% of them... Here were two expensive Devs not getting features done as fast as anybody else. Look at all the money I saved!
- brudgers 11y ago
  Ideally, upward, downward and lateral communication channels have people on both ends who are sensitive to issues created by timing. One of the roles of a leader in some organizations is to model desired behavior and develop productive habits throughout the team. Since there are many more lateral communication channels within a team and there is an aspect of being a technical lead that is being a peer to the team's members [and not "the boss"], there is more productivity to be gained when all team members communicate in ways that reflect awareness of the state of the communication channel from the other person's perspective. The problem with the internet text boxes is that complex human interactions get sketched and lose important details.
code_sterling 11y ago
I wouldn't recommend this. I have over 15 years as lead dev experience, and this isn't good advice. This tells your team that your time is more valuable than their contribution. No matter how good you are, you can't do as much as your team if they are properly guided, supported, and motivated.
- FLGMwt 11y ago
  OP's most important point is that when you're talking to team members, you ask them if it's a good time. Ideally, they'll take that as leading by example and hopefully they'll catch on.
memracom 11y ago
Your flow is not important, theirs is. In any leadership role you are more like a janitor than a hero. You have to clean up the messes, keep the bathrooms supplied, fix the broken things. Either train yourself to cope with breaks in the flow, or get used to doing less coding.

by erlich 11y ago

nostrademons 11y ago

It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it. You should also be coming up with good ways to use productivity tools asynchronously. But remember that the natural impulse for many employees will be "Oh, the boss is busy, I better not disturb him. Guess I can't do any work until then!" You need to make sure that whatever communication mechanisms you agree on have buy-in from the rest of the team, and that they'll be comfortable interrupting you if they're really blocked and unable to get work done.

jghn 11y ago
This. As a relatively new technical lead I'm finding myself coding less and less because of these sorts of things. I don't enjoy that aspect but at the end of the day what my job really is is to make the rest of the team as productive as they can
hinkley 11y ago
The second most important thing is to make sure the guy with the checkbook agrees with this. Worked myself out of a job once by not doing that, not on my timeline. Actually both leads did the same thing, and I have no idea how they solved deep technical problems after that since the two of us were handling 75% of them... Here were two expensive Devs not getting features done as fast as anybody else. Look at all the money I saved!
brudgers 11y ago
Ideally, upward, downward and lateral communication channels have people on both ends who are sensitive to issues created by timing. One of the roles of a leader in some organizations is to model desired behavior and develop productive habits throughout the team. Since there are many more lateral communication channels within a team and there is an aspect of being a technical lead that is being a peer to the team's members [and not "the boss"], there is more productivity to be gained when all team members communicate in ways that reflect awareness of the state of the communication channel from the other person's perspective. The problem with the internet text boxes is that complex human interactions get sketched and lose important details.

code_sterling 11y ago

I wouldn't recommend this. I have over 15 years as lead dev experience, and this isn't good advice. This tells your team that your time is more valuable than their contribution. No matter how good you are, you can't do as much as your team if they are properly guided, supported, and motivated.

FLGMwt 11y ago
OP's most important point is that when you're talking to team members, you ask them if it's a good time. Ideally, they'll take that as leading by example and hopefully they'll catch on.

memracom 11y ago

Your flow is not important, theirs is. In any leadership role you are more like a janitor than a hero. You have to clean up the messes, keep the bathrooms supplied, fix the broken things. Either train yourself to cope with breaks in the flow, or get used to doing less coding.