MANAGING HUMANS: BITING AND HUMOROUS TALES OF A SOFTWARE ENGINEERING MANAGER

Managing Humans: Biting And Humorous Tales of a Software Engineering Manager was written by a veteran software engineering manager Michael Lopp and published on July 26th 2016. The third edition of Managing Humans: Biting and Humorous Tales of a Software Engineering Manager contains new episodes from Lopp’s experience as a manager at Apple, Pinterest, Slack and Borland. Whether you’re an aspiring manager or the current manager, there is a story in this book that will communicate to you directly and help you survive the craziness of dysfunctional bright people caught up in the chase of riches and power.

HOW THIS BOOK HELPED US

Writing code is not easy, and so is managing people. This book provided us with insight on how to manage your developing team. The book helped us understand that different people have different engineering personalities. The author also discusses approaches that help us handle conflicts between your engineers, motivate employees, build effective teams, and conduct meetings well.

THE BOOK EXPLAINED UNDER 60 SECONDS

this book is full of stories based on companies in Silicon Valley where people have been known to yell at each other. It is a place full of dysfunctional bright people in an incredible hurry to find the next big thing so they can strike it rich and then do it all over again. Among these are managers, a strange breed of people who have been given power over your future and bank account through a mystical organisational ritual. Whether you’re an aspiring manager, a current manager, or just wondering what a manager does all day, this book has a story that will speak to you.

TOP THREE QUOTES

  1. “My definition of a great manager is someone with whom you can make a connection no matter where you sit in the organisation chart.”
  2. “One of your many jobs as a manager is information conduit. The rules are deceptively simple: for each piece of information you see, you must correctly determine who on your team needs that piece of information to do their job.”
  3. “A manager’s job is to transform his glaring deficiency into a strength by finding the best person to fill it and trusting him to do the job.”

BOOK SUMMARIES AND NOTES

Part one: The Management Quiver

A large part of management is about deciphering problems. There is no better way to solve a problem than by trying it. It doesn’t matter whether you succeed or not. At least you have progress. All employees have managers, and you must figure out your manager; what does he want? How does he communicate? How does he deal with issues? After learning these lessons, you give them a try. You don’t have to succeed, but at least you’ll progress.

Don’t Be a Prick

A great manager can connect with any employee regardless of their position on the organisational chart. The people you work with tend to have vastly vast differences. Therefore, great managers have to work very hard to see and recognise employee differences. Every person you work with has a distinctive set of needs. Listening to these people and cognitively document how they’re structured is part of your professionalism. This is your most essential job. Your senior may be pushing and telling you how hitting your targets is your number one job, but you won’t write code, test it or document features. Your team will have to implement these things, and your job is to manage them.

Managers are not Evil.

The fundamental what-do-you-do disconnect between managers and employees is why employees don’t trust their managers and even find them evil. Since most managers don’t comprehend what someone is doing for their company, they’re spontaneously biased against them. And since a manager understands their job personally, they think it’s more important. Run away from any evil as soon as possible, or anyone who puts themselves before their team cannot lead and lie. If your manager is not evil, you don’t need to run. But still, you have to understand how he is built.

Stables and Volatiles

The delivery of the 1.0 launched a split in the development team into two types: Stables and Volatiles. Stables are the engineers who work happily with direction and appreciate that there seems to be a plan. They value an efficient team. They play nice with others, assess risks and conscientiously work to minimise failures regardless of the complexity and are known for their calm reliability. Volatiles are engineers who define strategy instead of acting according to it, have management issues, and perceive working with others as time wastage. Volatiles become stables by creating processes and carefully describing how things should be implemented since they have scars and experiences.

The Rands Test

The Joel Test: 12 steps to quality code. It’s a highly irresponsible and sloppy test to rate software quality. It’s a test with 12 points. A score of 12 is ideal, and 11 is bearable, but a ten and below means you have series issues. The Joel test documents the health aspects of an engineering team. Yet there are more points to be considered. An expanding team has to frequently invest in new approaches to decipher what it collectively thinks about.

