Abstraction

Every so often I learn something that challenges something I’ve (almost always unconsciously) held as a fundamental truth.  For me, it was a fundamental truth that group activities such as brainstorming are more effective than individual efforts in creative exploration of an issue.

I’m sure the “fundamentalness” of this truth is largely due to the ubiquity of group think in business.  People constantly have meetings, and brainstorm, and attempt to arrive at consensus.   But it turns out that brainstorming is not only unproductive, it’s very unproductive:

Interesting article in Scientific American about a study that shows the brain is hardwired such that people fit into two behavioral categories. (More likely a continuum, but for purposes of illustration I’ll keep it straightforward).

In one category, people are predisposed to alter their behavior based on new information. In the other category, people are less responsive to new information, and tend to maintain the same behavior. Although the context of the study was political (this isn’t a political blog), I think that the study is equally interesting from a business perspective as well. A quote:

Amodio says that the anterior cingulate cortex (ACC), a forebrain region, “serves almost as a barometer for this degree of conflict.”"People who have more sensitive activity in that area,” he notes, “are more responsive to these cues that say they need to adapt their behavior,” reacting more quickly and accurately to the unexpected stimulus. On average, people who described themselves as politically liberal had about 2.5 times the activity in their ACCs and were more sensitive to the “No-Go cue” than their conservative friends.

“They are more sensitive to the need for change and more sensitive to the need to change their behavior,” Amodio says about the politically left-leaning subjects.

At an overall statistical level, I suspect that having a disposition one way or the other is not a good predictor of business success. All other things being equal, two entrepreneurs of opposite dispositions have an equal chance to succeed at the beginning of a new venture. Where it does matter is how a person copes with the unique challenges the new business will face.

For example, a person that tends to maintain the same behavior despite conflicting information may have the tenacity and drive to stick with a business plan no matter what until it succeeds. She will have the steadfastness necessary to keep the business moving forward even when everyone is a naysayer. In some business contexts, this is exactly the right person needed at the helm; the business would fail if the leader was endlessly second guessing and altering course.

On the other hand, a business plan into which people have poured blood, sweat, and tears, may be fatally flawed. In this case, the leader must be flexible enough to honestly appraise new information that conflicts with the existing business plan, and alter the course of the business based on this new information. Here, the leader that stubbornly maintained the status quo would fail.

How do you know which leader is right for which challenge? You don’t, except in retrospect. As Nassim Taleb points out, most of what happens in life is random; all you can do is put in your best effort. A person plays much less a role in their own success (or failure) than they give themselves credit for.

I’m a procrastinator. I’m a little embarrassed to say this, though I don’t consider it a personal shortcoming (I mean, I don’t think procrastinating per se makes someone an asshole). Procrastination smacks of immaturity, of unprofessional slacking. And god knows, “unprofessional” and “immature” are the absolute last things anyone would think about me .

Here’s the thing: procrastination works for me. Always has. When a deadline is close enough to begin to cause a little anxiety, I can tackle a project with a focus and flow that is harder to find when there’s no time pressure.

Imagine my surprise (and a little relief) to discover that I’ve stumbled upon a pretty effective — and clinically proven — strategy. Stress, it turns out, causes blood levels of cortisol to increase. Too much cortisol is a bad thing, but just the right amount boosts interest, attention, and motivation, producing maximum cognitive efficiency and achievement. By procrastinating until a deadline began to loom, I am creating a “sweet spot” of stress during which my performance is better than it would be had I not procrastinated.

With procrastination, though, there is a fine line separating the sweet spot from a negative downward spiral. Procrastinate too much and you risk stress levels climbing high enough to produce a feeling of outright fear. At this point, the more stress escalates, the worse mental efficiency becomes.

This cortisol “sweet spot” phenomenon has implications for leading teams. It implies that leaders must introduce gentle stress into a team to effectively motivate them, to help them reach their full potential. I say “gentle” stress to distinguish my suggestion from the stress caused by the red-faced-table-pounding behavior favored by the Steve Jobs or Larry Ellison wannabes among our corporate leaders.

“Gentle” stress means establishing specific, moderately aggressive deadlines for each project, and then frequently following up with the team member to assess how he/she is doing against the goal. Defining a deadline itself is important (work always expands to fill the amount of time available), but the (lets call it what it is) nagging creates a sense of urgency around the deadline. You are reinforcing that the deadline is meaningful, that you care about it. Creating a sense of urgency and meaning can take the team to the productivity “sweet spot.”

