I'm only a mid-level developer. I've been offered a position as a tech lead with the aim of building a team. What advice would you give a new, inexperienced, and ambitious tech lead?
It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
Ask your team to write out everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in assessing what they were planning to build. (It also makes for a great log of what we did and why we did it. This will be the product documentation for your entire product tomorrow.)
Treat your team like your family. Do not stress them out with too much work. Be respectful of their time and effort. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task.
You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance for your business team too.
Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
There is a lot to add to the above list but in general the idea is to help your teammates grow, help them think critically, stand for your product - make the tough calls.
I think your advice is great for tech leads at big companies, but for tech leads at startups, I have to disagree with the point about "Work for your product - not your company."
At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind.
"Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.
As a tech lead at a midsize company (~300 employees) I have to agree with this. There seems to be a strong tendency among tech teams to always push back on everything that business wants. We need to remember that we’re on the same team.
> If you’re at a startup, your product is your business.
Your product is whatever you end up with after the long tenuous period of being startup, which often evolves/pivots drastically over time. Your product is your ability to execute.
Depends if the product is a key profit center. If your startup is making a product and it's not a profit center, it might get binned, it might get pivoted, it might postponed. The advice is great, just don't die on a shortsighted engineering hill when the decision come from emotional attachment to your work rather than what's best for the companies positioning and financial health. You can always put that love and energy into a new/pivoting of the product.
The problem is if you're at a startup you probably don't know what your product is, because you don't know who your customers are.
My last startup died because we committed too hard to the product and the business model, which while innovative and one that I still believe could have succeeded - we utterly failed because we didn't understand our customers and we didn't pivot fast enough, ran out of runway and then everyone but the founders got laid off. Waiting on hearing about the equity.
If I may function as the devil's advocate - One can read the above as a claim that because you didn't have a good business guy engineers should have worked faster? Would a faster product iteration worked if the business acumen would still have been missing?
It might have. Part of it was arrogance and bad advice from VCs, not lack of business acumen. There was a rejection for industry practice because we were different and doing something different, but it wasn't actually different and couldn't monetize because we focused on users that couldn't pay us real money, while working in an industry that doesn't value innovation.
I don't think the argument is that engineers should work faster. It's that they should be willing to skip some of the stuff you would normally say is good practice in order to ship features super agile and make any necessary pivot easier.
It wasn't a lack of features so much as a lack of talking to people that had purchasing discretion. Never focus on users in B2B, focus on people who have the ability to approve a purchase order.
This isn't universally true. It only applies to a segment of "pioneering" startups. It will hurt a startup otherwise.
There are different types of startups. Not all startups are working on novel discoveries and exploring new frontiers. Zoom built a better video conferencing platform by not moving fast and breaking things.
I agree with you that you have to work for the company objectives.
I think at a start-up the correct decision early on is to take on a bunch of tech debt, but then pay it down as the horizon of the company expands.
Early on, you need to iterate fast on a few key flows and make a product that people want, but once you get product market fit, things like scalability and reliability start mattering a lot more and you need to pay down the debt.
The issue comes when the company's objective is actually to build a reliable, stable, long term product, but it is still in startup mindset of "ship this feature by yesterday at all costs", and expects the rest to come for free.
That only works if tech team is evaluated and measured with the same objectives as business teams.
I've heard so many times "think of bigger picture".. but when we did the tech team got kicked down - as we didn't achieve our own objectives because we sacrificed them for "bigger picture".
Respectfully disagree on the "write it out first" advice. I'd argue "think it out first" or "talk it out first" is sufficient.
I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.
Consider that a successful product will be maintained for years. It is highly likely that a people will come and go.
Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.
I disagree with this. Writing a set of "technical objectives" that say how a thing will work takes an hour at most and it helps you think through it better than a conversation. It also helps you pass information to QA. If someone asks what the thing does, you can just send them the link. Ultimately, taking an hour to write it down pays
dividends later on.
I would like to disagree here. Got into a team which has working prototype but not a single word on document.
Which makes this hard to follow up with prototype.
Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
If you have remote teammates or may have any in the future (i.e. if your company allows remote engineers), a culture of writing things down is imperative.
I like the part about writing things down. There is a lot of mental organization that needs to happen when you write it down. It also forces you to make decisions.. which is also hard.
A related aspect of organization and making decisions is meetings.
Meetings, other than 1 on 1 meetings/collaborations, are best for making decisions, NOT for sharing information.
Information sharing relevant to the decisions to be made should happen before the meeting via group emails (or possibly through a software tool like Jira) with questions and responses. Written information is easier to reference, quicker to search through, and can be multiprocessed in that multiple people can share information or ask questions simultaneously. If additional information is needed after the fact, you can email after the meeting.
Going into a meeting about building a feature or product for example, you should know the constraints on that, and be able to weigh them in making the decision. When is it due? Who is available to work on it, who will test it, who will maintain it, and who is it for? What aspects/functions are necessary, and what are merely desirable? What resources are available? Why is the feature being added? How might it be constructed?
Finally, be ruthless about moving forward in meetings to get to decisions. If a couple of people agree on something, and begin to quibble over the details? Ask if anybody is opposed to that general idea or has a better one to offer. If not you have made that decision, and can decide on the details, but if so, the detail discussion is premature. It's quite probably also premature if you haven't decided who is going to work on it; the point is you want to nail down the higher level decisions, not get lost in the weeds.
Amazon just assumes that nobody will read the prep material and reserves a block of time at the beginning (as long as 90m IME) for silent reading and markup. Seemed to work pretty well.
At my current company (small startup) I wanted to convince people to talk through the issues and write things down or write down at least something. Think of user stories, requirements, personas, product vision, company vision, sprint goals.
In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue.
They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.
Finding a way to show them might be difficult, but rewarding.
(unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience.
I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions.
However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them.
Doing so, things end up feeling more like trade-offs than compromises.
The only time I write anything with a pen and paper now a days, for the most part, is when I do 1:1s and check ins with my team. No computers for me. If I need to schedule something it comes after. The team member gets my full attention, no phones, Slack, email, or anything getting in the way.
This is about as comprehensive as you can get in terms of what really matters in a good tech lead broken down into a few paragraphs. Who needs a book?! :)
I agree with your comment and particularly this part:
> It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
When I had a TL job, I basically relearned the word "team" during my very first weeks. It was an amazing experience.
Don't forget that each member of your team is a unique individual. Just like raising kids, there is not a one size fits all formmula. Get to know each member of your team on a personal level. This will go a long way in building trust and being able to lead them effectively.
As a tech lead, you bother about building the features that the business has identified - and building it in the best way possible, thinking long term about the product. While as a business decision maker, you focus on what your users want - else you will be out of business fairly quickly.
It's definitely a balance. I should have phrased it as "make sure the product satisfies your users needs" rather than their wants. And this isn't to say you should add a thousand features, but I do believe it's important that tech leads goals line up to users, not only to the technical excellence of the code. You can't make good decisions on technical improvements or debt reduction without balancing users needs. It's easy to build a straw man example that is on the extreme end to demonstrate this, so I won't do that. The day-to-day is more nuanced.
If one defines gorgeousness as ease of grok, then gorgeousness directly contributes to the wellbeing of users through maximizing the technology's ability to quickly and effectively adapt to their needs as they arise. Agreed that it's a secondary concern to fulfilling the featureset.
Could definitely be true! I personally have a hard time imagining how code could be pleasing to the eyeballs by any other metric than how easy it is to understand.
IMO a clever one-liner or a hyper optimal routine that takes minutes of staring to decode isn't gorgeous, but you're certainly right that many would disagree with that. IMHO this philosophy runs directly contradictory to the one in which leaders empower those around them.
If you stand up for your product, you are standing up for your users, or your clients if that's a less ambiguous term.
For some teams, for example a lot of teams in Google and Facebook, the end-users are often different from the Product's clients; the client of Google's Chrome is Google's empire. The programmer that added the X-Client-Data header undoubtedly improved the product, at least short-term-business-wise, while actively harming it for end-users. Someday end-users may leave if they continue to erode trust, but for now it's a boon for the Product.
Edit: Please don't work on those products. Please develop products that respect people. If you develop trust, and actively respect people; I posit that a lot of people will opt-in to reasonable analytics, and even advertising. If many don't now, they might when the dust settles.
Agree. I much prefer the term ‘product engineer’ to all previous titles. It shouldn’t be a cargo-cult switch where everyone starts calling themselves one, but it is by far the best title as a guiding principle to what we are meant to be doing.
Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.
DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.
If you find yourself teaching your team take a step back.
The best managers build super star teams and gives the teams ownership and autonomy. You are in a good position if the team is teaching you, not the other way around.
Try to build a team made up of people technically superior to you. And give them ownership, this is key. It is not just about finding engineers who take ownership. It’s about giving engineers ownership and getting out of their way.
This does not apply in all circumstances. My jump into tech lead came as the old tech lead (15+ years xp) and young superstar(~4 years with wisdom beyond his years) departed from it.
The replacements were a developer just coming off a PIP and a new graduate with zero industry experience, having not interned. I still kept the focus on developing the team as much as possible but the candle needed to be burned on both ends: taking on a large majority of implementation whilst quietly fixing mistakes made as to not shake growing confidence were commonplace throughout the first 6 months.
Towards the end of our involvement in our product I’m proud to say that both developers had outgrew their ranks and delegation and trust came without thought. I was pretty close to burnout by the end of that year if I’m honest with myself though and my own career progression has without doubt stalled due to it
> I was pretty close to burnout by the end of that year if I’m honest with myself though and my own career progression has without doubt stalled due to it
Sounds like you had a tough time but empowered the team to succeed. Maybe with some personal cost to yourself.
How would you approach the situation knowing what you know now? What would you do differently?
I'm talking about an ideal to strive for, so of course this is rare.
If you want to do management long term and manage bigger and bigger teams without burning out this is what you need to strive for and ultimately impliment aspects of this if you can't impliment it fully.
For bigger teams you even need people with superior management skill sets in order to delegate.
I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design?
On the subject of teaching your team you're right however. Instead aim to create an environment that fosters sharing. In my team I created a weekly tech share which the team does on rotation. It's been great for harmonising the team.
>I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design?
I'm just talking about the ideal you should strive for. Given the opportunity this is what you should try to do. Of course like many ideals, you rarely have the ability or resources to fully implement the ideal.
>Building a team of collaborators with a baseline of technical aptitude and a willingness to learn is what most people should strive for.
What I meant to say is, your philosophy of building teams is for inferior managers. People who cannot perform above the baseline.
Normal and high performing managers always strive for hitting something above the baseline. Not to be insulting, but logically if you think this way than you must be inferior. Just speaking out of pure logic, no malice intended.
That depends on what tech lead role means in OP's context. It might me a team lead, in which case you are right, or something like coding architect which is usually one of the most senior members of the team with additional soft skills. Such person is expected to teach others.
It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
Ask your team to write our everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in accessing what they were planning to build
Treat your team like your family. Do not stress them out with too much work. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task.
You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance or your business team too.
Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
- Not delegating. New leads often feel that if they're not writing code (or doing whatever it means to be an individual contributor), they're slacking off. The definition of "work" has changed. It now means "helping your team succeed". If you try to be an individual contributor, you are doing your old job instead of your new one, and you'll get overwhelmed and sink.
- Not asking questions. New leads often think that being a lead means being an expert, so they're embarrassed to ask or consult someone else about their team's domain, for fear of looking inadequate. Your team and your peers are the experts— it is your job to ensure that expertise prevails, whether it's yours or someone else's. You'll look much more dumb if you're too insecure to admit what you don't know, or fail to ask basic questions that allow you to get the job done.
- Hiding problems. When things aren't going well (and often they don't), don't hide this from the leadership above you. They are there to help you and guide you, and can save you from crashing and burning. You will look much worse if a problem comes to light months after it could have been communicated and dealt with.
- Not communicating. Share what's going on with your team. Share what's going on in the big picture. Don't keep people in the dark, either above you or below you.
Some leads (moreso if they're prone to impostor syndrome) think they have to wait for permission to speak, or to be offered something that they need— don't do this. If you have something important to say/ask, it's your responsibility as a leader to say it and get what you need.
- Forgetting the big picture. As an individual contributor, you often only have to think about near-term or small-scope problems. It is an easy mistake to make as a new lead to spend priority on those things instead of keeping in mind what's necessary for the entire team to succeed at its high level goal.
My understanding is that "tech lead" as a role in Big Tech is more of a gateway position to bridge the gap between IC and management roles, a transition for a well-performing engineer who otherwise has no experience managing a team to "bootstrap" and gain that experience. During this, coding expectations for said engineer naturally lowers, and is shifted towards the total productivity of the emerging "subtree".
I think there are probably almost as many definitions of tech lead as there are companies. In my case the tech leads in the company are responsible for turning high level requirements from the rest of the company into actual actionable work, and feeding back up to senior management places where we could improve the existing product by refactoring/introducing new features. Alongside that we do line management for the people on our team, and generally act as a point of contact to try and reduce the level of interruptions to developers.
It’s very much not an IC role - we might throw together the odd prototype, and we’re all very capable of rolling our sleeves up and helping out if a project needs an extra person for a bit, but the general rule is that if we’re on the critical path for implementing a project something has gone wrong.
This sounds like a Product Owner to me. Indeed, all these types of roles are pretty much interchangeable depending on the exact structure of your teams.
From my cynical experience it's a way to "reward" individual contributors with a meaningless title to make them feel like they are advancing their careers. It's purely responsibility without empowerment. In my naive days I was told I was a "tech lead" and I was very proud until I realized this meant being a scape goat for project's misfortunes without having the ability to schedule other people's time and thus materially change the way things as opposed to being the midnight oil superhero. Since then I never accepted such nonsense.
Make me a proper leader with the ability to truly delegate and alter scope, workload and the timing of work or pound sand.
At my org "lead engineer" is a seniority title. The people you look for are the maintainers and core contributors- the people with access to approve commits, and the people who are highly active in design and code review.
Didn't mean to suggest that it should be zero— only that new leads feel like they are falling behind when they're actually doing normal leadership tasks, because it's not coding, and coding is what feels like work to them; or that their instinct for dealing with increased workload is to code more (instead of organizing more). Those are bad instincts, hence they need to readjust their definition of "what feels like work".
I agree, that advice is more for managers than tech leads. A mistake I've seen orgs make often is promoting their best developers into role where they don't code. A tech lead that doesn't code is a manager.
I am sure the meaning of "lead" varies from company to company. This advice applies to any role where you have any degree of responsibility for others' success (and haven't before).
Where I worked, as a lead I was probably doing up to 50% individual contribution and the rest "management". But I have seen new leads in the same role do 150% individual contribution, and then let their team down on leadership tasks because they've let themselves become swamped. This is a very common error for any newcomer to a job that involves leading other people (which OP specifically says is their role).
I don't think it's an error to put a coder in a position of leading others; it's just that being a productive coder is a weak predictor of being a good lead— you have to look at other markers. Having that kind of "on-the-ground" understanding can be a great strength that can't be had any other way.
A tech lead should code, but most of what they achieve is through code written by others, so that should be the focus of their work and what they're evaluated on. The coding done by the tech lead is to (a) keep in touch with what's happening; (b) maintain technical standards and infrastructure; and (c) key parts that require specific expertise, but all these three things essentially facilitate the productivity of others, not mainly make an individual contribution.
I like to think that given infinite time, any average person could do anything that's physically possible. Alas, given the upcoming universe heat death, this is moot.
Total number of people who have ever lived is around 15 billion IIRC, so ~1500 billion years. Most stars live around 10b years, so one person would burn through 150 stars to accomplish everything done by all humanity up to this point.
First thing I'd say is that tech lead is role, not necessarily a job title.
Second, tech lead is probably the highest position you get to without choosing management vs technical career paths.
You can grow in technical depth and authority without managing more teams, and still stay in connection with the code; or you can try and enable teams to succeed, and steer things towards the business objectives, and spend a lot less time coding. But most companies (at least those that try and retain tech talent) will force you to choose, or choose for you.
Get the O'reilly's book "The Manager's Path - A Guide for Tech Leaders Navigating Growth and Change" and READ IT.
1) You will not need to trust others to write better code/systems then you and that you will very likely be unable to code anymore.
2) Establish a good relationship with your team members. Seek for people who you can delegate to and trust. Trust and reliable people are really hard to find. When shit hits the fan - and it absolutely does - you'll need that.
3) You need people who will push and people who will follow. Having just one group and not the others is a recipe for disaster.
4) Establish what things you should care for and what not. The amount of shit is insane and it only gets worse you need to have a threshold on when and on what to react.
5) Do you own research as much as possible on key things.
6) Keep asking "why". It annoys me as f* but also forces you to go deeper with explaining and understanding of the problem. (don't wanna say google "Five whys")
7) Encourage people to go deeper, to learn more to become experts.
9) Have 1-on-1s. Regular. Scheduled. Talk about life/work. Try to find how you can make the place and challenges better. Help them grow in an organisation and professionally.
10) Sketch things out. Write em' down. Otherwise, you'll go insane repeating stuff.
I sincerely wish you good luck.
P.s.: People have more bugs and are sometimes even more broken than software. :D
#9 is insanely important. I've had this in the last two companies I work for and it makes a huge difference. You won't get the details you need in an all hands meeting. In a 1-on-1 people will spill their guts, will tell you what exactly is going wrong in their opinion and how it might get better.
It's also very important to know more about your employees on a personal level. Are they going through a tough time, do they feel unchallenged or bored? Do you have issues between team members that need resolving? All this can come out in these 1-on-1s.
A few good resources for this. The different positions of "Technical Lead", "CTO", "Engineering Manager" all vary from company to company so I'm not sure what your new role will entail.
Agreed. Unless a leader is taking the responsibility for a failure (which they should!), the leader should never say "I". When talking about a success it should focus on the team, and is okay to point out individuals who did great work.
I cringe every time I see a lead/leader present team work and say "I" over and over.
It's a myth that it's not possible to maintain a holistic perspective that melds both the trenches and the command tent behind the lines. The best technical leaders I've worked with were the best because of precisely this: the ability to contextualize trench level decisions within command center level perspectives and vice versa.
Sometimes a firing is a failure of the leader. Recognize that. All people have the ability to drive 110% on anything. It is the leaders job to find that spark and ignite it in his employees. A firing is a failure to do this and is sometimes necessary.
>All people have the ability to drive 110% on anything.
I don't believe this statement... I generally assume and believe the best in people but after years of working at large tech firms... some people are literally there to put in minimum effort needed to not get fired. Some people are actually even worse and will actively drive away the high performers with negativity and nothing you do or say will change their opinion.
Yeah these people exist. But even these people have something that will drive them.
I'm not saying that you have to find the spark or that even everyone has the ability to find it. Sometimes, the challenge is so great that it's just not worth it or beyond your abilities.
But it's still there for everyone. If you're really really good, you can find out what it is for most people and trigger it.
>Sometimes, the challenge is so great that it's just not worth it or beyond your abilities.
Yeahhh. Sometimes, as you try ever harder to enable someone to succeed, you eventually realize you're becoming their therapist. Sometimes, you realize that enabling this one person to succeed would involve neglecting everyone else. Sometimes the necessary acceptance, equanimity, and nurturing are of such an absurd degree that it looks like special treatment, or indulgence, to any third party.
I was in this exact position a few years ago! I led a group for a year and a half, with somewhat mixed success. We did some pretty great successes, but also some pretty embarrassing problems that were at least partially attributable to my inexperience. I learned a ton though! The below is my experience, and may or may not translate to yours, but believe me, it was learned the hard way.
Being a tech lead is only partly about the tech, and mostly about the lead. You'll ultimately succeed or fail based on your team.
Being an effective leader requires a completely different set of skills than being an effective engineer. This, as silly as it sounds now, took me by surprise. You may have a decade-plus of dev experience but still be starting from zero when it comes to people. (Or not; some people will be better equipped for this than others. I wasn't so much.)
Find a mentor. Someone you can be completely honest with, and who will be honest with you. Bonus points if they know your team well
too -they'll see things that you won't.
You may have to be pretty intentional about finding out what's going on in your team. Once you're in a position of authority, people won't always feel free to tell you.
Share as much context with your team as you can. They'll be more motivated if they understand why their work is important and has value. Even if you understand this... people aren't mind readers. They don't know what's in your head.
Part of your job now is to be available to people. This may mean you don't get to actually work on the tech yourself as much (or at all). It may mean you get interrupted more. That's may or may not annoy you, but you need to make the best choices you can for your team now, not (just) for you.
Share success when you can. You may find yourself in situations where people attribute your team's success to you... and while that's not wrong (you're the lead after all) it's also a great opportunity to share credit with those in your team. It's worth so much to people when you do this.
People are not interchangeable, and treating them as if they invites trouble. You can have great people, who still have a hard time working together for whatever reason. Be aware of inter-team dynamics; they can sink you. (Situations like this are why it's great to have a mentor.)
It's important to keep a close eye on how things are going, but don't confuse that with micro-management. Your best people are going to want some autonomy, and it's best for everybody if you find a way to give it to them. If things aren't going so well your instinct may be to tighten your grip... not necessarily wrong, but consider that may come across as a lack of trust on your part.
Above all: think of your job as less about being in control (though you may be) and more about fostering an environment where your team can do your best work. Get them what they need, shield them from the crap, give them what opportunities you can. Don't be selfish or mean. Be kind, be empathatic.
One of my favorite parts of the Tao Te Ching is this:
A leader is best when people barely know that he exists, not so good when people obey and acclaim him, worst when they despise him. Fail to honor people, They fail to honor you. But of a good leader, who talks little, when his work is done, his aims fulfilled, they will all say, “We did this ourselves.”
Your role is now defined by what your team needs you to be. Listen to them, care, and see what you can do to help them thrive.
One thing I don't see mentioned here is your reward cycle is going to be different as a manager than as an engineer writing code. When you write code, you know right away when you make progress on something. You go home at the end of the day happy you got feature XYZ working or you go home cranky because you spent the day fixing a fucked up dev environment. Either way, the time between doing work and getting feedback for it is almost instant. Code compiles and look I can enter data and it saves! Awesome!
As a manager, this won't be the case. You won't get that instant reward like you did as an engineer. It might be months or even years between when you started something and you see any reward for it. It might be weeks before you even get feedback that something changed at all. Hell, you might never get to see the reward for a project you have in the oven. This can be very challenging to deal with when you are used to getting near real-time reward for your work.
You will have to adjust to the new reward cycle as you step out of coding for a day job. It's okay to have mixed feelings about it too. Just know that you will have to find other ways to find reward in what you do.
I recommend getting clear guidance from your supervisor on what 'tech lead' means to them. A lot of the commenters here think tech lead is a management position however you shouldn't assume that your employer has that same view. It doesn't sound like you are a 'team lead' otherwise your position would be called 'team lead' and not 'tech lead'. Therefore you don't have any real control over what anyone does, you can't make people do things, and you will be responsible for leading the tech, so you can't really delegate that away to individual contributors. Good luck.
Yes tech lead in my experience is a BS non title invented to keep the most productive rank and file developers feel like their careers are going somewhere. It's extra responsibility and expectations with no additional empowerment
Exactly. Tech lead is the worst role I've had. It's like make believe manager, you get a bunch of extra supervisory work in addition to your regular work, but no actual authority to do anything about problems, other than stay late make up for the problems yourself.
You get bombarded by everyone outside your org who has a question vaguely related, and by your junior devs for anything they don't want to figure out themselves, and by your manager wanting to know whether we can release this half baked component X to some other team even though it will break production. You get maybe a little extra recognition but it's just not worth the 3x extra work.
Speaking as a team lead, the most important thing is to know what your expected role is - are you a manager? Are you in charge? What does your boss expect of you, and what does he expect of your peers?
You succeed when your team succeeds... if they don't, then you don't.
In my case, I don't have any authority other than influence. That's ok, it also takes a lot of responsibility off my plate.
If you have authority over people, know that you can tell them what to do if you have to, but if you reach the point where that's all you can do, you've failed.
Knowing what's expected of you by whom is important regardless of your role. And also team success over personal success -- you have to be in some petty backstabbing nonsense for those things to not be tightly related.
I have a Lead title at work, but like you I don't have any authority over anyone. So I don't really have any advice for the OP, as it seems what "lead" means varies so much from company to company, and to me as soon as you get in the business of authority you really need to start thinking about management, not tech, to which I can only suggest read Deming.
I think my ideal model for 'tech lead' is something like how (I've heard, could not actually be the case) Bryan Cantrill at Joyent operated. Even when he was VP Eng, and later CTO, he still was involved in code, and generally engineers there both "led and were led" without very hard cut roles on that axis.
Become a student of psychology. If you're coming from an IC->management role for the first time, expect your worldview to be broken, and let it happen so you don't have to have a spectacular flame-out to allow it to reset (happened to me, and very common for people coming from the very unambiguous world of "code compiles" to the very loose world of human interaction, where people can't even understand their own motives, let alone anyone else's). Even a modicum of authority changes the way people interact and respond to you, and that's not going to change. Work within it, meet people where they're at, and understand that when it comes to dealing with reports, they're usually right and you're usually wrong.
People are the only thing that matters. Deadlines come and go, companies go bankrupt or get their entire C-suite arrested in midnight raids, competitors come in and break everything and turn the company into a zombie. The thing that endures is the people. If you have good people on your team, consider yourself lucky; being a great boss is one of the best ways to cement a lifelong connection to the best people, and you'll get way more benefit from it than you deserve.
Nothing is straightforward or face value. Understand this and don't try to change it. There's a lot that you'll have to learn for yourself, but keep your priorities and loyalties straight, don't buy into anyone's bullshit too far, and you'll be fine. Good luck.
Just generally, as an employee, what I value in my manager is "someone who's got my back".
I would say what that means is, internally, you run interference to shield your reports from management incompetence and thrash, you take responsibility for failures, and internally promote (in the "promoter" sense) them. And externally, proactively provide professional advice and support, even if that means losing someone important to your team.
More than anything else, those are the qualities I strive to as a manager. (Not saying I'm perfect at it)
This right here. My manager needs to be a shit shield not a shit peddler. A team will never get anything done if the lead lets upper management pull the team every which way.
I would say "provide 'actionable' professional advice". There's manager who keeps dropping advice thinking they're some fountain of knowledge and there's some manager who actually provide tailored made advice for said individual that can be acted upon.
General advice without a specific individual in mind is useless. That's like saying "do the right thing".
I found the hardest part of becoming a leader is trusting my own judgment, intuitions and decisions.
The "Disney" quates for managers like "it's the team that succeeds" and "you don't accomplish tasks, you'r team does" led me to disregard my experience and allow engineers to dictate most of the design, which turned out rubbish.
I knew better, had solid arguments for my design, yet I let the team proceed with an inferior solution in the spirit of enablement.
The customer payed the price.
I’m only half joking. Hopefully your company is ‘one of the good ones’ and it will work out, but they are few and far between.
The tech lead job varies a ton from one company to the next, but all too often it comes with high expectations without enough autonomy or authority to deliver on them. Make sure your boss provides clear expectations and work with them to clarify boundaries over time. I’ve been on both sides of this process and it is difficult and necessary.
Too often, tech leads are expected to wear more hats than they are able to wear well. Delegate all that you can and if there is still too much work to do, ask for help.
It’s all about communication so actively work on this skill.
1. Remind yourself daily that the metrics you've used to gauge your own productivity or success until now do not apply. It's really hard. Resist the temptation to do non-TL things if it will affect your TL responsibilities.
2. Find other people who have more/broader experience than you do, and pay attention to the perspective they provide. There are many people who know more than most TLs but don't want the role themselves. You can help each other.
3. Remember that lead is as important as technical in your job title. Your role is to bring people to a place they're not already. Figure out what's missing in your project and/or your team members' skillsets. Those are the things that it's your job to address.
As a tech lead you may have to be 'the voice of the company' to your team members, and sometimes say 'no' to requests that you might actually think are reasonable, from a purely tech perspective. The impact on your relationship with the team depends a lot on whether you play yourself as part of the team - and are visibly aggrieved on their behalf - or become perceived as 'one of the managers'. Whether this is a problem or not depends on the corporate culture and whether there are other managers visibly involved.
Also, remember to reserve time in your day to deal with problems raised by the team. These will often occur when you are least expecting them. And some may be outside your own comfort zone.
On a positive note I found that being a tech lead made me a better team member for my own management, since I better appreciated some of the leadership challenges they were under. You'll sometimes be left stunned by how hard or well your team members are working to solve problems, and this can make it all worthwhile.
Realize that you are / should be in control. Make sure you get mandate from the higher ups, that you get to say yes or no based on your own judgment. But don't rely on yourself for everything, work with your team as well. Realize that you're a manager, you manage people, priorities, considerations, etc, and that for purely technical decisions you rely on input of your team a lot.
Make sure that technical decisions are documented (e.g. via an ADR), making sure to document what you and your team know and consider at the time of writing. This is a pushback to hype-driven development; you don't want to be stuck with a bad decision just because one team member showed up at work one day with a feature implemented in technology X without proving they've done the work for it. And you don't want to have to waste time with future employees explaining (again) why technology X is used - you can refer to the docs, and if they want to challenge it, have THEM come up with counterpoints, have them sell it to you and the team, and have them defend the time / effort investment to change the technology.
Re: hiring, always do a technical interview, even if you're hiring internally. Involve your existing team members, they have to work with the new candidate after all. Have the applicant do a small project (4-8 hours) representative of the technologies and context of your project in their own time, and challenge them during the interview (the goal being they can prove they wrote and understood the code they produced).
It stands for Architectural Decision Records. More info here: https://adr.github.io. We use this at my work to keep a record of our decisions, as the name implies ;-).
I've been a "senior developer" for several years and just moved to a formal management role with direct reports. Briefly, here's where I would suggest you start.
1. Read the book Extreme Ownership by Jocko Willink. I'm not the first to suggest this book but it has fundamentally shaped how I work and how I interact with others.
2. Try to write. I'd start with writing your "Manager Readme" file even if you don't plan to share it with anyone. Defining expectations is critical and it's start with understanding your own psyche. What is important to you? What are your expectations for someone? The internet is filled with examples of Manager Readme's along with posts that are totally for this idea and totally against. You can find mine without too much trouble if you check my comment history and find my GitHub.
That idea and set of principles is something I'm kind of surprised hasn't become more widespread. It also changed my approach in a fundamental way and is one of those things I wish I had learned a long time ago.
Also I've found his Good concept a useful way to stay positive:
Oh, the mission got canceled? Good… We can focus on another one.
Didn’t get the new high-speed gear we wanted? Good… We can keep it simple.
Didn’t get promoted? Good… More time to get better.
Didn’t get funded? Good… We own more of the company.
Didn’t get the job you wanted? Good… Go out, gain more experience, and build a better resume.
Got injured? Good… Needed a break from training.
Got tapped out? Good… It’s better to tap out in training than tap out on the street.
Got beat? Good… We learned.
1. get 2 mentors: a technical one and business one (doesn't need to be domain specific)
2. your job is transitioning from "doing" to "enabling". You'll be responsible for issues of governance AND operation. Learn the ropes equally. As you introduce successful operational concerns (bottom up) start to generalise them so they can be used as a top-down concern (i.e. i do devops -> we all do devops here, it's part of the training)
3. leading by example doesn't scale - stop. Embrace a teaching method that ends in trust: i.e. 1. introduce a concept to dev A, 2. get dev A to demonstrate it back to you independently (monitor and prompt as appropriate), 3. from afar passively observe future implementations of said concept and revert to steps 1..2 if required, 4. inform dev A that they are trusted explicitly with this concept and that it is theirs to run with - encourage them to onboard dev B in a similar fashion.
4. at the top you're more responsible for team morale than you can possibly imagine - random acts of kindness and/or direct conversations go a long way... whether it's donuts or "a quick catchup" over lunch, do it... regularly (if you find your postponing these kind of meetings you've got a priority inversion issue to sort out ASAP).
5. if someone is dishonest in any way take it to HR before they walk over you and your team/product/department suffers. In other words, with HR's help, address slow/no work or unapproved "wfh" days as a threat.
6. push back against harmful designs and rushed/skipped processes.
Number 5 reads a bit like this: if an employee is not motivated enough, instead of trying to find the cause and mitigating, go on the hostile path and get HR involved.
In fairness, this could be a good advice for roles that are easy to hire for (e.g. minimum wage manual labour).
I'm of the opinion that dishonesty is serious because it's an irreconcilable breach of trust. There are many things I'm happy to deal with internally providing there's a frank account but once someone intentionally misleads another it makes individual management untenable.
Separately it's a HR problem because of the nature of certain types of work. I'm struggling to fit my view with neural diversity though - some devs say dishonest things without malicious intent because they lack skills to effectively communicate.
Sometimes people reframe mistakes or lapses in a "dishonest" way to save face. I think it's important to use those occurrences as opportunities to show that it's safe to be honest instead. Allow them to come clean and show that the highest priority is correcting the problem. Running straight to HR instead of creating a teaching moment could increase distrust and the incentive to be dishonest.
There is a line between this and manipulative dishonesty, of course. Bad faith (when it's clearly that beyond reasonable doubt) should be treated with close to zero tolerance.
I am two years into being an 'inexperienced tech lead', and I think there are some good pieces of advice in the other comments. But I think the most important thing seems to be having some structure to your progress in all of the mentioned categories. When dealing with your team have an objective in mind for not only the conversation or meeting but for the takeaways you want your team to have. Take note of what assumptions changed your mind for certain decisions. Assume you're wrong and need to experiment to be right.
More practically: I write down feedback that is given to me regarding leadership style and write down things that I think about at the 'moment of impact' (assumptions, reasoning, and metrics for success/failure of decision) when decisions are being made. Read over these notes often enough that you are aware of those things when they happen again. Anecdote: Developers often want time to create a quality feature and if they are frequently pressed for time due to business requirements, they are unhappy and the product suffers, often in less than obvious ways. It was only really obvious that this was a problem when we tried other ways of planning and prioritizing because the assumption was that development pressure was a given for a tech company, turns out that some development work can be offloaded by better planning and prioritization based upon better thought out business objectives. These learnings came about because we kept took notes of decisions that were made, and could refer back to them as crucial points of pain/cost/failure.
If you don't have some structure to your approach, you'll find it difficult to call out specific changes that need to happen.
There's a lot more that could be said. Tech leads are often interfaces for other parts of the business so respecting the context of other's roles and aligning incentives is more important than proving your job is being done 'correctly'.
I worked couple of years in this role so here are my few cents:
1. Listen - Learn to Listen to Your customer and Team Members. Understand the reasoning behind what they are asking for.
2. Show, not only tell - I used to sit next to devs and see that problem they are mentioning is actually is problem. Sometimes issue could be business requirement. If technical issue, explain throughly teach how to go about solving such kind of problem. If they are still not able to do it fine, work with them while continue to explain. You want to teach - how to go about "solving problem".
3. Learn, Learn More and Learn More and Keep Learning and then Share - Learn about the business domain. Learn about technical domain. Learn about everything which lets you 'get things done'.
4. Delegate - But delegate properly, once task is assigned, make sure the team member understand what needs to be done. And they understand 'how it will be done'. You don't want to figure out at end of day that because of misunderstanding or lack of information task was not done correctly or worse has to be redone from the start. Reworking sucks big time and will suck big amount of time for everyone - you, team member and customer.
5. Get Details - Try to get as much as detail as possible, based on information take decision based on 'who is right for this job'.
6. Don't play favorites.
7. You dealing with Humans. People make mistakes. Find way to reduce chances of happening mistake in first place.
8. Be cool. Never get Angry. Anger drives out reason.
I would advise you to not take the position. It would be a disaster in my opinion to attempt to be a tech lead without years of experience at the senior level. Your high level engineers will catch whiff of your lack of experience. Your mid and associate levels will not accelerate as fast as they could have, and you will feel over your head. You will essentially be Peter Principaling yourself.
If you are going to do it, read a ton of books. Minimum in my opinion are:
1. The Managers Path -- general advise
2. Coaching Habit -- for performing 1 on 1s
3. Extreme Ownership -- for building an effective culture that delivers results.
I think it depends on the context. if the organization is overall reasonably competent and the engineers turn out to be relatively low drama this can work out great.
some dev organizations I have use a rotating release shepherd osition (gatekeeper). it usually works out pretty well, and junior engineers get a taste of what its like to live on the other side. its perfectly functional for a senior engineer to mentor a junior manager.
the one thing that concerns me about this story is hiring. my first tech lead position they gave me some heads and I promptly hired two smart-talking bozos with years of experience that wasted my time for several months until thankfully one of them quit and I got up the courage to fire the other.
My direct report is humble and most willing to learn. That doesn't mean they aren't at the end of the day still a very green associate developer with 7 months of experience so far. Any talks about reaching senior developer status any time soon would be a huge disservice to their development. We need to first talk about what being an exceptional associate developer looks like, transitioning to being a mid level developer.
Really good coding/architecture skills or able to collaborate and seek opinion and input from others.
For me as long as people have one or the other I can work with it. I've often been in scenarios with people that aren't good and won't collaborate and THAT'S the hell.
Obviously both is best but the skill set is rare. I'll happily take someone that defers to me and trusts my judgement over the HELL. Its not ideal and doesn't result in the best outcomes but its still workable.
I transitioned into a tech lead a year ago and at first it was kind of annoyed by all the requests from the team regarding technical assistance.
I realized there were two paths I could take. 1. Continue to be annoyed and try to get as much coding in as I can. 2. Sit down with each individual, help them, give examples of how things should work etc.
Luckily I chose the latter option and I have a great relationship with all the team, I have strong coders that are more self-sufficient, and I enjoy more time coding now.
I think the lesson I learned is that you get out of your team much more than you put in, strive to inspire your devs.
It's okay to make mistakes. Really, you're going to make loads of them, and your team is going to make loads of them and you're going to own those mistakes.
It's now going to be more about getting the best out of your team than it is about squeezing out more code. I spent a lot of time beating myself up over how much code I wrote dropping off, there is a nice sweet balance you'll find.
Learn to delegate, and learn to do it early. You'll burn yourself out super quickly otherwise.
Wait, do you actually want to stop programming and manage other programmers so early in your own personal development arc?
My primary advice is a strong "most people asking this question should not do this".
Not because you won't be good enough or grow into the job, but because it's a completely different job - and one that many programmers who actually like programming don't enjoy and in many cases aren't well suited for.
There are two toxic traps I should confront. The first is that titles like "tech lead" and "CTO" flatter your ego and impress your friends and parents. The only thing I can think of that exceeds this on the "sounds amazing today; tomorrow you'll start the rest of your miserable life" is an idealist taking money from a VC. Find a different way to impress your dad.
The second is that many companies do not understand how to incentivize programmers beyond "junior/intermediate/senior" (even architect is mostly just a senior who has to spend time managing, eg are distracted and less productive most days than a senior with a closed office) and you get to the point where the upper reaches of the programmer food chain are managing other programmers. Very few things could be more destructive. Honestly, it's fucking obnoxious.
You know what the very best programmers should get? A salary twice as big as the next best programmer, a quiet private workspace with permission to work from home, paid childcare and spousal assistance, and firm dedication from the management to insulate them from as many meetings and distractions as logistically possible. There should be penalties for disturbing them. Now that's tech leadership.
Also, the folks saying that you're working for the product, not the company are high as a kite. They are painfully wrong.
Long story short: if you love what you do, thank them politely for considering you and ask them for a quiet workspace and insulation from meetings. Then get back to work.
2. Lead by example - be the change you wish to see
3. Focus on strengthening your team members (designers and product managers included!)
4. Ensure your engineers are given ownership and leadership opportunities
5. Do not be afraid to let someone else lead - actually encourage this
6. Do not overload yourself (surprisingly easy to do)
7. Expect the amount of time you spend developing to decrease
8. Expect the amount of time you spend in meetings to increase
9. Actually spend time learning the business your code supports
10. Become a resource to the non-technical ppl your team supports
A lot of good advice in this thread, but remember to have patience with both yourself and your team as you take on this new role. Nothing changes overnight and it might be a number of weeks/months until you find your groove.
Great absolute clarity on what is expected of you by your manager. Tech lead roles have a mix of manager-light bits and your manager may have very specific ideas as to what the role ‘looks like’ or ‘feels like’. You need that info to succeed.
Absolutely this. There's a lot of nice talk in this thread about empowering and enabling your team - but in my experience, that's not what companies are hiring tech leads and managers for. They're hiring you to get stuff shipped!
So understand your own manager's approach to management, and make sure you're aligned with it. Recently I was in a job where my own "servant leadership" style clashed quite badly with my boss, who was much more focussed on management "driving delivery" of projects. It did not end well.
If a team member comes to you and says that they feel disrespected, discouraged, ignored, or even _bullied_ by a more senior team member, take that seriously. Immediately schedule a 1-on-1-on-1 and don't give anybody any time to prepare. Create a safe space for people to voice their concerns, and express to _everyone_ that if they are not capable of treating others with respect, they can be made redundant.
I'm going through this right now and it sucks. I wish my team lead had my back, but they don't.
Never consider yourself senior to someone unless you can do their work, and until they have demonstrated they can't do it. Otherwise, stand back and let people work.
You doing their work is sometimes going to be needed, but a 'good team' has an equitable workload. Be willing to do any of it.
The biggest thing a team leader can do is help the team communicate with itself. The worst thing a team leader can do is create conditions where team members are not communicating.
I agree with this because my 2 favourite places to work (my current on and one 9 years ago) had more of a 'self organising' vibe which encouraged people to put their hands up for things, and although the most senior people have the most codebase knowledge (due to simply having written that code themselves over the years), there are now a lot of areas of code that newer people like myself are the experts in. And also applies to technologies, for example React is known more by a few people needing it for their task.
The point I am getting at is that it is OK and I'd argue optimal if the team leader knows less than the person they are leading and the team leader has to ask them questions about how something works, but their job is to know enough to be able to make decisions and get a feel for things.
For one scenario: if two members of your team disagree passionately on something technical and come to you for resolution do the following: tell them they must resolve the argument between themselves with you as a mediator (to make sure they stay civilised and focussed on the technical arguments). Tell them they must come to a consenses themselves. Do NOT pick a side unless the process breaks down. I made this mistake and it wasn't good.
Never treat issues of incompetence, inexperience, or bad attitudes as interpersonal disputes. When one team member isn't following well-known processes, or is obviously wrong, you must pick a side quickly.
(Examples include things like magic numbers instead of #defines, use of strings instead of well-defined enums, pull requests with lots of commented out code. They can also go to deeper topics, like bad database schemas or poor data access patterns.)
Why must you pick a side quickly? If you treat incompetence or inexperience as an interpersonal dispute, you aren't managing. Instead, your team will quickly view you as appeasing incompetence, and this will quickly drain morale. This is especially the case if one person should be moved to a less-challenging role, or fired.
From personal experience: In these situations the technical lead fixed the code before merge, and management eventually pushed the other person out. But, it was a long slog while management tried to be diplomatic with someone who just wasn't willing, or able, to be professional.
I agree with that totally. In the case of technical incompetence for sure it's demoralizing for others to pretend it's a dispute with no "right" answer.
In the case I was involved it was two very competent senior developers and the dispute was between a iterate-fast-and-learn approach, and a build-for-the-future approach. It wasn't clear which one was right at the time and I respected both their opinions. It became clear that it was growing from a technical disagreement into something much more personal. I let it go too far and felt like I needed to step in and pick a side. I believe that I missed an opportunity for them to come to a compromise and learn something about that experience, instead ending up with one very pissed off dev, and one that thought I was on their "side" from then on.
Sometimes you feel like you have to make a decision just because your in a position of power, when actually in many cases you can be there as a mediator, lowering the emotion and keeping things professional and let people work it out themselves.
When you have a disagreement about how something should be done, think that your role is to try and convince the other person. If you don't convince them and their way is safe enough to try, don't stop them from doing it.
If it's not safe enough to try, then understand when you use your authority to stop them there will be a strain on your trust relationship that you need to deliberately rebuild.
Join the Rands Leadership Slack group [0] if you're into slack communities. This question gets asked a lot and there are dedicated channels to chat about exactly this and overall it's a supportive community :)
- You can't lead a team further than you have been yourself
There is a constant need to spend time up-skilling, performing tech spikes, thinking ahead
- 20% of people do 80% of the work. You should be in the 20% and also invest time with the people in your team that are in the 20%
- Genuinely care about the people you lead and help them get better at whatever their goals are
- "You can't lead a team further than you have been yourself"
I respectfully disagree. A good leader hires, nurtures and grows individuals that are better than himself. The goal of course always is to have the team be more than the sum of its parts. In doing so it should be the goal of taking it much further than the leader could ever have gone alone.
Being a lead should not be a platform for showing how much of a star you can be, it should be a platform for sharing your knowledge and skill with your team. This allows them to grow whilst taking and take the work they are capable of doing off your hands. The only development work you should be doing is the work they are not capable (yet) of doing.
This should leave you time to plan, teach and review as well as attend the meetings and do the paperwork that inevitably comes with a leadership role.
- Treat your team like their adults, not children, and respect them like such.
- Also, be transparent and clear with them. Hiding things or beating around the bush just wastes everyone's time.
- Give them autonomy to explore new tech when they get the itch, and you'll likely get better results and keep your team active and engaged.
- Embrace the blameless culture. Failures and bugs happen. Being hostile about it means people are more likely to hide stuff and not be up front about things. Not to say it shouldn't be addressed if it becomes a problem, but everyone's going to mess up sometime. Also, it's your job to make sure that any heat from on-high doesn't come down on them.
I've was a TL for a few years in my career and still play that role from time to time.
1. have your team's back, no matter what. They (and you) are going to screw up but your team is counting on you.
2. make the team better, every single day. Whether it's technical, emotional, productiveness, it doesn't matter. The team just needs to be better every single day.
3. get rid of the assholes, acquire those who want to be better
4. see the forest through the trees. Understand and appreciate how the work your team does translates into dollars for payroll
also, a while back someone posted this link on leadership from the Army. It's more straightforward and clear than any airport bookstore leadership book you'll ever find.
Hello, I've been in your position many years ago, so my 2 cents of hard earned experience.
If your project pipeline has a non-coding architect, they better be your subordinate. If they are not, be prepared to push back on their design decisions. Ideally they should have a stake in the project delivery.
When some estimate, deadline or feature complexity feels off to you, listen to your inner voice and stand your ground. No matter what others, with more seniority/authority/clout in the company think.
Take care of your team. Get rid of slackers, but don't overwork the others.
Accept responsibility for the failures, and share success with the team. "I failed", "we succeeded".
Remember that the programming is the easy part. Planning and collaboration doesn’t come as naturally for most engineers, and becomes increasingly important the higher level that you go. This is because large software isn’t built by one person that goes all Superman and codes it in isolation; larger software is done in collaboration.
1. Collaboration is key:
1a. When there are differences in opinion on how to implement something, your desired outcome is that the right thing happens for the company, and that everyone feels like their opinion was heard and legitimately considered. You don’t want to alienate even the most junior engineers even if you have absolute power over them.
1b. You need a good relationship with your business partners/customers, with your boss, and with your direct reports. Make this a top priority. Productivity improves drastically when the customer loves you. You need the upward, downward, and lateral relationships healthy because it’s crucial that you and your people feel safe to talk about the truth and work on solutions together. Counter example: people don’t want to ask for help or talk about what they’re feeling uncomfortable about because they think they’ll be judged as incompetent or a problem child. It’s important that you don’t feel that way when talking to your customers or boss, and that your people don’t feel that way when talking with you and each other. Foster a culture of love, respect, and acceptance to help with this.
1c. Pick your battles. Figure out for example when a design decision really matters strategically and when it can go either way. Give your people as much latitude as you can to give them a chance to learn from their mistakes.
I drone on here about collaboration because some of my larger failures in the last few years are because of running afoul of these ideas. Forgetting these ideas often leads to winning the battle but losing the war.
2. Constantly work to empower your people And figure out how they need to grow. Figure out their target growth areas, keep notes on those, give them opportunities to grow and learn in those areas. Watch how they do, and give them feedback every chance you get about what they did well and how they can do better. Never miss an opportunity to show them how pleased you are with positive things.
There was a good book, written my one of the first Facebook front-end devs, and she was also interviewed about this topic on an HBR Ideacast podcast...
If you establish a strong, rigorous software QA process, everything will be like butter. Your team will feel more confident about the product they release - and thus about you and each other, and you will have fewer emergencies to deal with, moreover with this virtuous cycle in place you'll generally be more on top and proactive about problem when they occur, rather than it just being another stressful thing in the backlog.
One thing you might not have had to manage up until now is dealing with conflict and/or under-performance. This will really cause any insecurities of yours to surface and make it feel very awkward in the workplace. If you feel like you need it (and you probably do anyway), have some therapy on your self-esteem and confidence, once you have dealt with that, discipline can be much more objective and less weird!
+1 to this. I read this book when I was new to management but found myself wishing I had read it earlier in my career. At least 50% of the book is really about the tech lead ladder. The topics on the management career path which much less concrete and flushed out IMHO. But the sections on technical leadership were really good.
I'm not a manager and I found a lot of value in this. I now ask my manager and my peers for immediate feedback anytime I lead a meeting. I've also adopted the habit of providing unsolicited feedback.
I would like to urge you to consider that maybe there is nothing to fix and maybe people are actually not interesting around you. I realized that I had the same"symptoms" as you did, but only sometimes. I started being worried just like you, but then I looked closer into how I communicate and with whom.
There are people who have a very different life, which I deliberately choose to avoid. Talking to these people diverges into talking about myself as there is always something exciting happening somehow, and they do ask about it (maybe out of politeness, but I'm a bad judge for that). These people sadly form a majority of people around me.
However, there is a much smaller number of people who I can listen to for hours and I genuinely care about what they have to say, so I ask a lot too. These people are really excited about their lives and have stories to tell. In my experience, not a lot of people have that. Also, they tend to care about things that I can say least imagine someone caring about.
So overall, maybe there is nothing to fix on your side here. At least, I think, there is a possibility of this.
>> What advice would you give a new, inexperienced, and ambitious tech lead?
Do try to keep things simple. By that I mean if you have the choice between a simple rpc framework and "the netflix microservice architecture with message queues and scalable container orchestration", do learn the latter, set it up, scale it to multiple sites over a vpn, but in the end,
Sometimes this means a bunch of things. For clarity, are you supervising people on the team or mostly guiding the team's work on a specific product?
In addition to others' recommendations about reading "The Manager's Path" (this is a must-do! An excellent book) I would take a look at how the team makes technical decisions and make sure that's healthy, and also make sure you have an understanding of the core value your product is trying to deliver by talking with your Product Manager.
If you are the defacto Product manager, make sure you know what the business is trying to accomplish so you can build the right thing and prioritize appropriately.
The more I do this work, the more a clear, open, decisionmaking process and a clear understanding of the value increment power everything else. Context and a way to talk about it.
One other note: your job will change. Know that. Be OK with it.
Think in terms of risk and ease of changing your mind / product.
Decisions which carry little risk and are easy to undo or pivot in the future, make them quickly and confidently.
Decisions which carry non-negligible risk but are easy to undo, give some thought but don’t fret too much. If the risk starts becoming reality, you can change your mind later.
Hard to change decisions with low risk are tricky. Make sure the time spent on research and decision making is proportional to the risk, which in theory is low, but that needs to be double-checked.
Decisions that are hard to undo and carry significant risk should be the ones you spend as much time as necessary thinking through, planning out, coming up with contingency plans, building in safety checks and making sure that you can avoid making those hard-to-make changes should you decision prove incorrect.
There’s great advice in the other comments already.
One additional resource I would recommend is https://devtomanager.com , which is a list of interviews with other developers on how their transition was like.
Understand what are the things that you should stop doing, and what are the new things that you should start doing.
What made you a great contributor and put you in a position to be promoted is not going to necessarily make you a successful tech lead going forward.
You need to start optimizing your work around different metrics now. How much you produce with your own hands becomes almost irrelevant, and how much your team produces as a whole, and how quickly people on your team grow becomes paramount.
Another aspect is that you should be managing up and sideways, be a voice and an ambassador for your team within your engineering organization. Be on the lookout for what is going on and provide air cover for people on your team.
Similar thing happened to me a long time ago. One major lesson to take away is this: everybody on your team is smart and capable unless proven otherwise. You are not supposed to be the smartest or most skilled developer there and you are not supposed to be the one to taken on hard technical problems.
Your #1 priority is to be a _facilitator_ in order to keep things on track. Clear the hurdles and engage with developers on the problems they are solving. And be humble. Don't treat others like they are less than you just because you are a lead.
And congrats! Enjoy it and be fully engaged. Also don't step on your superiors' toes or make them look stupid in front of their superiors. If you disagree with them, make sure to do it in private.
You're going to mess up and people will try to manipulate you. Trust yourself, be respectful and professional, and just keep showing up. You'll get good at this, but only if you keep trying.
If you don't know what to say or are feeling angry, don't say something just to have a response. Its super rare that you need to commit on the spot. If you get negative feedback from your boss, wait a day before you try to start panic-changing things on the team. Bosses are flighty and under pressure, try to keep it constructive.
Your main job is to keep the team productive. If you do this, you can leverage having a team that delivers into raises for yourself and your team -- eventually.
There's no magic. Humility, patience, fairness, learn from mistakes and be a good listener. There's nothing you inherently lack that can't be acquired through experience. Don't let titles or status go to your head, because it's all temporary and meaningless anyhow. Perhaps find a mentor, either internally or externally, to help you grow into a respectable leader because the last thing you or any sane person wants to do is evolve into a PHB Lundberg who thinks they're a superior species. A sense of humor, appreciating people's good work and self-deprecation helps too.
It's important to say "no" or "we shouldn't be doing this" especially at startups. In my experience many startups hit a brick wall and it's the responsibility of new hires and promos to try and help the company move past that wall. As an engineer it is often the case that the company is solving the wrong problems. Running a strong team - that's the easy part. Pushing back on management and being able to collect data to defend your position and support your proposal - that's more difficult
First ask yourself if you are the kind of person that enjoys serving others. Do you like to help the less experienced guys? Leading ain't about telling people what to do. So if you aim for that back off.
From my experience having kids helps a lot. Look into your past. Did you enjoy organizing stuff? Do you like to communicate with people? Do you have experience lobbing your ideas?
If you ain't scared of that then go and find yourself a mentor. Best would be if that is somebody you already respect.
> First ask yourself if you are the kind of person that enjoys serving others.
> Do you like to help the less experienced guys? Leading ain't about telling people what to do.
Sometimes telling people what to do is right. Sometimes it isn't.
We can bring up a thousand cases proving both.
I recommend the OP reads "The Dichotomy of Leadership" by Jocko Willink, which is about understanding where the balance lies.
This may sound very pedantic, but please spend a week reading “High Output Management” by Andy Grove.
The biggest change that happens when you move from a individual to a team lead is that suddenly you have a team which you can leverage to get the needle moving.
This is a great opportunity to punch above your weight but also fraught with peril if not planned well.
There is a need for a mix of comradeship and accountability which is not easy to grasp. But please spend a week reading the book
I think the most important aspect of the job is making sure that what you and your team plan will work. Try to keep things simple and use well tested technology. If you are attempting anything bleeding edge, do a quick proof of concept to make sure there are no gotchas. Sometimes team members want to use something novel to solve a problem, and they tend to underestimate the risks (short and long term). Keep it simple. Deliver what you say you will.
You seem to already have it, but admit what you don't know, and don't be coy about it. You will learn from those below you as much as from those above you.
In addition to lots of other good advice I see here, I would say that you should remember the old adage "fake it 'til you make it." By that I mean act the part. Taking a leadership role requires not just a change in action, but a change in mindset. You need to see yourself as the lead, and at least pretend to be confident in that role. In time you will actually feel legitimate confidence in your abilities.
One tip: Make sure that tickets (both bugs and support requests) make sense.
Meaning: Make sure that you're either running, or involved with, ticket triage. No ticket should go to an engineer without a basic review. (Edit: 2-3 minutes a ticket)
What are things that you should look for, before assigning a ticket to an engineer?
- Is the title and description coherent? Written in decent English (or whatever language your office uses.)
- Did whoever submit the ticket do an appropriate amount of troubleshooting for their role? (Or are they just trying to pass work off on your engineers?) Specifically, if this is a support escalation, did the submitter follow any troubleshooting steps that you've already documented?
- If this is a bug, do the steps to reproduce make sense?
- Do your processes require things like logs, screenshots, videos, ect? Are they present? (Edit: QE and support need to be trained on what kind of information to collect before passing a ticket to your team. Being a "team player" means holding other groups accountable for providing your engineers what they need to do their jobs.)
- Is this a duplicate of a well-known issue?
- Is the bug steered to your team appropriately, or should a different team take the first attempt?
- [Edit] Are there multiple bugs / support requests in a single ticket? (I have a firm one-bug-per-ticket, or one-escalation-per-ticket rule. It just gets too confusing otherwise.)
The above shouldn't take long. Specifically, during triage, you aren't trying to understand the bug or escalation. You're just making sure that whoever wrote the ticket put in enough knowledge that you're comfortable handing it off to your team.
When a ticket doesn't make sense, just send it back to whoever wrote it. You might need to meet with other managers to make sure that everyone understands what you need, and expect, prior to assigning work to your team.
The point is that you should be the filter blocking other teams from sending crap to your engineers. You can also involve your team members in triage, as long as your team members understand the difference between triage and actively working on a bug.
What happens when you don't triage well? Bugs pile up on your team and don't get solved. Some engineers will be good at asking for clarification for bad bugs, other engineers will just let them sit.
In this case, when tickets aren't being resolved, the solution is to re-triage and send back poorly-defined tickets.
As several other people have recommended, get a mentor.
If it's company large enough that it has managers who primarily talk to other managers, you're not going to be able to figure things out quickly enough to survive in that role.
Trust your team. Never break their trust. If you do that, you will not make it.
Never put yourself before your team (i.e. make your needs more important than the team's needs)
First piece of advice is the title tech lead applies to several different roles.
Everything from pm to architect to just most sr. Dev.
First thing to do is go to your new boss and get them to give you an exhaustive list of your new duties, responsibilities, what success look like, etc..
Also go to other people who have done well in that role at your company and ask them the same questions.
Remember that great teams are not necessarily homogeneous. This means you might need to tailor parts of your process around your team as opposed to trying to make your team fit the process. This also means that there is no perfect template for "developer", because of this you might want to consider a mix of creative, workhorse, meticulous, etc.
Technical leads generally are not managers. There's a lot of confusion here as to the division between providing technical direction and managing people. Your task as a tech lead isn't to manage people. If that's being what you're being sold then get a written description of the job requirements.
Tech leads work through their team to deliver. To work through their team, they need to drive to consensus. To do that, they need the support and understanding of their team, so they need to lead. To lead, you need to manage. That doesn't make a TL responsible for firing or resolving interpersonal disputes, but it certainly makes them responsible for coaching/mentorship/up-leveling in a much more direct and often valuable way than a manager.
Take an ownership role in what your team is trying to build and the purpose in which it's intended to serve. If you don't, people around you won't feel the need to either. And those that do need you to be an owner when you're not, will find ways to go around you.
Be very explicit in your interviewing. Follow a process. Have the same people ask the same questions every time. Ask for a rating immediately after the interview. See who are the good interviewers over time. Don’t count on recruiting to source good inbound candidates.
The advice that I was given when I temporarily took a team lead position is to overcommunicate everything. Build good relationships with the people you report to and your peers and (hopefully) you can lean on them and ask questions as you learn and adapt to this new role
Protect your team and make sure they're empowered to do their jobs and are unblocked. Depending on the organisation a lot of pressure may be placed on your shoulders and you need to make sure that doesn't impact on their productivity.
its' like a family
where you enjoy when the whole family is doing great
You have to think about each and everyone on the team while keeping the healthy competition.
Identify the people's interests and feed them type of challenges e.g. someone like debugging for those weird things or someone doing research and coming up with the ideas
Lead with the examples
Try to connect with them off the works (depending on the country/location)
Bring up the difficult discussion as early as possible, don't avoid them at any cost
Train more leaders as you're trying to finish your job
Take ownership and delegate
The TL;DR is that you are now responsible for anything that is not moving your team forward. If nobody knows what "forward" means, it's your responsibility to define it. If a code review is languishing, that's your responsibility. If a person has a technical question and they're junior enough that they don't know they can ask it, that's your responsibility. If your team doesn't have a good technical strategy, that's your responsibility. If your team is having trouble getting technical help from another team, that's your responsibility.
It's not your job to do all of these things, but it's your job to make sure they get done.
Your job will no longer be primarily about creating good code, it will be about making it as easy as possible for everyone else on your team to do so.
Writing well is very important. I literally spend half my day writing: tickets, pull request comments, upstream status reports, explaining the cost/benefit of various options to project managers.
Get basic functionality locked down early and then build from there.
Don't micromanage tech decisions but do make it easy for people to be consistent with one another by providing a style guide.
If all you do is prevent a few foundationally stupid decisions from making their way into the project, you're already way ahead. [hint: most really stupid decisions are not actually any one person's conscious decision].
empathy builds trust and trust builds respect, define the box, public praise private criticism, let them fail, give everyone ownership of something, promote continuous ideas, teach synthesis from the finest grain possible, isolate that which varies, abstract, your decisions are reversible make one and move forward, fall in love with the problem, be cross functional, listen first then act, stay one chapter ahead, be consistently consistent, make them smile!
My favorite quote -
"A manager needs to
provide the tools to do the job
remove obstacles from doing the job
and take responsibility for the result"
E. Jaques
Be firm yet be fair and consistent; there is a lot of room in-between, which you can figure out as you go along ─ don't get overwhelmed, as there is no blueprint.
Be very good than most team members in your tech skills and demonstrate it when chance presents, that will make them respect your judgement. If your tech skills are not on par with some of the team members that's fine, but you need to handle them differently. Time and time again i have seen skilled members of the team will question authority if they don't get along with team leads. Remember the cost of replacing a manager or techlead is low compared to skilled people because they get paid lower usually. You may have to delegate work but you must be the most skilled guy in the team or you should have a very likable personality.
My team lead philosophy: engineers that score successes continue to be successful.
There will always be a backlog of tickets, and you can't hit inbox zero. But you can hack it. Executives need to increase the Average Sales Price (ASP) and Reduce Churn. Your team will want to fix technical debt.
Your job is to bridge the gap: help your team understand how their work impacts customers. Help the business understand how your team's successes impact ASP and churn rates.
Tell your team they hit the goal. Tell the organization your team hit the goal. Tell the organization where your team can see you telling the organization. Many engineers aren't known for their salesmanship, and they can and should improve, but you can step in and rapidly build trust with them and the organization by selling their work on their behalf.
Instead of asking for time to fix tech debt, explain to the organization what the tech debt actually fixes: Reliability (churn), Operations/Chores (COGS), Resistance to Future Change (ASP), Infrastructure Bills (COGS), App Performance (churn), and like that.
The weekly 30-minute O3 is your new best friend, especially with non-technical stakeholders. As a team lead, I usually meet with engineers every other week—you're a team lead, not their manager.
Understand the differences between Accountability, Responsibility, and Authority. Responsibility is "yup, we're on it." Accountability means the business expects you to accept "consequences" for failure. Don't accept Accountability without both Authority to make decisions and compensation for the job risk. More than likely someone else is accountable (an actual manager or maybe a product owner.) Engineers are too difficult to hire to be holding them accountable. As an ambitious founder-turned-tech-lead I bristle a bit at this, but at least you can be aware of how things are set up.
But this also means you'll have limited authority, and you'll have to achieve alignment rather than dictate solutions. Which brings me to:
Pre-wire meetings. If you need a decision to go your way, meet with each attendee individually first and get their feedback on your proposal. Don't put together the meeting with everyone until you're confident it's a formality.
You can push back on processes that don't work for you: too many meetings, scrum ceremonies, taps on the shoulder. "I understand the importance of schedules and status updates to the business. My team needs protected time to achieve our best results. Will you help me batch our meetings into tighter windows so we're able to both put in the work and keep the business informed on our progress?"
Set up systems. Don't take on all the chores yourself. Set up a schedule for a "triage" engineer, include yourself in the schedule. I like rotating out weekly. This engineer intakes all of the bugs/questions/fire drills and provides answers and verifies things aren't on fire. They are assigned less critical tasks that week because they'll be interrupted. This gets you protected time to think.
Set up engineering "pairing office hours" 4-5x a week. You're not a manager: you still need to be on a Maker's Schedule. Your engineers will need help and rubber duck sessions, but if you drop everything every time they ask or get stuck, you won't ever be able to get in the zone yourself. Likewise, they'll know when you're available to help. Tell them you expect them to come prepared with a list of things they've already tried.
Read every MR your team submits. Don't comment on the direction 8 times out of 10 (unless you're directly assigned to a review.) You're looking for opportunities to ask Ben to talk to Samantha because they are both changing related areas. Great software is built by gardening over months, quarters, and years. You don't need every MR to be perfect (and that's subjective, anyway), and you'll achieve better results month over month if your engineers feel like they have ownership over their work.
On the flip side, if you're the one being micromanaged, try accepting responsibility for larger time frames. "We will achieve this specific thing by next Friday. We will provide confidence updates on Tuesdays and Thursdays." Then do it. Every time, if you can. The reason the CEO can go play golf on a Tuesday afternoon is because he accepts responsibility for improving the valuation of the whole company by 120% by the end of the year. The junior engineer accepts responsibility for one JIRA ticket, and is likewise expected to be available from 9-5 most days.
Read both Peopleware and The Mythical Man-Month. You're not a manager, but they will help you articulate your frustrations and give you tools to talk to management.
Email and twitter in profile, let me know how I can help.
One of the best answers on the whole thread. It is good to know the things I suffer most (no deep work because of interruptions) are quite common. Your post deserves to be much higher on the thread.
I'm not sure I'd value his advices at more than entertainment value though, it's half ironic jokes half serious but cynical, and last time I checked he was pushing hard on his quizz product that turns out to be a bit of a ripoff. I wouldn't put my trust in that guy too much.
I'm not sure how great that channel is for in-depth advice. The best case is that he's got a really dry, sarcastic sense of humor. And I think he's currently just running his cs interview prep business on the side after getting fired from Facebook.
Well, I have been where you are, so here are some lessons I learned:
1.) Delegate. Have nothing to do.
This is not about being "lazy" or not doing "actual work," it's about giving autonomy to your team. If you do not delegate, your team will constantly be blocked by you and you will not retain them. If you delegate properly, and trust your team, it'll feel like you (sometimes) have almost no job at all.
A pretty solid way to delegate, is to find out where people want to go next in their career, and offer up decisions/work based on helping people get there. It also prevents #2 on my list...
2.) Do not horde work.
It's shitty, I've done it, and learned from it. Every-fucking-time I accidentally did it, it sucked, it would (a) take forever because meetings can eat your life, (b) stress you out because of the time constraints, and (c) MOST IMPORTANTLY someone on my team would have benefited from, and enjoyed, doing the work more.
3.) Hire people smarter than you.
Don't be afraid to hire people with more experience than you or who are "smarter" in some specific field of expertise than you.
You will learn so much by being open to others knowledge, your team will benefit even more by having other people able to guide/mentor/coach them.
4.) Blame process, not people.
When shit hits the fan, you should ALWAYS be cool as a cucumber. It doesn't matter what the reason is, if someone pressed the wrong button, configured something badly, whatever it was cannot be undone.
What you need to do (AFTER) is a root cause analysis; I have always been a fan of the "Five Whys" but to each there own (you can probably google that to get started if its new to you or to find others). You can then implement, document it, and develop new process so that shit storm doesn't happen again.
Just in case the focus here on process wasn't clear, let me spell out the other part to be clear: do not every fucking blame your team. Do not ever blame an individual. You will fix nothing, and your team will grow to hate you as you toss people under the bus.
5.) Shit rolls down hill, it also rolls up hill, and you're always stuck pushing it.
Depending on where you are in the org, this isn't quite so heavy, but truthfully, as a manager/lead the bullshit you weather for your team is what defines you. The more you prevent rolling downhill onto your team, and the more you prevent rolling uphill to your boss(es), the more loved you will be by both.
At some places, without bullshit densities strong enough to make a strange-quark, this won't be an issue... At other ones, this will very likely be what keeps your bosses and your team happy in an otherwise (i.e. other departments) not-fun workplace.
6.) Be kind and be honest.
Don't treat people like family. Treat them better. Families have bullshit, families hide things, families have history, families might be kind, but they can also be brutal. You also can't fire your "family," but you might have to your co-worker... So, just fucking don't.
What to do instead? It turns out, when push comes to shove more than anything they want (a) honesty about the state of the company and their status, (b) to be communicated with kindly. Don't yell at people, or talk about them behind their backs, don't marginalize people or groups you don't think are in the room (I cannot believe what some people will fucking say when they think "no one" is listening)...
And we all can have a bad day and maybe rudely reply to someone or do something not our best-selves, and in those situations you just gotta learn to proactively and meaningfully say "I am sorry." It's even good for you if people find out you did, because it means you're not an asshole, and again they'll trust you more.
The best will be when people give you that same respect because you've set the standard and they want to uphold it...
7.) Your title doesn't mean anything, your experience does, it is the real investment here and completely defined by what you do and how much you put into it.
8.) If it truly fucking sucks, leave. Don't be afraid to jump shit; with a "lesser title." See #7 again, as long as you've done it right, you'll very likely be getting paid more anyway :)
Recently, I've been in charge of Growth at Whitesmith. For the last months I can pretty much resume everything to talking with everyone. Not only it will give you insights where you should go, but it will also help your team to solve their pains and frustrations and they will naturally grow and follow your lead.
So, a few (sorry, not that few) notes:
* Too much information around
You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.
* Listen your team and know their pains
More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.
* Delegate and communicate
Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)
* Iterate fast
Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.
* Are we engineers, or are we humans? (terrible pun with The Killers song)
Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.
* Align expectations
Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.
* Growth aka learning, enineering manager, space for your team to improve
Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.
Sorry for the long post. A lot of things coming to my mind atm. Feel free to reach out and disagree. That's actually what I do as a tech lead with my team. Also, I've been told the book "The Phoenix Project" is a really nice read for tech leads.
I am late to the party but here it goes. Everybody recommends to take care of the team and nurture. But nobody mentions what to do with slackers. Tech leads don't have the authority to hire/fire people but responsible for their performance. If one decides to only give 10% of their time to work, how one can motivate them?
I have a few pieces of advice. The general theme, always focus on making other people successful, and make sure things are meaningfully organized with both current and future team members in mind.
1. Checklists make everything easier. What needs to be in the checklists should be the most common issues that come up during code review or have been related to defects that made it past the dev environment.
2. Good agile documentation means all business rules/application behavior requirements should be in the story/task and in a centralized wiki. This makes it possible for new team members to familiarize themselves with application behavior quickly, and that list of behaviors is also the documentation on what needs to be tested so QA can implement integration and regression tests.
3. Every major code review needs an organized explanation of code changes per business rule. I've got my team using a OneNote where they initially write down each stories business rules at a high level for non-technical people in a list format and add sub items that describe an architectural overview of changes like design patterns and technologies used, and an addition sub level briefly describing code changes. I also have them provide links to an articles they used to make decisions or that describe design patterns used rather than needing to rewrite them. This rarely takes longer than an hour for a large story and it provides a semantic map between business logic and technical terminology for non-technical people and a sort of historical stream of consciousness that can be looked back at to get a feel for the history and direction for a given project.
4. Assess how team members are doing with technologies they use and get them whatever training they need.
5. No matter how experienced a developer might be before they join your team, new team members should always start out by getting the project to run and fixing bugs. Expecting too much too fast is a guaranteed way to lose high quality talent.
6. Always keep your ego out of everything and if someone is getting defensive about code, remind them that there is no such thing as perfect code. There is always room for improvement, and the focus on any changes or development/architectural decisions must always be about the potential future cost of each decision. Principals like Dry and Solid are important, but over implementing them will always result in difficult to maintain code. Abstraction is only good if it doesn't lock you into a design pattern that might not apply to the future state of all application behaviors you might need in the future. Also, reflection based code is cool to implement and a huge pain to get right let alone maintain or update.
7. Always beware implementing anything you're excited about. Code should always be focused on efficiency and maintainability, never on how cool or familiar a specific tool is. This is sort the same as keeping your ego out, but more about keeping your excitement out of things.
8. Developers should talk to customers, and logging should be implemented in ways that enable analyzing feature usage and user feedback. Many feature request come from managers, but the end users are the people that really need to feel like your software improves their lives.
9. Beware any list that has a psychologically pleasing number of items because it is definitely padded out or shortened to reach that number.
Watch Band of Brothers - Dick Winters I think is the best example of a good leader.
Doesn't ask from the team things that he wouldn't or isn't capable of doing.
And as many of the other comments have said you are there for the team. They will produce the real value.
What can you do to get them all the things they need to succeed? What can you do to shield them from the nonsense? Poor requirements, unnecessary meetings.
I think you want to give chances to fail but also provide that safety net so they don't fail too hard.
First of all you need to figure out if you're a "tech lead" (informal title, no reports or authority) or a "dev lead" (formal title, with reports and authority).
As a former Google tech lead (and I know this sounds like a YouTube parody): my advice is don't be a "tech lead" for long. Either be a dev or move into management. Make up your mind. Google "tech lead" is defined above.
As a tech lead in such informal position, you'll end up doing 2 jobs and you'll eventually find that the level of effort required is not commensurate with compensation. You can make much more and have a faster career progression as a manager. You can make the same money with less effort and headache as a dev. Your IC career won't move any faster just because you're a "tech lead", indeed the opposite could be true, because now a non-trivial fraction of your productive capacity is taken up by intangibles which are very difficult for an IC to articulate the value of come performance review time. Being a tech lead makes no logical sense whatsoever, at least not at Google, unless you're aiming for a manager position in the near future, and you need to demonstrate your "leadership qualities".
Other companies may differ, of course, but I bet it's like that at most places that have "tech" leads. In contrast, at Microsoft there's "dev lead", not "tech", and it's a frontline manager position, with reports and authority, and with the aim to move upwards on the management ladder.
Google-like informal "tech lead" is not even a title, it's just a SWE too stupid to understand that they're basically doing more valuable work, and more of it, for the same money.
Exactly what happened to me, then I read the Gervais principle and reduced all my stress by leaving for a new role 'just' being a dev instead of tech lead
What have your experiences and tasks been so far as a mid-level developer? What were you in charge of? Did you have a regular rapport with other departments, with clients, stakesholders? Did they talk to you directly when they "wanted things done"?
What are the sizes of the companies that you've worked in already? How big over all, how big were the teams you were on?
I'm surprised no one is asking these questions to see what existing experience you do have can contribute to this, because it is possible that this might be a natural extension of what you already do. It's company-size specific, but good to ask all the same.
In smaller companies, being a mid-level developer means occasionally having to make a call that directly impacts the bottom line and talking to the CEO and clients in a very matter-of-fact way. You wouldn't know that from just the title of a person however.
Assume that, for the people on your team, work is a #4 or #5 priority. And there's nothing wrong with this, as long as they're giving you a solid 80-90% effort during working hours.
If you ask them to put work ahead of family or faith or rest, or if you somehow expect more than 100% effort from them, you're going to drive away the ones who have other options. And the reason they have other options is because they're the best ones.
I’d like to add to this. Not only should you not ask your team members to put work above their own personal well-being, you should actively be challenging people who are doing that unasked. Every company will have an occasional time when extra effort makes sense, but if you’ve got people who are consistently working 10 hour days, or doing work at weekends or on holiday, it’s your job to deal with that. Find out why they’re having to put in that extra effort, then fix it.
Often this will be a case of one person having all the knowledge of a specific thing and needing to pick up any bugs around it, sometimes it’ll be that they’ve been given a task they’re not equipped to do. Occasionally they’re just not very good. Those are the cases that are reasonably easy to deal with.
The worst cases are the true believers - people who are so bought into the company, or the work they’re doing, that they just want to be working every hour of the day. The temptation will be to shrug your shoulders and count yourself lucky that someone is willingly doing a bunch of extra work for free. Don’t let them do that, because otherwise they’re going to burn out at some point, at which point you’re stuck with a bitter wreck of a person dragging the rest of the team down, and also suddenly lost a massive chunk of productivity that was carrying projects.
This sort of thing is especially common in early stage startups, and I’ve on occasion had to go round the office kicking people out. On one occasion I had someone go on holiday but continue popping up and doing things, eventually I had IT disable all their accounts for work systems until they got back.
The other thing around this I’d suggest is not to let a culture of rewarding heroics to build up. You should see every case of someone having to work a 100 hour week as a failure, even if it meant the project got shipped on time, or whatever fire was burning got put out. Post-mortem it, and then fix the root cause.
I always say people have five productive hours per day. I ask they give me four of those on working days.
This applies to creative work: development, document writing, content production and similar. Meetings, sales, email and other types of interactions are less taxing.
I don't mean to downplay the effort of interaction-type tasks. It's the result of observing people around me. I know many people who are happily productive on sales for 12h workdays. I know no developer who's proud of code written on the 12th hour.
Don't assume that these sales people are so happy to work overtime. They probably rely on commission and/or need to hit that sales target. Sales teams are known for super-competitive, target-driven, and high-pressure culture. We software engineers have it easy in comparison.
This is a personality characteristic. For me, meetings and sales are definitely a production that tax me enough. I want to quota how often I do them. (Sales, preferably never.) Some people get positively powered up by sales or meetings though.
I’ve even had medications turn meetings and such social interactions around for me. So I know it’s not a universal truth one or the other way.
The truth is that the "best ones" are often obsessed with their work and endure painful tradeoffs in their lives, for example their family lives, because of it.
People who do great work tend to think about their work all the time. No one thinks about their fourth priority all the time.
I'd refuse. You've basically disqualified yourself. If you mean well by your team you go and train under an experienced tech lead and then move up when you think you are confident you can actually do the job. Mid level developers should not be tech leads.
If you feel that you are a mid level developer then positioning yourself as a newly minted and inexperienced tech lead is a recipe for failure, someone else will be called in later on to clean up the mess, assuming the company survives.
I'm only responding to the content of the post, if there is more that I'm not aware of then you're free to point me to it but for now this stands unopposed based on the facts available. After all, what better way to interpret the question then to answer it truthfully?
It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
Ask your team to write out everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in assessing what they were planning to build. (It also makes for a great log of what we did and why we did it. This will be the product documentation for your entire product tomorrow.)
Treat your team like your family. Do not stress them out with too much work. Be respectful of their time and effort. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task.
You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance for your business team too.
Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
There is a lot to add to the above list but in general the idea is to help your teammates grow, help them think critically, stand for your product - make the tough calls.
All the best!