The Rands Test: 11 Possible Points

  • Do you have a one-on-one?
  • Do you have a team meeting?
  • Do you have status reports?
  • Can you say “no” to your boss?
  • Can you explain the strategy of the company to a stranger?
  • Can you explain the current health of the business?
  • Does the guy/gal in charge regularly stand up in front of everyone and tell you what they are thinking? Are you buying it?
  • Do you know what you want to do next? Does your boss?
  • Do you have time to be strategic?
  • Are you actively killing the Grapevine?

How to Run a Meeting

Meetings are supposed to generate a feeling of structure, go on for an entire hour and conclude with a sense of accomplishment. Alignment and Creation meetings are essential: alignment meetings are strategic communication exchanges that hardly jump into the strategic. These meetings usually have a weekly intonation. Much as several approaches to shatter these meetings, their calculated iteration typically keeps them on the rails. Creation meetings involve more creativity to dive into solving a problem. Every complex situation calls for unique solutions, and coming up with these solutions is where creation meetings go wrong.

Favourite quote of the part: ‘Managers who don’t have a plan to talk to everyone on their team regularly are deluded.”

Part two: The Process is The Product

People mess up every day, all of us. There are unknown ruins that no one recognises but us, and the public one, the embarrassing moments where you look up, and all eyes are on you. To avoid these screw-ups, you create a process as an organised team. The objective of this process is to structure your work and get rid of guessing. A process generates an engaging and healthy tension between those who evaluate and those who create. In this tension, there are useless conflicts like pointless meetings, yelling in the hallway, etc. It would help if you avoided these conflicts much as you needed them.

1.0: The Hardest Thing to Build

As a software developer, you’ll be screwed at a certain point. And when this happens, keep thinking, don’t scream or yell, handle your workmates with decency, and everything will be fine. 1.0 is creating the first version of your new product. It’s what most startups are trying to do right now. Maslow’s theory helps you understand the difficulty of 1.0. Maslow’s theory affirms that as humans meet their needs, they seek to satisfy successively higher needs. The approach assists people on edge and offers insight when stressed out. The top of the Rands 1.0 hierarchy is the pitch or the idea. The idea is essential because it defines the structure and constraints of everything below it. With your pitch ready, you’ll have to locate people to help you build your idea. These could be your founders. They’ll build not only your 1.0 but also your engineering culture. Processes define communication. The process is how your team communicates.

The Process Myth

The assumption that engineers are genetically inclined to hate the process is incorrect. Engineers appreciate structure, order and predictability. Engineers love the process. They hate approaches that can not define themselves. A healthy process aims to define structure so that order is maintained and predictability is increased. If you look into the process, you’ll find the conditions that led the way to its necessity, how it could be awesome and your role in maintaining that awesome. The process is not generated as an approach to control but instead created as documentation of culture and values for the New Guard. With a small team, you only need a process that little since everyone knows everything and everyone.

The Old Guard: They usually comprehend the culture and the values because they have lived and experienced them.

The New Guard: They spend much time disoriented about these values because they need to be explained.

How to Start

The beginning is usually a three-phase dedication: you’re either worrying about starting, organising to begin, or starting. During the middle phase, which is preparation, you torture yourself by lying about time wastage and throwing guilt-laden words like laziness. Yet, you’re getting some work done. Your brain is usually more intelligent about thinking than you think. The several states of preparation are your brain cleverly and proactive trying to assist you. In its different forms, practice usually ends up in a bad rap. Stress is a creativity buzz kill. When stressed, you turn on your reaction and survival mode. Your mindset starts sending you signals about how to survive that situation, not an elegant solution to your problem.

Mornings have the ability of optimism since nothing has messed up your day yet. Evenings are dark, iterative reminders that no matter what you do, time will pass, and you have wasted some of it.

Taking Time to Think

To be a successful manager, you need to have well-developed react instincts. A quiver overflowing with experience gives you all kinds of approaches to problems. The timing and accuracy of some of those approaches will be excellent. Still, your quiver will steadily empty except if you take time to think. Your brain is split into two parts: the creative brain, which is the source of inspiration and the reactive brain, the part which does not like thinking because it’s messy. Thinking requires slowing down and immersing in the problem; your reactive brain thrives in such situations. Your creative brain loves the unknown. It’s always happy when it’s full of ideas. Thinking is something you can only drive by time or a meeting. There is usually no beginning or end—you never know when you’re done.

The Value of the Soak

