More on this book
Community
Kindle Notes & Highlights
Read between
February 27 - July 28, 2020
Everyone’s very first experience of management is on the other side of the table, and the experience of being managed is the foundation on which you build your own management philosophy.
put a little thought into what you might actually want to discuss before your 1-1 meetings.
Beyond assigning stretch projects, though, good managers will also help you understand the value of the work you’re doing even when it is not fun or glamorous. Your manager should be the person who shows you the larger picture of how your work fits into the team’s goals, and helps you feel a sense of purpose in the day-to-day work.
Try to find people to work for who push you to succeed but also reward you for success, who inspire you to stretch yourself.
You will not get everything you ask for, and asking is not usually a fun or comfortable experience. However, it’s the fastest way forward.
She’ll be imperfect. She will say dumb things, or do things that feel unfair or harmful to you. She’ll give you work that you don’t want to do, and get annoyed when you complain about doing it.
remember that your manager expects you to bring solutions, not problems. Try not to make every 1-1 about how you need something,
Listening is a precursor to empathy,
It can be hard to remember what it was like to experience your world for the first time. How does work get done? What are the rules, spoken and unspoken? For example, you may have a standard vacation policy in the HR handbook; this is a spoken rule. The unspoken rule is that you don’t take vacation the week after Thanksgiving because you’re in ecommerce and that’s an important week for the business.
Tell your mentee what you expect from him.
Highly technical hands-on managers can be good for small teams of senior engineers, but alpha geeks are often better off kept out of management and given more of a focus on technical strategy and system design. You tend to see alpha geeks in the CTO role at technology-focused startups, where they are given a design and development focus across from an execution-focused Vice President of Engineering.
What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals.
When you need to assign a mentor for your new hire or intern, figure out what you’re hoping to achieve by creating the relationship. Then, find the person who can help meet those goals.
Emotional labor is a way to think about traditionally feminine “soft skills” — that is, skills that address the emotional needs of people and teams. Because the outcome can be hard to quantitatively measure, emotional labor is often dismissed as less important work than writing software. It’s assumed to be something that should just be provided without financial recognition. I’m not suggesting that you should pay people extra money to serve as mentors, but they need to be recognized for the work they put in, and the mentor should be treated as a first-class citizen with respect to other
...more
The project was a mess, and what did the tech lead do? He went chasing after the next refactoring, because he was sure that the problems were entirely in the way the code was structured. You probably recognize that story, because it happens everywhere. 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.
When my team at Rent the Runway created our engineering career ladder, we consciously chose to define the role of tech lead as a set of characteristics an engineer could take on at many points on the ladder, rather than a specific level. We took this tack because we wanted to recognize that, as teams change and evolve, the tech lead role may be held by many different stages of engineer, and may be passed from one engineer to another without either person necessarily changing his functional job level.
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.
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.
Being a tech lead is an exercise in influencing without authority. As the tech lead I am leading a team, but we all report to the same engineering manager. So not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work.
the 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.
From now on, wherever you go in your career, balancing is likely to be one of your core challenges.
What’s worse, you’ll often need to balance doing things you know how to do and enjoy doing, such as writing code, with things you don’t know how to do. It’s natural for humans to prefer activities they’ve mastered, so when you have to spend less time on your current talents in favor of learning new things, it’ll feel quite uncomfortable.
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.
In a healthy organization, there is no shame or harm in raising issues early. Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on.
rarely is the tech lead given an increase in salary or a title bump, and first-time tech leads often have no idea how hard the new responsibilities can be. As I mentioned in the definition of the position, many companies consider this to be more of a temporary title, a set of responsibilities you may take and shed several times in your career. It can be a stepping-stone necessary for promotion to more senior levels, but it is not usually a milestone that comes with immediate, tangible rewards.
Doesn’t agile software development get rid of the need for project management? No. Agile software development is a great way to think about work because it forces you to focus on breaking tasks down into smaller chunks, planning those smaller chunks out, and delivering value incrementally instead of all at once.
As you move forward in your career, you need to understand how to break down work that has complexity beyond the scope of what you can do as an individual.
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.
The plan itself, however accurate it turns out, is less important than spending time on the act of planning.
I’ve always been surprised how grateful senior technical managers have been when I can explain some very basic modern ideas (e.g., what’s this NoSQL stuff all about, and why should I care?) to them in a nonthreatening and noncondescending way.
educates them without making them feel small, they learn to trust my judgment and advice, and we bring about change.
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. You are addressing uncertainty,
Break down the work. Get out a spreadsheet, or a Gantt chart, or whatever works for you, and start breaking down your big deliverable (say, rewriting your billing system) into tasks. Start with the biggest pieces, then break the big pieces down into smaller pieces, then break those down into even smaller pieces.
Push through the details and the unknowns. The trick of project management is not to stop when you feel a little bit stuck, or tired of
Work through the unknowns until you really feel that there is no more value to be gained in spending time on them.
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.
I have a strong opinion on pushing people into management roles, which is that you shouldn’t do it. If you’re not ready to take on management-type responsibilities, don’t take them on.
You do set the standards for culture on your team, which is good and bad. It’s good when they take after your best aspects, and it’s bad when you realize that your team is also mirroring your faults.
Process czars struggle when they fail to realize that most people are not as good at following processes as they are. They tend to blame all problems on a failure to follow the best process, instead of acknowledging the need for flexibility and the inevitability of unexpected changes. They often get focused on easy-to-measure things, such as hours in the office, and miss the nuances that they fail to capture when focusing on the things that are easy to measure.
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
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. Learn it. Get a sense for it. Visualize it. Understand its connections, where the data lives, how it flows between systems. Understand how it reflects the products it is supporting, where the core logic for those products lives. It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.
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. On the other hand, if you make no technical decisions and leave everything up to the team, decisions that could have been made quickly can drag on without resolution.
“new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.
How do you like to be praised, in public or in private? Some people really hate to be praised in public. You want to know this.
What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback? 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? Maybe a direct report fasts for religious reasons, which sometimes makes him cranky. Maybe he always gets stressed out while on-call. Maybe he hates reviews season.
Are there any manager behaviors that you know you hate? If you asked me this question, my answer would be: skipping or rescheduling 1-1s, neglecting to give me feedback, and avoiding difficult conversations. Do you have any clear career goals that I should know about so I can help you achieve them? Any surprises since you’ve joined, good or bad, that I should know about? Things like: Where are my stock options? You promised me a relocatio...
This highlight has been truncated due to consecutive passage length restrictions.
The more senior the hire, the more he should participate in creating this plan.
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.