In a previous post I broke a taboo by expressing my feeling that “some meetings are an important, and often neglected, aspect of good management.” (Breaking a taboo, I mean, by doing anything other than denigrating the hated meeting).

And, just as everyone, I still hate meetings. Hate them. Painful. Ugh.

But I see that Tyler Cowen has something positive to say about meetings, too:

But there is good news for the legions of meeting haters: Most meetings aren’t as wasteful as they seem.

Face-to-face gatherings serve valuable if hidden functions. For example, meetings publicize information about status. Who speaks? Who finds it necessary to praise whom? Who displays a confident demeanor? Meetings help managers and employees figure out how to build necessary coalitions. They bestow social intelligence.

A good reminder of the value of consciously maintaining focus and participating within meetings. Meetings are often the primary (sometimes the only) interaction point you will have with many colleagues, particularly those hierarchically above you. Even with colleagues you see and with whom you interact every day, meetings can serve to establish lines of authority and can build (or tear down) respect among teams.

The message: no matter how painful, how redundant, or how meaningless a meeting may seem, you should focus and squeeze as much positive, productive energy as you can out of the situation. The alternative is to risk being seen negatively — no one likes a whiner or a slacker.

In the most highly stressed projects, people at all levels talk about the schedule being “aggressive,” or even “highly aggressive.” In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. “Aggressive schedule,” I’ve come to suspect, is a kind of code phrase — understood implicitly by all involved — for a schedule that is absurd, that has no chance at all of being met.

Tom DeMarco, Slack

Interesting essay from Andrew McAfee about Tom Malone’s Future of Work. Future of Work talks about how information flow was once associated with decision maker; that is, because information was expensive to gather and transmit, it was made available only to the persons that needed it to make a decision. With the emergence of internet technology, the cost of distributing information is effectively zero. With huge amounts of information available to anyone within an organization, the organization becomes more decentralized, less hierarchical.

McAfee points out a flaw in this argument, essentially saying that a general availability of information is not necessarily correlated with decentralized decision making:

Let’s say that a mortgage company realized that a few of its loan officers were just better at assessing credit risk than all the others. For whatever reasons (intelligence, experience, intuition, etc. ), they just had superior specific knowledge. In that situation, it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers. All the general knowledge (income statements, credit histories, etc.) would be sent to these few people, who would apply their specific knowledge to it and made decisions. In this example low information costs are still important; they allow all the general knowledge to be zipped to the few good officers. But the effect of low information costs isn’t decentralization and greater empowerment. Instead, it’s centralization of an important decision right and reduced autonomy for most loan officers.

Thought experiments like this one indicate to me that the net result of disappearing information costs won’t necessarily be decentralization. It will instead be the decoupling of information flows and decision rights. Organization designers will be able to allocate decision rights without worrying about how costly it will be to get required information to deciders. Leaders will be able to ask “Who should make this decision?” without adding “Keeping in mind that it’s going to be slow, difficult, and expensive to get them the general knowledge they’ll need.”

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case. I agree with him that we’re at a very interesting point in the history of technology and the economics of information, but I’d label it a great decoupling (of information flow and decision rights) rather than a broad decentralization (as decision rights lateralize along with information flows).

I’m a big proponent of making information available to anyone in an organization; I have posted before about the importance I place on an online product requirements tool and a product information wiki to encourage and enable collaboration. I do this because markets are dynamic and technology is complex, and I believe that multiple inputs on product definition is larger than the sum of it’s parts. Certainly of a much greater benefit than can result from the efforts of a single centralized product “decider.”

To me, the mortgage example given above doesn’t hold the same implications for organizations as it seems to for McAfee

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case.

I think it is true that some decisions will always be centralized because it requires tacit knowledge that only a few possess (as in the mortgage example). But strategic decisions, such as a product evolution, will always benefit from the input of multiple perspectives.

Further, efficient dissemination of information enables the development of tacit knowledge and enables contributions from persons that would otherwise not have the opportunity. In this sense, too, the mortgage example seems to fall short: common information flow enables the development and identification of more people that happen to be very good at a particular role. McAfee’s comment that

…it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers.

It’s important to place decision making responsibility in the hands of those that will make the most effective decisions. But it’s also important to nurture superior decision making skills so that the decision workflow avoids a single point of failure. Instead of taking away the decision making rights of lesser-skilled workers, why not leverage the information flow to enable a sanity check of their decisions? The burden on the more-skilled worker will not increase, and the organization benefits from growing the (forgive me) “competence footprint” associated with a particular skill.

 “Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.”
- Charles Mingus

I was thinking today of the ideal product management team structure, building on my assertion that the product management primary role is to define successful products. I tend to agree with the “Triad” structure promoted by the Pragmatic Marketing folks, in that this structure provides for a manager of each of three important elements of successful product definition: a person to guide overall strategy (in my mind this is the leader of the team), a product manager to define requirements, and a product marketer to tell the world about the product.

So far so good, but I think there’s an important role missing within the triad; namely, a person responsible for ensuring the usability and overall look and feel of the product — a product designer. This person is responsible for defining the experience of using the product, for building prototypes, for conducting usability tests, and for acting as a counterweight to the person defining the requirements. This last is particularly important as it sets up a healthy discussion within the product team, testing whether important requirements are missing (”if we don’t have a breadcrumb, the user gets hopelessly lost”), or whether existing requirements are really high priority from a user perspective (”23 options for report generation will only confuse the user, since only three types ever get used”) .

Among the most consistent experiences I’ve had over the course of my career is an organization’s consideration of user experience as a second, third, or last priority. The “hard part” is seen as the development of the features themselves, with user design seen as a trivial exercise to be addressed sometime later. Incredibly, I’ve seen a company ignore user design even after its enterprise customers refused to purchase a product because it was too hard to use.

I’ve got a theory that this attitude is a symptom of “technical bias” prevalent in high tech, which posits that writing code is hard and important, while everything else — interface design, for example, or documentation — is easier and less important. People that write code are smart, and everyone else is less so. Engineering offers real ROI, and other functions don’t contribute equal value for the money.

It’s certainly true that writing code (at least writing it well) is hard, that it takes a certain cognitive acumen to do it, and that an organization will fail without it. But it’s also true that a development team’s effort is worth nothing if people don’t buy it. Seriously, have you seen people try use a product with an interface designed by engineers? “Wow, check out them elegantly coded algorithms” just isn’t typical feedback.

Everybody hates meetings. Meetings are the bane of all office workers, denigrated as a staggering waste of time. So, duly acknowledged. But some meetings are an important, and often neglected, aspect of good management: the weekly team meeting, and (especially) the weekly one-on-one with each direct report.

In my mind, the weekly team meeting is not an individual status meeting in which the boss begins by saying a few words followed by each participant speaking in turn about their specific area. In such meetings there are two types of people: those that have not yet spoken (they are ignoring the speaker and noting what they will say when it’s their turn), and the people that have already spoken (also ignoring the speaker, they are in a state akin to catatonia waiting for the meeting to end.) Instead, the team meeting should focus on working together toward a set of common goals (or even a single goal), with the objective toward sharing progress toward the goal, obstacles, challenges, suggestions, etc. That the team is physically participating in the same meeting should not be incidental.

Individual goals and accomplishments should be discussed in a regular one-on-one. In my experience, it’s very rare that a manager will schedule these meetings. Some feel that such a meeting is a waste of time, that the close day-to-day interaction of working together is sufficient. I disagree.

One-on-one meetings enable a focus on issues that are relevant to the individual, such as progress against action items, without unnecessarily using other people’s time. They create a natural forum for coaching and mentoring, and foster an environment in which negative feedback is much easier to provide (and much easier to hear). One-on-ones should hold to an agenda so the person knows exactly what to expect. I usually start positively with general comments about how the persons activities are contributing, and bring up any negative or controversial feedback that I might want to give (and allocate time to discuss it). I then discuss the person’s specific action items and deliverables (this isn’t an opportunity to micro-manage; the emphasis is on uncovering problems that I can help solve), then invite conversation about the person’s general professional goals. I finish the meeting by invite the person to bring up any items they wish to discuss and always end with a positive remark and a “thank you.”

Particularly with many direct reports, it’s true that regular one-on-ones take a lot of time. This is the number one reason they are so often neglected — who can stomach yet more meetings?! Combined with team meetings, however, I believe the reward is significant — a greater awareness of the day-to-day activities of everyone on your team, better responsiveness to their issues, improved team “chemistry,” and greater efficiency.

At the beginning of my career, I visualized product management as a set of serial tasks. I was to conduct market research, write requirements, submit the requirements to engineering, build collateral, define pricing, train, promote, then start all over with the occasional pause for a huge promotion and fat raise.

These activities, designed to lead to product success and eventual early retirement, did not at all correlate to my actual experience. Product managers live a very non-serial life. Every activity is urgently needed at once, and there’s never enough time to do any particular activity as well as I would like. This was irritating.

If I had a better grip on best practices, I thought, or had a deeper understanding of technology, things would get less messy. I was partly right. I did need a better understanding of best practices, and my efforts to understand various technologies have paid dividends (if not royalties, as in the case of a book I wrote about the mobile internet). Sadly, the messiness continued.

In the fullness of time, however, I came to accept two fundamental truths: First, making software is hard, and you just can’t fit the process into a neat series of boxes — activities will bleed together. Second (really a corollary to the first), trying to achieve perfection in any one stage of a process will cause neglect of other stages, and is thus an enemy of success.

This means that a good strategy lies in ensuring product management activities complement one another instead of competing for time and bandwidth, and that each activity gets enough attention to achieve success.

The best single way to do achieve these goals is to have an open information policy. I ask my team to post everything (work related) they do in a wiki created for just for the product team, and I encourage everyone in the company to do the same. Product requirements are written using an online tool that everyone can access; the entire requirements-writing process is available for all to see (and comment on) in its painful glory.

In this way, my team has the benefit of everyone’s thoughts and input throughout the entire process. The engineering team is better prepared for product requirements, and can get a jump start on design and feedback. The sales team can see product direction and can provide suggestions related to their geography or to a customer. Since everything is online and updated in real time, material is immediately available to anyone who deems it “good enough” for their purpose.

Some folks think that an engineering background is a requirement for product management. I agree that technical acumen is important. But a specific degree? Experience as a developer? Nah.

Given two equally smart people, it isn’t true that the one with the MS is automatically the better product manager than the one with the MA. For one thing, and this doesn’t color my opinion at all, I don’t have an engineering background. I have a masters in Journalism and my first career was as a comedian (now retired, and no longer funny).

The notion that an engineering background is the best foundation for product management has two drivers. First, it seems to provide proof of technical chops. I suppose this is true. Thing is, though, all software efforts are unique. A background developing a software product isn’t necessarily relevant to the management of a different product. I’m more interested in experience successfully managing products that depend on different technologies than a background writing code.

Second, there’s the notion that an engineer will be more successful working with the developers that will ultimately build the product. I dunno. Claiming that a person will be more successful brokering relationships by dint of an engineering background seems a stretch to me. Besides, a product manager has to successfully form relationships with many different stakeholders. It’s not enough to be “respected” by engineering. You also have to work well with the sales organization, the marketing organization, the operations folks, and, most of all, the customer.

To me, there’s no specific background or degree that’s better or worse for a product manager. What matters is intelligence (both academic and emotional are equally important). Proven technical acumen — not a degree, but a demonstrated record of successful management of software products. A strong, palpable passion for creating products — show me a person that talks with excitement and passion about previous projects. Communications acumen — an ability to speak well in front of others, to effectively present, and to write well. Demonstrated leadership — I’m leery of candidates that break out the old saw about how the most difficult part of product management it is to “be responsible for the behavior of people over which you have no authority.”

To boil it down: hire people that are smarter than you, and that aren’t assholes.

The product management function can be described as a “bridge” between sales and engineering; responsible for helping make sales successful by providing a product that customers want to buy, and helping make engineering successful by defining the requirements for such a product.

In Silicon Valley, reqs almost always ask for “strong communication skills” and “solid writing ability,” but in the end its the acumen for technology that matters. What people ask about is whether the person is sufficiently “technical.” So how technical is technical enough?

The answer is that it depends. A product manger’s technical depth should be sufficient to enable them to innovate, to think creatively about how the technology could be used to solve customer’s problems.

