Skip to content

Latest commit

 

History

History
25 lines (16 loc) · 5.19 KB

techlead.md

File metadata and controls

25 lines (16 loc) · 5.19 KB
Raw

What does being a Tech Lead mean?

Be responsible for and own the overall plan.

  • Business Goals: Understand and frequently reflect on the business goals for tickets. The PM will definitely do this, but it is also the tech lead's responsibility to think about this as well. You bring special insight, because you can most accurately compare business value to technical difficulty.
  • Clarity: Understand all the pieces of the project, including infrastructure. You don't have to know every technical detail of a given piece, but you should be at the level where you can comfortably explain the approach, the reasons why, and any concessions to both a technical and non-technical person. You should be able to answer questions such as these: What’s the hardest part of this project? What might go wrong? How will we know if it’s working? What gets logged and monitored? How will we debug this if it starts acting weird?
  • Deliverables: Know your team's deliverables: What are they? When are they due ? If you don't know when they are due, then help/lead the effort in determining a realistic due date. This also includes getting well ahead of any integrations, performance bottlenecks, and raising issues/risks early and often (don't raise a single issue once and expect it to be handled). This also means you get over the understandable reluctance to estimate, because you need to match the team’s plans against other teams’ plans and external events.
  • Backlog: Know what's in the backlog. Take time to periodically look at it prior to grooming meetings (and discuss anything with your PM that you think should be up for grooming discussion well before the sprint planning meetings). This goes hand in hand with helping to prioritize work with your PM. This is something that you should do with the PM, not something that they do for you. Also you should detail out high level technical approach (and also have your fellow teammates do the same) on tickets rather than dictating them out to the PM. Example of a technical task breakdown: https://github.com/DoSomething/quasar/issues/329#issuecomment-291883051. It’s recommended to organize larger work in an issue, like this: https://github.com/DoSomething/phoenix-next/issues/341, linking each task item to the specific PR that completes it.
  • Icebox: Know when to deprecate issues or requests that are no longer relevant to the project. As someone who's most intimately familiar with the tech aspects of a project, you should coordinate with the PM to close tasks that have become irrelevant so the backlog doesn't grow endlessly. When closing an issue without working on it, document the decision. Here's an example in Phoenix-Ashes.

Be Transparent and ensure your team is too

  • Communications: Lead best practices both from a technical and communication perspective (testing, coordination, etc). This includes leading in collaborating with other teams. For example: Work with Morgan to create a better debugging checklist appropriate for your application that provides key and relevant information to devops when raising a potential infra issue.
  • Documentation: Wrangle those docs! Are things documented and accessible to others outside of the team? Do you have proper onboarding documentation if a new person joined your team today, or would you basically have to provide a brain dump? Is there a basic diagram of your application’s architecture and integrations?

Ensure you're not a Blocker to the team

  • Set Aside Buffer: When taking on work, ensure you are not 100% booked. You will have additional overhead from serving as a tech lead. If you feel like you are in danger of taking on too much work, you should delegate, figure out a smaller lift implementation that gets us 80% there, or raise this issue.
  • Be Available: You are the most interruptible member on your team. Part of your responsibility is doing your best to protect your team's head's down time, and to unblock anyone who is stuck (with balance in mind; sometimes depending on the situation, it may be more appropriate, if there's time, to allow a developer to work thru a problem in order to learn/grow). Unblocking someone might mean: rubber ducking an issue, pair programming, or sometimes even finishing existing work in a branch and having a session with that developer to go over your solution.

Be your team's advocate

  • Velocity: Understand how much your team can accomplish so that your team isn't under pressure for extended periods of time unnecessarily. You, with your PM, are the leading voices for setting expectations. You should definitely help other devs on your team feel comfortable about voicing any readjustments to their estimates as well.
  • Empathy: Know your team, and understand any tensions that are arising (examples: someone feels overwhelmed/lost with the ticket assigned and is spinning and afraid to ask for help; someone is dissatisfied with the concessions/technical debt being taken on; someone is unhappy with the work they are assigned since their interests are misaligned, etc)