More on this book
Community
Kindle Notes & Highlights
Read between
April 3 - April 22, 2023
Managers who care about you as a person, and who actively work to help you grow in your career. Managers who teach you important skills and give you valuable feedback. Managers who help you navigate difficult situations, who help you figure out what you need to learn. Managers who want you to take their job someday. And most importantly, managers who help you understand what is important to focus on, and enable you to have that focus.
The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.
Managers usually cannot guarantee promotions, but good managers know what the system is looking for and can help you build those achievements and skills.
Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.
Her job is to do the best thing for the company and the team.
Try not to make every 1-1 about how you need something, how something is wrong, or how you want something more. When you have a problem, instead of demanding that your manager solve it for you, try asking her for advice on how she might approach the problem. Asking for advice is always a good way to show respect and trust.
The mentor gets the chance to see what it is like to have responsibility for another person, and the mentee gets an overseer who is focused on him alone, without other reports clamoring for his mentor’s attention.
Mentoring new hires is critical.
These documents should constantly evolve to meet the changes of the workplace itself. Mentoring a new hire by helping her work through the documents, and having her modify those documents with any surprises she encounters during onboarding, provides a powerful message of commitment to her.
The Alpha Geek
Alpha geeks make absolutely terrible managers, unless they can learn to let go of their identity as the smartest person in the room and most technical person on the team.
Look for someone that you believe can succeed in the role, and who wants to distinguish herself beyond her coding ability.
Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying.
The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for.
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.
They focus on the whole team’s productivity and strive to increase the impact of the team’s work product.
They are also learning how to partner effectively with product, analytics, and other areas of the business.
However, tech leads will be working on one major new technical skill: project management. The work of breaking down a project has a lot of similarity to the work of designing systems, and learning this skill is valuable even for engineers who don’t want to manage people.
Ultimately, 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.
Project management is the act of breaking a complex end goal down into smaller pieces, putting those pieces in roughly the most effective order they should be done, identifying which pieces can be done in parallel and which must be done in sequence, and attempting to tease out the unknowns of the project that may cause it to slow down or fail completely.
Hand those tasks off to the people who can actually turn them into ticket-sized work.
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.
Unfortunately, sometimes you will mis-hire a person. Having a clear set of expected goals for your new hires that you believe is achievable in the first 90 days will help you catch mis-hires quickly, and make it clear to you and to them that you need to correct the situation. Create a set of realistic milestones based on your prior hires, the current state of your technology and project, and the level of the person coming in.
A best practice in many engineering teams is to create a set of onboarding documents that are edited by every new hire as he gets up to speed.
get as much feedback as you can about the new hire’s perspective on the team in that first 90 days.
Sharell knows that this project needs to ship on time, but instead of sitting in on every meeting and tracking every detail, Sharell works with Beth to determine which meetings she should attend, and helps Beth understand which details to escalate to Sharell.
ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis. Then sit on your hands if you must, but wait a week or two to see what they give you.
they’ll remember whether their manager was with them during the stressful period, or off somewhere else, doing her own thing.
When you have a product or business head, she should be accustomed to using data about the business, the customers, the current behavior, or the market potential to justify her decisions. Start adding other data to the mix. For example, give that person data about team productivity (such as the time it takes to complete features) or data about quality measures (like how much time is spent dealing with outages, or the number of bugs found in QA or after releases). These efficiency and technical data points can be used to evaluate decisions on both product features and technical changes.
It’s kind to tell someone that his behavior in meetings is disrupting the group.
As the manager, you’re responsible for handling uncertainty and limiting how much of that uncertainty you expose to your team. Don’t be a telephone between the engineers and the rest of the company, parroting messages back and forth and distracting people who are busy with the important tasks you’ve already committed to do. But you’re not a black hole, either. Try to get a teamwide process in place for talking about new features and customer complaints, and limit estimations that occur outside of this process.
Plan to work on at least a couple of features in your first 60 days. Take a specced-out feature and add it. Pair with one of the engineers on a feature he’s working on, and have him pair with you as you start working on a feature of your own. Get your code reviewed by a member of the team. Perform a release, and do a rotation of supporting the systems for at least a couple of days if support is part of the team’s responsibilities.
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. You might write blog posts for your engineering blog, prepare conference talks, or participate in an open source project. Do something to scratch that creative itch,
If you teams can’t operate well without you around, you’ll find it hard to be promoted.
Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership. This type of positive no is a pretty hard skill for most engineers to master.
In this modern era, frequency of code change is one of the leading indicators of a healthy engineering team.
I bet if you honestly take a look at a team that isn’t releasing frequently, you’ll see cracks. The process of performing a release takes a long time. Engineers don’t feel ownership over their code quality, and they leave all of that work to a QA team, which creates a lot of back-and-forth communication delays.
I find that engineers who don’t write tests often have a harder time breaking down their work, and learning how to do test-driven development (even if they don’t actually practice that on a daily basis) can help them get better at this skill.
Incident management, when it becomes merely reacting to incidents rather than working to reduce them, can turn into a task that diminishes your team’s ability to do what they do best.
Impatience and laziness, applied to process, are the key elements to focus.
As a leader, any time you see something being done that feels inefficient, question it: Why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value faster? Can we strip down this project into something simpler and get it done more quickly?
Any manager you hire should role-play a few 1-1s as part of the interview process. One of the best ways to do this is by asking the people who would report to the new manager to interview her by asking her to help with problems they have right now, or have had in the recent past. Similar to a senior engineer being asked how he might approach debugging an issue that you just resolved, a good manager — even without a full understanding of the people or projects involved — should have good instincts for questions to ask and suggested next steps that might improve matters.
Do thorough reference checks for anyone you’re planning to bring on board, even if you’ve worked with that person before. Ask the references to describe the ways that the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again. Ask them what they love about the person, and what drives them crazy.
Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support. Take this into account in every planning session.
She spends some time sketching out this vision and presents it to the rest of the senior leadership team.
Give them space one-on-one to react, to ask questions, to get it straight from you. And as necessary, make it clear that these are the marching orders and that you need your people to be on board with the changes,
In a case where you need to get the message out to your whole organization, talk to your managers first, give them talking points, and then let them share with their teams before bringing the whole group together.
If you openly make mistakes and apologize, they learn that it’s OK to make mistakes. If you always ask the same set of questions about a project, people start to ask those questions themselves.
Write the values down if they aren’t already written, and try to be explicit.
Instead of just visualizing the level as a set of skills and attributes, the long-form ladder reads a bit like a performance review of a person operating well at each level.