When creating a startup, you’ll face several seemingly inconsequential decisions. Among those thousand decisions, there are five that matter. These five decisions can change the face of your company. However, it’s only possible to determine which decisions matter and which ones don’t. You might spend a lot of energy deciding on the big decisions might be, but that’s much less essential than making the decision. The soak is when you implant a seed of a thought in your brain and let it bump around in a great stew of ideas, facts and other incidental crap that seems to relate. Active soaks are undertakings you can direct and usually need stacking up content. Passive soaks are occupations where you require your brain in a random different and pray. To implement an active soak, ask simple questions to form a picture, pitch a stranger your mental concept, and then repeat. To execute a passive soak, sleep on it because your subconscious can abstract elegant solutions when you least expect them.

Favourite quote of the part: “You’ve heard the groans, and you’ve seen the rolling eyeballs and made the fair assumption that engineers are genetically predisposed to hate the process. It’s an incorrect assumption that doesn’t add up.”

Part three: Versions of You

Your team is filled with a unique set of uniquely not you individuals. Much as you’re on the same team and share the same executive goals, you are different in detail.

Bored People Quit

Boredom is more accessible to fix than the absence of belief. There are many reasons other than boredom that someone will quit. Your company might suck or be headed toward suck. This person might randomly

get an offer that fulfils their life’s dream. There is a bevvy of unpredictable reasons that someone will leave. Still, boredom is an aspect of their daily professional life you can quickly assess and fix. These are the three approaches to detecting boredom: First, you discover any alteration in the daily routine, and a decrease in productivity is a vital early sign that something’s wrong. Second, you ask, “Are you bored?” even when you don’t have the boredom feeling yet, it’s an excellent question to ask yourself and your team. You do more digging when your teammates answer the question without staring at your face. The point is to detect boredom. Third, when they tell you, listen. Usually, when someone tells you how they’re bored, they don’t do it quietly and when you least expect it. And they do. Try to listen to them and inquire from them about what you can do.

Bellwethers

Success in an interview is getting as much information as possible from the candidate. This happens by throwing a comprehensive set of interviewers at your candidate. Through their diversity of perspectives the interviewers find the correct information you can have to make a hiring decision. Interviewing is a team sport, and failing to get everyone’s view regarding a candidate is a lost opportunity to gather some random piece of perspective. It also sends an implied message to the team when Dave gets excused. In software development, this is the most superior skill that needs to be

assessed, but it’s also the one that is done the worst. Engineers are great at being technical, but they could be better at being social. This means there’s a good chance the best engineer on the team might be the worst technical interviewer because he’s uncomfortable dealing with human beings. When you send him in to determine whether your candidate knows anything about database normalisation, he will be more nervous than the candidate about asking a tricky technical question.

The Nighty-Day Interview

When you accept a new job, you are still determining who you will work with, what you will be doing, and how much (or little) you will like. Call everyone you want. Ask their opinions. Trust the fact that a good friend referred you for the gig. Your first job is to relax. Like the first day of school, you’ll overcompensate on your first day, your first week. Most people only lay their clothes out the night before they work. You’re doing this to calm yourself. Those clothes neatly laid out at the end of your bed are a visual reminder that you have control over this thing you can’t control. Take these eight steps and follow them during your first ninety days.

  • Stay late, show up early.
  • Accept every lunch invitation you get
  • Always as about Acronyms
  • Say something foolish
  • Have a drink
  • Tell someone what to do
  • Have an argument
  • Find your inner circle

Favourite quote of the part: “Your team is populated by a unique set of individuals that are distinctly not you. Yes, you’re on the same team, and perhaps you share the same professional goals, but each of you is different in the details.”

HOW THIS BOOK CAN HELP SOFTWARE DEVELOPERS

“Managing Humans” by Michael Lopp is a practical guide for leaders and managers of software development teams. The book discusses insights and strategies to effectively manage software development’s complex and dynamic nature and the people involved. It covers topics such as communication, team building, career development, and conflict resolution, all of which are critical to creating a positive and productive work environment for software developers. By implementing the strategies outlined in the book, software developers can improve their leadership skills gain a better understanding of how their managers operate and how they can effectively collaborate with their teams to achieve their goals.

DevologyX OÜ
Harju maakond, Tallinn, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Cape Town
7530

[email protected]