Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to Be a Good Technical Lead?
520 points by Evgeny on Oct 15, 2015 | hide | past | favorite | 174 comments
Dear HN,

You've been a source of great information before, and I'm sure I won't be disappointed by your advice.

I worked as a Software Developer all my career (more than 15 years now), but now I'm interviewing for a Technical Lead position. I have almost two weeks before the interview.

I'm interested in resources and advice on how to be a good Tech Lead, regarding both technology and people skills. Of course I've seen and taken note on how other leads work, but still feels like a big step for me.

The development environment is Microsoft.NET. The main product is a complex software. The main goal would be to develop it so that it is "loosely" built, split into separate modules so that each one can be modified without touching the others.




Here are three rules I've followed:

1) If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself.

2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something.

3) If someone wants to try an approach that you think is wrong, say: "I'm not sure that's the right approach, because of X, Y, and Z. However, I've been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?" If you're working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.


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.


- you're going to be part of a lot of meetings, email list etc... Make sure you flow information down to your team, every day.

- your main job will be to:

    - unblock your tam members

    - bring them back on track
- consensus is great, but sometimes it doesn't work. Know when you need to make a decision even if not popular.

- praise publicly, criticize in private

- give people a chance (give warnings)


Also:

  - Be explicit about your expectations for each of the team members. This is a
    discussion, not a declaration.

  - Give feedback early and often, both constructive and kudos.

  - Your first priority is the productivity of your team, not your individual
    productivity. This means taking the time to help team members that are
    struggling, even at the expense of closing out your own stories on time.

  - Don't be afraid to be vulnerable, admit your own failings or tell your team
    that you don't know. Allowing your team to see the decision making process
    when you go through it can be very valuable and is much better than just being
    the guy who has an answer to everything. As a plus, showing your own
    vulnerability will lead to your team showing their vulnerability more readily.

  - Even if you've got the answer, sometimes it makes sense to let your team make
    the decision. There are often many right answers. Remember, your job isn't to
    choose a right answer, it's to ensure that the team doesn't choose a wrong
    answer.


> Even if you've got the answer, sometimes it makes sense to let your team make the decision. There are often many right answers. Remember, your job isn't to choose a right answer, it's to ensure that the team doesn't choose a wrong answer.

Couldn't agree more. Allowing the team to own decisions as a group goes a long way toward boosting morale and giving each member a greater sense of pride and ownership. Sometimes people need subtle guidance away from poor choices, but often time, allowing people to explore options on their own-even briefly, they'll often make the right choice in the end.


> Your first priority is the productivity of your team

I agree! The grandparent talks about unblocking team members and bringing them back on track. These little tweaks happen frequently as part of team productivity.

Other things also affect the team's productivity though! Consider how productivity will be impacted with various paths forward (Should we implement feature A or B, should we implement it with X or Y?)


your main job will be to:

- unblock your tam members

- bring them back on track

Ditto. Note that the unblocking/course-correcting role is the real job. Depending on the size of the team, you may or may not want to be involved in architecture/design of minor projects that crop up all the time (things that might take a week or two to develop). Your team should trust and rely on your advise/insight around technical issues. Writing code yourself would be a secondary role though if it's a smaller team (2-3) people, you'd be advised to pull your weight there as well.

And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.


And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.

Exactly. In my experience, team lead of smaller teams (less than 6-8 developers, testers, etc.) just means 50% more work for the same pay and status. You are not a true manager in your superiors' eyes.

Also, it is rarely a way to move up the ladder. In our business, changing companies every few years is the only way to get promotions and raises.

Unless the job comes with the ability to purchase resources, make hiring and firing decisions, while also being paid more, team lead is not a position I volunteer for anymore. It's better to use the extra time for your own projects / networking.


- Don't be a part-time developer while managing. Managers who fight for code with the people they're managing are the worst.

- You are there to filter the more outrageous demands of other department into something manageable rather than just forwarding everything people say down to the department.

- Don't quibble team member's estimates for time required to implement feature X. Just forward that to management.

- Encourage each team member's professional development. Encourage members to mentor each other. If someone screws up, it's possible they didn't have the tools to succeed, have them investigate what they need.


This is one of the more useful set of management tips that I have read.

First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.


no wonder, they have the tech lead skills :)


With your experience you will likely know the right course of action to take immediately, but will still have to reach consensus with the team to keep them engaged as solving the problem is the fun part.

Get good a steering the conversation to your solution vs. just handing it down. You know the whole making it seem like it was their idea thing.

If your team perceives you as an authoritarian, they will be afraid to make any decisions on their own and you will become a constant roadblock.


What's a good source on becoming a software dev lead? Here are a few suggestions among the many available:

Brooks' "The Mythical Man Month" is a classic in this space, though I think its emphasis is less on leadership than the difficulties in software project management. And the book is rather dated now.

DeMarco and Lister's "Peopleware: Productive Projects and Teams" is also a classic, and emphasizes interpersonal team dynamics as well as software project management.

Hunt and Thomas's "The Pragmatic Programmer" is highly regarded and traces the progression of a software pro from being led to becoming leader.

Mantle's "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" looks intriguing, but I have no firsthand experience with it.

I know agile is a big deal these days, but I can't recommend any books that are specific to doing it well. I'm not really a fan. But in this space, you might take a look at Rich Sheridan's: "Joy Inc: How We Built a Workplace People Love". He runs a small creative agile contracting shop that employs a variety of techniques build and maintain a positive workplace.

In a similar vein is Weinzweig's "A Lapsed Anarchist's Approach to Being a Better Leader". He's the founder of Zingerman's Deli (in Ann Arbor MI) and is a very creative force toward making your workplace constructive and engaging. Not related to software, but full of good ideas.

Weinberg's "Becoming a Technical Leader: An Organic Problem-Solving Approach" is an oldie but goodie in this space, though it doesn't focus on software but tech of all kinds.

Finally, I heartily recommend "Code Complete" as an excellent source on how to program solid/maintainable code, especially if you hope to lead more by example than command.


Amazon links for the lazy:

"The Mythical Man Month" - http://amzn.com/0201835959

"Peopleware: Productive Projects and Team" - http://amzn.com/0321934113

