Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you work as a tech lead?
118 points by obvthroaway 3 months ago | hide | past | favorite | 112 comments
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?




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.


If your team is waiting a full day to "surface issues" you've got some deep and troubling communication problems that a daily meeting isn't going to solve.


Depends on the team. I almost prefer juniors to make some mistakes and spend some time trying to figure it out on their own. There's a good chance they won't figure it out, but the journey they go on is a lot of time worth it.


    There's a good chance they won't figure it out, but the journey they go on is a lot of time worth it.
That's true of the good guys. Just make sure that you don't let the not so good guys spin their wheels in perpetuity, day after day on yet another problem. Or sometimes the same in different clothes. The good guy also probably told you earlier by pinging you for a quick 5 minute chat / call and was then back on his way.


but i thought leetcode made sure you hire competent engineers?


I think it’s hard to draw a broad stroke. Good team members unblock themselves. Sometimes that means dealing an answer right now. Sometimes that means shifting to something else.

My personal experience is team velocity is higher when you avoid team member immediately jumping for help when they face a problem. Loosing 1 day on 1x person is no worse than having 2x people loose 1/2 day.

Also, sometime problems just take time to solve. I’ve often come up with solutions after letting a problem sit for a day.


Having it last a maximum of a day is pretty convenient though. Of course it’d be better if people tell you after being stuck for a few hours, but not all people (especially junior) have learned/internalized that yet.


I think this depends on the dev - some devs will contact immediately when there are issues, and others suffer in silence.

It comes down to devs who are good at communicating, and those who arent, and shows the importance of communication as a skill. I'd take a weaker dev who is good at communicating over one who suffers in silence everytime


Well, the question was about junior engineers. In my experience, they will occasionally burn a whole day without making real progress. Communication is one of the many skills that differentiate juniors from more senior resources.


Many people prefer to focus on their work instead of constantly keeping an eye on Slack.


Where do you people get this "daily standup" idiocy from? Maybe I'm too old for this crap, but you can't get anything meaningful done in just 8 hours, and if you can, what you did is definitely not worth wasting time talking about.

I feel like you have to be a literal code monkey that needs to be guided on almost a method-level to get any productive plus out of daily "standup".

This hyper-corpo "agile" garbage should have been dead and buried a long time ago. As someone who has worked professionally as a coder for over a decade, one, at most two meetings a week is what's reasonable. Anything above that is a giant red flag, most likely means you don't trust your people, and reeks of shady business practices like rotating (hiring & firing) junior devs so you don't have to pay for seniors.


We had a daily standup at my first job in apartment maintenance, too.

Just five minutes of the whole team there at the start of the day to sync up; but it turned up lots of practical problems, like who would be in the shop to receive a planned delivery when most people would be in jobs they couldn’t pause during the day.

We have them in software for the same reasons — and it’s a giant red flag to me when senior people treat it as some kind of horrible imposition we spend five minutes a day on teamwork.


It's not five minutes a day though. Work has to stop before, and work takes a while to start after. The manager's work may take 1 minute to start and 0 minutes to stop, but an engineer working on something tough that isn't well documented may need at least 3 hours.

That means if standup starts at 10 AM, people are going to start work at 5 AM (if working from home) or end up starting work after lunch so that lunch isn't another interruption.


So move stand-up to the afternoon, or to earlier in the morning.

And if you know you have an interrupt in an hour, perhaps put off that 3-hour-long task until the afternoon.


That's the point. The "5 minute" disruption ends up with the team losing half a day of 'real' work.

Tech leads seem to have it worst as they're expected to communicate but also write code. A common pattern is to be available 8 hours/day for disruptions like this, and then work 2-8 hours at night.


> The "5 minute" disruption ends up with the team losing half a day of 'real' work.

This has never been my experience across a decade of being an SDE — and this sort of hyperbole undermines your case.

> Tech leads seem to have it worst as they're expected to communicate but also write code.

Your numbers don’t align with (eg) Amazon’s definition of SDE, where SDE1s are expected to spend 4 hours a day coding (50% of time) and SDE3 (tech lead) only 2 hours a day (25% of time).

They literally adjust their expectations to account for the increase in meetings.


You call it hyperbole then literally in the next paragraph say that SDEs are expected to spend 2-4 hours coding.


It's madness, most tech lead positions suck donkey balls.


I have learned it is better to have a team that has gelled, than to be organized around a superstar or hero developer.


That depends on the work and how it has been chunked down. Even longer projects that may take a couple weeks can have some milestones.

When I worked on a team of only senior, experienced engineers, we never had a problem keeping each other updated during daily standups. The exception I have seen might be very complex refactors, or trying to solve problems with no clear approaches.

With a team of junior engineers, it's great engaging with people and help with mentoring.

Lastly, I have found that true uninterrupted deep work lasts no more than a max of 3 hours a day, maybe 4. I've done full 8 hours daily like that, and I burned out. In hindsight, I realized that most people can't really do a full 8 hours like that.


That's understood to an extent, however the things that require that level of focus also generate other tasks like documentation, tests, possibly updating group notes or tickets regarding to the task or subtasks involved. When you add in incidentals like refilling your water, stretching, interfacing with calendars and emails, it's understandable that 3-4 hours of deep work per day is totally adequate.


I don't consider documentation and tests to be incidental, and have approached them with the same level of care and intensity as I do coding. In those days, I typically use pomodoro in order to leave room for things like refilling water, stretching, etc.


Good for you


It's nice to chat to real people for 15 minutes sometimes? Such a short meeting shouldn't feel very disruptive.


I prefer async chat; less disruptive and less annoying. I discuss more and it is easier to discuss tech stuff that way. In person/speech is a time waster we find; it is just because people are to lazy to think first and write something comprehensive down, so instead they just rattle off their train of thought. After a while most prefer it (been doing this for 30 years); the only ones who don't are sales/marketing (I schedule meetings with them a few times per month) and busy-workers who made it through the interview; we fire them. They won't perform anyway.


That's why workplaces have coffee machines and work policies include small breaks

If you wanna chat, it's fine with me, but you don't need to force everyone in the team to do it