Sometimes, this don’t mean a person has to be particularly technical. Web technology, for example, is mature enough for people to speak about it abstractly; to talk about features and functions without knowing or caring how it happens. A product manager for an MPLS router deployed in 10GigE networks, on the other hand, needs solid geek credentials.

A good way to gauge if a person is technical enough for a particular product management role is to ask about how they have innovated in the past. For example, in the context of your particular product, ask the candidate to “give me a couple examples where you were creative in defining product features to solve a customer’s problem, or tackle a market opportunity.”

Not only will this help you measure if the person has the appropriate technical depth, but whether they are too technical. After all, someone with a background developing compression algorithms might not be the right choice to manage a social networking site for pre-teens.

In a previous post I’ve mentioned my position that product management should not be part of an engineering department. Some folks have said that my argument is too academic and doesn’t have relevance in the real world. Fair enough. I’ll try again:

A product manager is measured by the success of the product in the market. An engineer is measured by the extent to which the developed product aligns with the requirements developed by the product manager. A product manager reporting into engineering is set up for failure: product requirements will be developed with an eye toward helping the engineering department succeed, not success in the market.

To be fair, there is one benefit of placing product management in engineering: When the company goes out of business and everyone is saying their goodbyes in the parking lot, people will feel a little better knowing that they consistently developed a product exactly according to spec.

Being a product manager is challenging. The role requires an understanding of customers, competitors, market trends, analyst opinions, and technology. It requires an ability to focus on the minute details of product requirements while simultaneously guiding those requirements in support of a high-level strategic vision. Product managers are held responsible for the actions of persons in different cross-functional teams; they are responsible when a product fares poorly, and give accolades to others when things go well.

Successfully managing a product team requires the creation and maintenance of an atmosphere in which product managers can be successful. Primarily, this means fostering a strong sense of collaboration — a certain positive chemistry. Creating an atmosphere in which the team “gels,” working together to ensure the success of all it’s members. It sounds like something of a platitude, I know. But every successful product team with which I’ve ever been involved displayed a strong degree of camaraderie.

To build such a team, I follow a basic rule: I make sure everyone I hire is smarter than I am, and I make sure they are not an asshole. A corollary to the rule: if I make a mistake and hire someone that doesn’t meet either of the two standards, I immediately help that person find a new role in which they will be more successful.

That bears repeating, although it’s the topic of another post: if you make a hiring mistake, address the mistake immediately.

Once the team is built, the challenge is to nurture and grow a team that works together in such a way as the whole is much stronger than the parts. There are many tactics to accomplish this, most of which are rely on physical proximity.

But what if you are building a team that is geographically dispersed? For example, it’s becoming quite common to lead a product team based in India, or to manage a team with members telecommuting from multiple locations worldwide. How to best build a team out of a group of such geographically dispersed people? It’s certainly possible, as is demonstrated by every open source project.

Turns out that there’s no difference between managing a geographically dispersed team and one that sits together in a bullpen. Physical proximity makes managing a team somewhat less challenging in terms of focus and effort, but the rules are the same:

1. You can’t rely exclusively on email, emailed documents, IM, and conference calls to communicate. Nor is it enough to version control documents in a CVS, subversion, or Perforce. There’s nothing wrong with these tools, but you must also implement an online collaboration tool to centralize and track communication across many different time zones. There are many, some suited to particular projects better than others. Basecamp (http://www.basecamphq.com/) is a popular commercial solution, but there are free options ranging from wiki software to combination wiki/tracking systems such as trac (http://trac.edgewall.org/).
2. Make sure people use the collaboration tool. Any tool is ineffective if it’s ignored or (worse) half-used. Getting people to use a new system is difficult; you must be prepared to insist.
3. You must have a clear, specific product strategy. What is the long term strategic goal, the vision, toward which the team is working?
4. You must have a clear, specific set of tactics to meet the goal.
5. You must have a clear idea how each team member will contribute to meeting the various tactical objectives.
6. You must make sure that every team member is clear on all of these messages. Each member of the team must be able to comfortably answer: What is our goal? How are we reaching the goal? What is my role? How will my success be measured?
7. You must carefully, daily, painstakingly, work with each member to ensure they remain clear — not only on the overall vision and tactics, but on their individual contribution.

In a global economy, geographically dispersed teams are more and more common. It takes effort to lead a such a team, but it can be done successfully.