"The Pragmatic Programmer" - http://amzn.com/020161622X

"Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" - http://amzn.com/032182203X

"Joy Inc: How We Built a Workplace People Love" - http://amzn.com/1591845874

"A Lapsed Anarchist's Approach to Being a Better Leader" - http://amzn.com/0964895692

"Becoming a Technical Leader: An Organic Problem-Solving Approach" - http://amzn.com/0932633021

"Code Complete" - http://amzn.com/0735619670


Thanks for the shortened URLs. Question: I always obtain those by hitting "Share" and then copying the link. Is there a better way?


DeMarco and Lister's "Peopleware: Productive Projects and Teams" was published way back in 1987 with 2 new editions over the years.

And even the first edition untouched is still completely relevant.

While its focus is "getting teams to work well together and develop good software", I think it has excellent viewpoints and advice for any workplace where people use their brains for a living, regardless of what the company does.

I'd also like to add "Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams" by Steve Maguire.


I highly recommend "The Psychology of Computer Programming" by Weinberg to this list. One of the best books about programming that I've ever read.


A big +1 for Becoming a Technical Leader. Foster motivation, organization and innovation in yourself and your team.


I'm so happy that I've read four of the mentioned above - the first three and the "Code complete". Will try to do some more reading in the nearest days.


Technology

  1. Know your apps.
  2. Understand your domain.
  3. Understand your technology under the hood.
  4. Have an idea of how you'd approach each project.
  5. Write detailed technical specs for juniors.
  6. Write general technical specs for seniors.
