Month: July 2014

Saying “No” Systematically

Itamar, Leave a comment

“The essence of strategy is choosing what NOT to do” – Michael Porter

And this is a good article on this topic by Vijay Balanchandran:

Say ‘No’ to product ideas systematically

Vijay argues that there are three main scenarios where saying “No” to customers will create friction: when expectations are set incorrectly by sales and marketing; when a customer moves out of your target market; and when customers make niche requests that don’t represent the overall market need.

He postulates that the latter two are “ok” but the former is something that you should fix. I’d argue that whether the latter two are “ok” or not really depends on the market you’re in:  in markets where the customer has significant leverage (massive accounts, limited total number of customers, intense competition, etc.) saying “Yes” to some of the requests that fall into the latter two bucket is actually the right thing to do. Product integrity doesn’t automatically trump all other business concerns.

But what I really like in Vijay’s article is the tool that he proposes for dealing with the first issue, which I’ll term “Expanded-MoSCoW“. In MoSCoW prioritization, features are classified into four buckets: Must-have, Should-have, Can-have and Won’t-have. Vijay focuses on the last bucket and suggests expanding it to: “Never-have”, “Not-soon-enough” and “May-not-have”.

This additional clarity on what the product is NOT intended to do (not even in the future), and our level of certainty around those statements, helps set clearer expectations with both internal and external stakeholders and drives better alignment. Furthermore, it can be expanded beyond the product realm into broader conversations about corporate strategy.

What other frameworks have you used effectively for saying “No” systematically?

Advertisement
Saying “No” Systematically

The Bell Curve Is A Myth

Itamar, , 3 Comments

This following post by Josh Bersin (one of Reid Hoffman’s co-authors of “The Alliance” which I covered in the previous post) made the rounds a few months back and is still top-of-mind for me:

The Bell Curve Is A Myth

The gist: most common HR practices (performance reviews, promotions, etc.) pre-suppose a normal-distribution of performance across the employee base. However, careful studies have shown that real performance looks more like a power-distribution than a normal distribution. Many of the common HR practices “break” under those assumptions.

Bersin provides references to the academic papers that drew this conclusion, yet none of them hypothesizes why performance looks the way it does. Here’s my thesis: in the general/broader population, performance/mastery of a given skill does distribute normally. However, in almost any professional setting, we apply some sort of screening process – we intentionally try to hire the people who are “above average” (if not the top 5-10%) who are most qualified for the position. Since we don’t just pick people at random, there’s no reason to expect a normal performance distribution post-screening. We would expect to see something that resembles the right-most portion of a normal distribution – which also looks a lot like a power distribution.

These articles make a compelling case for why the current HR practices don’t make a lot of sense under these assumptions. But they fail to propose a prescriptive way to change them in the right direction.

What do you think? If we assume hat performance (at least in professional settings) follow a power-distribution, how should we change some of the key HR practices?

 

The Bell Curve Is A Myth

Tours of Duty

Itamar2 Comments

Just finished reading The Alliance by Reid Hoffman et al.

The book expands the three core concepts (tours of duty, network intelligence and corporate alumni networks) outlined in this HBR article:

Tours of Duty – The New Employer-Employee Compact

The gist: even though modern-age employment no longer means staying in a single workplace for your entire professional career, this notion hasn’t explicitly been integrated into the way employers and employees interact with one another. The dissonance between the “welcome to the family” message you get from your boss and the long pitch on at-will employment you get from HR a couple of hours later is all too common. The fact that most likely there will be a “day after company X” is not acknowledged by either side, and the relationship between them suffers as a result.

Hoffman and team offer a theory-to-practice guide on three key concepts/tools to address this disconnect:

  • Tours of Duty – Regardless of contract, structure the long-term engagement (next 2-4 years) between the employer and employee as a definitive “tour of duty” with clear objectives and milestones that benefit both sides.
  • Network Intelligence – Encourage employees to develop their professional network and tap them to solve company challenges. There are more smart people outside your company than inside your company – the math doesn’t lie 🙂
  • Corporate Alumni Networks – Build an “official” alumni network for your company and clearly define its ongoing engagement with the company. It’s a great way to leverage that talent even after it’s no longer working for the company, and it continues to reinforce the value of past employment with the company.

Overall, I found the book to be a quick and easy read. The core disconnect that it addresses is a critical one and it’s not being discussed openly enough – so this book is an important step in the right direction. All three frameworks are pretty compelling and definitely move the conversation forward.

That being said, it’s pretty clear that all three authors have drank the LinkedIn kool-aid, which weakens some of the arguments they make. It would have also been great to take the “implementation” parts of the book a bit further and deepen readers’ empowerment to drive those transformations in their orgs.

Still well worth the read!

Your turn: what do you think of the “tours of duty” concept?