I usually don't want to chat at work, write me an email if you need something and I'll reply as soon as possible


Then have a coffee break. You may discover that it is even nicer than saying "yesterday I did ... today I will do ... I am not blocked" to other human beings :-).


Especially remote otherwise async teams.


It’s a technique and may or may not be effective for a particular team. When I was an EM, we’d fairly regularly take stock of any processes to assess whether they were worth keeping, needed tweaks, etc. Funnily enough, on the daily standup one, I was the one who didn’t think it would remain, but the team really liked it.


its always somebody dropping these gems in interviews followed by “is this age discrimination”

the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders. in which case your own velocity isnt important as opposed to knowing if other team members are blocked on something you may be familiar with or even responsible for

a daily meeting that shouldnt exceed 10 minutes, or done asynchronously daily, is a decent way of accomplishing that


I agree with everything you say here, except for the asynchronous part. It's much better for a team to see each other face to face for a few minutes a day, especially for remote teams. It's wildly higher throughput than bullet points most people don't bother reading, it gets exposure for junior engineers, and it builds a stronger sense of being a team.

Someone who acts like being asked to spend 10 minutes a day with their team is some major imposition is worth losing over it.


We chat about everything in our team, asynchronous. Works fine for 30 years. I find people who have issues writing down their thoughts and bullet points first (which means they will be answered or addressed by someone before they can even hit a meet invite button). Each their own of course; everywhere I go (and we see a lot of companies close up because the nature of our work), we have to push away the meetings as they never work at all. What helps is asking very high hourlies; then suddenly meetings are not so wanted anymore (which proves the point).


I see the same.

There are places where the lone developer working completely async can work. Hopefully, they don't come out with over-engineered stuff that no one else can use.


> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders

That’s mostly theatre though.

Building useful software is not measured by team velocity or throughput.

In 2024 counting this stuff is crazy.

Measuring outcomes and customer value is infinitely better than measuring velocity.

Output is not hard, deciding and testing that you are building the right thing to create the right outcomes and customer behaviours to give them value is far more important.

In 2024 velocity and story points etc. and other theatrics are huge red flags to signal the organisation is not building meaningful products with care and craftsmanship.


I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.


Not the person you're replying to, but I'm not convinced there's a difference. Discussions about velocity boil down to "how much can we fit into the next sprint/month/quarter". This typically feeds into some kind of burndown or roadmap update. However it retains the pitfalls of estimating something that is often unknowable in advance.

I may be misunderstanding your comment in which case I'd greatly appreciate clarification as I really struggle with workflow planning.


I'm convinced people understand the difference.

Everyone struggles with workflow planning and that's why people use the old mid 2010s scrum terms differently now.


I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for?

In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".


> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders

Are you suggesting that the daily standup is to provide progress updates to the wider company (and possibly clients)? In my experience doing it like this makes it less of a safe space. It's purely a discussion between Devs and QAs about what's currently being worked on.


Alternatively why even have a meeting?

Just have a channel in slack/mattermost/teams for your team to post what they did and what they are stuck on at the end of the day and what they plan on doing at the start of the day.

You get the same result but without forcing people to spend the 15-30 minute wasted time before the meeting and the hour or so of degraded performance while they try to get back into the zone after the meeting.

Standups only benefit management and they really are the pinnacle of "this could have been an email/message".

The only time they may be acceptable is if everyone on the team dedicates their entire schedule (at least for the week) on that one project and if they work the exact same hours, the exact same days, in a no-remote environment. Then you can have a quick 10 minute meeting around the coffee machine while people grab their coffee in the morning.

Otherwise just make it an email/slack message.


Unless people sync up socially, it is unlikely the team will gel.

Some places let a lone developer do everything. More power to them. I think there's a better chance for the team to problem solve together and be able to have continuity as people join and leave the team.


This does not require standups.

You can have planning meetings but those are relatively short (<1hr) bi-weekly or monthly meetings.

And you can have an open coworking VC. I've not seen this formally in a corporate environment personally but I've sat in calls with friends at work for hours doing mostly the same thing (just informally). And in a formal capacity it's fairly common in open source project spaces. Their discords will have an open VC channel for "co-working" or working while on VC so they can occasionally chat, ask questions, or otherwise interact socially in a way you could while in an office setting.

The best part of coworking spaces is that they are optional. You join when you want and you deafen yourself or leave/DND when you don't want to be there and need to be undisturbed.

If you want to build a social fabric and get the team integrated, the way you do that is culture. Enforcing socialization isn't a good thing.

Don't make "Mandatory Fun". The only thing it breeds is a toxic work environment where people don't want to be there.


You can go for tgif for socially gelling. We go to lunch together, often dinner en also drinks. No need for standups for any social contact. Especially when talking about work things.


That sounds like there is something to unpack there. I think it is beneficial but others do not. Why is it?

Maybe it is because I've largely worked on remote-first teams, even before COVID. There are no TGIF, unless people make an effort to zoom together while drinking or something.


Sure, I work mostly with remote teams for the past 30 years. My point stands in that yes, Zoom is nice for socialising; I see no point in daily standups and voice meetings. We do have drinks/gaming for social; just no one wants to 'socialise' while working on something; it's simply not effective.


This. Virtual coworking spaces are a great solution for people who work well that way and you can host virtual game nights or movie nights outside of working hours for people who want to participate but you can't make people socialize by wasting their time with pointless mandatory meetings.


Socialization isn’t about doing things like pizza night or having games. It’s more about establishing connection and rapport, the basis of trust and communication. Most people are not going to be doing that asynchronously.


Most humans we hire / work with / meet online or irl do. It doesn't really matter what 'the rest' are up to for me.


> just no one wants to 'socialise' while working on something; it's simply not effective.

That sounds like you disregard the entire notion of paired programming, which I'm sure you didn't mean to do.


yes that’s what asynchronously refers to, it’s in my post you might have been typing while I added that


ahhhh yeah. I'm guessing I probably caught it right in that sweet spot between post and edit.