People

   1. Be nice.
   2. Understand you are a resource provider, not a boss.
   3. Get shit done.
   4. Ditch team building gimmicks (see #3 for what's important).
   5. Listen!
   6. Share. Share. Share. 
   7. Teach. Teach. Teach.
   8. When you need a bad guy/gal, you're it.
   9. When you need a good guy/gal, your people are it. 
  10. Know how to run a project as needed.
  11. Know how to run a meeting as needed.
  12. Don't be bashful.
  13. Don't be (too) stubborn.
  14. Stand your ground with users/bosses.
  15. Have fun & foster an environment for others to too.
  16. Always do the right thing.
  17. Never stop being a programmer.
  18. Never stop loving building stuff.


    4. Ditch team building gimmicks (see #3 for what's important).
I'd say gimmicks aren't going to save you, but consider morale events and other subtler stuff to help build team cohesion. Things like going to lunch regularly together, for example. When people are more comfortable with each other it makes it a lot easier for them to collaborate, rely on each other, ask each other questions, mentor each other, etc.


The art is to distinguish between gimmicks and effective team building. I believe regular lunch together is great. Having a day-long team building event not so much. Watching a movie together is nearly useless because there is little interaction.

I think the important aspect is for people to interact in different contexts. Lunch is already different to the usual office context. Playing games is great in general (board games, paintball, rpg, team sports, whatever).


I would like to work for a leader like that.

In that way, I would rather stay there as savy engineer for as long as it holds.

What impresses me the most are,

8. When you need a bad guy/gal, you're it. 9. When you need a good guy/gal, your people are it.

It is natural for good leader to think for engineers. But also thinking in the position of users/productivities wise is important.


These seem to be terribly vague, e.g.:

  16. Always do the right thing.
Some of these I either misunderstand or contradict each other, e.g.:

   1. Be nice.
   8. When you need a bad guy/gal, you're it.


I think number 8 (& nine, because they are heavily related) mean that when higher ups want to blame someone, they should blame you as technical lead (and not individual team members) but when someone needs/is going to be praised make sure it's the team member that deserves it (and not you!). I heavily agree with this.


You'd be surprised how easy it is for teams to do the wrong thing. Most people have too narrow of a focus, not enough perspective, and not enough wisdom to even care about the right things. Without people with experience, vision, and influence often times the right things just don't get done.

Being nice means not being ruled by your emotions and not slipping into pettiness. If you have a disagreement with someone, do it nicely. Give people the benefit of the doubt. Etc.

But on the other hand, sometimes it's necessary to do or say things that are unpopular or difficult to accept. The difference is doing the unpopular thing that is necessary vs. being mean because you can't control your temper or you're just a jerk or you're trying to "win" some stupid technical argument. Don't be a jerk, don't yell, don't belittle people, but absolutely call people out on their shit when necessary.


I think 8 means that if you need to find someone to blame, you're it. (Whereas 9 means that the praise goes to your team, not you.)


I always recommend the book "Leading Snowflakes" for new technical leads or engineering managers:

  http://leadingsnowflakes.com
It gives very concrete advice, and it explains the people side in terms of skills that may already be familiar to you as an engineer -- for example, to "code review" your management decisions with your teammates.

I'm also a big fan of this video on Autonomy without Chaos, by David Singleton. David is one of the best engineering managers I've worked with, and really exemplifies a style of management that's focused on empowering your team from the bottom up: https://www.youtube.com/watch?v=RKgZmHhSD9I


It's always interesting to come across a book relevant to me and find that it's basically a step-by-step implementation of Nathan Barry's "Authority" guide to writing a book (I mean that in a positive way, the site is very well made).


A good tech lead in my mind is someone with a strong technical vision who has the backbone to see their vision through, but is also very adept at ironing out the myriad issues that fracture teams. It means being an advocate for the best technical solution but compromising with the other teams in the org to meet their needs. It also means being very unpopular as a good technical lead will give commandments from on high even when they're not popular or well liked opinions.

Basically your job will be reducing friction by pissing everyone off. So it's even worse than "if you've done it right, no one will know."


In my experience, a good technical lead won't give commandments from on high. A good technical lead will consult and facilitate a discussion and mediate conflict. They will also be directive when the time is right, but only after having listened and weighed the arguments. They will also be able to explain the rationale behind those decisions.


I've had your tech lead. They're a weenie and nobody ever congeals around initiatives because they have endless meetings to debate everything all the time. Sometimes you just need to say, "do it this way or find another job." I know that's not a popular idea around the democratized millennial coddling of Silicon Valley, but honestly I'd rather have someone throw down the gavel than sit through another month of research findings meetings before we finally decide git is better than svn. Your person isn't a lead, they're a diplomat.


A really good tech lead will manage you by telling you "do it this way or find another job", but will manage the more sensitive members of the team by gently suggesting what they might want to do, and might manage the more technically-minded members of the team by pointing out the concrete pros and cons of an approach.

The point is that different people need to be managed in different ways. You might want clear direction. I will quit if told "do it this way or find another job". The best managers will interact with you in the ways that get the most out of you, while interacting with me in the ways that get the most out of me. If we were to compare notes, it's doubtful we'd believe we had the same manager.


democratized millennial coddling of Silicon Valley

What does this even mean?

I'm sorry that you felt your time was wasted in meetings, but you seem to ignore the equally bad outcome of blindly chasing a direction and pissing off all the devs who actually had some foresight.


It means what it means. Do you want me to define each word?

It doesn't mean ignoring devs who have foresight; it means looking at the options and picking the best one. Not endlessly debating. We agree on the approach but I think you misread my comment as being a unilateral decision all the way through. I'm just saying you have to be able to make a tough decision without waffling and without all of the facts but with enough conviction that people fall into line with you.


> It means what it means. Do you want me to define each word?

The most meaning that can be extracted is about your worldview.

The fact is, there are indecisive weenies, and there are over-confident blowhards, but most people fall somewhere in between. When you complain about the culture in general, especially in a get-off-my-lawn manner, it sort of pushes you into the far end of the spectrum where you start to lose credibility with your employees because they realize over time the confidence is not commensurate with the knowledge and expertise.


Yes, and of course there is a middle ground between "my way/highway" and endless discussion.

Debate for an hour (even two?), ask everyone their opinion, and then make a decision. Revisit in a month or three.


I'm not going to take the inter-generational warfare bait :). But I agree with what I think is your main point.

My natural tendency is to want consensus. I think that's worth attempting within a reasonable time-frame. But after some discussion, eventually a decision needs to be made.

Many decisions are reversible at a very small cost. Sometimes making the wrong decision, soon, then correcting it, soon, wastes no more time and resources than not deciding at all. Sometimes it's even preferable for morale.

Having everyone row together in the wrong direction, then change course, isn't ideal. But at least everyone is rowing in the same direction and feels like a real team. Often that's better than sitting in middle of the ocean, oars in the water, debating and going nowhere.

But as with most advice I offer unsolicited, I'm going to waffle and say, "it depends on the situation". :)


Some of the best tech leads I've worked with are exactly like this. Your example of "find another job" is the quickest way to destroy a cohesive team.


A good tech lead _knows_ when to step in to make the hard decision without lots of discussion, but he also _knows_ when to take the soft road to facilitate a fruitful discussion and to arrive on a consensus.

Otherwise, if the only tool you have is a hammer, everything will look like a nail.


As a tech lead, you're a mixture of manager and lead engineer.

As a manager, you should be clear to represent your team in public in terms of giving everyone credit for success and taking personal responsibility for failure yourself.

As a manager, you need to balance what technical work you assign yourself - it should be a mixture of interesting projects and valuable scutwork. Don't be the guy who takes all the good work for himself and only delegates work no one wants.

As a lead engineer, the most valuable thing you can do for your team is to focus on helping them start things and finish things. Folks do well in the middle between those two, but most of the wasted time and frustration comes from not knowing how to begin working productively on things or getting lost and not knowing how to wrap them up successfully.

As an architect, be able to quickly change altitude when explaining the behavior of the system or code that you're responsible for. When debugging an issue with a developer, be able to dive deep into the technical details. When explaining a schedule or cost estimate, be able to talk about the system at a high level to the CEO.


As a tech lead your job is to support the developers in your team so they are as effective as possible. This means:

1. You must know the code. Say 'no' to meetings - spend most your time coding 2. Be honest - When you know the answer say so even if that means someone will have to redo a lot of work. If you don't know the answer, say so (there's no point pretending to be cleverer than you are - you got the job so you deserve it, never try to prove your abilities to others) 3. Remember your job is to support others so fight for your team's interests even (especially) when unpopular higher up. 4. Lead by example - take the shit jobs and write awesome code. 5. Let your team members review your code AND TAKE THEIR ADVICE! 6. When team members ask you questions attack their problems with the same determination as you would attack your own 7. To inspire your team members you need to be loyal to them. 8. To inspire your team members you need to be loyal to the business (often forgotten) 9. '7' is more important than '8' 10. Be the best developer you can be (note the word 'be' not 'appear to be')

Ultimately, if your team regularly invite you for beers after work and your boss respects you then you are doing ok. Never, ever assume that 'team lead' is anything more than a specialist role within the team. Your job is to support others. That does not make you more special or important. Respect is earned not given. Being a good team lead is much the same as being a good developer. If you find the job hard then you weren't really a good developer. This is why a lot of companies don't externally recruit tech leads, preferring to recruit from within.


On management, it's tough to find good info - some is trite leaderhip strategies. I tend to favor the order writings cause they've stood the test of time. I keep this one saved and re-read it pretty regularly.

http://philip.greenspun.com/ancient-history/managing-softwar...

My team is remote, a couple of us been together 10 years and most of us at least 5 years. My managing style I picked up from my mgrs in the company. Pretty hands off. Stars are stars and don't need me meddling - so the general style - let them do their thing.

As far as the average or underperforming employee, I view my job not as trying to "improve people". I need to empower people. As a leader you have some influence on your team, but I think that's a bit overblown. A person's performance is really a result of their mindset.

Their IQ as well. That's important, but some people are just motivated for excellence, others not. I think the key is - understanding where you have opportunities to influence this in your team members' and when not.

One thing I did notice - moving to a mgmt position. It is very temptimg the idea to just get rid of them. It's tough but easier then getting someone truly hopeless to make the necessary effort to improve.


Some excellent advice here already, but I'll add a few more. One is to avoid putting development tasks on your own plate that you won't be able to complete. Your time is now likely to be taxed at 50% or more meaning you'll have a lot of demands on your time for meetings and such and so you'll find dev tasks can pile up. Just take on less work for yourself and delegate.

The other one is learning how to wield your authority. You'll now (hopefully) be invited to or least have visibility into leadership meetings, design reviews, contract reviews, road mapping. Make sure you voice opinions in terms of much time tasks will take, which people are needed, what is feasible/infeasible, if you're signing up for a mission impossible. Stop saying things are "hard" or "easy" and instead identify "risks".

Notice that almost nobody in this thread is telling you to work on your technical skills :)


