Management Advice
One of my angel portfolio companies recently put in the investor update email:
- What books/blogs/podcasts made a big impact on how you managed people (for the better)?
I gave them possibly a longer answer than they bargained for, but the CEO suggested I turn this into a blog post, so here it is.
There’s a big mistake in management books to only read the feel-good ones like Peopleware. The hardest activity in management isn’t making people happy, it’s getting results while still making people happy. Any fool can run an unproductive work environment where everyone loves their job, and any jerk can hit delivery targets while flagellating their team into high turnover.
These things are both hard, but go to any conference or event on engineering management, and you’ll hear almost entirely about retention and engagement, and almost zero about results and productivity. This is a bad thing and needs to be actively corrected for when you go out trying to find advice on management, as most of what people want to talk about is not even the challenging part of management.
To that end, I recommend:
The Hard Thing About Hard Things by Ben Horowitz
High Output Management by Andy Grove
Keith Rabois interview on Dorm Room Tycoon as a substitute for some of the things I learned from Keith directly and indirectly at Teespring
A lot of people hate this stuff, and say they are looking to build a culture with a sustainable pace. I used to believe that, but I don’t anymore. Building a startup is an essentially heroic activity, and no $1BB company has ever been built with a sustainable pace before product-market fit. You simply have too many other disadvantages to compete while trying to pull a 40 hour work week.
There are a few prominent companies who do this. So few in fact, that every time someone wants to pull a counterexample for a great software company with a sustainable pace, they pick one of three possible examples out of the universe of successful tech startups. They are all either: small ($10MMs) companies built in a relatively short time (e.g. several years), or large ($BBs) companies built over a very long time (e.g. decades). But I don’t think you can build a $1B company in a several years that way. It always takes heroic effort.
I see two ways to commit to heroic effort:
- Hard work. You habitually work many more hours a week than is natural or comfortable.
- Crazy focus. You are absolutely relentless with triage, execution, and accountability, more than is natural or comfortable.
Every Fortune 100 tech company has done hard work exceptionally well. Some people call this survivor bias. I call it evidence. As groundbreaking computer scientist and mathematician Richard Hamming says in The Art of Doing Science and Engineering:
I regard the study of successes as being basically more important than the study of failures. As I will several times say, there are so many ways of being wrong and so few of being right, studying successes is more efficient, and furthermore when your turn comes you will know how to succeed rather than how to fail!
Crazy focus is more rare, but I have worked with people like this. One company that does this exceptionally well is Pivotal. Every Pivot has a story of bringing the Pivotal development process to a struggling team that believed they were kicking ass, working 10 hours a day, but when they went down to 8 hours while increasing their focus, they became exhausted, and hated it. I saw this many times at various clients, and I suspect these engineers only thought they were doing hard work, when they were in fact doing a lot more socializing, web browsing, etc. during their 10 hour day than they realized. This is really a worst-of-both-worlds situation, where they both weren’t spending enough time at home AND weren’t getting as much done at work as they could. This should be avoided at all costs and should not be confused with the kind of hard work that is productive.
The only thing I’d add that some of the above resources don’t talk about (and might not agree with) is that I don’t think you should be whipping people who seek more work-life balance into submitting to a startup pace of work. I think you should be selecting people (through hiring, promotion, positive/negative reinforcement, and yes — firing) who are excited about what you’re doing and realistic about the effort required to get there.
When that is done correctly, you’ll find that when there’s an opportunity to put in more work to build the company faster, they take that opportunity more often than not. That’s an internal culture you have to build, and I think many people who beat the drum of “hard work” in this conversation under-appreciate intrinsic motivation as a large component of this.
Every engineer has spent “too much” time on something, got obsessed over an idea, lost sleep, forgot to eat, to get something done…and loved it. They did it at their last job, their own startup. They did it throughout college, and in high school. The story is universal. You should create an environment where people love to learn, love to work hard, and know that bringing the mission to the world as fast as possible is better than creating it more slowly, full stop. If [your mission] is worth doing, it should be done as big and as fast as humanly possible.
Given that context, then I’d also recommend:
But I’d encourage you not to walk away from that book believing, as many managers erroneously do, that if you simply build intrinsic motivation in your team, you are doing your job as a manager. You also need to be managing results.
For that, I recommend:
A post I wrote years ago on my favorite approach to agile development
I like giving teams business-level goals and KPIs. I don’t have a great resource for that specifically (maybe I need to write one), but the Lattice blog is great in general.
There’s also a new book by John Doerr called Measure What Matters, which I haven’t read yet, but looks to be an overview of goal-setting for high growth startups, using Google’s early days as an example. I’ve heard him speak on this, and it’s compelling.
I have some opinions about how to measure not only the velocity, but the business impact of teams, but I will save that for another blog post.
