Becoming a Data Group Manager

In my professional journey, I started as a developer when the waterfall model was dominant. Features were delivered annually, and releasing a version was a tense process. If clients discovered major bugs, there was no quick fix mechanism in place, and client needed to wait to the next release.
Later, I transitioned into a Quality Assurance (QA) manager role, a position that has accompanied me throughout my professional life. As such I learned that while all companies desire high-quality products, few prioritize it over speed.

Here are a few mile stones from my career as a quality manager:
On of the main marks in my career as a quality manager, was the transition to Agile. After a 9-year sojourn in Brazil, I returned to Israel, ready to embrace a new chapter. The stage was set: a QA manager role in a prominent international company, that this transition would thrust me into the heart of a seismic industry shift—the adoption of Agile methodology. My quality group, however, operated in a manual QA realm, where quality was no longer an isolated function in the R&D. It became an integral part of the development team, one manual QA professional, proficient in UI testing, tasked with ensuring the quality of work produced by 3 to 4 developers. Adding to the hardship the QA in the team started reporting to both the team lead and the QA manager, they had a day-to-day manager and a professional manager, and sometimes they didn’t see eye-to-eye on what the best approach is for the team’s effort. On top of that the automation tool was on the UI layer only, and many times the automation tool wavered, yielding false positives. Doubts crept in—was automation truly effective? Could it replace manual testing entirely? The turning point arrived when R&D teams embraced a new mindset. Quality was no longer the sole domain of quality team members; it became a collective endeavor. This cultural shift fostered team engagement and laid the groundwork for a robust Continuous Integration/Continuous Deployment (CICD) approach, a key result for agile methodology.

In another case, as a QA manager at a startup, I witnessed a fascinating evolution in our approach to automation. Initially, the quality was relatively high, but we knew there was room for improvement. The turning point came when we introduced automation layers. Suddenly, the quality mindset became more tangible. Implementing this automation shift in a small-scale R&D environment was challenging due to velocity constraints, but the team embraced it. After setting up the automation infrastructure, the team found itself somewhat idle, as developers and automation developers took full responsibility over the infrastructure and the creation of automation tests. There was a question what about the automation infrastructure team, what will they do? During discussions with the business stakeholders, a specific pain point emerged. A repetitive task consumed hours of employee time. The solution? We automated that task, freeing up valuable human resources, instead of automation team becoming obsolete, they were repurposed to create Robotic Process Automations (RPAs) for the business.

When I stepped into the role of Head of Operations, I faced the dual challenge of overseeing R&D quality while managing a diverse operations group comprising DevOps, NOC, and Tier 3 support. As a leader, I recognized that quality should permeate every aspect of our work. Whether it was code, processes, or customer interactions, maintaining high standards was non-negotiable. One of the solutions for a major issue was simple, you see, our DevOps team excelled in technical outcomes, but their reliability in meeting time commitments was inconsistent. To address these issues, we adopted the Kanban methodology, work items were represented on a Kanban board, allowing everyone to see the status of each task, transparency became our ally. By limiting work-in-progress (WIP), we achieved a steady workflow, Kanban’s focus on continuous improvement empowered us to provide more accurate time estimates.
In my journey with a major gaming company, as manager of 5 QA managers, I encountered a fascinating challenge: standardizing quality practices across various game, each game/studio operated as an independent entity, treating their game as a standalone company. I grappled with harmonizing diverse approaches to quality assurance, as Each game had its unique context—varying technologies, code maturity, and manual tester resources. We assembled the QA managers who had never collaborated before, into a team, managers have started to discuss their experiences, challenges, and solutions. This collaborative exchange provided quick, proven solutions for a range of common problems. Streamlining our practices as facilitate in reducing manual QA by 30% across all games, as we worked together on a shift left approach, as the solution for the company needs.

In the upcoming articles, I’ll share my own experience, as data development group manager, as I was tasked in providing code and data quality tooling to the entire data department. This was a new quality field for me, which presented a lot of challenges, where in some parts we were successful, and in others not so much, please join me as I unfold my personal experience.