Last Updated: 2024-05-06

Your way of doing things vs. the teams

• Ideally, teams have a lot of autonomy in this area to accomplish their goals, but it can’t be 100% autonomy, or else you’ll have a hopeless fragmentation of technology stacks, tools, and processes. Think “80% autonomous / 20% coordinated” across teams, and in some cases centrally decided by a single person.
• tell your team why, and work with them on what, and leave how up to them.” And if one of the things you look forward to in being a manager is “calling the shots”, you should strongly reconsider.
• If someone wants to try an approach that you think is wrong, say: "I'm not sure that's the right approach, because of X, Y, and Z. However, I've been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?" If you're working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.
• If they do things differently, think of it as an opportunity to learn from their experience. Also try to remember, you design systems the way you do because it worked for you, they will design it their different way because they are drawing on what worked for them, look at it as an opportunity to learn a different way of doing things

Under Performance

• If someone is not performing their duties as well as you hoped, your first question should be what you could have done better to communicate, unblock, or train.
• If someone is causing behavioral difficulties as a professional, it's probably better to fire them. You should be managing work not behavior.
• If someone can't commit the time needed to overlap with core hours (and get something done 4-5 days a week), they are probably not a good fit due to the blockage.

Praise

• Tell people "you're doing great work" every so often
• Compliment code a lot, esp. in code reviews, where there will be some negative stuff put in.
• When someone's PR gets released and it's big news, celebrate it publicly in front of their peers, maybe linking to the public site. This encourages others to finish things.
• Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself.
• If someone does something you want others to do, shine light on it publicly and explain why it is good.

Not micro-managing

• Key an eye on pull requests also means gently guiding the junior devs to amend their code when they head down the wrong path (e.g. by pairing with them) rather than just rejecting it outright or (worse), writing a snarky comment.
• Give your subordinates problems (in a lot of detail), not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential.
• Bring in multiple programmers and do a call together if a problem is important.
• Never do your team member's work. Help them in every way for them to do their work, but just don't do it for them. This is because you want them to grow, to take ownership, to make their own mistakes, to not feel micro-managed. And to preserve your time for more management.
• THAT SAID, if a team member is not experienced in a particular tasks, they may welcome some guidance.

Efficient Reviewing

• Ask for links for each page to test
• Ask for screenshots before/after to speed up.
• "I trust you've tested this so I'm gonna merge. But ping me when we're both at work so we can deploy together in case any surprises come up"
• Create an expectation that they've tested each branch in their code. If you find an error, ask how they tested this?

Not drowning out other knowledge

• Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves.
• Don't ask leading questions. Ask "What do you think we should do?" instead "Do you agree that abandoning docker is a good idea"?

Giving Feedback

• Give feedback earlier and often
• Never review someone's PR (with the assumption that it is fully finished) without first asking if it's ready for review yet.

Getting others to come to you

• If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something.
• Don't say "reach out to me if you need help" in a public channel. No-one will ever reach out. Instead ping people privately and ask "how is it going with the onboarding". I found nearly every person on my team was having issues but wouldn't have reached out.
• If someone comes to you with an report or idea, and you don't necessarily agree, still tell people "your feedback is always appreciated and I listen to you"
• Get on video calls regularly with your reports. Make excuses to do so (e.g. to code tour or get some input or explain a bug or explain a feature or just before a release say "hey can we go over this before pushing to production"). Frequent short calls (every 2 days or so). Try to add some personal stuff at the start of the call. Volunteer info about yourself.
• Put yourself out there, let the team get to know you as a person so that connection is better. So post in the personal/random groups etc.
• When you want feedback from your reports, a) don't phrase things personally ("how am I doing?") because this makes them feel unsafe. Instead phrase things in terms of the system ("how did you find that meeting"?", "how are our workflows working for you"?). And don't ask for general overly general feedback "
• If you want to know if you pissed someone off, just ask them. It's better than playing the guessing game
  • Realize that other people might not listen to or respect you at first. You need to earn that respect. Otherwise they think they could do your job better than them.

Priorities when a tech lead

• It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it. Therefore, lower your expected output.
• Default loop: "Cycle through all your reports and make sure that you have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat." - https://news.ycombinator.com/item?id=3407643
• Avoid signing yourself up for any code deliverables in the critical path. Instead delegate this. You can work on tech debt that will never get prioritized (but which the team will love)
• Always have an answer to "what should I do next?" if a team member asks
• Delegate whatever you can
• If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself.
• Promote what your reports are doing in the company
• Make sure what they're doing is aligned with the company's goals.
• You still take ownership over those components you are responsible for (e.g. BE, DB, FE etc.). But delegate implementation. The reason for ownership is to be able to communicate about it to other technical teams.

Creating Consensus

• You need to get buy in by talking to stakeholders before the meeting in 1:1s, hearing their fears, seeing what could be changed for them to find this more acceptable. At the very least you can see other people's opinions
• Some people will always have strong negative reaction to new ideas on first encounter. Therefore they must be gradually introduced to them. (Or in a 1:1 before the bigger public meetings)

Estimates and Deadlines

• Don't create deadlines unless someone will actually die.
• But do estimate approximately as as S (at least a few hours), MM (at least a day), LLL (at least a week), VVVV (at least a month)

Managing Upwards

• "I'm not opposed to this idea but it is a significant change." We can certainly do this. And Y (reason support). However, .... X (major problem). Not saying we shouldn't do this.
• Create a spreadsheet ordering tickets and if a new request comes in from management, ask what should be de-prioritized.
• Ask them "what's worrying you" and understand their concerns?
• Do as much as you can to get to know your manager and for them to get to know you. This smalltalk makes for much better relationships and can move mountains. Found a new restaurant. Staring doing this.
• Send higher level management up a list of what's released / done (that they can show off with)

Encouraging programmers to test code

Create a PR template with a section "how I tested it/what needs to be tested". Encourage developers to fill it in with URLs (so that the reviewer can also test it).

Admitting Mistakes

• "To be clear this is MY FAULT we ended up here. I thought about desktop but not mobile."

Communication

• As needed, be prepared to communicate in
  • words
  • diagrams
  • code examples
• You need to ensure that knowledge isn't siloed in your team.

Time Management

• If you need to combine coding time with managing time, use Google Calendar to block focus time. Then have clear office hours that others know about (so they can plan blockers ahead)
• Plan to be idle half the time (so have the capacity to attend to your team's needs as they arise)

Keeping reports happy

• Give programmers a few projects just to make sure they are happy
• Find out where each team member excels and assign responsibilities accordingly
• If they ask for a tool (e.g. even a 300$ one) that helps them be productive, fight to make sure the company gets it for them.

Anticipating leadership needs

• You should be thinking about what happens if the guy above you retires (and how you can fill the gap to serve the company)
• You should also be thinking about what happens if you leave... who will you be grooming to take that roll. If there are no suitable candidates, then that could be an issue.

Giving TODOs

• Even for small things (like copy comments in Slack to docs), create a TODO in that person's project board. That way, both they will remember and you won't need to follow up and ask.
• If some PR needs changes, place that in someone's TODO pile at the right place as well as writing the feedback in GH.

Keeping on top of long projects

• Can you each (FE and BE) give a bullet pointed list of what you need to complete this PR?
• Get on syncing calls for large ongoing PRs at least once a week. Otherwise the team might be working under radically different assumptions (which wastes work)

Speccing

• For massively complicated tickets, create diagrams before text to help you iron our your thinking. Connect nodes as a graph. Label areas/quadrants.

Releasing

• Integrate the code "dark" early and often to avoid git conflicts
• Identify 20-30 alpha users to release features to early using a special testing link. This gets you real-world QA without reputational damage.
• Keep the old version of a page and the new one simultaneously live for a while in order to allow people a way to keep using the software while you work on bugs.
• Take snapshots of some DB tables before risky migrations on them. Whole DB might be too much work.

Team Alignment

• Instead of telling people what to do, you communicate the goal you want to achieve and why you want to achieve it. Concretely, this can mean clarifying your team's objective at the start of the week and making sure everyone knows this.
• At all times, you should know what your company's mission is and how your team aligns with this.