Back to resources

How to Wear a Lot of Hats

QA Team
Agile / Scrum

13 October, 2021

Phillip Derosa
Phillip Derosa

Global Director of QA at OneSpan

Phillip Derosa, Global Director of QA at OneSpan, has never been afraid to fill in the cracks between departmental duties, often coming up with a brand new intermediary position to occupy during times of need.


If you play poker online, chances are, you’ve probably heard about the game the World Series of Poker. We would release to our customers every three months.

A lot of businesses are looking to reduce their time to market, and this is across a lot of platforms. In the game industry, we are eager to bring new value to our customers as frequently as possible. It’s a competitive market, so we like to be able to act quickly when a trend catches fire. You ideally want to reduce the number of changes that you deploy for each release, as well.

In this case, I was the product owner and a Scrum master of Scrum masters on a team. I was also the QA director and the release manager, a position that was brand new to the company. I was wearing a lot of hats.

Actions taken

Our mission was to reduce the length of our release cycle, bringing it from three months down to two weeks.

We solved this problem with executive buy-in, who sponsored this change in velocity. It was an initiative that involved a lot of people. Those in the studio were saying that it was impossible, that three months was the bare minimum; to them, that was just the way that things were. Having our leadership on our side helped us a lot in making this change.

Even if we were only able to shave a few weeks off at a time, the progress that we were making was still better than nothing. I had built a small automation framework team and we did what we could to streamline our testing process. We started with our end-to-end testing, which is the part of the process most capable of showing us whether or not we have a working product.

We ended up automating around seventy percent of our end-to-end tests, all of the ones that people would have to manually go in and validate. After running those every night, we would catch all of the issues that we had to figure out.

The server side was quite advanced in terms of the best practices that we had in place; server developers tend to have to do things right the first time, or else things start to break. Very bad things can happen.

We also added a smoke test prior to their merge. In order for the merge to go in, they would deploy the solution after running a few core tests. We were using the product just like a customer would.

At one point, I took on a release manager type of role, more of an additional hat than anything else. It was nothing that had been a part of the team’s way of working before. We defined, step-by-step, a process map. We planned out every single thing that needed to happen to get the product through production. In retrospectives, we were then able to analyze every step and identify areas that could be improved.

Along with this process map came a schedule. This was especially important toward the end, where the sequence of events ended up mattering a lot. After defining all of these processes, we then defined an owner for each step. Our teams were taking more responsibility for the quality of their deliverables than ever.

We had exposed all of the right people to the importance of everything that we were doing at this juncture. They had fresh ideas to bring to the table. Getting the team actively involved in the deployment process proved to be vital to our effort to reduce these release cycles.

Lessons learned

  • My parents were free-range parents; I was always one to sort of do my own thing. I really do not toe the line when it comes to my role on the team. I can be the QA director, but if I see a problem outside of those duties, I put on a hat and I fix it. It’s easy to just say that something is not your job. It takes energy, but you learn so much by going above and beyond.
  • I’m a systems-thinker. I see everything as a system that works together. When solving a problem like this, it can be helpful to learn how every piece of the puzzle works. How does everything all fit?
  • Once my managers saw the value in this new position that I had come up with, they felt comfortable enough to hire somebody to take on the role full-time. Filling this gap has been very helpful to us.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

10x engineer or 10x impact?

26 May

Hiring 10x engineers is hard for most companies. It’s a tough battle out there for talent. So how should most companies approach building their team?

Building A Team
Coaching / Training / Mentorship
Vaidik Kapoor

Vaidik Kapoor

VP Engineering - DevOps & Security at Grofers

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Innovation / Experiment
Personal Growth
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Building A Team
Internal Communication
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Growing Through Different Engineering Lead Roles

8 May

Weiyuan Liu describes his experience moving up from an individual contributor, tech lead, and engineering manager.

Coaching / Training / Mentorship
Career Path
Weiyuan Liu

Weiyuan Liu

Director of Engineering at Zillearn

Here to Make a Recognizable Difference: How to Develop Teams

5 May

Eric Merritt, VP of Engineering at, divulges on the many complexities of developing teams in management by solving problems according to their needs, and empowering teams.

Sharing The Vision
Coaching / Training / Mentorship
Eric Merritt

Eric Merritt

VP of Engineering at

You're a great engineer.
Become a great engineering leader.

Plato ( is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.