Good morning,
A few days ago, I posted a short blog about how my college basketball coach approached feedback. One thing I left open at the time was the question of how to apply the lesson I learned over my four years on the team to the challenges I might encounter as a budding Business Bro.
I thought Ben Horowitz shared a good example of how to approach this task in The Hard Thing About Hard Things. He helped his product managers better understand his expectations for their role with a document called ‘Good Product Manager, Bad Product Manager’. (Those interested in reviewing the document before continuing with this post should CLICK HERE.)
There are a few things that immediately stick out about the document. First is the lack of explicit instruction. This document is not designed for someone just starting out in the job – it is targeted at the seasoned professional who has mastered the basics. For the newest members of the team, I’m sure there were more appropriate materials available like process documentation, FAQs, or how-to manuals.
A less obvious but perhaps equally important feature is the way these examples do not refer to critical functions of the team. Horowitz describes how to break down a problem, the right way to communicate, or the definition of success. The direction he gives helps his team understand how to do the work, not what to do, because the question of how is really a cultural one and the challenge of creating the right culture is giving it the appropriate amount of space and time to grow.
The final feature I noted was how his notes all seemed to generalize from very specific examples yet never included the detail required to identify a specific incident or individual. It's a good example of the idea I explored in my post last week - direct criticism to the team rather than to an individual. Instead of berating a specific person for getting a report in late, the document mentions the importance of discipline and notes how getting a report done on time exemplifies a disciplined approach.
I once wrote a similar document to help set expectations for a team of analysts. It was not the polished piece of writing I aim for around even these parts (and I don’t plan on posting it any time soon). At first, the document was met with dull stares and confused follow up questions. For the newest members of the team, my effort did not make any sense because the generalized references to past errors did not resonate with them.
But I think the overall result was very effective. By creating my own version of the document, I demonstrated my resolve to set clear expectations rather than micromanage performance. The document set guidelines and defined the decisions I wanted others to make on their own. The team was a little more inclined to try and resolve their own problems and a little less likely to waste time worrying or complaining about forces beyond their control.
I struggled to describe what I saw as the most important effect from the document for a long time. I finally found the wording I needed in Fred Brooks's Mythical Man-Month. A strong team, Brooks points out, values hustle, a trait he defines as moving a little faster than necessary. Teams that do this, he points out, create cushions to absorb the impacts of unforeseen events and try to resolve errors or make up lost time on the day of the problem rather than waiting until later.
In the weeks and months after I finished the document, I noticed we were getting our error rates down and our throughput up for our various reports and data products. Although I did think the document was partly responsible, I didn’t understand exactly what the connection to it was. Brooks using the word hustle helped me see it in hinsight. Hustle is a concept I understand better.
Hustle isn’t the same thing as working hard. We were all working pretty hard. No, hustle is doing something as soon as it becomes evident it must be done. Hustle is chasing down lost causes just in case something changes during the pursuit. Hustle is setting a standard, just because, and holding ourselves to it when others would accept less.
This wasn’t always happening in my team, I thought. Perhaps our lack of hustle explained how sometimes work piled up at the back-end of a process. Or, maybe a little extra hustle would finally prepare us to work around the server-induced delays we had experienced many times before.
So, how did I go about defining hustle? I mimicked the layout of Horowitz's document and tried to list pairs of behaviors where one behavior demonstrated hard work while the other demonstrated hustle.
Getting a group together and thoroughly discussing how to change our process in response to a new contract, for example, is hard work. But reading the contract before the meeting is hustle.
Sending a professional and timely email to ask a colleague for help with an urgent issue is hard work. Picking up the phone or walking over to someone’s desk to get help right away is hustle.
Working through lunch, asking out of meetings, and turning up the headphones really loud to finish up an important project is hard work. But coming in early to do it before all the other demands of the day have sapped the energy level or sticking around later after you've kept your commitments to your colleagues is hustle.
The difference between hard work and hustle, I think, is humility. The hard worker is driven forward by a sense of agency. For this person, each reward is fully earned. Hard workers reap what is sowed. If something comes up and the work doesn’t get done, well, hey, not my problem! If everyone worked as hard as ME...
The hustler is a lot like the hard worker. But the difference is a humble acceptance of what is beyond control. Hustlers do not know any better than the hard workers what the delay is going to be. But instead of throwing up their hands and saying ‘not my fault, I worked hard!’ hustlers focus on what little remains in their control. They get the work done as early as possible so the work isn’t compromised by unseen delays. They never have a Plan B because Plan A accounts for all the contingencies.
Good teams need both of these qualities to succeed. But of the two, hustle is a much harder quality to instill in the team. This is the power of a document like ‘Good Product Manager, Bad Product Manager’. It doesn't blame an employee for being late to the meeting – it just points out how some people in the same situation, somehow, managed to arrive on time. It forces people to identify what they can’t control and makes them work on minimizing the effects of those things rather than worrying about the unpredictability of unknown events.
