Breaking Stereotypes: QA Takes the Wheel as a Mission Captain
In the vibrant world of Scoro’s software development, only our skilled developers have so far taken on the role of a Mission Captain, leveraging their technical expertise to guide the way.
Our VP of Engineering, Juan Gutiérrez, has described the role of a Mission Captain in his The framework is not quite right for you? You can still contribute! article as follows:
Every mission has a Mission Captain who is responsible for the mission, mission set-up, execution, ways of working and outcome. The MC is usually a software engineer, and any engineer (regardless of the seniority) could potentially be a MC. The MC works very closely with the Product Manager within the mission lifecycle. The MC is also responsible for ensuring that the mission has a crew and who is part of it.
So, being a QA engineer who focuses primarily on the quality of the missions, the idea of stepping into the role of a Captain had simply never even crossed my mind.
But sometimes life surprises us. So when a Product Manager approached me with an offer to take on this challenge, I was pretty sure he was joking. I mean, what could a QA engineer like me bring to the table? I didn’t have the technical skills of a developer. But then it struck me — I realized I had a unique chance to do things differently.
For me, missions had always seemed a bit chaotic — riddled with ineffective communication, missed deadlines, and a structure that always leaves something to be desired. But now I had a rare opportunity to break the cycle and make a real impact.
So off I went, excited to see where this opportunity would lead me. Or where I would lead it.
Leveraging my skills as a QA engineer, I approached the assignment with a structured mindset, zeroing in on a few key aspects.
Effective communication
The most common “what-could-have-been-better” feedback we have received from retrospectives has always been communication. That’s why I took this topic as the cornerstone of our teams’ collaboration. I prioritized promptly addressing any questions or concerns, guaranteeing that the team operated with a shared understanding. Here are some topics I focused on that could also come in handy for you if you’re looking to improve communication within your team:
- All important discussions must happen with the whole crew. There should be no private chats with only some of the members as this creates silos and/or deprives others of the possibility to contribute to the decision-making.
- When questions arise, the Captain needs to make sure the answers are given ASAP, so we could continue working without blockers. This means pinging PM for business-related matters, designers for design-related issues, and developers with technical topics. Don’t leave anyone hanging.
- I cannot stress this enough that stand-ups are not just status report meetings! While it’s important to stay informed about each other’s progress, I believe that the true value lies in discussing potential roadblocks, sharing valuable information, and ensuring we are all aligned.
Well-prepared scope & crew
In order to succeed, the mission scope and crew needed to be well-prepared. We had previously struggled in missions because we had taken on more than was feasible within that time frame out of sheer ignorance. I made sure we had a thorough understanding of the problem we were solving while being realistic about how much we can deliver. Here are some of my suggestions for addressing this issue:
- Together with the PM, cut the scope down to multiple phases. What is the most valuable part we need to deliver first? What can be left out in case we start running out of time? What is definitely only nice-to-have?
- Facilitate lots of refinement meetings all together before the start of the mission. Welcome open discussion and all sorts of questions, no matter how obvious they may seem. Ensure that every team member has a clear understanding of our goals and desired outcomes.
- Reach an understanding of the solution on a technical level and think through the complexity of the solution. Which fields are missing from the database and which endpoints should we add to our API? Are we going to do some refactoring? For this, a non-technical MC must seek the help of a software engineer, who joins the mission.
Transparent progress tracking
Frequent last-minute landing postponements have kept us from sticking to our roadmap effectively. I believe this hiccup occurs because there’s little visibility into mission progress. To address this, progress tracking became essential. It enabled us to set weekly goals, identify the next steps, and grasp the overall mission trajectory. Here’s what I propose for the next MCs as well:
- Involve the whole crew in the creation of tasks to ensure everybody is on the same page about what needs to be done and what steps need to be taken to accomplish this. This approach helps align everyone’s expectations and promotes clarity and coordination within the team.
- Create weekly milestones for the whole mission with the entire crew. If something doesn’t get accomplished on time, re-calculate the progress. This way you can see early on, whether you can land on time or need an extension.
- Have a Weekly Planning meeting. During that, you can go over the milestones and plans for the week and check whether the previous ones were reached. This is also the perfect time to give a small demo about the progress!
Team Spirit
As a leader, it is important to be the glue that holds the team together, ensuring that every team member has a voice, that their ideas are valued, and that we foster a sense of belonging and collective responsibility. Some things you can try:
- Care for your team. Ask your team how they’re really doing, whether they feel overwhelmed or stressed, and if they need help. Provide positive feedback to uplift their spirits.
- Have an additional retrospective meeting in the middle of the mission. Don’t wait until the end to gather feedback on what could have been better. Allow the crew to suggest improvements that can be implemented ASAP. I recommend doing mid-retros only if the mission runs longer than 6 weeks!
- Don’t forget to have fun and celebrate small victories! Icebreakers are a great way to start meetings. If possible, do more lunches together. Celebrate the mission starting and landing. Go out for drinks, or order some cakes and pizzas!
Conclusion
By implementing these strategies and practices, we were able to dedicate ourselves to building the desired outcome. When faced with technical decisions beyond my expertise, the most experienced senior developer helped determine the right approaches and tackle complex coding challenges. However, it was a collaborative effort where we all worked together to find the best possible solutions. That’s why I believe captains don’t have to have all the answers, it’s enough to be able to coach and lead the people to the right answers.
And you might be wondering, how did the testing process go while the QA was busy running the show? Well, it went even better than I anticipated. Since I was able to be on top of all the changes and updates, the testing didn’t lag behind the confusions of what-where-when we can test. And since the developers were coming to me with their questions anyways, we were able to tackle the testing challenges together before the features were implemented.
Would I recommend it to other Quality Engineers to take the lead once in a while? Absolutely! I encourage every individual to embrace opportunities to experiment and explore their potential in different roles. However, in this case, it is crucial to assemble an experienced team, preferably with at least one senior developer who can provide guidance for tackling complex challenges. Otherwise, it might become more challenging and affect the mission’s overall success. But all in all, my experience showed that it’s well worth stepping out of your comfort zone if you have a strong and skilled team behind you.