I get asked this a fair bit so I started to collect a few of my favourite links together in a blog post: http://www.andykelk.net/leadership/the-big-list-of-managemen...

Specifically to new tech lead roles, I'd recommend "Peopleware" and "Behind Closed Doors"

And a couple of articles specific to your situation: http://firstround.com/review/this-90-day-plan-turns-engineer... and https://blog.stackexchange.com/2015/08/developer-turned-mana...


Thanks, added your blog post to favorites. I lived in Melbourne for 12 years, still consider Australia my home.


Have a read of these essays http://97things.oreilly.com/wiki/index.php/97_Things_Every_S...

Basically you want to become a "Force Multiplier" for your team, thinking a few steps ahead, seeing the big picture, guiding everyone past upcoming road blocks, you need to be able to mentor/help out when it its the fan. And of course you still need to code ;)

A hard job but endlessly fun


You will have people who depend on you to allow them to get on with what they do best. You will likely find that you don't write code any more, but have to trust others to do a good job - a better job than you might have done, even. You may not have the time to understand everything they produce. Even so you need to be able to understand the system at a higher level.

As you say, you have some architectural responsibility. This can seem like a large weight on your shoulders if you think that it is all your job. Remember that your developers probably have a huge amount of understanding of the codebase: Don't be afraid to let them guide you, at least partially, in making improvements. There may be others at a similar level who have moved elsewhere in the company who can give you what their plan was for making things better... They might have been where you are but without your remit.

It can be a role where you get to build stuff (with the hands of others), have some power and weight behind decison making, also ever-varied and even fun. It can also be stressful and extremely taxing. Good luck!


I also recommend Patrick Kua's 'Talking with Tech Leads' book: http://blog.fogcreek.com/becoming-a-tech-lead-interview-with...

There is also this interview with him here: http://blog.fogcreek.com/becoming-a-tech-lead-interview-with...


I'm sure you will get plenty of good advice. My own (limited) experience is that your job is going from a "Individual Contributor" to a "Team Lead". This requires a pretty drastic change in thinking and is not something to overlook, or else things will not end up well. This means that there is going to be a lot of work - much more than you can do by yourself - that's why you have a team to support you. The primary thing I struggled with in the past was delegation. Learning to trust (but verify) your team to complete tasks the way they should be done. I think a lot of people struggle with this and is a primary reason for not doing well in a new role.

Some other quick things that come to mind are: - Don't be a gatekeeper of information. If you learn something that would be a benefit to the team, make sure they know it and don't have to go through you to get it. That is - get the team involved.

- Do take a Crucial Conversations course. You will inevitably have to deal with conflict within the team and knowing how to approach the situation will help significantly.

- Do have 1-on-1's with your team on a regular basis. You determine how often, but it should be regular and should be a priority for both of you. This is where you will learn about conflicts within the team, about their career path and aspirations, about personal issues that they are dealing with, and will help build trust between the two of you.

Good luck! It's a fun role and comes with it's own challenges, but can be very rewarding!


> The primary thing I struggled with in the past was delegation. Learning to trust (but verify) your team to complete tasks the way they should be done.

I would like to add that the above is only possible if you "plan" the work. If you have expectations of how a certain task should be accomplished then you should be able to define the task on a detailed enough level so that you "can" delegate it and that the team member working on it actually has the ability to complete the task according to your expectations.

There is nothing worse for a team member to be given some vague idea of what should be done to then afterwards having a big discussion on the expectations, i.e. how to be a mind reader.


Regarding people skills, I always recommend Peopleware[1].

[1] http://www.amazon.com/Peopleware-Productive-Projects-Teams-3...


In no particular order:

1. Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves.

2. Give your subordinates problems, not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track.

3. You're a facilitator, not a doer. People will come to you with their problems, and you must be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted “flow” time.

4. Be aware of politics. The moment you manage a team, politics become a part of your daily job. This is not a bad thing—“politics” just means managing interpersonal relations; it becomes a bad thing when you ignore it.

5. Never be in a position to take. Success belongs to your teammates; failure is all yours.

6. Face problems head-on. People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1.

7. Offer clarity. Explain what you expect others to do in a measurable way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally.

[0] https://en.wikipedia.org/wiki/OKR


One thing that I've not seen mentioned is that you don't have to feel like you're the one that has to answer all the questions, just because you're the lead. Deferring questions to those you feel may have more specific knowledge shows that you know where your weaker areas are and where the strengths of your team are.

This also goes for asking your team questions, don't be afraid to ask them things you feel unsure on rather than try and power through.


Book: Becoming a Technical Leader by Jerry Weinberg is a good read and one that I re-read often - https://leanpub.com/becomingatechnicalleader


In addition to everything already said, I reemphasize:

- allow your team to focus

- provide just enough structure (and no more)

- help shorten feedback loops

- try to remove hurdles to acquiring information

Deep focus unleashes creativity, passion, and great work. I know that's when I'm the happiest.


Management is a completely separate set of skills from engineering, and a set you have to force yourself to learn. The best book I've read on the subject is Andy Grove's High Output Management [1] -- it talks about how to choose tasks with the highest leverage, how to run meetings and one-on-ones, how to make managerial decisions, and how to motivate your team.

[1] Cliffnotes at http://charles.io/high-output-management


all of these lists sound nice and all, but think back to the people that you really respect that have taught and influenced you to become who you are today.

