Showing posts with label Product Management. Show all posts
Showing posts with label Product Management. Show all posts

Tuesday, October 13, 2015

Hire the best, or hire the lizards

There is a practice I have observed far too many times. And it is one of the largest killers of value at companies large and small. It is the practice of turning superstars into lizards. It actually happens. And you've likely seen or experienced it yourself.
The process goes something like this...
Company F invests significant amounts of time and money in hiring. It develops elaborate recruitment engines to find the best, most creative people. It ensures a robust interview process so only the driven and accomplished make it in the door. And it choreographs onboarding to give these rockstars what they need to deliver value.
Then it happens. Over time, and with imperceptible slowness. The perception changes. Company F starts treating these boiling frogs as the less competent, less trustworthy, versions of the people they hired. These former elites become the necessary recipients of 19th century sticks and carrots.
Sure hiring mistakes happen. But generally, these processes tend to work pretty well.
So what happened?  Did these winners actually lose their ability to deliver? Why are these superstars now looked upon as reptiles with the associated brain capacity?
Leadership. Or more accurately, a failure of leadership.
These former denizens of success were hired, in part, for the great accomplishments they've made in their careers. There is the innovative engineer who developed a method to reduce bandwidth usage by 98%. But now he has every story estimate questioned. There is the product manager who led the global launch of a consumer app to millions of customers. But now she isn't trusted to make a decision on the next two week sprint.
But the success these former heroes achieved is not a result of their own herculean efforts. It is a marriage of the person and the many factors that made up the environment in which she achieved her success.
When a flower doesn't bloom, you fix the environment in which it grows, not the flower. - Alexander den Heijer
If you expect people to achieve similar results they must have a similar environment. Your job as a leader is to craft that environment. And then empower, trust, challenge, nurture, and inspire. Otherwise, you are destroying the greatest asset your company has.
Hiring great people is hard. But if you are hiring the best people and not inspiring them, you might as well hire the lizards. It is a lot easier.

Sunday, June 16, 2013

Maybe "How do we scale Agile?" is the wrong question

For the last few years I have been hearing one basic question with increasing frequency, "How do we scale Agile?" More specifically, how do we scale agile product development for a single product across more than a handful of teams?

I can't help but wonder if we should instead be asking ourselves a different question all together: Should we scale Agile?

What Agile frameworks like Scrum point out is that it can be incredibly difficult to scale development beyond a couple teams. This has nothing to do with an inherent inadequacy of Scrum, it has to do with the fact that the communication overhead required to coordinate the activities of multiple teams increases at an exponential rate. The percentage of investment dedicated to coordination continues to rise with each additional team involved in an effort.

Maybe the first question to answer when considering how many teams to dedicate to a product is: Is increasing the size and complexity of this software development effort worth the additional value we will create for users of our software?

I have seen scarce few examples of massive development efforts that create a level of value commensurate with the size of the team building it. But maybe I just haven't been looking in the right places. What do you think?

Update 8/23/2013: Just discovered Martin Fowler's opinion (at least in 2003) about the same matter at http://martinfowler.com/articles/canScaling.html. Reminded that I need to spend even more time on his site! It is a truly great resource.

Monday, June 3, 2013

The Ticking Clock for Enterprise Software

Prediction: Enterprise software, as we know it today, will be largely dead in five years.

Specifically doomed is the model at companies like Oracle, where hitting revenue targets has become significantly dependent on the persuasiveness and drive of a sales force that is more than 50% of its total employee count (As of December 2012, Oracle's sales force was around 63,000 strong, compared to a total employee count of ~118,000). More on the larger trend in a later blog post.

Earlier this year, Oracle announced that it had missed Q3 revenue, and blamed that miss on its sales force and a lack of urgency. As a product-focused guy, it feels weird and a little scary to pin my success on my sales force's sense of urgency?


John Burke, Oracle's group vice president for global sales support and new product introductions, attributed this to his observation that "salespeople don't often know the real stories behind why their customers bought and how their customers actually use their products." They are too far removed from the software to actually know its value to users and customers. Their goals have been reduced to hitting a number, rather than delivering value to customers.

This is not a unique perspective. Former employees have echoed the same sentiment on public forums for years. Even the employees that seem to like working at Oracle betray its lack of customer-focus.


The writing is on the wall, and has been for some time. Success in enterprise software will be led by a shift in focus back to the customer and the user. Back to people wanting to use your software, rather than being convinced to. Back to driving value for customers.

If Oracle and other legacy enterprise software companies don't change their focus, there are plenty of customer-centric companies that will happily displace them in enterprise IT stacks.