Just the other day, Jeremy Keith wrote that problems with performance work isn’t only a matter of optimization and fixing code, but also tackling people problems:
It struck me that there’s a continuum of performance challenges. On one end of the continuum, you’ve got technical issues. These can be solved with technical solutions. On the other end of the continuum, you’ve got human issues. These can be solved with discussions, agreement, empathy, and conversations (often dreaded or awkward).
I think that, as developers, we tend to gravitate towards the technical issues. That’s our safe space. But I suspect that bigger gains can be reaped by tackling the uncomfortable human issues.
This was definitely shocking to learn when I joined a company a few years ago and found that there was a mountain of performance work that I couldn’t do alone. I started trying to teach folks about performance, as well as holding office hours and hopping onto projects and teams that needed help. But I realized that all this work didn’t help. The website I was working on in my spare time was getting slower, despite my best efforts.
Frustrated and exhausted, one day I sat back in my chair and realized that I couldn’t do all this work alone. The real problem was this: there’s no incentive for folks to care. If performance magically improved by ten thousand percent, no one in the company would have noticed. Customers would have noticed, but we all probably wouldn’t have. Except me, because I’m a nerd.
In Ethan Marcotte’s latest talk, he describes this people problem when it comes to design systems:
Creating modular components isn’t the primary goal or even the primary benefit of creating a design system. And what’s more, a focus on process and people always leads to more sustainable systems.
Design systems are about good, quality front-end code just like performance is, too. But if people within an organization are not incentivized to use the components within a library or talk to the design systems team, then that’s where things quickly get bonkers.
I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.
The most obvious incentives are money and performance ratings, or even hiring a person or team dedicated to this particular line of work. Improving visibility into performance problems and celebrating big wins is another thing that can be done to shift the balance and make folks care more about this whole new area of expertise. But these things really have to come from the top down; not from the the bottom up. At least that’s been true in my experience.
My point here is that there’s no single solution to fix the incentive problem in large organizations. It sounds silly, but in order to make that website, the biggest hurdles to overcome are those incentives. If no one cares about performance work today, then shouting and screaming and being a jerk about it won’t help at all.
Trust me, I have been that jerk.
That is true.
The question is: what is possible to do about it?
I don’t even feel that logic works here.
Performance is important for the company. But still, there are always other priorities, other problems, and sometimes just plain resistance and neglection.
So what is possible to do?
Build personal relations and trust with every person you work to convince them? It is hardly possible, especially having in mind our gravitate towards technical issues. Because convince people in anything is hard.
I often say this.
Doing the actual work is easy… satisfying all the people along the way is the hard part.
First: we need to track performance.
Using lighthouse or webpagetest, analysing the page and tracking the metrics over time.
Or even better, using web vitals or a RUM solution.
Second: put this metrics with the other metrics. Look for correlations with business metrics like bounce rate, conversions, session length, etc.
If you can demonstrate that performance issues correlates with business issues, there will be more people on board with fixing it.
Achieving this alignment could make easy convince people on the importance of performance.
Um, just tie performance to dollars. There’s an Amazon story about milliseconds and likelihood of converting sales out there, should be easy.
I think you hit the nail on the head Robin with the sentence “The real problem was this: there’s no incentive for folks to care.” That problem, lack of incentive for caring, is at the core of most ‘people problems’. And of course, the problem is different at different companies and at different times because people dynamics change over time. Think about it for a moment. When a company hires its employees, other than wanting a “job”, does it try to ascertain the candidates motivation for wanting to work at the company? Most employees want to do a good job and contribute to make the end-result better, and often money is not necessarily at the core of their motivation to work at a particular job. But we’re all human, too. And unless a person is so desperate to have a job, which is not unusual especially now, having what I’d characterize as a dedicated approach can wear thin quickly. This can occur if one has no control of their work and is often 2nd guessed by their manager – the “BOSS” – or someone else. It can often help if individuals have a stake in their work which in turn has a direct effect on their success in the company. That often means doing more important work and getting recognition for good work, increased responsibilities, and even pay incentives if the company can afford that. And the other side of this issue is to have sensitive and “caring” managers that understand how to successfully motivate the people that work for them. Fear, such as fear of loss of a job if performance is poor, or some other negtive motivation, is of course a motivator, but it’s not the best. Tapping into what makes one want to do better work is a better approach and that’s part of the skill-set managers need, but all too often, they do not. It’s a tough issue to crack but worth the effort to do so.
Thanks for writing this up Rendle, and I hope I can contribute something here with some wise East mystical words;
There needs to be a balance between the monozukuri, the making of things, and the hito-zukuri, the making of people, because each need their own maintenance and one cannot make without the other.
In short, I believe design systems have two problems; technical consistency and perceptual consistency. Your system can be technically perfect for your customer yet people who work with it see it differently; they might think it sucks for them or that it takes away doing their job “like normal”.
In reverse you can also have your customer completely fooled your design system is absolutely splendid (Stripe dev-tweet) by being seeing the perceptual consistency of “the system”, yet under the hood the engineer is completely convinced it’s “a mess”.
So my parting thought; “Technical problems are easy to solve, Perceptions are really hard”