Thursday, December 16, 2010

Productivity

The head of my engineering department had a meeting yesterday to talk about getting from requirements to shipped product. He talked about our need to become more productive and more efficient--not because we were dogging it, but because the market place is getting more competitive. He made a couple of points that had the same clarifying effect you get when you've been knocking about in a dark room and you finally turn on the light. That "aha!, that's what I've been barking my shins on" kind of moment.

He defined just one metric for assessing the productivity of an engineering department: $/E
$ = revenue
E = number of engineering employees

The point is that any time you are exerting any kind of effort, you must ask "Is this adding value that someone will pay for?"

He also talked about efficiency, and he pointed out that there are only two ways to improve efficiency:
  • Add more value for the same amount of work.
  • Do less work for the same amount of value.
The second bullet leads to such questions as "Do we need  a 90-page PRD to build this?" and "How much detail does the programmer need in the wireframe to know what the UI needs to do?"

He did not give the following sobering example, but it is food for thought along these same lines as we go into the new year.

Let's say that your product has a profit margin of 10% and let's say an employee costs $100,000 a year.

A company would have to sell $1,000,000 of product to add $100,000 to the bottom line.

Or it could lay off that employee.

I worked for a guy who had been a colonel in the green berets. He used to describe poor performers as "So and so isn't worth their rations."

$/E

10 comments:

Potterful said...

Love the metric! I think we can also ask the question "what can we STOP doing" and reapply that time to activities that add value.

Additionally, we need to consider tracking a customer's usage of information products and using that data as potential indicators of revenue opportunities for other departments. For example, if we are able to track which customers download a video and they download three videos in a short period of time, this might indicate an opportunity for training or consulting. Or perhaps emailing them a promotion regarding training/ consulting. It's at least worth a phone call from the Account Manager to check in with the customer and see how things are going.

On a separate note,there is an interesting article re: SaaS model and scaling the business; see http://www.forentrepreneurs.com/saas-economics-2/. In the section titled "What happens if we can lower Churn?", the author talks about creating negative churn (increasing revenue per client over time via upsell/cross sell/seat expansion). So, within the context of "business problems your customer needs to solve"...the question becomes how can information products help customers and contribute to revenue over time? These are the types of considerations that will help tech comm professionals prove their "value add".

Michael Hughes said...

Eileen, your point about tying information products into revenue generators is absolutely right on. Here are a few I've encountered:
* Documentation that supports trial demos See Making the Deal
* We're working on a mobile app for our product--one of the goals is to let our sales folks have a little wow factor during a sales call
* I worked on a bill pay product once where we provided a dynamic tip to use additional features based on what features the customer was using. For example, if they paid the same vendor the same amount 3 times in a row, we suggested setting up an automated payment.

In short, any time we can get close to revenue, jump in with both feet.

BTW, here is a link to the presentation that inspired the points our director was making, a presentation by Mary Poppendieck: Presentation

Michael Hughes said...

BTW, here are three great points from Poppendieck's web site this morning

The three biggest wastes in software development are:

Building the Wrong Thing
"There is nothing so useless as doing efficiently that which should not be done at all." ~Peter Drucker

Failure to Learn
Many of our policies ~ for example: governance by variance from plan, frequent handovers, and separating decision-making from work ~ interfere with the learning that is the essence of development.

Thrashing
Practices that interfere with the smooth flow of value ~ for example: task switching, design loopbacks, technical debt, even backlogs ~ cause organizations to deliver increasing less value while using increasingly more resources.

Avi said...

I've found the Pareto principle to be a handy heuristic to dramatically improve productivity and satisfaction. But applying it entails the willingness to make hard decisions (like firing a troublesome client) and the ability to refrain from busywork.

More about the Pareto principle here:
http://www.scribd.com/doc/3664882/The-8020-Principle-The-Secret-to-Success-by-Achieving-More-with-Less

Paul said...

A PRD is an example of the organization "talking to itself" and leaving a record of its activities for future evaluation by management. If the honcho doesn't see value in a PRD, then I ask Why Not?, as in, is he/she going to remember all the relevant decisions that went into making that product (or product version) happen? If the PRD is mostly the output from a query of a Requirements Tracking/Management System, then maybe some part of its value (the redundantly published info) might be harder to justify.

And you didn't opine whether you think the honcho's definition of productivity is proper. I would say $/E is quite missing the point. Rather, it should be a measure of how efficiently (production cost plus costs of ECOs) Engineering is building what it "required" by Marketing, which in turn requires Marketing to understand what customers want/need.

Michael Hughes said...

Paul,
"Honcho?" Dealing with some authority issues?

I think the $/E metric is great because in the end it is the metric that measures what organizations survive and which ones don't.

The problem with PRDs is they have a heavy footprint and tend to be unilateral statements. The idea in Agile environments (and we are an Agile development group) is that you want to get to actionable decisions sooner and with more input. The model he was suggesting was replacing PRDs written by Product Managers with robust user scenarios written by cross-functional teams.

Same paper trail, same history, but now the documentation converts more quickly to user stories which drive the estimates and the development work.

As he put it in the meeting, we need a document that does not need to get translated into working documents (like the user stories that Agile relies on).

And from my own experience working in many different methodologies, I think he is right. These large planning documents we spin cycles on, whether they be PRDs, Documentation Plans, etc,. need to be replaced with artifacts that move us more quickly to testable, shippable product.

Paul said...

Agile seems to presume that product development is mostly from scratch, which in reality is rarely the case. (In software development, "starting over" is the best guarantee of "more bugs.") It's important to have records of "how we did it last time" so the team has the continuity of company practice as a baseline for (that is, constraint on) changing too many product development variables.

No, I'm not a fan of management these days. Look around us. Employees are cannon fodder.

Joe said...

Two issues:
First, it's not the number of people, but the cost of the talent. There are a number of company's that are willing to hire into cheap labor markets to get more people. Go into a country where salaries are 3:1 to US. If you believe it takes 2 offshore employees to equal the productivity of 1 US (admittedly a bad assumption) you would still be wise to use that market to save money. Yet your $/E number is now trending the wrong direction.

Second, the difficulty comes when companies start comparing their numbers against other companies or to different projects within their company. The revenue curve for different projects at different times of their lifecycle is very different. If we solely used the $/E metric we would never develop another new product (stretching a point to illustrate a point).

Anonymous said...

Michael Hughes alluded to jumping in with both feet when you get close to revenue. If your development costs $2,000,000 over two years from start to finish, you're a heck of a lot better off if you spend the bulk of that in the last three or four months than if you spend it in the first three or four months.

$/E is only part of the metric you should be looking at.

Michael Hughes said...

As a UX guy, I would rather be at the front end of the cycle where I can influence requirements and have real impact on design. The closer you are to launch, the more your role gets constrained to usability and putting lipstick on the pig.