Ask HN: Advice for a new and inexperienced tech lead?
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?
Thank you HN
Thank you HN
258 comments
[ 4.4 ms ] story [ 277 ms ] threadI'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 haven't read the book, but it has 5 stars on Amazon.
So what's wrong with the book that multiple people downvoted the suggestion?
They assume the best of others.
They lead by example.
They are a facilitate as much as they delegate, and they don't lose sight of the fact that you can't lead from the trenches.
A good leader remains objective when it's hard to do so, and doesn't take it personally when somebody disagrees with them.
A good leader is kind, humble, and willing to help.
A good leader doesn't back down from using a firm approach when it's needed.
A good leader doesn't apologize for doing things that have to be done (discipline, firing etc).
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.
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.
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.
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.
Not sure why this analogy is applied to software development. The best managers I've had lead from the trenches where we all work.
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!
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.
It is important to listen to your users, but not necessarily do what your user’s want.
Especially in the context of the user’s role.
Adding a thousand requested features also has its drawbacks.
The one caveat is to be sure to also think about your team members as "users" of the code base.
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.
IMHO.
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.
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.
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'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.
In order to approach the ideal you must have intrinsic knowledge of the baseline as well. Good point.
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.
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
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.
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 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.
A simple 2-3 line github issue is often enough. what and why.
Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
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.
(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.
Good luck!
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.
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.
If you’re at a startup, your product is your business.
The point about not hesitating to move fast is the biggest difference between startups and mature companies.
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.
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.
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".
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.
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.
> 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.
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.
This applies to creative work: development, document writing, content production and similar. Meetings, sales, email and other types of interactions are less taxing.
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.
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 have observed an inverse correlation between consistent, unasked overtime and ability.
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.
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.
You can't shortcut these things.
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.
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.
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.
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.
Don't let ambition get in the way!
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.
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.
Good luck on your career move!
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.
Good luck!
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.
Good luck.
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.
There's a lot of interesting discussion on that thread that might be useful to you as well.