update: just found this deck, which does a very good job summarizing the premise and approach covered in the book. 

Tours of Duty

Performance Reviews and Functional Overloading

Itamar, 1 Comment

Today’s topic is a bit abstract so I’ll start with a concrete example:

Earlier this year Michael Mallete gave this lovely talk at Agile Singapore:

Performance Appraisals – the Bane of Agile Teams

It’s well worth an hour of your time, but if you can’t spare it, at least skim through the slides.

Here’s the gist: performance reviews are being used for six different purposes: improve company performance, provide career guidance and coaching to employees, improve feedback and communications, manage salary and benefits, facilitate promotions and justify terminations. Since it’s stretched it six different directions, it does a very poor job supporting each of the purposes.

A typical case of “jack of all trades, master of none” / “a bird in the hand is worth two in the bush” / <insert your favorite proverb here>.  I’ve seen this pattern enough times to give it a name: functional overloading. Another common area where you often see it is the product roadmap: is it a planning tool? a marketing tool? an alignment tool?

We usually end up in these situations while having the best intentions in mind. In an attempt to keep overhead/bureaucracy to a minimum, we try to use existing practices and tools to solve new problems by slightly tweaking them. But in the process, we end up stretching them too thin and overloading them.

In the case of performance reviews, Mallete advocates for an extreme approach: go back to the basics and tailor the most effective tool/practice to each one of the different purposes that we were using the original one for. I think this may be too aggressive at times, but some fragmentation of the existing tool/process, even if it’s not to its most basic components, is probably in order.

Your turn: what are the most common tools and practices that you’ve seen get functionally overloaded?

 

Performance Reviews and Functional Overloading

Turning your team

Itamar, Leave a comment

Fred Wilson writes incredibly insightful posts about managing growth and this one is one of my favorites:

Turning your team

The gist: the skill set and type of leadership required from your executive team is a moving target that changes dramatically as the company scales.  As Fred puts it: “your first VP Sales who built your first sales team, is not likely the person who can manage a $200M quota”.

Sometimes the people in these roles can scale as quickly as the organization, but more often they can’t.  Fred really hits the nail on the head on this one as well: “Turning the team is not the same as firing someone for poor performance. It’s firing someone for doing their job too well. They killed it, and in the process got your company… to a scale that they themselves aren’t a good fit for”.

Turning your team requires bold decision making and foresight, but like any other bold decisions, it pays massive dividends when it was the right call to make.

One of the biggest challenges with effectively turning your team is detection and timing. Is the recent snafu just a hiccup? or a leading indicator that it’s time to turn a member of your team?

Would love to hear some more structured thinking/evaluation on this one. Anyone willing to share?

 

Turning your team

CTO vs. VPE

Itamar, , , Leave a comment

The difference between a Chief Technology Office and a VP of Engineering is a topic that’s been on my mind recently.

Luckily, I ran into Mark Suster’s blog post on this exact topic and it resonated well with me:

Want to know the difference between a CTO and a VP of Engineering?

The gist of it is illustrated in this simple diagram that Suster created:

suster vpe cto

 

The only important nuance that it fails to capture is that a VP of Engineering is NOT a magical creature that’s just as process oriented as a Program Manager and just as technically capable as a CTO. Her ability to straddle both domains will come at a cost of being slightly weaker on each than the pure domain expert (CTO/Program Manager).

As Suster point out, most start-ups bring on board a CTO/Chief Architect as one of their first Engineering hires, and rightfully so, since this is the more pressing need at the time. However more than a few fail to identify the point where the need for a true VP of Engineering becomes pressing, and end up over-taxing their CTOs with managerial responsibilities that they have no ability nor desire to take on.

At Opower we brought our first VP of Engineering when the Eng team was about 10-15 strong. When did you bring yours in? Is there a “magic number”?

 

CTO vs. VPE

It’s Time to Split HR

ItamarLeave a comment

I think it’s fair to say that many HR organizations struggle to keep up with the fast-paced evolution in the modern work environment. Some of the reasons for that are structural in nature: from the reputation that these organizations have and the challenges that it poses on attracting innovative talent, to CEOs failing to prioritize investment in this area as their companies scale. 

Many complain that HR is broken but few suggest ways to fix it. Well here’s one solution, proposed by Ram Charan:

It’s Time to Split HR

The gist: split HR into two separate roles:

  • HR-A (administrative) – your typical HR person, managing comp, benefits compliance etc. and reporting to the CFO. 
  • HR-LO (leadership and organization) – a high potential person from ops/finance (with real business expertise), responsible for improving the business capabilities of the company and reporting directly to the CEO. 

Will this be enough to fully “fix” HR? Probably not, but it can be a pretty big step in the right direction. 

What are your thoughts: is HR really “broken”? What are some of the other ways to “fix” it? 

 

It’s Time to Split HR