You have to be a manager in order to throw a word salad like this. "stakeholders", "forecast team velocity", "aggregate potential throughput"...

As an engineer, my feeling is that this bullshit never works and loses a lot of my time for the sake of a manager justifying their work instead of actually creating value.


"stakeholders"

Can I ask what do you think this the term "stakeholders" describes and what alternative terms you should use?


Stakeholder is corporate jargon.

User, customer or client are the normal, non-corporate jargon, terms.

A cynic might think 'stakeholder' gets used when a company forgets about the end-users.


I was more interested in the original authors definition as he called it part of a word salad.

I don't see a problem with some terms as being corporate jargon. That's just shorthand for an idea the same way any slang for a group is shorthand.


Here is why I did not answer: I don't think you are genuinely interested, I think you just disagree and were trying to argue that it was not a "word salad". Which is valid, it's okay to disagree with my subjective opinion.

For the sake of the argument: I say "apple, pear, avocado... that's a salad!" and you answer "Why would you say that an apple is necessarily part of a salad? How should I call an apple if I don't want it to sound like it is part of a salad?"

What makes a salad is the aggregation of multiple ingredients. Of course "stakeholders" is not a word salad.


You typed more about your definition of "word salad" than you did about stakeholders.

I think business shorthand is great. The word stakeholders has meaning and isn't part of a word salad to me.


> You typed more about your definition of "word salad" than you did about stakeholders.

Because it seems to me that you focus on my definition of "stakeholders" but you actually have not understood what I was trying to say, which requires understanding what I mean by "word salad".

> The word stakeholders has meaning and isn't part of a word salad to me.

And this confirms that my point hasn't been understood.


Yes, I do not understand your point.


> creating value

No true engineer I know would be caught dead using that phrase. Must be a manager! Gettim!


Hahaha, Touché! Here is an upvote :-).

I think it's very funny because I first wrote "instead of actually doing stuff" (which was wrong because this is "doing stuff", just bullshit stuff IMO). So I rephrased as "instead of actually being productive", which I thought was maybe a bit aggressive.

So I went for "actually creating value", because it felt like the way a manager would describe it. "I appreciate that you are doing work, and it is good, but it is not creating value... therefore I believe we need to change something" is how I imagined trying to constructively say "this is all bullshit, but I respect you as a person and I believe that you could do proper stuff instead".


Did you pick up any management experience on your way to becoming "too old for this crap"? I just passed the decade mark in my software career, and I've gone from individual contributor to tech lead twice now. I've mentored multiple developers through their junior years and into mid-level positions.

I'm not an expert on agile or waterfall or whatever methodologies people write books about. I genuinely don't know or care what the big tech companies are recommending. I just know that standups are an effective tool for managing a junior team.


I'm not saying you're wrong, but I get a whole lot done in 8 hours.


Me too, but it's usually not hard stuff and it's not worth talking about it

I'm just better at coding than at sitting idle while a group of people every morning talks about minutia like it's something really important

If I've said "it takes X days" and I've consistently delivered on time, I probably do not need to check in everyday to say "we are one day closer to delivery"


Well, if people can't get anything meaningful done in 8 hours, there're some issues with planning and delegating tasks. There're a lot small tasks that can be done to push thing forward and they shouldn't take a lot time to do if planning went well.


The problem is that the team doesn’t trust you (not you in particular). So everything needs to be discussed within at least some of the team members and your PM/EM. Meetings are for that (because it gets messy via chat only).

I don’t like it either.


Cargo cult from some bullshit agile methodologies.

And then shifting baselines: young engineers start in a world where "agile is good" and "waterfall is bad", but they don't know what waterfall is or where agile comes from. They are just given the agile bible and made to believe.


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.


"Delivered in phases until end of Q1 2025" -- sounds like it could be reasonable, or might actually be some kind of waterfall disaster.

My advice is that you do your best to push for actual users having their hands on the software as early as possible.

And for there to be a direct route from the users to you and your team members.

That is going to matter more than anything.

As far as the team, you should have a chat room open all the time, and people know they will get a response within a few hours during work hours, or right away if the other person isn't really in the middle of something.

It should also be easy to enter a voice chat, video chat or screen share.

Everyone should know that the chat room should be used freely when necessary but not as a distraction.

The manager should be in the chat room. If he/she won't/can't pay attention, push updates for anything that requires their attention and weekly progress reports.

As things progress, some of the users should be in the chat room also.

Try to aim for a release that users are testing at least once a week, as soon as that becomes possible.


I’m not a “Tech Lead”, but as a Sr. who leads emerging GenAI tech at Corpo, here’s my personal approach:

1. Support the orgs journey - This could be everything from accross requests or ad gov queries.

2. Experiment independentl - This is critical. If you don’t have the elbow rooms to explore, you’re likely taking directions from some turd.

3. Experiment with business stakeholders - This is how you learn about what biz (thinks they) wants. - Also critical.

4.(Internally) Open-source our teams findings - Try to generalize the technical components to a degree where others can utilize.

5. Consult with AppDev Teams - Sharing best practices, methods and pointing them to the open-source components as needed.

6. Build community - We host Bi-Weekly Task Force Meetups - Focused on tech-minded business stakeholders - On the off-weeks of these Task Force Meetups, we host: - GenAI Developers Meetups. - Focused on tech tech. - GenAI Office Hours

Sprinkled in there are white-glove training and general consulting.


@YCombinator: let’s go with some simple markdown parsing, eh!?


Over here [999]

[999] https://news.ycombinator.com/formatdoc


I'm a manager but has single contributor responsibilities.

1. How do you interface with your team (and how frequently)? A. Daily, if not hourly. Via calls, chats and emails.

2. How do you interface with your manager (and how frequently)? A. Ad-hoc and scheduled 1:1, my manager is a C level (smallish company, ~$40 in net profits.)

3. Do you have some recurring meetings? What is their cadence? A. Yes, but this depends on the employee, high flyers I let them set the schedule. Folks that turn out to need more help, I set the schedule, anywhere from once a week to once a month.

