More on this book
Community
Kindle Notes & Highlights
Read between
September 3 - October 21, 2022
1-1s serve two purposes. First, they create human connection between you and your manager.
Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it.
Being an introvert is not an excuse for making no effort to treat people like real human beings, however. The bedrock of strong teams is human connection, which leads to trust.
The second purpose of a 1-1 is a regular opportunity for you to speak privately with your manager about whatever needs discussing.
Ideally, the feedback you get from your manager will be somewhat public if it’s praise, and private if it’s criticism.
Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.
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. The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.
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.
Especially as you become more senior, remember that your manager expects you to bring solutions, not problems.
What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals.
Your career ultimately succeeds or fails on the strength of your network.
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.
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. Marc Hedlund
One final piece of advice: try to keep notes in a shared document, with you the manager playing note taker. For each person you manage, maintain a running shared document of notes, takeaways, and to-dos from your 1-1s.
It’s important to remember that being a good leader means being good at delegating.
Taking the whole team to lunch, leaving work early on a Friday afternoon to attend a fun event together, encouraging some PG-rated humor in chat rooms, and asking people how their lives are going are all ways to cultivate team unity.
The risk of going hands-off is greatly amplified if you don’t spend enough time coding before moving into this role to get yourself deeply, fluently comfortable with at least one programming language. I advocate strongly that you spend the time to gain mastery of programming before moving into management.
It’s hard to have an agile team that doesn’t understand the value of breaking its work down into small chunks. You’ll likely need to teach this skill to new hires out of college, but even senior developers sometimes need a push here.
It can’t be said strongly enough: your peers who are not analytically driven are not stupid. On the flip side, we undermine ourselves when we fail to talk so that nontechnical peers can understand what we’re saying. Throwing out jargon to people who aren’t familiar with it — and who don’t even need to be familiar with it — makes us look stupid to them.
Be clear about code review expectations. For the most part, code reviews don’t catch bugs; tests catch bugs.
Use a linter for style issues. Engineers can waste absurd amounts of time on questions of style, specifically formatting. This should not be up for debate in code review. Decide on a style, and put that style into a linter that formats the code automatically.
Keep an eye on the review backlog. Some companies implement a limit on how many outstanding review requests a person can have assigned to him, and they block that person from requesting review when he has too many outstanding requests.
Resist the urge to point fingers and blame. It is incredibly tempting, after a stressful outage, to point fingers and ask people why they failed to foresee the consequences of their behavior. Why did they run that command on that box? Why didn’t they test that? Why did they ignore that alert? Unfortunately, this blaming only results in people being afraid to make mistakes.
Look at the circumstances around the incident and understand the context of the events. You want to understand and identify the factors that contributed to this incident.
Be realistic about which takeaways are important and which are worth dropping. Be careful not to give the impression that people need to solve every problem they identify in the course of the exercise.
The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others. The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that drive you crazy, the better off you will be.
