Another examination of some really good observations I did not (somehow) cover in the first few posts I wrote about The Hard Thing About Hard Things.
The first was about CEO 'types'. One types loves to make complex decisions. This sort can spend an entire day thinking about strategy and gathering information. Two types enjoy making a company run well. Thinking about strategy makes the 'two type' gets antsy. However, these CEOs excel at optimizing process, creating accountability, or setting goals. Many organizations struggle when the CEO in charge is the wrong type to face the challenges facing the organization in the present moment.
The distinction reminded me of something I’ve noticed while following sports over the past two decades or so. Some coaches are like the first type. They excel at using their extensive knowledge to recruit new players and fit them into the team. Their teams become known for having strong cultures and a distinct style of play. Other coaches resemble the second type. These coaches are tactical masterminds and find ways to defeat teams boasting greater resources or talent.
The challenge for the sports teams does not differ from the one faced by any kind of organization. Most coaches tend toward one type or the other. As their strengths are applied to the team, the team starts to reflect the character of the coach. In order to remain balanced, the team will need an infusion of the other ‘type’ of leadership. At this point, the coach might become redundant if he or she lacks the skills needed to switch leadership styles. (1)
The second observation was a point about business books in general (2). Horowitz writes about how management books generally study ‘peacetime’ companies. He defines ‘peacetime’ companies as any having an edge on competitors in a growing market. They can reinforce their strengths while aiding ongoing market expansion. The other type of company is one ‘at war’. In this state, companies are fending off existential threats and doing everything in their power to survive one more day.
These conditions require radically different CEO mentalities. In peace, leaders must encourage broad creativity. In war, leaders must require obedience and alignment with a singular objective. To navigate both requires CEOs intuitively understand when to follow management principles and when to discard them (3).
So, what’s the problem with writing about peacetime companies? I have two possible answers. First, it is easy to get away with mistakes when things are going well. A writer on the outside might look at these mistakes and not understand how harmful applying the same techniques would be in any other context. Workplace quality is one such example. As The Business Bro commented in his post about this book, when things are going well, it doesn’t always matter if the company is a good place to work or not. But if the organization is in trouble, it can make the difference between success and failure because people will stay and fight for an organization they like working for.
The second reason is the fact that most businesses fail. Logically, a business will enter a ‘wartime’ situation before it fails. Having the right skills to stay afloat is required for survival; therefore, any business that still exists must have these skills (and if the the business does fail, there isn't an outwardly obvious reason to write about it). Since there are no obvious differences in survival skill among businesses that still exist, I imagine it is very challenging for a writer to determine whether one business is better equipped with survival skills than another.
Footnotes / imagined complaints
1. Some coaches get around this problem through delegation!
Delegation seems like a good solution in general. Couldn’t a CEO of the first type seek out executives of the second type? I suspect the obstacle to this approach is ego, a problem far easier to point out than resolve. If a ‘thinking’ CEO hands over certain decision-making responsibilities and the company does well, who should really get the credit?
2. And, more specifically, about Jim Collins.
Horowitz makes a couple of snippy remarks about the 'wisdom' of business books written by authors who’ve never run a business. I’ve read some of Collins’s work over the years and I'm pretty certain the comments are aimed directly at Good To Great, a book I received as a gift for my college graduation.
3. Sports, again…
The peacetime/wartime distinction brings to mind yet another sports comparison. Some teams are simply better at winning close games than others. I think a coach or a captain with a ‘wartime’ mentality leads these teams. In a close game, they quickly discard the notion of playing with creativity, flourish, or flair. They simply focus themselves and their teams on the singular task of winning the game and demand full commitment to the task from those around them.
Showing posts with label books - the hard thing about hard things. Show all posts
Showing posts with label books - the hard thing about hard things. Show all posts
Saturday, April 14, 2018
Saturday, January 13, 2018
reading review: the hard thing about hard things, part four
Over the past couple of months, I've shared examples highlighting Horowitz’s ability to cut straight to the core of an issue. Here are two other examples of the same from The Hard Thing About Hard Things.
The first example addresses contingency planning. A lot of business leaders have clear-cut contingency plans for worst-case scenarios. They know, for example, just what they would do to save the company if it were about to go bankrupt.
Well, if the best move is so obvious, why not just do it now instead of waiting to go bankrupt? In a lot of cases, figuring out how to make the move prior to reaching a true crisis is a lot better for the organization than waiting for rock bottom. And if things go well, there will be many more resources available to execute the plan than there would be if the company was running out of money.
The second example applies to firms who employ 'at-will'. Sometimes, an employee will get a new job offer and announce his or her intention of leaving a company. If the employee is a star, there will be a temptation to present a counter-offer and convince this person to stay. Deciding whether to do so is a decision that largely comes down to the individual in question and the organization’s ability to quickly fill vacated positions.
However, if a counter-offer is made, it comes with the likelihood of leaks. The employee has probably told a number of people in the organization about the new job; suddenly, things have returned to normal. Even if the employee keeps quiet, others will probably guess what happened and understand the best way to get an off-cycle raise is to generate an offer from a rival firm. As Horowitz himself points out, when a company publicly responds to squeaky wheels, it should prepare to start using a lot more grease...
The first example addresses contingency planning. A lot of business leaders have clear-cut contingency plans for worst-case scenarios. They know, for example, just what they would do to save the company if it were about to go bankrupt.
Well, if the best move is so obvious, why not just do it now instead of waiting to go bankrupt? In a lot of cases, figuring out how to make the move prior to reaching a true crisis is a lot better for the organization than waiting for rock bottom. And if things go well, there will be many more resources available to execute the plan than there would be if the company was running out of money.
The second example applies to firms who employ 'at-will'. Sometimes, an employee will get a new job offer and announce his or her intention of leaving a company. If the employee is a star, there will be a temptation to present a counter-offer and convince this person to stay. Deciding whether to do so is a decision that largely comes down to the individual in question and the organization’s ability to quickly fill vacated positions.
However, if a counter-offer is made, it comes with the likelihood of leaks. The employee has probably told a number of people in the organization about the new job; suddenly, things have returned to normal. Even if the employee keeps quiet, others will probably guess what happened and understand the best way to get an off-cycle raise is to generate an offer from a rival firm. As Horowitz himself points out, when a company publicly responds to squeaky wheels, it should prepare to start using a lot more grease...
Wednesday, January 10, 2018
hustle is hard work
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.
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.
Subscribe to:
Posts (Atom)