Back to resources

Testing and Solving a Problem as a Team

Collaboration
Feedback

1 June, 2021

Shay Mandel
Shay Mandel

VP Engineering at Next Insurance

Shay Mandel, Engineering Group Manager at Next Insurance, found himself in a rut with his team; including a new voice in the conversation helped to push their efforts forward.

Problem

After spending some time with a new development team, I wanted to increase our rate of releases. We had a very large QA team, and, as a result, an extensive and grueling QA cycle.

One thing that I notice a lot of organizations struggling with is moving from manual QA to an automated QA system. In this example, we had a few teams who were saying that there was no way that they could operate under these conditions, on the front-end, especially. They also claimed that the back-end was too complicated to rely on automation alone in its own right.

The attitude was not one of trying to figure it out, but rather one of why it could not and would not work.

Actions taken

I tried a lot of things in order to build a technical solution myself, and many of them, in spite of being technically working, did not convince the team to make the move.

I am not a front-end guy, but I do know what front-end testing entails. I created a proof of concept and presented it to the team. It was a small part of a huge script, which I was able to extract through refactoring and test in isolation. It wasn’t convincing enough.

After a few other mishaps, we held a hackathon to see if we would be able to crack it together. We worked for three days, refining the structure of that huge script. But the team still wasn’t convinced that it could be tested. We tried to automate another area, this time in one of the back-end teams. The same resistance to automation was present.

I sought out the advice of somebody who was not immediately involved with the project. I asked them to dedicate some of their time to the problem. They were not as familiar with the code as my main team was. They brought no prejudice against the difficulty of the project to the table, which, in my opinion, probably helped them to solve the problem. We started by building a small testing framework, and, after testing and testing, eventually we got it to work.

Our QA process was shortened greatly, from three days to maybe twenty minutes. Eventually, the developers found that it was easier to simply write the code than to explain it to the vendors on the outside.

Lessons learned

  • Sometimes, the baggage of knowing the history behind a project may make it more challenging to engage with it fully. You need to be able to come fresh and to just do it.
  • If you set out clear requirements and give adequate time to the right developer, it will happen. You need to give people time. If you don’t give your people time, it will not happen. If you don’t have good requirements, it will not happen.
  • Sometimes, you need to be naive in order to solve a problem. Isolating yourself with the problem may give you more space to think about it from all sides.
  • If you showcase that something is working, you will earn the buy-in that you need from others. If they see that the product is good, they will believe in it.

Discover Plato

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


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

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
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

How Less Viable Solutions Solve Common Architectural Challenges

13 May

Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Architecture
Different Skillsets
Conflict Solving
Collaboration
Tom Hill

Tom Hill

Engineering Manager at Torii

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

Plato (platohq.com) 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.