More on this book
Community
Kindle Notes & Highlights
Read between
August 7 - September 4, 2022
Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code.
My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process.
it is expected to be both a technical position and a leadership role, and that it is often a temporary set of responsibilities rather than a permanent title. So, with all that said: what is a tech lead?
The tech lead is learning how to be a strong technical project manager, and as such, they are scaling themselves by delegating work effectively without micromanaging. They focus on the whole team’s productivity and strive to increase the impact of the team’s work product. They are empowered to make independent decisions for the team and are learning how to handle difficult management and leadership situations. They are also learning how to partner effectively with product, analytics, and other areas of the business.
Tech leads are in the position to act as strong technical project leaders, and to use their expertise at a larger scale so that their whole team gets better. They can make independent decisions, and they play a big role in coordinating with other nonengineering partners that their team might have.
You can’t lead without engaging other people, and people skills are what we’re asking the new tech lead to stretch,
tech leads will be working on one major new technical skill: project management.
biggest trick of being a good tech lead: the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs.
Part of your leadership is helping the other stakeholders, such as your boss and the product manager, respect the team’s focus and set up meeting calendars that are not overwhelming for individual contributors.
Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving.
have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software.
gather input from the experts on your team,
start identifying priorities
Even if you are tempted to pull a rabbit out of the hat yourself, you must communicate this obstacle first. Your product manager should know as early as possible about any possible challenges. Enlist the help of your engineering manager as needed.
In a healthy organization, there is no shame or harm in raising issues early.
As a large project nears its delivery date, there will be compromises on functionality.
None of this means that you don’t need to understand how to do project management. You’ll have projects that for whatever reason can’t be completed in a single sprint, or even two small sprints. You’ll need to estimate project length for your management team, and give some detail on why you believe things will take that long.
I don’t even like hiring project managers because they often act as a crutch for engineers to use instead of learning to think through their future work and ask real questions about what they’re doing and why,
project management has to happen, and as tech lead, you should be doing it when it is needed,
the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens.
They each felt the frustration of the plan lacking detail, and they each went away and did the uncomfortable work of thinking about things that aren’t code, that couldn’t be perfectly predicted. And they’ve each led complex projects to successful outcomes thanks to this work, and are better equipped to build bigger systems and lead larger teams now that they understand what breaking down a project really means.
You are addressing uncertainty, trying to find the unknowns, and recognizing that you are going to make mistakes in the process and miss some unknowns despite your best efforts.
Break down the work.
Push through the details and the unknowns.
Run the project and adjust the plan as you go.
As things slip (and they always do), keep everyone apprised of the status. But now, instead of guessing how far you have to go, you can clearly point to the milestones that have been hit and outline the expected remaining work.
If requirements start to change midflight, take those insights and apply them to the changes. If the changes add significant risk to the project, necessitate a bunch of new planning, or simply require a lot of additional work, be clear about the cost of those changes.
Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it.
Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan.
If you feel like there’s plenty of purely technical learning for you to do on your team, and you’d rather work individually on this project with someone else running it, don’t take the tech lead role. If, on the other hand, you don’t think the individual work would challenge you technically, perhaps it’s time to push yourself into learning some new skills — and the skills of the tech lead are good ones to try out.
Real Life of a Senior Individual Contributor
Real Life of a Manager
Engineers who believe in the “right tool for the job” sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues with planning, focus, time management, and prioritization. They try to stop all work while they search for the perfect process, or constantly push new tools and processes on the team as solutions to the messier problems of human interactions.
The opposite of the process czar is not a manager who gives up on process completely, but rather someone who understands that processes must meet the needs of the team and the work.
It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.
If you’re only doing the most boring work, stop that, too. You’re a senior engineer who has a lot of talent as a developer, and it’s reasonable for you to take on some of the harder tasks.
You’ll be involved in most major technical decisions for your team. Involved, however, is not the same thing as being the person who makes all of them alone.
Determine which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve.
Your productivity is now less important than the productivity of the whole team.
the price of communication overhead. Instead of having every team member sit in a meeting, you represent the team, communicate their needs, and bring information from that meeting back to the team.
Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constan...
This highlight has been truncated due to consecutive passage length restrictions.
practice your writing and speaking skills. Write design documents and get feedback on them from better writers. Write blog posts for your tech blog or your personal blog. Speak in team meetings, speak at meetu...
This highlight has been truncated due to consecutive passage length restrictions.
Don’t forget to listen during all of this communication. Give others a chance to speak, and hear what they say. Practice repeating things back ...
This highlight has been truncated due to consecutive passage length restrictions.
One strategy is to ask a series of questions that are intended to help you get to know the aspects of the person that impact your ability to manage him well.
How do you like to be praised, in public or in private?
What is your preferred method of communication for ...
This highlight has been truncated due to consecutive passage length restrictions.
Why did you decide to work here? What are you excited about?
How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of?
Are there any manager behaviors that you know you hate?
Do you have any clear career goals that I should know about so I can help you achieve them?

