[HN Gopher] Ask HN: How do you work as a tech lead?
___________________________________________________________________
Ask HN: How do you work as a tech lead?
This is a blanket question. I am working with a team of junior
engineers, 1-3 yrs in experience. We have been assigned a project
that is to be delivered in phases till end of Q1, 2025. Main things
that I want to know about are: 1. How do you interface with your
team (and how frequently)? 2. How do you interface with your
manager (and how frequently)? 3. Do you have some recurring
meetings? What is their cadence? 4. How do you take care of
documentation? 5. How do you ensure that you have time to work on
your sprint tasks while context switching? 6. How do you ensure
everyone is moving in the same/correct direction?
Author : obvthroaway
Score : 12 points
Date : 2024-08-19 16:59 UTC (6 hours ago)
| sybercecurity wrote:
| Don't have full solutions to every question since I had the
| luxury of leading teams that had more experience (5+ years), so
| YMMV:
|
| 1-3. Try to do more 1-on-1 or small group meetings, once per week
| max. Unless there is a lot of overlap/cross concerns, I found
| having a big group meeting become "holding court" where one
| person speaks to the lord (you), while the others sit there
| waiting (or checking email). Same would go with talking to your
| manager, try to do more 1-on-1 if possible, or ask if you could
| submit a quad chart instead of a big holding court meeting.
| (https://researchservices.cornell.edu/sites/default/files/201...)
|
| Other than that, if you are comfy with being pinged via
| Teams/Slack/whatever, that seems to work best for small
| questions.
|
| 4. One thing our org tries to do is have regular rebuild days.
| That's where you take a base VM/system and rebuild your
| environment and code by following your own instructions. Best way
| to catch what you didn't document: modules you forgot you added,
| environment variables, etc. Basically you want to think about the
| experience of a new team member or customer who lacks the oral
| history and institutional knowledge of the project. Once a
| quarter is fine.
|
| 5. Agree to have offline hours where you work on your own tasks -
| marked on calendars if necessary.
|
| 6. Semi-frequent group meetings and rebuild days help here as
| well. This is where I was luckiest in that the team was more
| experienced in working together, so there wasn't much shepherding
| needed.
| neilharia7 wrote:
| 1. Have a daily/thrice-in-a-week standup with your team for
| updates/blockers on the tickets that they are working on
|
| 2. Weekly/Once-in-two-weeks with your manager to update on the
| milestones and address any updates related to
| personal/professional yours or on behalf of your team.
|
| 3. TBH, it depends, if you are involved in working with cross-
| teams. If it's the start of the project, the recurring meetings
| with PMs and other stakeholders should be thrice a week to know
| the requirements and address any blockers from a high level and
| tech debts that need to be resolved as a pre-requisite to start
| the project.
|
| 4. There should be at least 2 documents, one the PRD (Product
| Requirements Document) and a technical doc (basically a technical
| PRD document), this can include the architecture design as well.
| The technical side should be handled by you (the TL) and part of
| your team (to lead sub-modules and upskill)
|
| 5. You need to prioritize the things and work on them accordingly
|
| 6. Having regular standups helps you know the same.
| brudgers wrote:
| [random advice from the internet]
|
| These are the wrong questions to the wrong people. "What do you
| need?" is the right question when asked to your team members.
|
| There is a magic formula. But the variables are each of the
| actual people on your team. Not a theory. It's going to be hard
| work. You are going to get things wrong. When you do, stop doing
| that and work hard on what seems to be right.
|
| Good luck.
| sdwr wrote:
| Good advice wrapped in some really, really, devastatingly bad
| advice.
|
| A good, experienced manager can give each person the tools and
| space they need to thrive.
|
| But that's only because they already:
|
| - retain authority
|
| - maintain a consistent schedule for everyone
|
| - provide (the illusion?) of forward progress
| brudgers wrote:
| If you rely on authority you are a boss not a leader,
| consistent schedules are for assembly lines, people are more
| important than progress.
|
| None of the things you mention will make people glad they
| work for you. Or eager to work with you on their team in the
| future.
| romanhn wrote:
| I'd highly recommend reading The Manager's Path by Camille
| Fournier. It has great directional guidance for folks starting in
| leadership (and experienced ones as well).
| beryilma wrote:
| 3. No meeting agenda, no meeting. It is OK to have weekly
| recurring meetings. But if you don't have an agenda emailed a day
| or so before the meeting, cancel the meeting.
|
| 4. Unless you have a somewhat detailed requirements document
| based on actual customer input, you will build the wrong thing.
| All stakeholders should be in agreement with what's on that
| document.
|
| 6. For the love of god, no Scrum or daily standup, unless you
| want your team hate you. Weekly iteration meetings for progress
| updates might work better. Your 1-on-1's is a better way to track
| team progress.
| mandeepj wrote:
| > 6. For the love of god, no Scrum or daily standup, unless you
| want your team hate you. Weekly iteration meetings for progress
| updates might work better. Your 1-on-1's is a better way to
| track team progress.
|
| If stand-up is done right, it has a lot of benefits. I've seen
| some people start boiling an ocean in that meeting or even
| after being included in every single meeting, would still ask
| the next day in the stand-up - *"What you did yday?"*
| -\\_(tsu)_/- .
|
| @allknowingfrog put it in the right way - * A daily standup
| ensures that no one spins their wheels for more than a day
| without giving you a chance to do something about it, which is
| really helpful for a junior team. However, remember that this
| meeting is for surfacing issues, not for solving them. Schedule
| follow-ups with the people who need it and let everyone else
| get back to work. *
|
| I recently bought [0]. The workbook[1] alone convinced me the
| money spent on it would be well worth it
|
| [0]: https://press.stripe.com/scaling-people
|
| [1]:
| https://assets.ctfassets.net/fzn2n1nzq965/5QpKqAjTVoskvZ4mRT...
| allknowingfrog wrote:
| You'll find yourself choosing between getting "your" work done
| and doing everything else on the list. It's important to accept
| that enabling everyone else is part of your job. In my
| experience, code review is the single most important thing you
| can do to mentor your team, maintain your code quality, and
| monitor your progress.
|
| A daily standup ensures that no one spins their wheels for more
| than a day without giving you a chance to do something about it,
| which is really helpful for a junior team. However, remember that
| this meeting is for surfacing issues, not for solving them.
| Schedule follow-ups with the people who need it and let everyone
| else get back to work.
|
| Document things when you get tired of answering the same question
| repeatedly. Focus on ROI, not some higher principle of best
| practice. You can get a lot of mileage out of conventions and
| tribal knowledge.
| lWaterboardCats wrote:
| Create an environment where everyone, including you, is forced to
| teach each other and and offer different patterns or approaches
| or pose the question on other ways to approach those and the pros
| and cons of it.
___________________________________________________________________
(page generated 2024-08-19 23:01 UTC)