4. How do you take care of documentation? A. I have a background in Technical Documentation... Probably drives my team nuts. But I focus on getting tribal knowledge in to Wikis at least, formal documentation as required by regulation or policy/standard.

5. How do you ensure that you have time to work on your sprint tasks while context switching? A. LOL... In seriousness I weight my story points heavier as what I am working on is usually obscure and/or steeped in regulation.

6. How do you ensure everyone is moving in the same/correct direction? A. Through 1:1 and daily stand-ups. Plus monitoring the board. Finally, communicating the overall goals and obligations of the group. If one of my team members says "I've heard this before" I respond with "Good, you'll here it at least one more time."

I took the more challenging direction with my leadership. I manage people balancing their expectations and mine. I'll give someone enough rope early on to see if they can manage themselves.

Parting thought, I work with and worked for many veterans. One thing I learned from them is find your NCO, lean on them and reward them. Consider yourself a newly minted butter bar (Lieutenant) and don't assume you know best. But use your experience to guide the ideal direction, avoiding pitfalls you know about.


What is a NCO?


Likely non-commissioned officer.

I think GP means to say find someone with the business context and experience you lack, who you can rely on as a 2IC (second in charge).


I had a team of about 8 junior people. We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.

In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.

I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.

In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.

When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.

The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.

Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.

Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.

Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.

This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.


> We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.

Oh no, don't call it a "daily scrum" or the anti-Agile folks will descend on you like a pack of locusts :)

But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.


> But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.

Which is completely different from saying "daily syncs make it easier for people to ask for help or say they're stuck".

What you actually need for people to ask for help or say they are stuck is to make them feel safe and comfortable doing it. As a human, not as an agile guru. If one can't get there, maybe one needs to work on their human skills instead of adding bullshit agile processes.


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


Strongly agree with this recommendation! The Manager's path is the most useful write-up of technical leadership qualities I've come across so far.


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.


I worked with many teams at many companies. I trained a lot of developers to become a good tech lead. Most of them didn't know how to operate a team, what to do and what to expect. I extract the essential parts for daily tasks for a tech lead and share how it works here https://ruzig.com/answers/2024/06/19/how-to-run-a-sprint-as-...

This is the daily workflow, practical, no theory. There are a lot more details when you run a team, and you need a coach to help you do it correctly. There is no silver bullet solution for these questions. The important thing you need to know is that you should follow good practices like doing science: predict, experiment, retro => make changes and keep following the loops.


1. Daily chats one on one, unscheduled time, with them showing me what they are doing in the editor. This time is used for code review. Sometimes it turns into pair programming for training. Text messages over teams as needed. Open voice channel where I sit on mute a few hours a day they can drop into to ask questions. They can similarly drop in and wait for me to show up if I'm afk or focused on something else.

2. Ad hoc chats with manager, he is hands off other than twice weekly meeting.

3. Twice a week 60 minute meeting with the manager, product owner, researchers, QA, stakeholders. We demo new features to QA, finished features, and partially complete features to stakeholders. Plan new features as needed.

4. 3-5 minute video demos every two weeks sent to all interested parties

5. I block off several hours each day as quiet time for myself to do work. When I run larger teams (+5 engineers) I do not have personally assigned tasks

6. Pair programming, live code review once a day with each dev. I always prefer to hire devs who like to pair program, so ideally they will be pairing and rotating tasks regardless. Also promiscuous pairing, with tasks assigned to a pair stream not an individual. This ensures built in training and code review. No silos or solo work without significant input from a second dev ensures a minimum level of quality, catches issues early, and builds camaraderie.

I would say, this project sounds highly risky. I would personally assume only one dev will get any work done, and plan accordingly. What would you do if you knew the whole team would disappear tomorrow? You would set expectations, deliver the most important things first and get it into the stakeholders hands immediately. Do this, and the extra features produced by the other devs will just be gravy on top. Don't try to micro plan out every dev's time feature by feature, instead just ask the customers to order the most important features first and try to get it in their hands. Trying to actually plan a project with a timeline greater than 12 months has a <10% success rate in my experience. Instead try to deliver a first working feature into their hands in 3 weeks. Repeat. Don't ever try to fix scope and time more than a month out, it's effectively impossible. If you could do that, you could just predict the stock market instead and skip all the hassle


Maybe it's just me but this feels like micro management. Especially the daily chats where they show you their work in the editor. Your team's autonomy is being minimized.


I wouldn't do this exactly the same way with fully trained Sr engineers, but a whole team of 1-3 year engineers I would certainly do this.

How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on.

The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this.

I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all.

This isn't creative writing, this is engineering.

Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team.

Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane.

The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible.

All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.


Also consider that while Gen-X developers grew up at a time where they can deep dive into tech on their own, with little support (what internet?), Gen-Z developers expect a much different experience (where _isn't_ the internet?). Helping them grow is how software will be relevant for the next generation.

One thing I have been noticing about the Gen-Zers coming in is that they seek out mentorship and are very open to it. Why not lean into it?


Exactly! I find many (not all) younger developers respond extremely well to this more present mentorship.

Also let's be real, the average project now is 10x the complexity of the projects when I was getting started in the late 90s. I remember my mentorship was little more than being given the pocket guide to Perl and told to read it. Also told to use emacs.

But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron.

We had a maybe 1000 lines of Perl scripts and a production database.

So it's not like there was a lot to learn. Of course a year in I still barely knew what a function was. After a year I learned PHP and made a basic website that talked to a MySQL database I on our one server.

The expectations were extremely low, there was plenty of time to putter and rework over and over.

So I try to be empathetic that this is a job that needs an extreme amount of on the job training.


> But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron.

My neck hurts from alternatively nodding in approval, to shaking my head vigorously side to side, as I go over the commas.


Haha fair enough, maybe you're not using all these things. I suspect though if you aren't doing a webstack then there is complexity elsewhere, like external API calls, message queues, enterprise service buses, s3 buckets, ML pipelines, k8s, monad transformers, SSO integration, security, distributed tracing, etc.

Many systems are vastly more complex than 20 years ago. Even just system integration is a complex web.

It's our duty to train our employees. I disagree with the philosophy that hires someone with <5 years in the field just to throw tickets at them like they are fully trained. I've seen so many talented engineers wither away and quit from this lack of mentorship. It's disrespectful to them.

If you are a tech lead, it is your duty to spend the majority of your time training.

If there are high level tasks that need to be done that only you can do, have a Jr team member to it. They obviously cannot, and will need to research the subject, learn the area, and then you can use daily review and pairing to ensure they complete it successfully. I'd prefer to have a Jr dev take a 3x to accomplish a Sr level task like SSO integration while learning the area deeply than they fiddle with some CSS while I do the SSO integration.

This builds resiliency in the team. Now two people deeply understand the SSO integration. At the same time another Jr dev maybe was adding our first message queue for job processing. Again this is far too difficult for a Jr dev, but they are getting little bits of feedback throughout the process, I'm getting the message queue we need, and the team now has two people who deeply understand it, instead of one.

If I'm on vacation, my entire team should be able to handle any issues, because they built it all.


> Haha fair enough, maybe you're not using all these things.

Oh, I am - just not very happily :)

