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

Question

Anonymous · Accepted 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

While working on a project to analyze genetic data for autism correlations,
there was a disagreement on the approach for data analysis. One team member
preferred using traditional statistical software, but I believed that using
Python would provide more flexibility and efficiency for processing large
datasets and performing custom analysis. I proposed trying both approaches on a
small subset of the data to compare the results and assess which method offered
better insights and processing time. After seeing the advantages of using
Python, such as streamlined data manipulation and faster processing, the team
agreed to adopt it as our primary tool, which enhanced the project’s overall
efficiency. This experience highlighted the importance of proposing data-driven
solutions and demonstrating their value.

Anonymous · 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

When working at Flutter a member of the release engineering team wanted to
automate the internal hotfix process with high priority. This would require
creating several integrations and approval workflows with an estimated effort of
1 software engineer for two quarters.
I disagreed that automating the internal hotfix process was a high priority. I
suggested the engineer run a cost-benefit analysis using information of how many
hotfixes were processed per quarter and what was the effort of running the
manual hotfix process. The engineer collected the information from the release
engineering metrics. It turned out the hotfix process was executed approximately
once per quarter and the manual process took only two hours. The cost then came
to 1 software engineer for two quarters and the benefit was saving 2 software
engineering hours per quarter.
After reviewing the cost-benefit I suggested the engineer select a project from
the many available with higher priority and lower the priority of the automated
hotfix process.

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

In my current role making semiconductors for different connected devices,  we
have to work with different OEMs to integrate our chipsets into their product
designs for operators such as T-Mobile or AT&T.  Based on the launched product
KPIs, we identified some interference issues between cellular and wifi channels.
 This has resulted in some intermittent performance issues and affect product
quality.  I suggested that we should provide some design guidelines for the OEMs
to assist them to develop a better RF filter design in order to maximize on our
chipset capability, and to work with the key OEMs on the performance evaluation.
 One of my peers has strong objection to this suggestion and recommended that it
was not our job to provide any design suggestion to OEMs and instead just let
OEMs work that out with their end customers.  I understand what is at stake for
our business if the end customer associated the performance issues with our
chipset.  I presented my case to the Product manager, to the test team, and then
senior management on the risks of possibly losing market share by not investing
in this design partnership with our OEMs.  The Product manager and test team
agreed to support my suggestion and developed a collaboration plan with one of
our key OEM.  I am glad that i pushed for this effort despite my peer's
objection because now the carrier customer has asked for interference
performance improvement in the product.  My effort gave the product and the team
a nice position to meet the carrier customer's request.

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, I had a Sr. Engineer who was very harsh with Jr. Engineers in giving
feedback. This led to Jr. Eng afraid of approaching with advice and team morale
go down and productivity was down by 10%. I had to coach this teammate to not be
hostile and instead approach people with Empathy and show ledership in asking
the right questions and help them grown in their carrer as well - with this
change in attitude, I saw that the team gel much better and the productivity
increased overtime.

Anonymous · Answer

In a recent project while developing an interface there were multiple conditions
and tasks that need to be implemented within a single interface so my colleage
wanted to go ahead and develop one single batch for the entire interface as that
would be easy to develop and that's how things have been working in this project
...but realiing the poetential imapct it might have in case of failure affecting
all the subsequent work and also identifying the point of failure and again
re-executing the batch would be difficult task I proposed that multiple batches
for specific services should be implemented as this would save batch run time ,
identifying point of failure and re-executing the batches would also be easier
and discussed these points with senior consultant, our manager as well as my
fellow developer to which everyone was on the same page and we implemented the
interface with 3 batches and ease out the life f the support team

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?

Answers

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Unlock Community Insights

Try Our AI Interviewer