Leading Teams

Manager and tech leads work together to ensure engs’ tasks match their skill sets and skill levels. In smaller teams both roles could be on one person
- Most TL are ICs, and they should delegate tasks to team members, even if it means slower. Otherwise, the team is hard to grow in size and capacity
Act quickly on difficult situations, e.g., productivity, skill, and motivation, because rarely these problems will work themselves out

Identify a strategic need for the company and show how it is linked to existing priorities.
Automate your process to reduce friction
Working to build team consensus
If your team is moving quickly, sometimes it will voluntarily concede authority and direction to team leads. Even though this might look like a dictatorship or oligarchy, when it’s done voluntarily, it’s a form of consensus.

“Above all, resist the urge to manage.”
Social health of them is as important as the tech health, but harder to manage
- At the end of each one-on-one meeting, “What do you need?”
Great managers worry about what things get done (and trust their team to figure out how).
Drive consensus and set directions, and let people put the product together to figure out how it should be done
You will not get everything right, nor will you have all the answers, and if you act like you do, you’ll quickly lose the respect of your team.
Your job is to inspire, but inspiration is a 24/7 job. Your visible attitude about absolutely everything, no matter how trivial, is unconsciously noticed and spreads infectiously to your team.

Go “broad” than “Deep”.
- Loss of details
- Engineering expertise less relevant
- Depends on technical intuition and ability to move engs in good directions
Your job became less proactive and more reactive. The higher up in leadership you go, the more escalations you receive. You are the “finally” clause in a long list of code blocks!
95% observation and listening, and 5% making critical adjustments in just the right place. Listen to your leaders and skip-reports. Talk to your customers, who may not be end users out in the world, but your coworkers. Customers’ happiness requires just as much intense listening as your reports’ happiness.
Walk a fine line between “too rigid” and “too vague” team structures
A common mistake is to put a team in charge of a specific product rather than a general problem. A product is a solution to a problem. The life expectancy of solutions can be short, and products can be replaced by better solutions. However, a problem, if chosen well, can be evergreen.

More on the high level strategy. Most of the decisions are about finding the correct set of trade-offs.
To defend against “analysis paralysis”, frame your process as continuous re-balancing of trade-offs
Guide people solve difficult, ambagious problems, i.e., no obvious solution or may not even be solvable.
- See the forest, and find a path to the important trees, and let engs to chop them down
Your strategy needs to cover not just overall technical direction, but an organizational strategy as well. You’re building a blueprint for how the ambiguous problem is solved and how your organization can manage the problem over time.

Leave a trail of self-sufficient success in your wake.
“If you want something done right, do it yourself.”
Delegation is absolutely the most effective way to train them. You give them an assignment, let them fail, and then try again and try again
Unless the task is truly time sensitive and on fire, bite the bullet and assign the work to someone else, presumably someone who you know can do it but will probably take much longer to finish. You need to create opportunities for your leaders to grow; they need to learn to “level up” and do this work themselves so that you’re no longer in the critical path.