You're the Tech Lead! Now What?
You've been programming for a while now. You know your way around the code, and you're starting to feel kind of senior. And it looks like someone else noticed, because you're the technical lead on your next project. Congratulations! But now what? It's a big job: The technical lead can be responsible for designing software architecture, writing requirements, interfacing with clients or management, mentoring less-experienced developers, or dividing work amongst the team-- and those are just the parts of the job they tell you about ahead of time. We'll talk about how to oversee the technological vision for the project without losing sight of what's happening on the ground, how to motivate your team members without overstepping your bounds, and some tactics to deal with challenges you might not anticipate, but will almost certainly encounter.
Editor's Notes
- #2: In other words: What is our job even
- #3: Im a technical lead, so you are my people. By way of context
- #4: Arent a tech lead, but you paid to be here, so I think youre my people.
- #6: I love the first part of this especially. Sometimes a job title, but often a project role. Product Owner: voice of the customer and stakeholder, but dont facilitate GTD. Project Manager: Keeps project moving and focused, but not technical.
- #7: May or may not: code, be most senior, have formal training. Tangible responsibilities/Intangible. TANGIBLE: Design architecture, write requirements, interface with clients/mgmt, mentoring juniors, divvying work, enact/create launch plans. INTANGIBLE: Scope creep, set example, review code, advocate for clients and/or devs
- #9: Our job is to make sure other people can do their jobs.
- #10: 1. Remove roadblocks. If someone cant work, you go solve it. 2. If your dev will run out of tasks <perceive the need>. Its a great sin to leave someone blocked.
- #11: Easier to work with data. Ammo for we arent working fast enough. Makes things impersonal.
- #12: When you are TL, a LOT of people are going to ask you questions. Efficiency: 2 hours/10 minutes. Your job is to be interrupted now.
- #13: You dont have to know everything. Its okay recommended to ask for advice. * Make it learning opportunity (DNS)
- #14: For developers, users, budget, client expectations. Whoever isnt in the room.
- #15: Have the whole project in your head at all times. Be The Resource. But youre human, so you should also write everything down.
- #16: Update project docs. Send meeting recaps. Esp w/clients, save your bacon. Avoid meeting Groundhogs Day.
- #17: Dev: Advo for client/budget/business needs/end user. Mgmt: Advo for devs. Push back on timeline. But be realistic. Leave with next steps. Clients: Advo for technical realities/limits, guide them towards solutions that meet budget, feature, and timeline needs. Advo for project: Sometimes you have to say no.
- #18: There are degrees of correctness. Everyone wants to write reusable code, but we never want to reuse someone elses.
- #20: Proper leadership to help people be their best selves.
- #21: You set the tone. Team should feel calm, confident, and in control. Protect from crazy. Positive conversation about clients/stkhldrs. Blow off steam deliberately. Otherwise: toxic/mistrust. Telling people what to do power. No hierarchy; this is a good thing! Intrinsic motivation.
- #22: Favorite tactic for intrinsic motivation. Worried about someones idea? Dont tell them, make them tell you.
- #23: Like a manager There are some things you can do about this. Motivation is one.
- #25: Identify where risks are. Third-party intg., other peoples code/servers/APIs, tech you arent familiar with. Go after the unknown, the black box.
- #26: Can I be real a second?