I follow 1..3 daily. I also have this.

4) Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself.

5) Expect to do less actual programming, but still keep ownership of one or two components (UI, DB, etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing features/bugs and to communicate intelligently with the technical team.

1-5 are great and what I do. The hardest one for me is 2. I have so many things to get done, but always remember keeping your team on track is your number 1 priority.

It's hard for me as well, but as I've lead more teams I've learned how to delegate more. It's okay to delegate hard tasks to more advanced members of your team, if it leaves you open for more questions and the ability to support others. As far as the client is concerned, I'm the representative for all of the backend work that's been done, so according to them it is I who take ownership for the whole thing. Therefore, the best thing for me to do is ensure that my team who is doing the actual coding work is as supported as they can possibly be, so they can get the most work done in the shortest time frame.

Ownership. Delegation. Support.

I have to remind myself that no matter how productive I am, I can't be more productive as a whole team of smart engineers. One of my main jobs as a tech lead is an enabler. If I can remove blockers and try to cultivate experts then things get done.

I do about 30% helping and answering questions. 30% meetings and planning. 30% code reviews. 10% coding.

I would like to join a team which has team lead who follows above points...

>Expect to do less actual programming

Even if you don't do much actual programming you need to be the one that monitors and accepts all pull requests.

That also means taking responsibility for any of the subsequent angry users because you merged that code and you could have stopped it.

Keeping an eye on pull requests also means gently guiding the junior devs to amend their code when they head down the wrong path (e.g. by pairing with them) rather than just rejecting it outright or (worse), writing a snarky comment.

> you need to be the one that monitors and accepts all pull requests

I disagree at least in part. On my team all of the engineers have the ability (and responsibility) to merge PRs. It empowers them and gives them a feeling of ownership. I let the experts in the affected area decide when code goes in/gets deployed as they're able to manage that better than I ever could.

That being said, when something breaks, it's still the tech lead's problem, even if he/she didn't hit the merge button.

5th is VERY must, after a while the team feels you are just another non-coding hairy pointed manager. The problem is developers will have hard time to accept your suggestions questioning your judgement subconsciously and consciously. If you keep telling them that you were once a hard coder, i am sure that won't help at all. so always make sure 1/3 rd time is spent in coding.

I'd add a

6) Make sure your team fully integrate the solutions with other teams. Encourage cross team communication. Make sure solutions are built with other teams feedback. The more other people is integrated in your team solutions, the more will be used and supported

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.

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.

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

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.

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!

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.

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.

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.

How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.

Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward.

I learned those rules from observing the behavior of group leaders I've worked with/for. There have been a few times (over many years) when I've thought to myself, "My boss is fantastic! I am so amazingly lucky to be working for this person!!" When that happens, I've asked myself, how does he/she do it? And tried to figure out the answer.

There also appears to be satisfaction in cultivating new talent and watching it grow. A friend of mine is at his most excited and animated when he is talking about the new ways his reports have grown as engineers, not when he's talking about this or that technology.

"Competence is it's own reward." Nicely said.

Well, if you keep working on shitty tasks (because you assign them to yourself) and keep being interrupted, only for your product to depend on the hazards of the market, you will get burned at some point if what you ship fails for reasons that don't depend on you or the team and people leave as a result.

I honestly hope it will not happen because you seem like a great Lead, but you can't say this scenario is not a possibility.

Burnout's likely whenever you work really hard on a product that nobody uses, regardless of what your role at the company was. It sucks to sacrifice hard for something that doesn't pan out.

The solution to that isn't to only work on the stuff that pleases you, though. It's to only work for companies that have traction or at least demonstrated consumer demand. It's the founders' job to validate that there's a reason for the company to exist; make sure they've actually done their job before you entrust them with yours.

This happened to me, and is one of the reasons I quit being a manager and went back to being a developer. The product didn't actually fail, but the daily stress of constant interruption and long hours of slogging through thankless shitty tasks eventually wore me down.