Not to get too into the weeds here, but I could live a long and happy life if I never had to read or write yaml that controls our build or CI pipelines, or troubleshoot layers of Helm and Kubernetes to figure out why our database migrations fail but only when running `alter` statements, or if I never had to manually search for `<FooBar` to figure out where some parameter is being passed from through twelve layers of React components down to FooBar itself.

But I also remember working in a world where Junior Engineer me FTP'ed code directly to production, hoping that `index_new2.php` was the latest, correct file on the shared network drive, and that nobody erased `index_old.bak` over the weekend because I still had to port some functionality over on Monday. (Joke was on me, by Monday the numbers had already come in, and it turns out that using Javascript to do financial calculations was a Very Bad Idea, and the functionality was no longer relevant. Plus, by then, I'd forgotten whether it was in `index_old.bak` or `index2.php.bak`.)


The team you are working with has very little experience so a lot of what they will be doing is learning, you need to give time for this but ideally you find ways to point them to standard ways of doing things and have them read rather than needing to reinvent the wheel. Where I work we do a loose form of agile which has lots of resources you can point people to. Below are my answers to your questions.

1. Daily

2. Every other week for an hour along with meeting when things come up.

3. Daily stand ups, every other week planning, retros.

4. Anything people work on that needs to be documented is done as part of their work. Changes to the system assume changes to documentation. Systems that others need to use more require more documentation but we don't put to much pressure on all of this because too much documentation can also be a pain.

5. Some people block off afternoon from meetings, I prefer to do this work in waves, when there is lots to talk about make sure these conversations happen, when everyone understands what needs to be done they are heads down working on it and I do my best to do the same.

6. Higher level meetings with leadership to align on goals get converted into team goals which are then converted into stories by engineering leads, in weekly planning we go over these tickets to make sure everyone is on the same page, sometimes new tickets need to be made for missing work but we try to make sure that everyone has enough work for the next chunk of time. You can check in on the status in standup and if something is off adjust something by adding more people to one ticket or breaking it up.

Another key thing to take into account is how to enable feedback from the people doing the work back up. You must enable the team to influence the goals and the work they are doing, sometimes they see a better way and it is important that they feel heard even if the path isn't changed.


1. At least daily with the whole team, and whenever you have something to discuss with someone individually. Be available on Slack (/Teams...). Announce relevant things on group chat (like a new API function becoming available, release dates...).

2. As often as the manager wants to. If you don't need anything from them, most are happy to be left alone as long as you deliver.

3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone.

4. I am not a huge fan of extensive documentation, because most people don't read it anyway and it gets out of date quickly. Just cover how to get started, and the overall structure so people can navigate. Keeping it short makes it more likely that someone actually reads it. But how much documentation you need depends on the organisation and project. It doesn't really matter whether you write it yourself or someone in the team. If you're lucky, someone in your team enjoys doing it. Just use some wiki-like system to make it easy to contribute. Or keep it in the repository as Markdown, if it's only for devs.

5. Depends on the project and team. But I have often tried to minimize the number of tasks I do myself, because as you suggested, it's hard to work on something when you're constantly being interrupted. In some teams I haven't worked on any tasks myself.

6. Talk to people and review their code. It's super-important to review as soon as the code is available, to minimize downtime and reduce context switching for the team members. Prioritize team members' code over your tasks!

(Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack).


> 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone.

Be fucking ruthless about this. If someone starts digging down into details that only affects them or one other person, postpone that discussion - otherwise, your standups will balloon into hour-long semi-pairing sessions while the rest of your team's attention wanders.

And ensure that the rest of your team is empowered to call that out, too - "Can we do a sync about <Topic X> after standup?"

> (Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack).

I find myself having trouble here, too, but one thing that helps is not feeling the pressure to be talking and/or typing and/or reading all at once, for a long time. Allow yourself and your pairing partner to just sit quietly and think during pairing.

I also "cheat" - before pairing with someone to support them on a problem they're having, I look at the code myself, first, and start diagnosing things. This prevents the issue of sitting there and staring blankly at code, hemming and hawing while you're trying to explain your thought process at the same time you're having the thoughts.


I'm currently a backend lead. Yes, it requires much more than usual effort to deal effectively with team of junior engineers. To be more detail.

1. Be clear and concise when explaining and demonstration. The more clarity, the better. Lead with examples is always the right way. And it needs time to change the mindset of the juniors. The benefit is, one day, they will bring back good ideas/feedback for you and the team.

2. Always challenging what the manager told us, because they have different mindset ! Do not assume everyone is on the same page.

3. Surely, depend on type of problems, the recurrent meeting is nessessary to make everyone on the same page. Confusion is the evil for everyone.

4. Documentation as code, code as documentation.

5. Work smarter, not harder.

6. Do not be afraid to be wrong ! Be wrong and you'll get the right explanation from team members.


1. Daily standup calls, and let things flow via slack/equivalent. You need to set your team for success, that means you need to make the work available to the team with goal based outcomes. Also, check in frequently to review the progress.

