Can you share an experience where you had to challenge your teammate's approach?

Question

Anonymous · Accepted Answer

In a recent project involving a multi-service platform, we faced a situation
where one of my peers suggested a new feature implementation that relied heavily
on synchronous communication between services. While this approach would have
met the immediate functional requirements, it posed significant risks for system
performance and reliability due to potential bottlenecks and cascading failures.
Recognizing the broader implications, I proposed an asynchronous event-driven
approach using a message queue system. To address this, I organized a series of
cross-functional meetings with our architecture, operations, and QA teams. I
prepared detailed impact analyses, including potential improvements in fault
tolerance and scalability, and shared these insights through a series of
workshops.
Through collaborative discussions, we mapped out the benefits and trade-offs of
both approaches. This inclusive process allowed us to align on a solution that
improved system resilience and performance while also accommodating feedback
from all relevant stakeholders. The asynchronous design ultimately proved to be
more adaptable to our growing needs, and the project was a success with enhanced
system stability and performance.
This experience highlighted the importance of considering cross-functional
impacts and involving diverse perspectives in decision-making, which is crucial
for senior-level roles.

Anonymous · Answer

In my role as a Team Manager at a call center, we were implementing a new
process to handle high call volumes during peak seasons. One of the senior
managers proposed a strategy that involved extending work hours for all agents,
including mandatory overtime, to ensure we met our service level agreements
(SLAs).
While the proposed strategy aimed to address call volumes, I believed it would
lead to burnout among the agents and negatively impact their morale and
productivity. My task was to present an alternative solution that could achieve
the same goals without overburdening the team.
I conducted a thorough analysis of our call volume patterns and agent
performance metrics. I identified that not all hours during the extended period
were equally busy and that a more targeted approach could be effective.
I developed an alternative proposal that involved optimizing our shift
schedules. This included:
 * Implementing staggered shifts to ensure we had more agents available during
   peak hours without extending overall working hours.
 * Introducing a flexible part-time workforce that could be called upon during
   peak times.
 * Enhancing our self-service options on the website and IVR system to reduce
   call volume.

I scheduled a meeting with the senior manager and other stakeholders. I
presented my findings and the alternative proposal, highlighting the potential
benefits:
 * Reduced risk of agent burnout.
 * Improved morale and productivity.
 * Maintaining or even improving service levels through better resource
   allocation.

During the meeting, I respectfully disagreed with the initial proposal and
explained the long-term negative impacts of mandatory overtime. I backed up my
stance with data and examples from previous high-call-volume periods where
burnout had led to increased absenteeism and turnover.

After a detailed discussion, the senior manager agreed to pilot the staggered
shifts and part-time workforce approach. The implementation led to several
positive outcomes:
 * Improved Agent Morale: Agents appreciated the more manageable work hours,
   leading to a 20% increase in job satisfaction scores.
 * Maintained Service Levels: We managed to meet our SLAs without overburdening
   the team. In fact, customer satisfaction scores improved by 15% due to
   better-managed call handling.
 * Cost Efficiency: The cost of hiring part-time agents was offset by the
   reduction in overtime pay and lower turnover rates.

This experience taught me the importance of having a backbone and respectfully
disagreeing when necessary. It reinforced the value of using data to support my
arguments and the need for collaborative problem-solving. By challenging the
initial approach, I was able to implement a solution that benefited both the
team and the organization.

Anonymous · Answer

In one of the project, QA manager asked to utilize automation to speed up the
testing cycle. However I had concerns about using automation. 
My task was to ensure that high standards for the delivery of the product and
address my concerns.
For this, I consolidated all evidence and convened one to one meeting with the
manager. 
Discussion started by sharing my concerns that- status of the project is still
under development which leads to continuous changes in the scope. secondly, the
project is all file based which leads to more time executing regression. Also,
to test one functionality, it requires lot of explicit wait time to complete the
test. I also prepared a small demo to explain my concerns.
After discussion, manager agreed on not utilizing this automation at the moment.
There was a task created in backlog to automate in future. 
Thus, this incident helped to save critical time, addressing concerns helped to
achieve better approach towards testing.

Anonymous · Answer

At Auctane, the setup was such that Eng. Teams would delvelop code, and the
deployment and operations was done by DevOps team. Even for Dev,Test
environments. A key cloud ops eng, left the company during a critical phase of a
project I was responsible for. This impacted our teams velocity, when I
requested to prioritize our teams items, director of DevOps said that there was
no other way around and we just have to be in the queue. I disagreed but started
to look for alternatives in the background. I talked to other managers and found
a common thread. I realized this a bottleneck for a the dev teams, hence I
proposed the idea of having a process, where in our dev would generate the
initial terraform scripts - collobrate with CloudOps eng to get an approval
after which the devs has the autonomy to deploy in dev and test environments.
While the Prod deploy will still be under Dev Ops. After convicing my peers, I
held a meeting with DevOps director as well. I presented the pros and cons and
Director brought into this process. By implementing this approach - it was a
win-win scenario. The DevOps team got the time it wanted to hire the right eng.
and we reduced the bottleneck for the lack of resource. We could improve our
deploy cycle by 20%

Anonymous · Answer

it happens on one of our project where I disagree withe team members approach on
the navigation system in the mobile app. team member will to show all menus
under the humberger menu but I wanted to give main navigation at the footer
because its easy to navigate the from there with the single hand asn the button
are near to fingertips.

Can you share an experience where you had to challenge your teammate's approach?

Did you come across this question in an interview?

Answers