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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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 :)

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.

It shouldn't be very often.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

- your main job will be to:

    - unblock your tam members

    - bring them back on track

- praise publicly, criticize in private

- give people a chance (give warnings)

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

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.

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?)

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

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.

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

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

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.

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.

"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

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.

  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.

  

   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.

  16. Always do the right thing.

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

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.

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.

    4. Ditch team building gimmicks (see #3 for what's important).

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

  http://leadingsnowflakes.com

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

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.

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

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.

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". :)

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

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

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.

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

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!

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

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.

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!

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.

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

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 :)

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.

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

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

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

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.

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

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

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.

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

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)

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.

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.

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.

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

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

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.

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.

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.

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!

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

- 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

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.

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

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.

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

Best of luck on your interview.

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

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

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

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.

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.

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

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

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.

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.

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!

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

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

http://madeofmetaphors.com/shapes

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.

http://marcusblankenship.com/list/

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.

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

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.

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.

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