2. Weekly twice or once should be good, ideally this is the time for you to talk about the challenges you are facing and also talk about the good things that are happening. Make things visible.

5. Have some focus time for yourself, may be 2 hours per day to start with and adjust up based on the team's needs.

6. Review meetings/gant charts/milestones/sprint retros


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.


Not technically a tech lead anymore, in people mgmt for last 10yrs, but still code at least 60% time and still scrappy.

1. at least 2x a week, group meets on Mondays and Friday to set weekly expectations, 1:1’s as needed weekly or bi-weekly

2. bi-weekly

3. See 1.

4. Documentation is part of “definition of done”.

5.& 6. Start the week with making sure everyone understands their week’s tasks, have a demo Friday to see what was finished. Then pair as necessary - maybe check-in Wed w/juniors. For seniors and up, know and track the multi-week goals.


Happy to speak with you about these questions — if you're interested, send me an email (in profile). You've gotten lots of decent advice in other comments but these are the kind of things that are often best talked out verbally because there's always nuance, exceptions, complications, and multiple reasonable approaches.


Async communication works. Kanban works.

There is no need to micromanage and make people hate their job. Give them substantial autonomy, and help them along the way with code reviews. It's easy to monitor what everyone has been up to by looking at their git log without having to ask them.


I started a habit 15 years ago of logging on before anyone else and doing my IC work until about 10-11a and block off my calendar so no meetings are scheduled before 10a. That gives me 2-3 hours of focused IC work every day. Of course this might not work for you but I hope it helps.


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.


> 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?"* ¯\_(ツ)_/¯ .

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


Standups slow your team down while providing a place to discover someone is off track. Foster an environment where people reach out before the standups making them unnecessary is a more agile approach.


1. Daily, but you may need to touch base multiple times a day as needed for struggling teammates or highly time-sensitive situations. The best thing you can do for a well-functioning team is make sure they have what they need (including well-defined and up-to-date goals) and then get out of their way, but for orgs that structure teams around leads, your responsibility is progress (whether this is a good tactic or not is debatable). Not being able to answer for where your team is at and not catching obstacles (anything from technical issues to gold plating or even sandbagging) before they get out of hand is your primary responsibility. You’ll have to figure out the balance and particulars with your team, and I think devs will feel less disrupted and stressed out if you set expectations up front rather than pester them. For example, if there’s a high priority issue, agree on what you expect them to do and tell them when you’re gonna check in next.

2. I had a weekly 1:1 to go over concerns individually, a weekly meeting between team leads and product to ensure alignment and be apprised of business changes or problems, and an end of week meeting with other tech leads to coordinate cross cutting concerns. More of that crap you can cut out or strip to the minimum, the better. The weekly 1:1 with my boss seemed to be most important.

3. I generally don’t mind a tight, small and organized daily stand up, and it did mostly help me accomplish #1 (since everyone could schedule around it), but these meetings are very easy to derail and are vulnerable to too many cooks in the kitchen. So that, the aforementioned weeklies, triage meetings, refinement sessions, code reviews, architectural reviews, etc… the meetings stack up fast and were one of the most miserable parts. Some were useful, some were only situationally useful, everything else was navel gazing and micromanaging. I can’t tell you what the right amount or cadence is, but kill anything that doesn’t have a firm agenda, limited attendance, or much value. Do your best to keep your devs out of meetings as much as possible.

4. I’ve never worked at a place with an organized approach, we mostly just figured out what we need as we went. Too much documentation is taking time away from work, plus it all decays as projects progress, but no documentation is worse. I tried to bring documentation into my responsibilities, but would delegate small, focused chunks to team members that did the work. Leverage things like OpenAPI, generated docs, plantuml or equivalent to do C4, ERD, sequence, etc. If you need to delegate documentation, put it in your acceptance criteria or requirements and make sure they can just brain dump and move on (rather than fussing around with what tool to use, etc).

5. I put cards in for all my sprint work, whether it was programming or a placeholder for time spent in meetings. You only have a fixed pool of time, pretending that programming vs meetings vs code reviews vs anything else all come from magic parallel pools just does not work. Anything unexpected that comes along takes time from that pool. If someone wants to add work, something else has to come out, end of story. Block time on your schedule, too, and be confident in saying no if someone tries to sneak more shit in or blow up your plan. Also, make sure it’s clear from your manager what expectations are from dividing your time between leadership tasks and technical work. Give them feedback on how that’s working during 1:1s, gather feedback from your team on how well supported they feel and how well your team is on track, recalculate and feed back into next sprint. I think it’s normal for you to do a lot less technical stuff in terms of day to day, and you have to fight the urge to get down in the dirt if your team needs leadership. I ended at like maybe 20-30% coding except during crunches. I did not enjoy that ratio and ultimately moved into architecture.

6. Well, if you’re doing something like scrum, you should have a plan before you execute each iteration. Everyone should know the priorities and deliverables expected at the end of it, and should have been able to have a say on whether it’s doable, clear, and you have everything you need. That time is your opportunity to look at all the work and figure out approx. how long it should take to get each thing done (comparing a task to similar historical work and using that as a rough estimate for how long it will take can help you here… building a rubric for your team to guide you here is a good idea). The rest of the sprint is you gauging where everything is at at least daily. Stand ups are supposed to take care of that. If you feel like there is a risk of something falling off, that’s your priority to get back on track or adjust expectations (last minute changes to the sprint should be avoided if at all possible, though). Then you’re supposed to measure how you performed the last iteration against expectations, figure out how to improve, and you feed that into next iteration. There’s a lot of watching cards in their swim lanes and activity in source control (or lack thereof) and reaching out to people when you are concerned.

The TL;DNR is a lot of planning, just enough communication, and being the glue to keep everything together.


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


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


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.


You have a firm deadline and presumably something with a lot of unknowns that needs to be shipped. That's pretty risky. Here's how I've tried to get a handle on similar risks with a background in statistics and operations research. (Please forgive me for the length.)

