If you want to improve engineering performance, you need to stop measuring productivity. The statement sounds counter-intuitive at first, but it’s true.
Think about it for a moment – engineering exists to create products and service for the enterprise. How well it performs in that role – i.e. measuring outcomes, not activity – is the proper metric for business success. This is discussed at length in this Openview article.
But how should this shift in performance measurement be implemented? And aren’t there still reasons for tracking the activities of your engineering staff?
For some answers and example, WorkSpace Today spoke with Michael Frendo, Executive Vice President of Worldwide Engineering of Polycom. In the interview below he discusses how Polycom has changed how it facilitates superior engineering performance.
How can engineering performance be tied to outcomes, not just activities?
A big aspect of that is having an engineering department that is very cognizant of the business itself, and what of development the business requires. The goal of engineering is to develop capabilities that drive revenue and profitability for the company. When you tie engineering to business cases, when it becomes a real partnership between other business functions, that’s when tying engineering to outcomes becomes easier.
After all, those outcomes are not complex or hard to understand. Successful new product, competitive advantage, good market share that is growing – these are the outcomes you want. And it’s easy to see if they are being achieved. Unfortunately it’s easy for engineering teams to become introspective, and start to focus too much on features, timelines or code, and not the ultimate objective.
It’s also important to remember that it’s not always big projects with lots of resources behind them that generate value for the company. There are many examples of small teams of 4-5 people developing the seed of something that eventually was valued in the billions.
Can you share some examples?
Look at the story of Instagram. It was a company of eight fulltime people and some supporting contractors. They generated a company worth over a billion dollars in just a year and a half. That’s an extreme example, but a great one that points to understanding the value of the work being done, not just the cost of the work. Too often companies get caught up with cost, or think that more resources necessarily means a more valuable end product.
Here’s one closer to home. We’ve heard consistently from clients that starting a video meeting can be the most difficult and frustrating part of the process. And users don’t want to get too involved with the technology. The integration of our video end points with Outlook calendaring – the ability to schedule a meeting right in your calendar and join a call with one click – was created by a single engineer.
Incremental improvements can deliver more value faster, and smaller teams and projects also assists in “failing fast,” since not every project will be successful.
What role does collaboration with the product team play in enhancing engineering performance?
Well, when you look at the very first product developed at Polycom, it was done by a very small team. The first conference phone wasn’t a blank page revolution, but it had a couple of very innovative features that no one else was doing at the time. It created an entirely new class of product, and we implemented additional improvements over time.
It’s been a similar process with our RealPresence Trio product. When it was first introduced it was not particularly feature rich, but it delivered the best audio quality in the industry bar none. That was what the teams kept a laser focus on. Then we increased features through a series of quick cycles, using customer feedback as our guide to what features would deliver the best value for the customer, and of course profit for the company.
Here too you need to focus on the outcome you’re trying to achieve. What good are impressive features if background noise isn’t canceled out, or if it’s hard to join the meeting, or hard to share content? None of these by themselves are big undertakings, but they add greatly to the experience and come out of a focus on the outcome desired.
How does Polycom promote collaboration with remote teams?
For us, video collaboration is the norm. After all, it doesn’t matter if your colleague is in the next building or in a different country, the experience is the same. Eventually you get to know the person and can actually forget you don’t work with them in-person!
Our goal of always improving the experience with remote teams led directly to the development of our RealPresence Centro product. It’s designed specifically for teams to ideate together, brainstorm, share content and whiteboard things with the remote participants being able to see the entire room at all times, not just one person.
Outcomes are most important, but team workloads still need to be monitored. How is that done at Polycom?
That’s a good distinction, and of course we want to measure bandwidth, understand the capacity of our teams. That’s why activity levels are important to know – not for performance, but so you understand capacity. Engineering is just like every other business function – there aren’t enough resources to pursue every opportunity out there.
Reviewing activity levels can also identify potential siloes, and help you see where there are synergies across projects. Customers will always view a company’s products as a continuum, not separate pieces. In the past, we had voice, video and content end points that had slightly different user interfaces. We realized there were many commonalities, and we could be more consistent and efficient in how the development progressed.
To-do lists always contain items that can’t be addressed. Understanding activity levels helps us be more agile, prioritize efforts and focus on points of differentiation.
What role does engineering play in determining what new functionality needs to be developed?
First off, as I’ve mentioned, we use our own technology extensively inside Polycom. I don’t think this is true with some other companies. Listening to your own needs and seeing what you’d like to see developed is very instructive, since engineering is such a collaboration function by nature. You need to challenge yourself and build things that not only your customers want, but what you’d like to see created to make your own job easier.
On the customer front, we put our senior engineering people in front of customers on a regular basis, to hear from them on what they think they need. This way, our teams hear about customer stories first hand, rather than having it passed to us by others.
Things get lost in that sort of “telephone” message transmission. Don’t just be told the requirement – see why the customer thinks it’s a requirement. That’s much more powerful and efficient. The pain point gets interpreted though layers and becomes a What, not a Why. And when that happens, a chance for innovation is lost. There are many ways to solve a Why, but only one way to build a What.
For more great insights, check out our interview with Michael Frendo on adopting an Agile development methodology.)