Ramping Up to Modern Performance - Key takeaways
01 Jul 2026
Yesterday I attended as session by Leandro Melendez on how to build modern performance practices, It was very insightful so I just wanted to share my takeaways with you lovely lot :)
Speaker: Leandro Melendez (aka Señor Performo)
GitHub: https://github.com/srperf/whoamiÂ
Speaker: Leandro Melendez (aka Señor Performo)
GitHub: https://github.com/srperf/whoamiÂ
Overview
I recently attended "Ramping Up to Modern Performance" by Leandro Melendez (Señor Performo). The talk challenged some traditional assumptions about performance testing and presented a modern approach that focuses on continuous performance validation, observability, and shared ownership across delivery teams. The key message was simple: performance is not a specialist activity that happens shortly before release; it is a quality practice that should be embedded throughout the entire software development lifecycle.
1. Performance Testing is More Than Load Testing
One of the most impactful takeaways was that performance testing should not be synonymous with large-scale load testing.
Traditional performance efforts often focus on infrequent, expensive BALTs (Big Ass Load Tests). Instead, teams should focus on continuously asking smaller performance questions and running lightweight tests regularly.
Examples include:
Traditional performance efforts often focus on infrequent, expensive BALTs (Big Ass Load Tests). Instead, teams should focus on continuously asking smaller performance questions and running lightweight tests regularly.
Examples include:
- What causes a mobile phone to overheat in a user's pocket?
- Which API calls have started getting slower?
- Has a recent code change increased memory usage?
- Are key user journeys still meeting response time expectations?
Follow the Performance Pyramid
The recommendation was to follow performance testing pyramids in the same way we approach automated testing pyramids:
- Lots of small performance-focused unit tests
- Automated service and API performance checks
- Limited UI and end-to-end performance tests
- Large-scale load tests only when genuinely required
The phrase that stuck with me was:
"Do more Chihuahua-sized tests and fewer Big Ass Load Tests."
Continuous feedback from small tests provides far more value than a single large test conducted late in the delivery cycle.
2. Make Performance Reporting Accessible
Performance data should not be locked away in specialist tools or teams.
Reporting should be:
Reporting should be:
- Dynamic
- Easy to understand
- Widely accessible
- Useful to developers, testers, product teams, and leadership
The goal is to democratise performance insights so that everyone can understand the health and behaviour of the system without requiring a performance engineer to interpret the results.
3. Shift Left and Shift Right
Performance activities should happen throughout the entire software lifecycle.
Shift Left
Performance considerations should begin before development starts:
- Establish observability from day -1
- Define performance requirements alongside functional requirements
- Developers own and automate performance tests
- Performance engineers prepare, coach, and enable teams
- Build continuous performance testing into development workflows
Shift Right
Performance work continues after deployment:
- Observability and monitoring
- Release strategies
- Manual load testing where appropriate
- Synthetic monitoring in production
- Continuous feedback between development and operations
A key point was that performance should exist both before and after release, creating a continuous quality feedback loop.
4. Introduce Observability (O11y) Principles
Observability was repeatedly highlighted as a foundation of modern performance engineering.
Observability allows teams to understand:
- What is happening within their systems
- Why performance issues occur
- How users experience the application
- Where optimisation efforts should be focused
Rather than relying solely on test results, teams should use telemetry, metrics, logs, and traces to gain ongoing performance insights.
5. Performance is Everyone's Responsibility
A major theme throughout the session was the need to remove bottlenecks around performance testing. In a modern approach:
- Developers create and automate performance tests
- Testers contribute performance validation
- Operations teams monitor production behaviour
- Product teams understand performance requirements
Performance engineers should not be gatekeepers. Instead they should act as:
- Coaches
- Subject matter experts
- SWAT teams for complex investigations
- Performance monitoring specialists
The objective is to make performance testing something that anyone in the team can execute and maintain.
6. Treat Performance Like Any Other Quality Practice
Performance should be treated no differently from security, accessibility, or functional quality. This means:
- Defining performance requirements early
- Including performance expectations within refinement and planning
- Incorporating performance into the Definition of Done
- Building observability into solutions from the start
- Continuously validating performance throughout development
Rather than being considered a release activity, performance becomes a standard part of delivery.
7. AI Can Help, but Cost Matters
The discussion also covered the growing use of AI within performance engineering. Potential uses include:
- Test generation
- Performance analysis
- Trend detection
- Quality assistance
- Root cause investigation
However, there was also a warning that continually using large commercial AI models can become expensive very quickly.
An interesting recommendation was to:
An interesting recommendation was to:
- Train or fine-tune AI agents on your own codebase
- Provide domain-specific requirements and context
- Reuse those agents across quality activities
This may offer a more cost-effective and relevant solution than relying entirely on general-purpose AI services.
8. Tools Matter Less Than Outcomes
There was a strong emphasis on avoiding attachment to specific tools. The best tool is the one that helps answer the performance question being asked.
Key principles:
- Choose tools based on purpose
- Use multiple tools when necessary
- Prefer open-source solutions where possible
- Use heavyweight enterprise tooling only when there is a clear need
No single tool will solve every performance challenge, and flexibility is often more valuable than standardisation.
- Look After the Cloud
The final takeaway focused on cloud costs and scalability. A common misconception is that scaling infrastructure automatically solves performance problems.
In reality:
Scaling often just allows inefficient systems to consume money faster.
Teams should focus on:
- Efficient code
- Performance optimisation
- Resource utilisation
- Early detection of performance issues
Good performance engineering is not just about speed; it is also about sustainability and cost efficiency.
My Key Reflection
The biggest shift in mindset from this talk was moving away from viewing performance testing as a specialist activity centred around occasional load tests. Instead, performance should be:
- Continuous
- Observable
- Automated
- Shared across the entire team
- Embedded from day -1 through to production
The modern performance engineer is less of a tester executing scripts and more of an enabler helping teams build performance awareness into their everyday development practices.
Megan Ozanne
QA Team Lead
I love all things test especially exploratory testing, I focus on building out automation first QA teams.
Open To
Write
Speak
Podcasting
Meet at MoTaCon 2026
Hiring
Teach
Sign in
to comment
Manage your entire QA lifecycle in one place. Sync Jira, automate scripts, and use AI to accelerate your testing.
Explore MoT
Thu, 1 Oct
A tech conference to help you navigate the ever-shifting landscape of Quality Engineering, AI, Leadership, Product, Accessibility and Security.
Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts.
Into the MoTaverse is a podcast by Ministry of Testing, hosted by Rosie Sherry, exploring the people, insights, and systems shaping quality in modern software teams.
