The Resident Expert
What’s a “resident expert”?
I came across the idea of a “resident expert” during Alessandra Moreira’s excellent talk at Let’s Test – The DIY Guide to Raising the Test Bar (slides here). She was talking about the fact that you do not need to be an expert in order to share your experience. This sparked a discussion in which James Bach made a point that really drew my attention. He talked about being a resident expert in this way (I’m grossly paraphrasing):
If I am in a room with Scott Barber and you wanted the expert on performance testing, he’d be the expert. If I am in a kindergarten, and you wanted the expert on performance testing, I’d be the resident expert.
Which is to say that being a resident expert does not necessarily mean that you are the ultimate expert at something, just that you are further along in the learning journey than others around you.
How I became the resident expert for performance testing in my organization
Just like a lot of people answer when asked how they came to be a tester, I sort of fell into it. When I joined Adobe as a tester, our project was young and didn’t have any clients in production. No one gave performance a second thought, it was all about adding new functionality. Performance testing was something viewed as a “nice to have” and was seldom done (usually in the form of JMeter scripts run by a dev against his local environment). It didn’t really fit anywhere in our Sprint. As for me, this was my first job out of college and I was basing my activities as a tester mostly on my manager’s expectations. I viewed performance testing, like the rest of my team, as something that other people did, not part of my responsibilities.
Of course, time passed and the project grew. Then one day disaster struck! A performance issue causing downtime in production! Now we need to do performance testing! And by the way, did we mention it needs to happen by the end of the week?
After 3 days locked in an office (to minimize distractions, not against my will!) with a shiny new load testing tool that no one had any experience with and a heap of online tutorials, I had cobbled together a test scenario that we used to reproduce the production issue. Then came a lot of focused work on performance tuning and, over multiple iterations, we managed to finally get out of the proverbial woods.
Rather than putting this experience behind us and waiting for the next catastrophe to strike, we chose to learn from our mistakes and incorporate performance testing into our work. One year later, our team runs performance tests every sprint on each release candidate, we run focused testing for specific features, we’re looking at new ways to trend performance.
Of course, in the beginning I spearheaded all performance testing efforts for our team since I was “the only one who knows what she’s doing”. Then came a training for the other testers in our org, a presentation for the whole campus, testing the new shiny architecture for our project’s move to Amazon and, recently, “consulting” work for one of our teams in the States to help them with their move to AWS. All this kind of cemented my reputation as “resident expert” within our organization.
How resident experts can make a difference
There are, of course, perks to being seen as the “resident expert” for something. For instance, being the sole engineer in a meeting with both the VP and Senior VP of your organization and being praised for your report afterward. I’m not going to lie, this kind of visibility feels good! Maybe sometimes you get to play the hero (identifying a key performance issue on a new feature early, in time to fix it before releasing it in production) or the villain (giving a NO-GO for a release that would impact performance). However, what feels really great is seeing how your work has made a difference.
In my opinion, there are 2 main ways in which resident experts can make a difference:
Spreading their knowledge
As “resident expert” you recognize that you have a looong way to go until actually being an expert. However, I feel it is your responsibility to help others around you who are just beginning their journey! Instead of hoarding the knowledge I’ve gained, I’m a big fan of an ‘If I can do it so can you! It’s easy! I’ll help you!’ attitude that I think coaxes my fellow colleagues to overcome their initial anxiety about learning a new tool or skill.
Spreading their enthusiasm
A magical thing happens when you care a lot about what you do and are vocal about it. Slowly but surely, you get to infect other people! Right now not only am I not the only person running performance tests in my organization, but I am not the only person driving these efforts either! Managers are asking about performance testing! Developers are concerned with how their changes are impacting performance! Even the operations guys are peeking their heads out of their office to see what we’re doing! We’re getting closer to building an ecosystem where everyone is responsible for performance! I have confidence that even if I leave, the testing will go on!
Sure, you don’t get there overnight, but constantly engaging the team in conversations about an issue raises everyone’s awareness of the subject. And it can be as easy as going up to someone and saying: ‘Hey! Wanna see something cool?’ Then pull them over to your workstation and show them what you’re working on! A shiny graph or an insightful interpretation of some results that tells them something they don’t already know is usually enough to get the ball rolling!
So in the end, am I an expert on performance testing? — Certainly not. Am I any good at it? — Who knows? Have I made a difference? — Definitely! And I think that’s what really counts.