what was the most important part? for me it was the person who was many degrees smarter than the rest of the team and pushed everyone to be their best. In my case he was not the most diplomatic or encouraging, hell he yelled at me a few times (and trust me, i don't appreciate being yelled at even by my parents). but anyone who was interested in software engineering was in awe of his skill. He devoured tech books and prototyped things on the train to work so that he always had good ideas and answers. I was sold right from the interview where I could tell he just knew his stuff inside and out. My point is that having the necessary knowledge to actually teach people is so much more important than all those other things. For most of us that means a lot of hard work in the trenches during free time. New technology? there goes Saturday and Sunday. It's the only way to have all the answers to the ones above you, and the ones you're leading.

Additionally try to get your team the best development/infrastructure tools money can buy and the best learning resources (such as pluralsight, egghead.io, all-you-can-read online books subscription)


I've been a team lead for less than a year but it feels somewhat natural for me since I've handled leadership roles informally on projects in the past. The hardest thing is having to delegate when a fire's going on that you know how to fix but you have to stop trying to uh... "do work"

If you embrace that you're expected to be a force multiplier for the team, you have the right mentality. But being sensitive to what role you need to play is critical. Sometimes you need to be a tie-breaker on a heated argument on a framework decision (lead by wisdom / deference to your respected authority), perhaps people are in despair and they just need someone that puts everyone at ease that something's being done right and you should just step in and write a reference implementation (lead by example).

One thing I would add is that you should find out if there's a program / product manager present and ask to interview with that person if you haven't. If there's no such role, you will have to pull triple duty as a product / program manager potentially by making a lot of strategic decisions probably. At that level, you might as well be considered a CTO though rather than a technical middle manager basically.


A colleague of mine wrote a useful post on this: https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b8...


OP, I'm sort of curious why they're hiring a tech lead from the outside. Why hasn't someone taken that position from within the organization? Someone who's worked on the project, who understands it, who has the moral and political authority to lead? I worry that your task will be really, really tough. If you can, in the interview, try and understand the situation over there. Why do they need an outside lead?


Maybe they are hitting problems that nobody on the current team can solve. Or they need new ideas and new blood. Experience is often very useful.


Hmm.. I didn't necessarily read it as they were hiring from outside necessarily.. I'm sure it's not uncommon to have interviews internally even if all of the potential candidates are already employees.


> I'm sure it's not uncommon to have interviews internally

In fact depending on location it may be legally required - I'm fairly sure this is the case in the UK (in addition to having to advertise the opening externally too, even if there's absolutely no intention of hiring anyone external) - please someone correct me if this is wrong.

Probably the sort of thing early-stage startups can get away with not doing because they're very under the radar, but it's certainly happened at mid-sized companies I've worked at.


Thanks, that is a good question to ask in the interview. I will. One of the reasons may be that I have experience in the particular field, and also worked for a competitor in my previous position a few years ago.


Being a team lead means you must manage in three directions:

a) manage the expectations of your boss and shield your team from distractions and firefights,

b) manage collaboration and dependencies with other other teams, and

c) manage the day to day work of your team.


I've been a Tech Lead for a year now. I'm still learning but some of the things I've done which I think will help are:

1. Start by setting up the development environment and getting the software you'll be working on to run locally. Then, fix a couple of easy to medium level bug fixes as soon as possible. This is the fastest way to learn what your team is talking about.

1.5 If you don't understand something that's being said at a meeting ask, but don't hijack the meeting, make a note and talk to someone who can explain in more detail.

2. Think at a high-level -- what is the product supposed to be doing, abstract away -- some engineers will talk in code -- which you may not understand early on but interpret what they're saying at a high-level.

4. Be available and approachable to everyone on the team.

5. Understand the impact of a bug fix or a feature -- how much QA effort does it require, what is the operational impact of the work, does it break backward compatibility etc.

6. Participate in product meetings and consider designing any new features as homework so you can better discuss it with the engineering team you're leading.

Good luck!

Edit

Some DO NOTs:

1. Do not complain how bad the code base is. No one likes someone new walking in and saying that at once.

2. That said, understand what technical debt there is and address it incrementally. Don't say "we should re-write XYZ."

3. Do not suggest alternate platforms and frameworks unless is absolutely makes sense -- this is especially true if the team is big and no one knows this new framework besides you. You need your existing team to contribute to and maintain projects.


What worked for me was to learn to listen to people, to let them explain the problem and sometimes find an answer as they were talking. What helped was to do lots of peer reviews of both code and documentation so the the young ones could learn from the old ones and the old ones could get new ideas or more up to date ways of doing things from the young ones. I came to realise that programming is flow based while leading a team is interrupt driven so I had to learn how to do context switching quickly and to block out areas of time when I could do my own programming. I had to learn to help people do their work and restrain myself from rushing in to do the work myself. And I had to learn that my team members were people who had lives outside work that affected the work they did.

For example, I had a team member who was a good programmer but had trouble coming to work on time. He was getting married so I bought him a clock radio as a wedding gift. That fixed the problem.


Great to hear others have gone through a similar process to the one I am taking now.

> block out areas of time when I could do my own programming

My biggest challenge is that this time for me is evenings and Sundays afternoons which eats into the work/life thing.


Maybe take off fridays, and make Sunday a formal work day.


Some gems from when I asked something similar 4 years ago...

https://news.ycombinator.com/item?id=3407643


Nice link. How have the last four years gone for you?


Sweet. Honestly, I did a search - must have used wrong keywords. More reading for me. Thanks!


There is some great advice in this thread. One thing that I've learned is that different organizations have very different cultures and ways of viewing technology (and thus technology leadership).

Some are more deadline oriented, some are more bug/problem oriented, and some are more product oriented, and others care a lot about the price per head of engineers and would prefer to outsource everything to the third world if they could ever manage it. A small number of companies care about open source contribution, attracting top talent, and innovating.

So whoever is hiring you probably has a very clear idea of what they want from the tech lead, so considering that the goals can be very different, you might want to ask this question. In my opinion, it won't seem like a naive question to ask because there are so many facets to people and technology leadership.


I just took a technical lead role with a bay area SAAS company. It's been a difficult adjustment having worked on contract where all I did was write code. Now, I sit in a lot of meetings, do code merges, interview/hire developers and worry about blockers on two Jira boards. Here are a few things you might want to try;

If their branching strategy is screwed up, help them fix it. You are going in to a .net shop and there is a good chance they have TFS. There is the ALM Rangers branching guidelines you can refer to.

Hold a brown bag and show the team how to write unit tests. Many of the junior developers on the team probably do not understand how to write tests.

