Live data from Hacker News

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

news.ycombinator.com

61–70 of 259 posts

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

#61

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

> (e.g. via an ADR) what is an ADR?

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

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

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

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

#63
post #13

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…

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.

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

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

http://www.paulgraham.com/makersschedule.html

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.

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

#65
post #3

Read at least the first few chapters of Camille Fournier’s The Manager’s Path .

Another good book to read: Radical Candor

+1

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.

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

#66

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.

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

#67

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.

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.

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

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

https://fas.org/irp/doddir/army/adp6_22.pdf

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

#69
1.Have patience as you transition into this role

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.

Congratulations and best of luck.

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

#70

A good leader doesn't compete with others- they bring out the best in others. 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 willi…

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.

Post reply on HN