For 1., 2., and 3., as frequently and synchronously as feels reasonable. Having a synchronous ritual of closing out the day (as opposed to opening it as is all too common) is tremendously helpful ("What did you all get done today? What warrants concern? Now, go home!"), and given that you're working in sprints, that reporting period should be good enough for most of the heavier-hitting touchpoints. Hijacking your sprint retrospectives for this is perfectly fine. If you need to meet synchronously more often for housekeeping, you'll know.

One-on-ones are a personal thing. Again, use your best judgment.

If the andon cord is pulled and kills the sprint early, say, kick your manager a quick email to let them know what's up. Their time is likely more valuable than yours, and it's worth trying to have trust that they'll let you know if they feel a synchronous meeting is necessary. Otherwise, the same advice on one-on-ones and other synchronous recurring meetings applies.

Everything else can be over email or your asynchronous messaging service of choice.

For 4., find someone with an MLIS degree. Seriously. Hire a librarian.

For 5., I'd strongly recommend adopting a practice that tries to minimize context switching as much as possible: just as in operating systems, context switches here are utter killers of performance and will slow you the hell down. Namely, if you have support obligations (for "site up," say) alongside needing to work on shipping and improving a product, establish a rotation (or possibly more than one) and include fixed-date product backlog items reflecting that/those rotation(s) to be considered during sprint planning that temporarily completely remove those individuals from product work. This will help keep those facts in front of you and make sure that the sprint workload commitment "feels right" given the regular reallocation of labor.

Completely removing those folks from product work will also help with bus factor concerns.

The team captain should run interference as much as possible for other interruptions like middle management drive-bys.

For 6., the name of the game here is what's called "one piece continuous flow:" the team is what ultimately ships things, not individuals, but it's the individual contributors coming together in lock step that enable each piece to be shipped. Folks going off on their own is fine in moderation (say, e.g., when reading and subsequently formulating comments to a design document or a report), but it can't be the norm.

Make your product backlog items trackable in a spreadsheet and try as best as you can to eschew relying on tools like Jira. I've had reasonable success with just giving suits an Excel spreadsheet with some VBA macros and pretty graphs: a lot of them know that tool well enough to make it work it turns out. Jira's nonetheless pretty familiar these days, but the complexity inherent in organizing work in epics and sprints and with tags and projects and workflows and screen schemes is a little too tempting when the actual work gets hard. Cut out as much meta-work as you can. Meta-work is expensive waste, and it, like context switching or rewriting your Emacs or fvwm configuration for the umpteenth time, will obliterate your performance.

As a corollary regarding meta-work, you can't scrub your bug tickets if you don't have bug tickets to scrub to begin with.

The team captain should have a habit of "management by wandering around" if they've doled out sprint work for the day to two or more subteams, albeit in a more systematic and regular and regimented fashion than the name implies. They should have a good "feel" for when folks are stuck and be willing to break through the bashfulness sometimes inherent with impostor syndrome by jumping in to pair with them. That feeling of not being good enough or a waste of time entirely evaporates when there's someone experienced roaming around to help proactively.

This all said, mobbing or pairing is only good to start, but you really need a collaboration of someone with proper product ownership (and not merely project management) and a sort of team captain on the development team itself to chart a course and make adjustments.

Hope this helps.


Been in both IC, TL, and EM positions. The TL in abstract fills the gap between the collective ICs and the EM. If you have no EM, you are the EM. Here's a bit of a brain dump.

It starts in planning and other ceremonies. From those meetings, you should leave with everyone understanding what they will be working on and you understanding everything that will be done in total during the next few weeks. You should be preparing for these meetings with sorting and filtering the queue of tasks. Then you should be fleshing out the tickets as a team. Over time, the team can also make sorting/filtering decisions.

You should also make sure any gaps are filled during 1:1s and check in with everyone to make sure they have a reasonable plan. As time passes and people mature, you can relax these touch points.

Other than that, you should be plugged in to all work streams from your team. This requires public conversations and sharing status before too much time is wasted. So you should encourage everyone in your team to ask the team for help if it takes >20 mins being stuck on anything. By the end of standup you should know what everyone will be doing today. You should also be able to predict some of the places people will be stuck and expect to be asked about them.

Pairing people up on mini projects is a good way to keep productivity up and get people to become comfortable asking for help and helping one another. This is crucial since you don't want to be the only person answering things.

You should be talking to EM weekly and ICs biweekly in 1:1 formats. Those should have a mix of prepared topics and random ones.

Beyond that, I would schedule pairing time weekly to work on something and round robin invite people to it. This was a good way to understand where folks are strong and to rub off on them in good ways. For example during an early session, I found one of my engineers lacked deeper knowledge of the language. So the following session with her was planned to coincide with a task that leaned on that and we paired on it. Sometimes it was a task I chose. I often would bring up the thought in 1:1s and mention that we have a pairing session coming up and give ICs the option to bring something they want to work on.

All of this gets you to people working properly and learning/growing. The goal is to rely on ICs for what they can do and continuously expand what they can do.

If you know what to build and have clear line of sight, this is enough.

Beyond that your job is also to contribute at a company/organization level to larger initiatives and get alignment on various things.

Staying productive is hard. I'd often do sprints where I'm mostly heads down and have no meetings for the first week, but batch a lot of meetings to my second week. Batching meetings is my single biggest tool here to get focus time. I will happily do 2 days of all meetings with the remainder being all large blocks of focus time. Having 2 days worth of meetings peppered into my week kills me.

Aside from this, you need some sort of way to manage your work. I would have 3 lists - sorted by importance. I would add to the lists as I go and periodically groom them (different cadence for each list).

1. tiny tasks - anything small; perfect for between meetings; if a task takes 15 mins or less, it's one of these

2. long tasks - anything that takes 1 day or less (so like 5 focused hours?); typically smallish ticketed things, but as tech lead often not always the case

3. long tasks - anything longer than above; often research tasks or exploratory things

I limit the length of the lists - different for each list.

I would do daily code reviews of everyone's PRs, not necessarily commenting since that can feel overbearing.


I found taking time to get things in order up front pays dividends later. Meet with the team to figure out the answer to these questions.

1. What communication mediums best fit the team and overall company culture?