Hold a team code reviews.

Initiate common architectural components like a logging or instrumentation framework.

Take on tiny bites of technical debt.

Push to get your team re-sharper licenses.


I heard about this model from Michael Church, which I like. The idea is that there are three forces, you need to balance as a manager.

1. Your team. This is obvious. Acknowledge they are humans. You have to worry about them. Try to keep them happy and safe.

2. The Business. This is the cold-hearted inhumane entity which only considers the free market. You need to satisfy that beast, because otherwise everybody loses their jobs. It only wants to squeeze the maximum productivity out of its employees. Often its goal are in direct conflict to your teams goals.

3. The Organization. These are all the other people in the company. Your boss, collegues in other teams, etc. They have their own needs and agendas, usually different to The Business. Do not forget to consider these.


My summary, after many years thinking about it, is: Build technical leadership in depth.

What ever you do, what ever the problem. It's a key-person problem unless your team can do it.

If you have to tell your team what to do. You are failing, and you need to do something about it.

The leader sets the vision, makes as start, demonstrates good and keeps people on track. The coach makes people the great person they want to be. A leader can use simple coach techniques to grow an resilient team who can work to build something great.

I've noted down some of my learnings: http://www.engineeringandcareering.co.uk/p/leading-and-guidi...


A couple articles I've seen previously on HN on the subject:

Things I was unprepared for as a lead developer -- http://dev-human.io/~pascaldevink/things-i-was-unprepared-fo...

Becoming a Tech Lead – Interview with Pat Kua -- http://blog.fogcreek.com/becoming-a-tech-lead-interview-with...


I guess I should really answer your question though :) I collected some interesting blog posts that I loved and stuck them here

http://www.engineeringandcareering.co.uk/2013/07/technical-l...

Talking with Tech Leads might interest you also: https://leanpub.com/talking-with-tech-leads


1) Solicit ideas from everyone. Admit when you don't know the best way. Attempt to achieve consensus. But be steadfast in the face of majority opposition when you're sure you do know better.

2) Insist on always doing the right thing. Never compromise your standards or your ethics [0]. You set the example for everyone else.

3) Treat your customer like an honored guest in your home. Bend over backwards to understand them. But never let them anywhere near your developers. It's not good for anyone, especially the customer.

4) Always take the heat for your team (which is easier if you're the single point of contact for the customer). Always spread credit around.

5) Don't get personally involved with your team [1]. You might have to fire one of them one day. And your praise will mean more. You can socialize with the whole team on occasion, but don't do anything that could ever allow the appearance of favoritism to develop.

6) Trust people to do their work. Give them a chance to succeed... or fail. But the few that repeatedly and consistently fail to live up to expectations or even improve, get rid of.

[0] If anyone ever tells you "we might as well do this unethical thing, because the customer will just get someone else to do it," your reply should be, "well then, it doesn't have to be me" and walk away. I have done it twice now and have regretted neither time.

[1] I would like to think this goes without saying, but NEVER EVER EVER make sexual or romantic advances towards anyone under you. It is extremely unethical. If there is any chance of something happening, wait until you're no longer on the same team. Best to wait for them to make the first move, too, if you're still at a higher authority level after the team change.


I really enjoyed "Notes to a Software Team Leader: Growing Self Organizing Teams."

The second half of the book is advice from various tech leads.


I can't recommend this book highly enough. This is the best book on tech leadership I've come across and I've read a lot of them.

It underscores the importance of NOT trying to solve problems for your team. Instead, help your team learn to solve problems on their own--so you don't become a bottleneck to getting things done.


Candour, honesty and therapy. And enforce ridiculously high standards.

Most of us are not as good as we say/imply we are. All of us are terrified that someone will find out, and terrified that we will slip. So there is often a refusal to say "I don't know" or a refusal to accept that we might need to slow down and think about the work we are doing

Your best bet is to make a team that is willing to try something that will make them look like they don't know what they are doing, send off signals to "management" that are opposite of what all the other teams are sending. (This is the other point about a tech lead - you will be compared to the other tech leads - if they are hiding their faults, you will look bad by comparison as will your team - how you persuade management this is not the case is hard.

My best suggestion for that is ridiculously high standards - perfect test coverage, documentation, linting, enforced peer review and more. For every commit. Enforced by scripts not by you.


Good read: http://dev-human.io/~pascaldevink/things-i-was-unprepared-fo...

Discussion: https://news.ycombinator.com/item?id=10223472


I would suggest to always put yourself in the shoes of the developers when you make decisions as a leader. Think about what you would have thought as a dev.

Also try always to explain why you make the decisions you make.

I am a dev and I hate when decisions are made without telling/explaining team members. I also appreciate a lot when I receive feedback, good or bad.


http://5whys.com - I'd recommend a lot of the advice there (I'm the owner of that blog so I'm a bit biased).

http://teamleaderbook.com is a book that I wrote for software team leaders


Well, that's too amazing to be true - as part of my preparation I started reading "The Art of Unit Testing" just a couple days ago (not that I did not write tests before, but got a suggestion that the book will help me better understand dependency injection, inversion of control etc.)


heh! It's a small world!


Wow, I can't say I'm surprised at the quality of the answers. I'll add a couple of my own:

.) be mindful that different members of the team are on different trajectories skill set wise. (beginner Exs -> juniors -> mids -> seniors -> etc)

I like to pair members with technology whose stability is inversely proportional to their experience.

More experienced engineers design tighter interfaces in the face of increased variability in final spec.

Whereas technology that is older will usually have a good breadth of info either in house or available on Stack Overflow which means the problems (and communally derived solutions to them) are accessible.

This I've found results in having to clean up less code overall, which helps build team momentum.

Which is my next point.

.) Team Momentum

You're leading a team, which can be assessed as a set of quantities at any given point in time (viz. velocity in Pivotal Tracker for instance).

The team however is a dynamic interplay of business expectations (from the principal, boss, client) technical debt (recurring known issues), and the team strength (which waxes and wanes based on moral, environment, etc).

Always look for ways to make the lives of the engineers around you easier.

-) build tooling

yeoman generators build tools etc.

