More on this book
Kindle Notes & Highlights
Read between
May 3 - August 3, 2022
As a manager, you’ve probably heard that the one-on-one (the weekly meeting where you spend between 30 minutes to an hour with your report) is sacrosanct. A good manager knows this; a great manager lives this.
Marc Hedlund, former vice president of engineering at Etsy and Stripe, says, “Regular one-on-ones are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time.”
follow through. What is trust if not consistency over time? Be consistent, show up. Show up physically to your one-on-ones. But, more crucial, show up for your report. Did they ask you a question? Great, that’s an assignment. Go find out what you can tell them. If you can’t tell them anything, that’s fine — but close the loop.
I’m talking to your other reports about you. We strategize. That’s why when you deviate from your pattern, we’ll know. If you ask us whether we have time to chat or if a calendar event shows up with no context, we’ll worry
Remember: you control our careers and our financial prospects. A bad manager forgets this. A good one never does.
Caring is what separates a good manager from a bad one.
Here’s what works for me, in priority order: Management This includes one-on-ones, planning, interfacing with other teams, and being available to your team. Code reviews This keeps me in the loop on what we’re shipping. Architecting Performed with other engineers, I’m a sounding board and provide guidance. Fixing bugs This is the majority of my coding now. I no longer have large blocks of focused time but often have 30- to 60-minute blocks. It’s a great way to stay up to date on the day-to-day issues that your team is facing. It keeps you in touch with your codebases and it helps take some
...more
A team of people will always be more productive than you’ll ever be.
Write down a list of goals for your average week that includes both management and technical items. That might include things like one-on-ones, team meetings, or scheduling; along with planning the architecture for the next big feature and preforming code reviews. Finally, set your expectations and communicate them to your team and elsewhere. Ensure that everyone knows where your priorities are and why. This prevents miscommunication over why you aren’t handling things others might expect from you. Write these priorities down in a clear way that you can reference.
we can’t expect people to tell us everything on their minds if we keep the reasoning behind all of our decision-making a secret.
If people see that positive changes come from providing feedback, they are more likely to speak up again.
to become a team, the group needs a goal around which to coalesce.
Usually the pressure of time creates enough tension to get the group.
documents come with a cost to produce and review. If all stakeholders are happy, a decision can be resolved at a whiteboard, which is preferred. It is as stakeholder groups grow larger, or decisions more contentious, that a document’s benefits outweigh its costs.
The guide — simply a Google Docs piece titled “WELCOME, CRIS!” — listed important documents, people I should meet, and a loose set of short-, medium- and long-term plans.
a WELCOME, {HUMAN} document. Who even is your team - Your team members and their charter - Your role and expectations in that role - Where does the team’s current roadmap live? - Where does the team’s pain live? What you should be doing - What you should focus on this week - What you should focus on in your first 30 days - What I hope, as your manager, will be true 90 days from now - Here is our career ladder / review process / reasons why we fire or promote people. Who should you talk to - List of humans you’ll probably talk to every day - List of humans who can teach you important job
...more
The job doesn’t change, but the conversations do Remote work doesn’t really change the way we work with our computers or write code. However, we need to adapt in how we collaborate and bond with one another. If you’re new to working remotely, most of what you will need to work on is communication. Your expectations for documentation will increase
Your meme game will level up
Make time for each other Have some one-on-ones with no agenda that are purely social. Encourage people to mention one thing they’re grateful for as part of their daily standup. Share pictures of pets. Share pictures of lunch. Say good morning to one another when you start your day. Say good night when you’re done. Have a team coffee break during which everybody just gets on a video conference with a beverage to chat about stuff. It’s easy for remote work to feel isolating and just be about work. To build trust and psychological safety within your team, it’s essential to know who the humans are
...more
Having people meet each other face to face is important
Asking someone to take time away from home stresses caregiving and home responsibilities. Your teammates might be able to travel once or twice a year, but recognize their burden and make sure it’s worth their sacrifice. Also consider traveling to them, and rotating who goes where.
The proper tools and manners are vital Have a video conferencing tool that can handle a lot of concurrent users. Make sure everyone has a good headset with echo cancellation. Be disciplined about telling people to mute when they aren’t talking. Use good screensharing tools, like Slack Screensharing, that allow others to take control of your screen. Using screenshots in tickets or pull requests are good. Animated gifs or HTML5 video are better.
For a level playing field, if one person is on a video conference, everyone should be video conferencing.
why complaining is so useful to me as a manager: It helps you find out about problems First and foremost, complaining is an act of trust, one that gives you, the manager, the opportunity to address the issue and channel solutions. If people don’t trust you enough to complain to, you might never learn what’s wrong. It is predicated on the complainer’s experience
when someone who reports to you tells you about their experience, there’s probably some implicit feedback there that can help you improve as a manager.
It shows you what they value People usually don’t complain about things they don’t care about. So, when they complain, they are likely showing you what’s important to them.
When two people on a team complain about each other, what you’re hearing is two sides of a conflict. This is great! Now you have the information you need to help them resolve
Often when people complain, it’s because they think something is out of their control. This gives us the opportunity to help them grow their circle of influence.
Maybe they complain about some company policy, and it’s an opportunity to understand the broader reasons and implications so that you can help them to work within their constraints rather than resorting to blame.
We are often focused on the biggest and most urgent problems, but the minor complaints we hear today can be signs of the pressing problems of tomorrow. What can we learn from them? What can we get ahead of? Sometimes it’s just a helpful reminder that the most pressing problems are not evenly distributed across the team, and can help us have a sense of perspective and progress.
It might not be your biggest problem, but it is theirs, so take a deep breath, and hear them out.
We don’t call them APIs, of course. We call them “social norms,” or “culture,” or — gasp — processes
The fundamental limitation of human APIs in an organization is that they’re great for sharing information, but they’re poor for decisions. And they miss a key point — trust.
One of the most shocking and exhausting things about stepping into a leadership position for me was the sheer volume of decisions that hit me every day, and the range they encompass:
There’s no API for these decisions, and the only way I’ve found not to lose my mind is to push some of the decisions down. Does this bug merit a point release? If someone’s asking me that question, probably yes, but my question back to them is, what makes you ask? Why do you think it might, and what is stopping you from going ahead and taking that action?
No matter what the reason, dismissing or devaluing your programmer’s ideas — especially in the first few months — is a bad move. Damaged by all the naysaying, they’ll try a few more times to present their ideas differently, aiming for a successful outcome. If they continue to feel punished, though, they’ll realize that the only way to win is to not play.
And if you start a novel or a software project without a good idea of the structure, after you get about a third of the way in, you’ll find yourself in a tar pit — too many possibilities, too many threads that don’t tie together. A mess.
As an engineering manager, this means providing direction and motivation, removing roadblocks and pain points, and ensuring great communication in the team you are managing and among peers and departments. All in a sustainable way. Bonus points if you improve any of these areas.
Rather than relying on social influence, you can use your engineering expertise to sway your peer. The best result for the company here is a merit-based debate of the options, not a favor to a friend.
