Transparency…Training…Setting Expectations

I’ve been reading The Hard Things About Hard Things the past few days by Ben Horowitz. Half-way through there is an interesting chapter called “Why Startups Should Train Their People”. The chapter is essentially a replay of a blog Horowitz wrote that talks about Good Product Managers Bad Product Managers. You can see the story here. Personally, I think the chapter should be renamed to “Why All Companies Should Train Their People…Continuously!”

Thoughts About His Blog First…

As technologists, I think we take for granted the training of our engineers and scientists. We see training as an ‘exercise’ that is done during the initial phase of on-boarding an employee to a team or a new job. Rarely is it seen as a continuous exercise. Most engineer organizations miss it big time during the on-boarding phase as well. They may spend a fair amount of time training new hires to learn the corporate policies, processes and norms. A little bit of time is spent training the engineer to get going, but mainly from an access and peripheral perspective.

Most technical managers take for granted that training is something that should be part of a continuous exercise. Just because a software developer may have years of working with an IDE (Integrated Development Environment), a source code repository like Git or SVN and a defect tracking system like JIRA or TFS, doesn’t necessarily mean that they are good to go with simply a wiki document on how to get started. The good technical managers go through the experience together with their developers to make sure they are on the right course and that the little intricacies (rarely documented) are small bumps in the road to get started and be productive.

Training is more than just getting a development environment up and running. It’s about setting a standard and defining expectations around performance and commitment to one’s craft. It’s about sharing the norms of the team culture, demonstrating them first hand and then working as a team to highlight mastery or achievement of those norms. For example, if the norm of the team is to commit code daily and the value is for transparency of work and a dedication to a quality pipeline, then what should be trained are both the norm and the value to the new team member. I call that out, because often teams will bring on new developers and have several norms in place that are poorly communicated to the new team member.

I remember that when I was more focused on Performance Engineering, the first thing I had a new team member to my team or software engineer to our development organization do was read my blog on habits good performance engineers exhibited. It was only the start of training for being on my team. I felt it was my responsibility to training all of my managers. I didn’t train all of the engineers, but every manager had to spend a fair amount of time with me so that we were really clear on expectations, as well as setting the standard that I wanted my managers to uphold.

This isn’t a one-time thing either. I felt it was important that I continuously learn and share my experiences with my team. For example, we value good engineers not just because they write elegant, reusable code, fix bugs timely and share their work. We consider them good because their constantly evolving and learning through experiences outside of their daily assignments. They are working on Open Source projects, learning new languages and collaborating with industry peers. We call them good because they are growing. The same holds true for good managers. They don’t do a set of tasks real well and repeatedly do them well. They learn about new things, technology, practice, process, etc…they experiment, share and incorporate. 

About the Article

I think anyone can replace the role or “Product Manager” with any job they want to insert. It could be “Budget Analyst” or “Software Architect” or “Release Engineer”. It really doesn’t matter from my perspective. What matters is the forethought about the beliefs Horowitz feels make up a good versus bad product manager from his own ideology lens. I don’t necessarily agree with every statement that Horowitz writes, but I do agree with the thoughts that expectations should be set. Managers and team members cannot just share the “expected” norms to a new team member without sharing the norms that detract from the team’s culture and success in the role. Being able to share both positive and negative norms are critical to establishing a stage of transparency for the team.

Ben Horowitz: Good Product Manager…Bad Product Manager

Good Product Manager/Bad Product Manager

Courtesy of Ben Horowitz

Good product managers know the market, the product, the product line and
the competition extremely well and operate from a strong basis of
knowledge and confidence. A good product manager is the CEO of the
product.  A good product manager takes full responsibility and measures
themselves in terms of the success of the product. The are responsible
for right product/right time and all that entails. A good product
manager  knows the context going in (the company, our revenue funding,
competition, etc.), and they take responsibility for devising and
executing a winning plan (no excuses).

Bad product managers have lots of excuses. Not enough funding, the
engineering manager is an idiot, Microsoft has 10 times as many engineers
working on it, I'm overworked, I don't get enough direction. Barksdale
doesn't make these kinds of excuses and neither should the CEO of a
product.

Good product managers don't get all of their time sucked up by the
various organizations that must work together to deliver right product
right time. They don't take all the product team minutes, they don't
project manage the various functions, they are not gophers for
engineering. They are not part of the product team; they manage the
product team. Engineering teams don't consider Good Product Managers a
"marketing resource." Good product managers are the marketing counterpart
of the engineering manager. Good product managers crisply define the
target, the "what" (as opposed to the how) and manage the delivery of the
"what." Bad product managers feel best about themselves when they figure
out "how". Good product managers communicate crisply to engineering in
writing as well as verbally. Good product managers don't give direction
informally. Good product managers gather information informally.

Good product managers create leveragable collateral, FAQs, presentations,
white papers. Bad product managers complain that they spend all day
answering questions for the sales force and are swamped. Good product
managers anticipate the serious product flaws and build real solutions.
Bad product managers put out fires all day. Good product managers take
written positions on important issues (competitive silver bullets, tough
architectural choices, tough product decisions, markets to attack or
yield). Bad product managers voice their opinion verbally and lament that
the "powers that be" won't let it happen. Once bad product managers fail,
they point out that they predicted they would fail.

Good product managers focus the team on revenue and customers. Bad
product managers focus team on how many features Microsoft is building.
Good product managers define good products that can be executed with a
strong effort. Bad product managers define good products that can't be
executed or let engineering build whatever they want (i.e. solve the
hardest problem).

Good product managers think in terms of delivering superior value to the
market place during inbound planning and achieving market share and
revenue goals during outbound. Bad product managers get very confused
about the differences amongst delivering value, matching competitive
features, pricing, and ubiquity. Good product managers decompose
problems. Bad product managers combine all problems into one.

Good product managers think about the story they want written by the
press. Bad product managers think about covering every feature and being
really technically accurate with the press. Good product managers ask the
press questions. Bad product managers answer any press question. Good
product managers assume press and analyst people are really smart. Bad
product managers assume that press and analysts are dumb because they
don't understand the difference between "push" and "simulated push."

Good product managers err on the side of clarity vs. explaining the
obvious. Bad product managers never explain the obvious. Good product
managers define their job and their success. Bad product managers
constantly want to be told what to do.

Good product managers send their status reports in on time every week,
because they are disciplined. Bad product managers forget to send in
their status reports on time, because they don't value discipline.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s