enriching internal tooling makes each engineer more effective, which means it has a compound effect.

  You can cover a lot of ground just focusing on addressing pain points in your team.
]) One last point actually, you're a leader so remember that means you're expected to have finer grain control over your ego, it helps if you take an objective view towards the technology that comprises your stack rather than a predominantly fanatical view.

Congratulations by the way! Regards,

Dante Elrik


http://katemats.com/


You can get a summary of this discussion here: http://sevcode.tumblr.com/post/131264031520/the-30-laws-of-s...


This seems prescient as I will be starting a new job as a tech lead in a week, and I actually considered making the same Ask HN post! Same tech stack, no less, although it's for 2-3 medium-sized projects, not a single large, complex one.

Best of luck on your interview.


Lessons I learned as Tech Lead:

http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-Le...


At the core of it - you're going to be leading engineers. A lot of how this leading happens depending on the organizational makeup of the firm you're going to. (This is super super important!!!).

So figure out the organizational culture before you join. Understanding this helps you understand the confines within which you will operate (for the first couple of months, atleast). If you're replacing someone, understand how they worked, what gaps were there in that person's performance and how you could cover those. If you're the first tech lead, then figure out what problems they're having that necessitated the creation of the tech lead position.


I've found this a really good discussion of how tech leads' responsibilities differ from front-line developers:

http://madeofmetaphors.com/shapes


This fellow writes some good articles on the subject and will send them via a mailing list once a week:

http://marcusblankenship.com/list/


Read this set of articles: "Things I wish I was told when I became a manager" http://fractio.nl/management/


http://www.engineeringandcareering.co.uk/p/the-well-rounded-...


After you get the job, here's something my old team learned through experience (failure): modular is good, but in practice, abstracting things to the theoretical max results is software that none of the developers understand, is impossible to maintain, and probably doesn't perform any better than if you didn't "optimize" near as much.

(Source: I was a programmer, then a tech lead, then moved into managing about 100 of them.)

Another tip: it's your job to help the programmers make you look good. You do that by making them look good. It should be a virtuous cycle.


There's plenty of great advice already in the comments, but mine is quite simple, and quite relevatory when I made the transition to Lead:

Measure your success by your team's productivity and not your own.


- Be flexible

- Prioritize everything

- Simplify code, processes, and infrastructure at every step

- Build a well-rounded, emotionally stable team

- Loosely follow scrum & agile

- Be realistic

- Be honest, even when it is inconvenient

- At the tech lead level, the most important skill is your own psychology. Hone your personality, establish work-life balance, and take some courses in positive psych

- Have an opinion

- Learn when to talk, when not to talk, when to put it in writing, and when not to put it in writing

- Adopt a "good enough, and let's move on" design approach

- Build strong relationships with non-technical management


You need to read this...

http://www.altisinc.com/resources/rules/


I would stress this the most: support your team. Give your team the technical and emotional support they need to do their jobs well and have fun doing it.

Some things I've noticed that had the largest impact on employee engagement:

-

1. Poorly defined development processes heavily impacts morale. Define your code standards, your process for picking a library to use, how you handle versioning of code (and which methodologies), how your team should escalate problems, and expectations of individual team members. Document this in a place where anyone on the team can view it.

2. All projects require documentation on how to setup a build. If that doesn't exist, developers ramped up on the project will loathe the project from the start (and in some cases, the team lead). From scratch, setup a project before handing it off. Document everything you had to do.

3. Onboarding of new team members: make yourself or someone you appoint available at all times for the first week or so. Document and fix anything the new team member needed help with. Onboarding is hard, this will be an ongoing process.

4. Setup one-on-one meetings. Once every couple of weeks seems ideal in my experience. Don't have an agenda, but have a few questions you resort to for filling in quiet spots for the more introverted types. Don't be afraid to ask hard questions (did you have a problem with Robert in accounting last week? are you happy with your salary? what would make you happier?). This meeting is key to employee retention and team happiness.

5. Allow for an open discussion on all major decisions. Have a tool in place where anyone can raise problems. If someone can post anonymously to start a topic, that's ideal. That is where some of the best business growth will take place.

6. Read a book on mentorship. Mentor your team. If someone surpasses your skillset on the team, you've succeeded. I've not read all of Maxwell's books, but he has some really great insight in the couple I've read: http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/

7. Become known as an advocate/mediator for those on your team and the higher-ups. Fight for your team when you need to, and fight for upper management decisions when you need to. Finding a balance is important, but never lose trust of those you lead.

-

In many cases, becoming a technical lead also means you are expected to learn the business side of things. It wouldn't hurt to read business-oriented books. Anything by Jim Collins is great (Good to Great is a must-read): http://www.amazon.com/Jim-Collins/e/B001H6GSHK

Best of luck, and congratulations on your learning opportunity!


+ for mentioning on-boarding and implications, another + for mentioning open discussions on things that matter


I think it can be summed up as "code less".

I want to stress that this is much more easily said than done.

- A lot of programmers gain immense satisfaction from writing nice code, and getting into "flow". There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product/module/apis rather than how elegant your code or apis are, then you are heading in the right direction.

An earlier comment on this page sums up the goal:

> 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.

- You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline.

- Coding less allows more time for you to ask your team what they need, think about what they need but don't realize, and get that for them.

- Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension.

- Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have.

- Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. "What did everyone learn this week/sprint? What could you do better?". As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.


1) Learn as much about the people on your team as you can. That can be sometimes hard while at work, so I end up going out to lunch with them or occasionally grab a beer afterwards.

2) While at lunch or after work, my team and I end up talking about random stuff, but it pays off when you can sense if someone is having a bad day/week or is stuck on a particular issue. Also helps to build mutual trust with your team and keeps the communication lines more open.

3) It's hard to sometimes tell how well you're doing as a technical lead, but one way I do it is by how often people come to me for help to things that can't easily be Googled. If developers are seeking out your help, they trust you and consider you reliable source of help.

4) If it comes down to doing more work or helping your team. Always pick your team. Helping them will likely be more productive overall than any amount of additional work you take on yourself.

5) Every developer is different. Recognize that when communicating with them and approach each differently. A true tech lead isn't a managing position, it's a mentoring/leadership role while still being a developer.