Also, I regret not having delegated some of those boring and shitty tasks, since they would have developed skills in my staff (like debugging under difficult environments) that would have made them stronger and more independent developers.

If you don't derive satisfaction from helping your team, absolutely do not become a lead. Between meetings, planning overhead, interruptions, team communication, documentation, and so on you'll never reach the kind of individual productivity you could alone.

Definition of shitty task varies greatly.

A personal anecdote: I have recently discovered I was bored on a job because the tech lead, after working with a dozens of engineers who considered cleanup and simplification tasks boring and wanted to implement new features, stopped parcelling out those and kept them to himself, while distributing new functionality tasks (which I don't personally enjoy doing 40 hours a week) throughout the team.

There's some amount of zen to it. Your job is no longer to be the best coder yourself, it's to make everyone else the best coders they can be. I don't have kids yet, but I can imagine some similarities.

On the other hand, once a month or so I hide from the office for an afternoon/night and replace some infrastructure or build an internal tool that's never going to get prioritized. Everyone's happy about it, and you get to feel like a bit of a hero :)

There is so much zen to it. I've gone from being the single developer sitting in a room with the founder and the creative director building a product from scratch to managing a technical team of 15 at the same company, with another couple dozen employees in other departments.

The difficulty of running a large technical team is all about managing coordination and communication overhead. You need to build a culture where interruption is frowned upon, but at the same time you need to ensure that knowledge isn't siloed. The balance is very very important, and the means of achieving it are much more art than science. I suppose I could throw up my hands and concede I'll never be able to regain the focus to be a good individual contributor, but I rebel against that inclination on the (perhaps selfish) belief that going full management would put me out of touch with the people I'm managing.

In any case, it is possible to both manage and write code, but it requires an incredible amount of discipline to truly embody the nature of each job and do them well side by side.

Be very judicious about how often you put your own delivery on the critical path of the project (or sprint, or other unit of work.)

It shouldn't be very often.

Yep. You should never ever be on the critical path

1. If you don't deliver and you hold up the schedule, you lose authority as a leader because really … if you can't, then you can't expect others. 2. You WILL be diverted to other tasks that will hold you up

Knowing #2 and still causing #1 is fatal.

My biggest energy expenditure is usually right at the beginning of a release cycle, or even a week or two before it when our process is working correctly (a good process means a boring release week).

We will have figured out some big infrastructure or design issue we need to fix and between requirements meetings we code like hell. Blocking people during week 1 or 2 goes a lot better than week 8 or 17.

I've found this to be the single greatest challenge I have as a tech lead. It's incredibly tempting to say "oh, I think I'll have time this week, so I can take that Trello card". If it's on the critical path, leave it for someone else. You won't have time.

If you are in a healthy organization, even though you verbally credit your team, etc., consistent successes will reveal that you are a good leader and mature leaders (above you) will recognize your value.

You lower your expected output.

For me, I get the satisfaction of solving the really crazy problems, and seeing how it affects team productivity. Every week you find a way to save the team a manhour or more of frustration, and it adds up quickly.

You also tend to fix bugs and perf issues nobody else is sanctioned to spend that kind of time to tackle.

Make sure you're getting compensated properly, and make sure it's work that's visible.

If you can't do those two things...well, enjoy your burnout. :(

I chuckled, then cried inside reading this, so true.

But there is something to add to this, I got burned out, took a mini-sabbatical and came back a rockstar with a pay raise.

I guess the invisible work became visible in my absence. :-)

An additional side-benefit, I became human again.

When my coworkers bitch about being underpreciated I tell them to take a week off and find out if they're right. if everybody isn't on the same page it's time to move on.

I think this is really good advice, as a Technical lead you should see yourself as mentor for the other developers.

But I also feel that it is important that you should see yourself as the one that also include the business goals into the development team.

Depending on the situation, you will at some point, if not often, have someone doing work for you that knows more about a topic or component. Understand that you don't have to know more or everything to be a good leader.

A very important point, and true of anyone holding any form of seniority in a position, but especially as a team lead. Always remain humble and accept that your team can have abilities and understanding beyond yours.

But, as an alternative to 3, and possibly an extension of 4, when you have an idea/experience of a solution to a problem but your team does not, create a dialogue whereby your questioning of their approach allows them to find your solution by themselves. You can pass on skills and techniques you've learnt in a manner where they learn them too rather than being told of the solution. Your team will feel proud of their solution and you can be happy knowing you are cultivating a strong learning environment.

As far as (3) is concerned, I'd say that it's more important to actually have an "I might be wrong and would want to change my beliefs in that case" attitude and just be honest.

It's terribly easy to notice when someone gives a canned "I'm not sure it's the right approach" response while thinking that it's obviously wrong. Noticing that causes many people to feel patronized and/or lose trust in that someone.

I agree. The "I'm not sure it's the right approach" is too easily brushed off.

Open, factual discussion has been my approach. It may bruise some egos, but in my experience, the alternative may be just as bad as rubber-stamping and that just isn't compatible with my ideals.

I also think that people will learn to respect the results of the approach in the long run and that is infectious, promoting real growth.

One of your long-term responsibilities is to grow your team so everyone is more effective in the future. To elaborate a little more on #1, the primary tool at your disposal is the ability to allocate work. It's important to allocate work in ways that are both achievable and meaningful to your team's growth. This means two things:

(1) Breaking projects into small enough chunks that they can be taken on by a single engineer.

(2) Coalescing small tickets into bigger projects so that they can be taken off in a larger chunk.

It's tempting to give all the small tickets to junior engineers, especially close to a release, but occasionally giving people projects that at the 90th percentile of their capabilities both gives them skill growth and gives them something to point to as an accomplishment come performance review-time.

I totally agree with (1) and (3). However, about (2), it obviously depends on the team and everything, but for me, I've asked that if someone has a question and I have my headphones on, ask me on slack. I'll respond quickly, and it's way less disruptive to me than verbal interruptions.

I guess for me it depends on whether the team lead is more of a peer or more of a supervisor. If the team is all senior people, then I'd agree, they should be more careful about interrupting and honoring the headphone convention.

But if the other person is more junior, or a direct report, or just joined the company, then I personally feel more responsibility to give a prompt answer and prioritize the other person's productivity over my own.

To add to your second point, it's also good to make people come to you if they need anything from someone on your team so you can filter out all the unnecessary interruptions and let them focus on their work.

Just wanted to thank everyone who contributed - don't know where to put this comment for everyone to see. :)

Posted before going to sleep, and didn't expect that many comments at all. What a way to start the day. Still reading.

I disagree on #1. There's no need to be a martyr as a tech lead. Assign the tasks based on who is the best person to get it done (based on competency, knowledge of affected components, etc.). Treat your employees like adults. They don't need to be coddled, they know there are unpleasant tasks sometimes. Just try to be fair and ensure that your employees are not getting too such tasks to the point where they feel bogged down. Ask them "are you bored?" whenever you have a 1-on-1 meeting.

>Ask them "are you bored?" whenever you have a 1-on-1 meeting.

Why would they answer honestly and not what they believe is your expectation? I know I have been in lots of situation where I chose the nice over the honest answer and I don't think I am special here.

I remember once someone was doing the absolute wrong approach for something and I did basically number 3 and they said "I'd rather do it this way", of course since I knew it was wrong I should probably just have said "that is wrong do it like this".

The problem with #1 is when you get fired for not building anything sophisticated and your teammates get promoted to replace you, because they built something fancy. Unless you manage to take credit for their work. Externally imposed politics is what kills the team.

Regarding (3) why there is so sharp divide between people who say, "don't sugercoat the truth" and what you just advised. It is confusing what side to be on.