Taking care of people
In the last year, a small team lost three developers. It's been a blow: the loss of productivity, the time invested into training, the relationships, the cost of upcoming hiring. I'm not a manager, yet I'm wondering: could the leaving have been prevented?
Since I don't have direct experience, I reached out to the book by Ben Horowitz. Ben was a cofounder and CEO of Opsware which was sold to Hewlett-Packard for $1.6b. He is now an investor and a board member Medium, DataBricks, and others. What I like about Ben is his writing style: no-BS, no sugar-coating, just telling things straight how they are.
In the book, Ben explains a key strategy: take care of the people, the products, and the profit, in that order. After seeing the three developers leave, I see now why people are put first. Without the three developers, there is nobody to improve the product, nobody to help increase profits. It doesn't matter how well we execute on our vision, or what our development methodology is, or what's the quality of the codebase—if there's nobody, the execution is gone.
So how one takes care of people? In the book, Ben mentions a tactic that he deeply believes in: one-on-ones.
Generally, people who think one-on-one meetings are a bad idea have been victims of poorly designed ones. The key to a good one-on-one meeting is the understanding that it is the employee’s meeting rather than the manager’s meeting. This is the free-form meeting for all the pressing issues, brilliant ideas, and chronic frustrations that do not fit neatly into status reports, email, and other less personal and intimate mechanisms.
If you are an employee, how do you get feedback from your manager on an exciting but only 20 percent formed idea that you’re not sure is relevant, without sounding like a fool? How do you point out that a colleague you do not know how to work with is blocking your progress without throwing her under the bus? How do you get help when you love your job but your personal life is melting down? Through a status report? On email? Yammer? Asana? Really? For these and other important areas of discussions, one-on-ones can be essential.”
—Ben Horowitz, from The hard things about hard things
Thinking on the topic, this thought by Lao-tzu is coming to mind: "Eliminate problems at their beginning, when they are weak." So all in all, it seems that one-on-ones, if meant well and done regularly, are fundamental to a well-functioning team.
Regarding the agenda for one-on-ones, Ben stresses that it is an employee's meeting, not the manager's meeting. The employee should do most of the talking, the manager listens. If the conversation needs a kick, here are questions that Ben found effective:
- If we could improve in any way, how would we do it?
- What’s the number-one problem with our organization? Why?
- What’s not fun about working here?
- Who is really kicking ass in the company? Whom do you admire?
- If you were me, what changes would you make?
- What don’t you like about the product?
- What’s the biggest opportunity that we’re missing out on?
- What are we not doing that we should be doing?
I've noticed the questions have two things in common: raw interest to improve, and humility.
There's another point I'm wondering about. What if a manager knows that one-on-ones are important, yet she is flooded with other work and simply doesn't have time?
What if we frame the problem of priorities as a conflict between the manager and manager's manager (or manager's stakeholders)? Let's say the manager values one-on-ones, but the manager's manager needs the IT budget to be done on time. Is there a way to resolve this conflict of differing needs?
It turns out there is a communication tactic that can be effective in this situation: The NonViolent Communication (NVC), invented by Marshall Rosenberg. Marshall used the tactic to resolve conflicts that range from a long-term marriage grudge to a violent war between two African tribes. Reportedly, NVC was the first book Satya Nadella asked his executives to read when he took over as a Microsoft CEO back in 2014.
I first read NVC around a year ago and I've been since learning it. I'm delighted to report that although it's been challenging, the effort brings fruits. In most cases, when I manage to communicate my needs clearly, without judging and without evaluating, the needs are met.
Thanks to Peter for his feedback on the drafts of this post.
- ← Previous post: EC2 Application Load Balancer: Identifying clients by user-agents
- → Next post: Tackling confusion with spreadsheet tables
This blog is written by Marcel Krcah, an independent consultant for product-oriented software engineering. If you like what you read, sign up for my newsletter