Makiko’s Questions

Who the hell is Makiko?

I met Makiko at Yahoo Japan and she generously helped a co-worked set up a series of meetings and was our stellar guide to the city after work.

A few weeks after we left she sent an email with questions from her engineers. I thought I’d share them for posterity’s sake (and for vanity metrics that sustain my husk).


Team vs. Individual Evaluation

How to set and measure a team vs. an individual contribution?

Teams
Teams are easier than individuals to measure. You set a goal with a timeline and measure yourself against the goal. This is as much of a test of execution as it prognostication, but a good leader needs both to get things done.

It’s your leader’s job to inform you if your goal is not ambitious enough.

Individuals
I prefer not to rank individual team members because it leads to two forms of waste.

  1. Team members optimize for the metric and not achieving the goal
  2. You waste a lot of time trying to “objectively” measure and rank people

Instead I take a satisficing approach to individual management. There isn’t much use in rank ordering individuals. It’s way more likely to cause issues instead of fix anything.

Instead I periodically hold individual meetings with team members to listen to their issues and establish a rapport. This way there is an established communication channel for them to come to me with issues. In addition, it provides a periodic forum to let them know that all is well or to discuss a perceived performance issue in private.

The lack of objective standards does open you up to the risk of favoritism/nepotism and other issues. Personally I’d rather air on the side of “unfair” than risk having the wrong performance model.

Open Source Software

When deciding if you release a project as open source or keeping it closed source, which aspects are important to you in order to make that decision?

In general:

  1. If the project is a tool I would make it open source.
  2. If the project is a product I would keep it closed source.

Your product is your team’s business. If giving your product’s source away for free isn’t part of the business strategy then there is no reason to do so.

When you develop a new tool, by making it open source you gain the benefit of free improvements through contribution (and a source of potential new hires. If your company is large enough, you may also set the industry standard for how to do X which also benefits you.

Project & Task Management

In either launching or revamping a product, what is a normal procedure to put into a task and assignment?

We hold a weekly meeting to discuss the priority for this week, explain to the team why we believe it is the priority and how we will measure success. This gives the team a chance for discussion and to voluntarily adopt the requirements.

The engineering manager and I then break up the new feature into actionable tasks for the engineers and place them in Trello so we can track their progress.

We do daily standups to make sure we are making progress towards the goal.

How did you make an ideal goal to a realistic outcome? How did your priorities and compromise the requirements? Any challenges?

Ideal goals should be used to orient the team, not to measure the team. Ideals are unachieveable and if you measure yourself against them you will always come up short and this will damage your morale.

Instead you make smaller goals that are specific, measurable and have a success/failure criteria. Use the ideal to make sure your smaller goal is aligned with the direction you want to go.

Ideals are important because it helps you prioritize features. Providing clarity on the ideal is part of being an effective leader. The ideal is your vision for the product.

“Product” manager’s skill requirements

We are still absolutely shocked that Yahoo! JAPAN don’t hold the same function of US defined “product manager”.

We want to know more details about what product manager takes in Yahoo! or US in general.

Do you have any examples or reference to define a PM’s role and skill requirements? So, we can use this for our skill development and the organization design in the future.

When we recruit for the APM program at Yahoo Oath, we look for several things:

  1. Technical ability. Although not all companies require their PMs to be technical, at Yahoo we believe that PMs that are also engineers build better products and can interact with their engineering team better.
  2. Product Sense. This is more vague, but we look for the ability to intuitively understand and articulate what is good or bad about a product.
  3. Initiative. No one will tell you what to do as a PM. So you must be able to create a vision for yourself. We look for hackathon participants, people that build their own projects on the side or are entrepreneurs.
  4. Communication. Most of the job is meeting with other people and talking. If you can’t articulate your vision then your team can’t execute it, no matter how good it might be.
  5. Analytical ability. Products are complex and a good PM must be able to break them down into smaller tasks and prioritize these tasks for their team.

That’s all folks. Time to turn this into LinkedIn click bait and see how that goes.