Here is the summary for Managing Humans, a book on software engineering management along with my interpretation and comments. Text in quote are direct excerpts from the book.
- People on your team have different needs, e.g., promotion, challenge, less stress. By filling their needs, you can make them content and productive. Your job as a leader is to listen to them and mentally document how they are wired. This is the essence of a software manager’s job.
- Manager is connector between the team and the rest of the organization. The main way for an engineer to show the work to the company is to communicate to the manager. Hence should balance external and internal focus.
- “Schedule one-on-ones with direct reports, keep them on the same day and time, and never cancel them.” One-on-ones are paramount. Keep them regular and at least 30 min. Maybe 45min is better. Not 15min. Avoid missing scheduled one-on-ones and doing status reports. Weekly is the best. These meetings are for managers to listen 50%+. If no issues, then focus on career building and needs of your reports.
- Know your boss’ place… and yours, in the food chain besides just the title of the org chart. “Politically active managers are informed managers. They know when change is afoot and they know what action to take to best represent their organization.”
- In a meeting, if someone is doing anything else except listening (open laptop? iPhone?), he is not listening. Ban laptops from your meetings altogether. Paper notebooks still work for notes (info can be digitized later), and they don’t require charging unlike laptops.
- In conflict resolution, listen to both stories. Preferably in-person not over email. People prone to unconsciously augment memory, misinterpret and twist facts to make a story in their favor. “If the story can’t stand up to the first three questions that pop into your mind, then there’s an issue”
- Two pizza team rule. With more than 10–15 direct reports it becomes extremely hard to really listen people.
- Sometimes just listening helps to vent a frustration. If communication is broken, then listen and repeat to understand.
- Meetings must have an agenda at the beginning, and a clear set of actionable steps at the end.
- Incrementalist vs. perfectionists. In a deadlock, it’s better to make an “executive” decision to move forward.
- “In the absence of information, people will create their own”. Kill gossips in your staff meetings. Don’t spread them yourself and prevent others from spreading them. Also, don’t tell too much. “As a manager, your job is that of a bullshit umbrella”.
- “The point of a performance review is not the review itself but the conversation that stems from it”. Send the report a few days in advance so it’s not a shock to the team member. Aim to mitigate any boredom and complacency by giving directions, i.e., learn Elixir.
- Speak the same language as the person you’re talking to: managerial (managementese) with other leads and technical with coders.
- Off-sites help remove day-to-day distractions and focus on strategic.
- If you want to progress as a manager, you need to stop coding while still coding but on prototypes, research, proof-of-concepts, i.e., no core products. This way you are still in the latest trends but not an impediment if you fail to deliver a critical feature or worse delivered a bug which crashed other parts (and your team had to fix it). “Stay flexible, remember what it means to be an engineer, and don’t stop developing”.
- Always allow your team to question your decisions but once the decision is made—all hands on board.
- Process must be a documentation of the engineering culture and value so it can be passed along to new members when engineers leave or company grows. Process must NOT be a way to control.
- Humans are bad at estimations. It becomes a bit better once they start working on a task.
- Project manager makes sure to ship the product; product manager makes sure that the right product is shipped; while program manager makes sure multiple (typically interelated and dependent) products are shipped, generally at the same time.
- Rotate your engineering between boring tasks like bug fixes, tests or tech debt.
- Each new engineer bring overhead of communication, decision, and error correction. (Read The Mythical Man-Month). Ensure the cultural fit. All things equal, it’s better to hire for attitude than skill. Know about strategic vs. tactical visions.
- Engineers treasure consistency, predictability, and efficiency.
- There are mechanical (data oriented) and organic (human oriented) managers. Make sure you speak with them on their level not yours.
Certain thing I didn’t agree with are:
- Multitasking: There are studies which shows multitasking and interruption is not good. As a manager often we have to multitask, i.e., be responsive over email and IM and keep the “doors” open for the team to communicate to us. Read Deep Work.
- Nerds are cute: My definition of a nerd is someone narrow minded in life, and prefers inanimate objects over humans. Merriam-Webster says nerd is unstylish and unattractive or socially inept person. Not cute at all. I believe it’s possible to be a good software engineer and not be a nerd.
- Not a disagreement, but I just had to have the third bullet point. :) The author didn’t write about remote work and keeping things remote-friendly. It’s becoming more and more prevalent and more effective to have remote members or even whole companies.
There are other gems in this book on how to focus, get into flow, optimize meetings, etc. However, these points above are all my take aways as far as engineering management.
Disclaimer: I filtered the content of the book through my own lens of experience in both tech leadership and individual contributor, so go for the real thing, i.e., buy the book and read it yourself. It has a good amount of humor as well like “Facebook – The means by which you keep in touch with people you’re trying to forget” or “Collaboration — A word used to convince you to work with people you’d rather avoid.”
One thought on “On Tech Leadership: Managing Humans Summary”