The makeup of a performance team is largely dependent on the size and complexity of the organization, its website(s), and applications. There are a number of common roles and responsibilities that need to be addressed for measuring, testing and optimizing the performance of a web property. This includes building technical, analytical and project management expertise, as well as establishing meaningful, two-way communication with the business.
But skills without commitment does not create a culture.
A strong performance culture crosses organizational boundaries. Ideally, everyone owns performance. That said, the responsibility for performance typically lies with a particular team (or teams in a larger organization), often within Ops, and sometimes made up of contract resources.
So what works and what doesn’t? How does a strong team drive performance as part of the company ethos? And what teams don’t succeed?
There are three common types of performance teams:
I’m going to use the rest of this post to explain why Reporters and Policemen are inevitably less successful, and why Collaborators are the biggest winners.
Reporters believe their responsibility begins and ends with measuring and testing, often even deferring the determination of exactly what to measure and test to others: “tell us what to do and we’ll tell you the results”.
These teams are typically on an island. They have little or no ties with development or the business. They sit in the data center and report results, rarely involved in remediation or analysis to drive continuous improvement. For Reporters, meeting a set of (sometimes seemingly arbitrary) SLAs constitutes success.
Clearly there’s value in providing visibility. But with little to no associated action, you can hardly expect this team to drive cultural change.
With more executive backing and empowerment, Policemen — not unlike Reporters — are focused on finding the data. But as opposed to being passive with the results, they use information to drive action. They understand the goals/SLAs and often have an incentive to make sure they are met, whether or not they are the RIGHT goals. As a result, they are very good at pointing out issues.
However, Policemen are not as good at helping to determine how to address issues. And even more important, they typically can’t tell you what would have the greatest impact. Again, numbers are good. It’s useful to know that your home page is slow. But it’s more useful to know that it’s slow because of a third party add on; and even more valuable to know if that’s the best area to expend resources for improvement, given the business goals of the web site.
First and foremost, successful teams have management support. Easily said, and obvious. But without a mandate across the organization, and a recognition of what poor performance can do to revenue and brand, a performance culture is impossible to build.
Assuming there is support, it is then the responsibility of the core team to drive that message throughout the organization. Again, while the company may want to establish a performance culture, that’s only possible if someone (or some team) owns it.
Here are the traits that make Collaborators so effective at driving performance throughout the company:
1. They have senior management’s agreement and support that performance is important, AND they take every opportunity to communicate what that means to the rest of the organization.
Like security, performance is impacted by everyone, from development to marketing. But these people need to know HOW they can affect performance. It’s the responsibility of the performance team to communicate how each department can help, in their language. The team must be the leading advocates for great performance!
2. They know that 80% of performance issues are a result of how the application or site is designed and built.
Catching issues early makes a massive difference in both the cost to remediate and the ultimate performance of a site. Are performance SLAs part of the design and architecture phase? Is the response time of the product search page or a particular service, for example, part of the design spec? Or is the performance part of user experience only considered once the integrated app can be tested?
3. They are consultative, with an ever-expanding understanding of everything that can improve and/or degrade performance across the entire ecosystem.
They are naturally curious, and collaborative. They work to understand the full depth and breadth of the application, website, infrastructure and architecture. They may not write code, but they can read it. They’re not DBAs, but understand the potential impact of queries, indexes and caching.
4. They educate and drive best practices into teams building and functionally testing features in development.
They may do this as part of either a center of excellence or agile team members, or both.
5. They build and buy tools to make life easier, for everyone.
They make sure teams put the right level of instrumentation in place to get the right data… particularly in an agile environment.
6. They work with release teams, development managers, test managers and other key stakeholders to create release criteria, goals and core milestones.
It doesn’t end there. They also ensure those goals and milestones are addressed, and that the right investments/tradeoffs are made.
7. They make data-driven decisions and use solid test methodology with complete transparency.
They correlate data from various teams and systems, including real user measurements, synthetic measurements, application performance monitoring tools, log files, etc. to get a complete view of performance.
8. They teach others how to fish.
But also do a lot of the fishing themselves (or at least set the hook and make it easy to ‘self-serve’).
9. They work 1:1 to address problem areas.
It’s not about sending out a list of issues and washing your hands of problems. It’s about collaborating with the DBA, architect, developer, marketer, and webmaster to come up with creative solutions.
The ideal Performance Team has some level of centralized control to drive best practices, common conventions and initiatives across the organization, even though many of the team members may be virtual: spread across the company. How and where team members report is going to be a function of the organizational structure, so care must be taken to avoid silos that fragment and impede progress.
No matter how big the team, there are a number of key roles involved in performance:
- Program Management
- Development Management
- Performance Architects
- Front-End Performance Analysts
- Performance Engineers
- Infrastructure and systems (network engineers, DBAs, etc.)
- Data Scientists
- Ops and Capacity Planning
Having worked with performance teams from hundreds of companies — ranging from one-man shops to large, cross functional teams — there is no “right” organizational structure. What is consistent in driving successful performance is ownership, passion, strong skills, organizational support and, of course, collaboration.
Okay, so you’ve bought into the importance of performance, and you’re committed to building a first-class team to drive it across the organization. Where do you start?
The first step is to understand where you are today. In my next post, I’ll talk about an Organizational Performance Maturity Index (OPMI) to help you determine the gap between your current state and reaching your performance goals.
About the Author
Dave Murphy is Senior Vice President of Delivery for SOASTA. Dave has enjoyed a varied career as a Silicon Valley executive with high tech hardware, software and distribution companies. With more than 25 years of experience leading pre-sales and professional services teams, Dave has written articles and been a featured speaker at industry events on topics ranging from networking and communications to software development best practices.