More on this book
Community
Kindle Notes & Highlights
Read between
November 1 - November 15, 2020
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.
Being a tech lead is an exercise in influencing without authority.
If you want to have autonomy over your work, if you want the freedom to make choices about what you work on when, you must gain mastery over your time and how you use it.
The worst scheduling mistake is allowing yourself to get pulled randomly into meetings. It is very difficult to get into the groove of writing code if you’re interrupted every hour by a meeting.
Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving.
In the systems architect and business analyst roles, you identify the critical systems that need to change and the critical features that need to be built in order to deliver upcoming projects.
This role requires you to 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.
in the process of being a tech lead, you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others.
Good managers are looking out for talented people who could be given bigger leadership roles, but sometimes this leads them to push people away from coding before they’re ready.
It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.
Working on the less exciting parts of the code base can teach you a lot about where the process is broken.
You want to encourage others on your team to learn the entire system, and you want to give them chances to stretch themselves, but you needn’t always be self-sacrificing in what you choose to work on.
If you start to make all of the technical decisions without soliciting the input of your team, they’ll resent you and blame you when things go wrong.
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.
If one universal talent separates successful leaders from the pack, it’s communication skills.
Practice repeating things back to people to ensure you understand them.
It doesn’t matter whether you choose to dive deep into technology, or become a manager — if you can’t communicate and listen to what other people are saying, your career growth from this point on will suffer.
“new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.
Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time.
Trust and control are the main issues around micromanagement.
Autonomy, the ability to have control over some part of your work, is an important element of motivation.
When you strip creative and talented people of their autonomy, they lose motivation very quickly.
It’s important to remember that being a good leader means being good at delegating.
Continuous feedback is, more than anything, a commitment to regularly sharing both positive and corrective feedback.
every week there should be at least one thing you can recognize about someone on your team. Even better, look for something to recognize weekly for everyone who reports to you.
Many companies expect you to be acting at the next level before you get promoted to it.
The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.
being a good manager isn’t about having the most technical knowledge. The work of supporting people was far more important to management success.
Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t underestimate the value of your technical skills as you work to become a successful engineering manager.
Humans, by and large, feel good when they set small goals and meet them regularly.
if overwork is due to (in)stability of the production systems, it’s your job as the manager to slow down the product roadmap in order to focus on stability for a while.
Strong leadership cares about cultivating success and having a team that delivers successful projects, which means honing your understanding of what is important to your customer.
The engineering director is not generally expected to write code on a day-to-day basis. However, the engineering director is responsible for their organization’s overall technical competence, guiding and growing that competence in the whole team as necessary via training and hiring. They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry. They will be expected to help debug and triage critical systems, and should understand the systems they oversee well enough to perform code reviews and help
...more
The engineering director is primarily concerned with ensuring smooth execution of complex deliverables.
Due to their breadth of exposure to both technology and the business drivers, directors are responsible for guiding the goal-setting process for all of the teams in their organization, helping these teams articulate goals that support both business initiatives and technology and organizational quality.
Finally, even if you don’t intend to write much code, I strongly advise you to keep at least a solid half-day once a week completely free from meetings or other obligations, and try to use this time at least partially on some creative pursuit.
Becoming a great manager requires you to focus on the skills of management, and that requires giving up some of your technical focus.
I have found the ideas in David Allen’s book Getting Things Done1 to be useful to think about, and I recommend reading it even if you don’t adopt the whole process.
Managing your time comes down to one important thing: understanding the difference between importance and urgency.
One example of an important but not urgent task is actually preparing for meetings so that you can guide them in a healthy way.
Any sort of standard meeting that involves a group of people, whether it’s planning, retrospective, or postmortem, should have a clear procedure and expected outcomes.
If your team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer.
skipping 1-1s because you’re too busy with other things is a great way to miss the warning signs of an employee who is going to quit.
Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once.
Tasks like project planning, systems design, or being the key person during an outage are the biggest opportunity you have to grow talent on your team while also making the team run better. Strong managers spend a lot of their time developing members of their teams in these areas.
Project management. Onboarding new team members. Working with the product team to break down product roadmap goals into technical deliverables. Production support. These are all skills members of your team need to learn.
Delegation is a process that starts slow but turns into the essential element for career growth. If you teams can’t operate well without you around, you’ll find it hard to be promoted. Develop your talent and push decisions down to that talent so that you can find new and interesting plates to learn how to spin.
A lack of engagement in meetings tends to mean the team isn’t engaged by the work or do not feel like they have a say in the decision-making process.
The popular management book First, Break All the Rules2 discusses several questions you can answer to help predict team productivity and satisfaction. Among them are: Do I know what is expected of me at work? Do I have the materials and equipment I need to do my work right? Do I have the opportunity to do what I do best every day? For most engineers, the answer to these questions can be discerned by the speed and frequency with which they push code.