You're the Tech Lead! Now What?

Notes de l'éditeur

1. There is also a fourth option: You aren’t really sure what Tech Leading is.
2. You aren’t alone. There’s a lot of ambiguity around tech leading. Let’s clear some of that up right now.
3. Sometimes a job title, but often a project role.I want to differentiate a bit: It’s not the same as a product owner or project manager, though there may be overlap in responsibilities on some teams. * Product owner: is the voice of the customer and stakeholder advocate, but they don't facilitate Getting Things Done * PM: keeps the project moving forward for all team members, but does not focus on the technical implementationThe TL may or may not Code on the project or Be the most senior.
4. Different at every workplace, but these are common:Tangibles/Explicitly Assigned * Designing software architecture - Writing requirements - Interfacing with clients or management - Mentoring less-experienced developers - Dividing work amongst the team - Creating and enacting launch plansIntangibles/Incidental * Say "no" to scope creep - Set an example: in code, in leadership, in attitude - Review code - Advocating for clients or devs, as appropriate
5. If your dev will run out of tasks on Friday, you should already be thinking about it on Tuesday.If your dev needs access to an FTP to do work next week, ping the admin now. Don't wait for them to have to ask.Never let anyone hit a blocked state. That's a waste of time: not only are they not working, they will have to ramp up again mentally.It's a great sin to leave someone blocked.Cultivate a sense of helpfulness: Perceive the Need
6. It's easier to work with data. Easier to convince people, and yourself.A burndown is ammo for a "we aren't working fast enough" conversation.It makes things impersonal (so people don't feel attacked)
7. When you are TL, people are going to ask you questions. A lot. PMs, other devs, management (briefs on the project), people who used to work with you on an old project, etc.Any time someone interrupts you, you should be evaluating whether this request is something you should do right now based on your priorities and the organization's priorities. Takes 2 hours to search or 10 minutes to ask.Your job is to be interrupted now. ...sorry. Your time gets sacrificed for their productivity.You don't have to know everything, that's absurd. But you should know where to find everything. Human 301 Redirect.
8. "It's fine to admit not knowing something, but never ever as an excuse. ‘I don't know’ should burst joyfully from your lips, followed by ‘but I will find out!’" - LloydIt’s safer to ask for advice from a domain expert than to fake it and be wrong.It's okay to ask for advice. When possible, make a point to learn from it. Ex: DNS
9. Advocate for your developers, for the budget, for the user's needs, for the clients’ expectations (and all software has clients, even if they’re internal)Find the balance. Advocate for whoever is not in the room at the time.
10. To do this, you need to own the technological vision.You need to have the 10,000 ft view in your head…You need to have the whole project in your head at all times. You should be The Resource.I’m a firm believer in having (at least) one person who has an overview of the project. That is how you stop things from falling in the cracks between individual responsibilities.
11. But you're human, so you should also write lots of things down.Update project docs throughout the project. Send meeting recap emails. Send recap emails of hallway conversations where something got decided. Especially if there's a client involved-- this evidence trail can save your bacon.If your process has insufficient documentation, that's okay. Make some. Use a ticketing system to track issues, discussion, and resolutions. Do it in Evernote, if that's the best you can do. But you have to write decisions down somewhere, or you are doomed to have the same meeting over and over again.Case study: Fisdap meetings.
12. Devs: Advocate for the client. Their budget, their business processes and needs. If you don't have external clients, you can always advocate for the end user.Don't only know WHAT decisions were made, know WHY.You aren't dictating to your devs how to write their code, so they will come up with new ideas and efficiencies. And that’s awesome! You need to be prepared to vet those decisions quickly. Knowing whether to say "yes" or "no" is a factor of the budget and/or hours, and the goals of the project.Management: Advocate for your devs. Be honest and realistic about the time you need to get this done, and push for a good timeline. If you need more time to do it Right, push for that, too. You'll have to make tradeoffs, of course-- making software is always about finding a balance. You can do it right until you're blue in the face, but at the risk of never shipping. So, be realistic when discussing with management. But make sure that you walk out of those discussions with a way to make this happen.Clients: Advocate for the health of the project. Sometimes, you have to say no to their requests. Make a recommendation when you can: Don't say "no" and leave them hanging. Say "No, but". "No, but we could do it if we added 1 week and sent you a change order." "No, but there is another way to gain similar functionality, if we do it this way.And sometimes, you just have to say No. It's not in the timeline. It's not in the budget. It's too close to launch. We just cannot do that, and here's why.
13. No matter who you're talking to: Just say NO to feature creep.Keep an eye on how the devs are solving problems. There are always degrees of correctness. As developers, we will always want to do it the "most correct" way. Sometimes that's the right call, for the health of the software. But keep in mind: We always want to write reusable code, but we never want to reuse anyone else's. So sometimes, that reusable code is overengineering.
14. This is the people part of the job.
15. This is a people job. You have to talk to people, you have to know how they work. You don’t have to know already, that’s fine– that’s why you’re here. If you don’t want to work with people… sorry. You got in the wrong line of work. Making software is a human-centric pursuit.
16. You set the tone for the project. No matter how it's going, your team should feel calm, confident, and in control. Lead by example. I want every project to feel absolutely as calm as any other project. I absorb the crazy.What does this look like? Positive conversation about clients and stakeholders. Don't highlight their shortcomings for humor. When needed, use discretion-- make convos deliberate, in closed rooms, with the people who need to know. Even then, take pains to keep them from being condescending. If you're complaining, you aren't working to find a solution.Case study: Nadine (Call her Natalie.). Not "This client is so needy!" Recognize the facts of their situation.Send an "I'm on it." email immediately, and wait until you have all the facts to send another. You take the stress of an unresolved issue off your team, and you don't flood their email and attention until you definitely have something to say.Don't say things like, "This project is going off the rails." It's not helpful. Acknowledge the pain points-- and move directly to solutions.You can't solve something you haven't defined. WHAT is going off the rails? Talking to a teddy bear: Structure the problem well enough to ask for advice on it (even if you never do).At the very least, you can't get advice if you don't have a well-defined problem.If you don't do this, you can cause two problems. It creates toxicity, and at the extreme, it makes the rest of the team worry that you can't be trusted to do your job.
17. Like a manager, you live in the Tech Lead Paradox: You don't write the code, but you shoulder the responsibility for it.As a tech lead, you have a little bit of "telling people what to do" power. Don't waste it, and don't abuse it.In most companies, you don't actually have any hierarchical authority. This is actually a good thing.There have been many studies that show that external incentives (money, PTO, free cake) aren't as effective at motivating people as intrinsic motivations.In other words, people want to do their best work when they motivate themselves.
18. How do you deal with the fact that you have no control over the code?Motivating people is a huge part of the answer to this. But there are things that you can do.If something doesn't match, use it as ammo.
19. Case study: Eyebobs timeline. I was worried, no one else was.
20. Identify where the risks are. Common: Third party integrations. Other people's API's, servers, or programmers. Technologies you aren't familiar with. The newest hotness JS library your FED desperately wants to use (for the first time, on this project).Relentlessly chase down the answers.
21. One more time!Facilitate to keep the project moving forward.Advocate, keeping the big picture in mind.And motivate, to get people to do their best work.(And write everything down.)