2. I think this is highly dependent on you, the manager, and the viability of the project.

3. What meetings does the team think they should start off with? No matter the answer, have a recurring meeting every couple weeks to assess and adjust any assumptions you make in these early meetings. Maybe you find you’re meeting too often, or not enough… or people are confused by where documentation goes, or whatever is causing friction. Make time to talk about it and come up with things to try to smooth it out.

4. Pick a place for documentation, which I assume will be somewhat dictated by the existing company culture or available tools… but have a spot with a basic structure, so it doesn’t become a question every time someone needs to document something. Templates may also help, depending on what it is.

5. You could agree that certain days are to be free from meetings, to ensure everyone has some heads down time, or create blocks where meetings go to avoid them taking the whole day. I also found it helpful to have a dedicated meeting for the team to get together to ask random questions, share things they learn, etc. When people know there is a place to do this, for things that’s aren’t super time sensitive (that would take more time than the stand up), they are less likely to fill random other times throughout the week or derail other meetings. Of course, if something is time sensitive and someone is stuck on something, that should revert back to #1 so someone can help them get unsuck. Something like Slack works for that, and team members can meet up as needed for that stuff.

6. Make sure everyone understands the goal of what you’re trying to do and why. Make sure they have context of the world around them, so they aren’t making decisions in the dark, or at least know enough to know when to ask the larger group. One thing I found really helpful at the start of a big project was to get everyone in a room to map out where we are today (not the ideal of what it should but the reality… assuming you are starting from 0), then map out what you’re looking to build. You can then draw the map(s) on how to get from point A to point B. Having everyone involved makes sure people see all the parts, so they have context, even if they aren’t working on all those parts. It also helps to get misunderstandings out into the open and cleared up, so everyone is on the same page. Some people moaned and complained about this when we did it, but after a while they got into it, and I found it extremely helpful to make sure we were all heading in the same direction. This is also a good time for everyone to get to know each other, and their background/skills, if they don’t already know each other.

This is how we ran things about 6 years ago in my team. It started off a bit slow getting all ducks in a row, but we quickly sailed past everyone else, because things were running so smooth. It was great. For a while I had to explain to my boss we were laying some foundation and he seemed a bit impatient by the lack or tangible deliverables. But fast forward a little and he was saying we were so far ahead of everyone I could go to Europe and chill for 3 months if I wanted.

Fast forward to now, with some major leadership changes and that old team broken up. Planning is done by a few people behind closed doors, documented haphazardly, where people are expected to spend their time hunting for docs they didn’t know where written to inform their work. The plans are always 30% done, and the people making them are a huge bottleneck, as they are a single point of failure and no one knows what to do without asking, as any decision made is deemed wrong, either due to lack of context, or ego. This isn’t what you want. It’s a mess… 3 years in and it’s still a mess like day 1. Make sure your team knows what they’re making, feels like they are part of the process, and can make some decisions along the way, within reason. If you try and do it all, it’ll be too much.


1. Mostly through daily stand-ups, but I hate these: I only do them due to MBAs in suits love progress reports and have the impression developers being 'idle' is a detriment to the business which has costs which they have to minimize. I tell my team that anytime they have a blocker to try to resolve it - but if they can't do it quickly to come to me (and I usually resolve most issues quite quickly just by guiding them through my process so they can learn from it).

2. This once again depends on the company. I prefer not interfacing with them: my job is to deliver value to the business by serving both the staff and the businesses' customers. My number one initiative when I am on-boarded to any organization is to understand: what is your goal, what do you want to accomplish and who are you here to serve? Once I figure that out, I can think in terms of end-users and various stake-holders and try to work backwards rather than having to have many useless meetings and having to constantly wonder what I should do next. Think in terms of the customer: what can you do to improve the product for them and what can we do to improve the business in general?

3. I usually do yes, but most of them are led by upper management and I mostly think of them as a waste of time. If I need anything, I get in touch to the user or customer who has the information and find this information directly. There is one recurring meeting that I do tend to have with my team: weekly learning sessions and these are non-mandatory and not really recurring.

4. Documentation to me is very important, so any communication which I have to do more than twice I document and I put it on a wiki or shared knowledge base which both me and the team can reference and point to in case anyone needs guidance. I'm also a huge fan of written requirements but that's me.

5. 1) Minimize meetings 2) Unblock your team by helping them out when they need help and teaching them how to solve their own issues instead of always having to come to you - if they can't resolve problems themselves or they come to you every day, maybe it's time to think about letting them go and hiring someone who is able to take more ownership and has a bit more talent in solving problems 3) Keep asking the question why? What is the business trying to achieve with my team and how can I improve it? Which activities can I do which are 'high-leverage' and which will help us accomplish what we need to accomplish? I'm very hands on so the way that I play 'lead' is by minimizing micro-management and getting my hands dirty: I develop the hard stuff that I believe my team won't be able to handle and try to also foster communication between my team as well: I tell them if they ever need anything to come to me directly and I will try to get them the information they need. Communication is the number one thing that will determine a team's success so I try to keep it moving - how can we communicate what we need to develop more effectively and how do we make this process more efficient? Sprints and stories and all that other crap to me is a sign that most software firms today are broken and that most developers take 0 ownership on aligning with the business. This is the reason why we have so much broken and shitty software today as well. Hire people that are excited about developing solutions for real human beings and that WANT to see the business progress without having a 'product owner' or 'sprint planner' or some bullshit-job personnel having to either disturb you and guide you and teach your staff to do the same. Also, take ownership and pride in doing quality work and teach your team to do the same by leading by example.

6. Make sure to understand the product and business and first and foremost: the customer and do your best to solve their problems. Also, read books which aren't just about copying stories on a story board or about shitty broken agile processes; understand general things about business and human psychology and usability and design - this will equip you to make decisions without having to be micro-managed by 'the business.' If the business needs and insists on micro-managing you or your team - then leave the company and find a place that isn't broken (albeit it is tough to find these...when you do find them, you'll find a lot of rewards in working for them - autonomy and pride and not being micro-managed are all amazing things).


Post YouTube videos as The TechLead /s




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: