Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Advice for a new and inexperienced tech lead?

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 259 posts

Re: Ask HN: Advice for a new and inexperienced tech lead?

#101

Post by richie5um »

cdbattags wrote: post #59
tensor wrote: post #36

Earlier quoted context omitted.

I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.

This is more or less my definition of the term "product engineering". The one caveat is to be sure to also think about your team members as "users" of the code base.

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.

IMHO.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#102

Post by sergiosgc »

KptMarchewa wrote: post #63
sergiosgc wrote: post #42

Earlier quoted context omitted.

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.

Meetings, sales, email and other types of interactions are more 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.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#103

Post by smilekzs »

jrochkind1 wrote: post #99
tbabb wrote: post #75

Top mistakes by new leads: - 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.…

"tech lead" is not considered an individual contributor role? Is it considered a management role? I'm realizing I'm not quite sure what is meant by a "tech lead" role.

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

Re: Ask HN: Advice for a new and inexperienced tech lead?

#104

Post by azhu »

tensor wrote: post #36
jaspal747 wrote: post #11

Few things I would like to say: 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…

I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.

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.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#105

Post by gwbas1c »

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.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#106

Post by blueprint »

tensor wrote: post #36
jaspal747 wrote: post #11

Few things I would like to say: 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…

I would say you need to stand up for your users not your product. A gorgeous code base that doesn't do what your users want doesn't help anyone.

A gorgeous codebase is not a product without relevant users to consume it.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#107

Post by basseq »

blowski wrote: post #35

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. 1. https://pragprog.com/book/jsengman/become-an-effective-softw... , which had a good conversation here ( https://news.ycombinator.com/item?id=22033129 ). 2. https://managinghumans.com/ by Michael Lopes 3. https://leadingsnowflakes.co…

On #2, there are a ton of well-written and entertaining articles by the author—Michael "Rands" Lopp—on his website.

https://randsinrepose.com/

He also hosts a slack that's up to something like 100,000 people. Ask a lot of dumb questions.

https://randsinrepose.com/welcome-to-rands-leadership-slack/

Re: Ask HN: Advice for a new and inexperienced tech lead?

#108

Post by cyode »

sub7 wrote: post #66
jaspal747 wrote: post #11

Few things I would like to say: 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…

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.

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.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#109

Post by bosswipe »

jrochkind1 wrote: post #99
tbabb wrote: post #75

Top mistakes by new leads: - 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.…

"tech lead" is not considered an individual contributor role? Is it considered a management role? I'm realizing I'm not quite sure what is meant by a "tech lead" role.

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.

Re: Ask HN: Advice for a new and inexperienced tech lead?

#110

Post by tbabb »

qxmat wrote: post #94
pesfandiar wrote: post #76

Earlier quoted context omitted.

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 dev…

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.

Post reply on HN