6) Be concise. Your team needs help, but they have work to do. Save the long explanations for later. That doesn't mean you should avoid the "why" in your responses, just don't make your answers a monologue.

7) If asked by a team member why you think a particular approach or solution is correct, give them an explanation. I always feel if I can't explain a particular subject, then I don't really know it that well and may be incorrect.

8) You don't always have to be correct. Admitting you aren't when you can't explain something reflects better than all other responses you could give your team.

9) Making yourself available to your team for assistance is also a must as already mentioned. Everyone communicates differently, so adjust to your team as much as possible.

10) Don't deter someone outright from pursuing a potential solution, even if you're pretty certain it won't work. Instead saying no, apply some rubber duck debugging[1] and talk them through their idea aloud. If all goes well, they'll either realize it's not feasible and learn the value of communication or they'll convince you that it will likely work. If they win me over, I'll try to help them devise a way to small way to test their idea further.

[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging


A great technical lead is a great therapist.

They're kind, supportive and know how to focus your energy to help get a really difficult task done. They don't dictate, they don't prescribe, they listen.

Your job as a tech lead is to listen and help figure out a way to make testing, compiling, deployment, support, and escalation easier.


Many times a tech lead isn't about being the smartest or most knowledgable person in the room - it's about getting your team, your boss, other departments on board with a plan and executing. In some environments it may be that you have to be the sharpest depending on the team you're given, but often times it's best to be the most judicious and compassionate. Think of it more like being a mini-manager - perhaps 30% management (where you're like an extension of your supervisor) and 70% software. Also be prepared to bring your boss into issues you may have with external teams/organizations, but try to shield your team itself from that activity. Be prepared to handle considerably more email, process work, signing of documents, etc.

I'm going to share a personal story - it might not have much directly actionable advice, but it may give you some thought on how to approach this strategically.

I spent about 15 years as well on windows software for enterprise health care systems (starting back in VS6 C++ days back in the late 90s) before jumping ship to do Rails development a few years ago.

Right around the 10 year mark in my career I was a run of the mill sr. dev... the only 'lead' experience was on a couple projects, rarely with more than another dev and most of the time solo. I just never really had much confidence in my skill set as a whole, esp. when it came to telling other devs what to do. In 2009 as a 33 year old I felt pretty deflated and was considering a career change. One thing I caught wind of was this book called "The Passionate Programmer" by Chad Fowler (not related to Martin). It was ~200 pages, and it was separated out into 50 or so little chapters of tidbits of mostly, well, soft skills, but also general career advice. I absolutely loved it and finished it in an evening.

In short order a whole bunch of things about my working style changed, not only my demeanor working with other engineers, but key key people in other departments in the projects I worked on(ie. QA, System Engineer, Documentation, Product, Project Management). Ultimately I realized at that particular organization the biggest problem was that departments were silo'ed a bit too much, and as a result schedules slipped because coordinating resources was always a challenge.

Six months after reading the book I was given a lead role on a medium sized project at that company (had 6 engineers on the team and about 20 people working on it for 9 months, ~$15M per annum, 300k LOC over the prior 10 years). One of the engineers who reported to me during on that project was one of the 2 Fellow Engineers at the company (3 titles above mine!). It went well, and my next review had a recommendation from my supervisor to go into management. I politely declined and a few months later was promoted to a principal dev.

One of the reasons why I believe this worked so well was 1) I did underestimate my skills as a whole - I was not the best, but I was certainly good enough that my suggestions held weight and I felt ok with admitting to things I didn't know and delegating 2) I had, as you say, seen other people in this position and already knew what success and failure looked like. I wasn't just given a position as a lead, I had assumed it to some degree on another project I was on at the time (not entirely and not to usurp the authority of the actual lead, but I just became helpful on things that needed to be done but were getting brushed aside, esp. things that were important to other departments). And as such, people started to pay attention to what I was saying.

It sounds like you think it's slated toward being an architect. It can be, but many times it really isn't - you may want to delegate that overall to the stronger members of your team and help them work through the process - be the person who asks questions and helps poke holes. Give the most challenging work to your brightest people. Isolate the more 'dangerous' members from mission critical stuff, and if they have the passion and smarts but they're just a bit misguided give them a nudge of encouragement in the right direction and challenge them accordingly. Pay attention to your devs' key strengths and delegate accordingly, but also remember to provide a degree of work that is challenging and exciting.

So that's my advice - check out that book. It's a quick read. It is about 6 years old now but the advice is mostly generic. Try to put some of it to effect in your current job... assume the role where you can. Even if it's just a week or so, I think the best practice is actually trying it out in real life.


Thanks a lot. I'm sure I read the book a few years ago ... will have closer look to make sure I'm not confusing it with "The Pragmatic Programmer".


Absolutely. Best of luck!


i enjoyed reading the book Team Geek http://www.amazon.com/Team-Geek-Software-Developers-Working/...


I liked Michael Lopp's (also known as Rands, from Rands in Repose) book, Managing Humans, when I first became a team lead 18 months ago.

http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...


Most of all, make your contribution visible to your leader, or to KPI, or to anything evaluating your contribution. If no one knows your great works, It worth nothing to your career.

First, know how they evaluate your works.


Checkout https://leanpub.com/becomingatechnicalleader


also worth reading: http://www.amazon.com/Driving-Technical-Change-Terrence-Ryan...


You lead the way and when you have half of them with you, the rest will follow.


Do you have a few kittens? Managing developers is like herding cats.

The truth is you don't really have real control.


Great question! I just wrote an article on this very topic here...

https://www.linkedin.com/pulse/real-work-management-marcus-b...

If you're looking for books, I recommend Johanna Rothman's "Behind Closed Doors" as a great book about leading software teams.

Good luck!


Learn to listen. To your team members. To your peers. To your boss(es). To people in other departments. Not just to their words, but their body language, their activities, the way they carry themselves in meetings.

I am constantly learning from the people around me how I can be a better manager. If I see something that catches my attention about the way someone handles something, I aim to bring that into my own toolkit.


Just try not to get fired.


Come on guys, I know we don't generally appreciate humor here, but this is pretty fucking funny.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: