Caveat: The views expressed here are personal. This is intended as a lesson in Conflict Resolution.
The issue started innocuously, as it were. In our management meeting, the manager (Lets call him ‘Manager2’) of DBA team presented an issue which was related to an area managed by the manager (Manager1) of Technical Team.
The problem went like this. Our organization is on ERP. Manager1 heads the technical team which makes technical modifications to the ERP Application. We have multiple instances of ERP Application, Development Instance, Testing Instance and Production Instance.
The technical team is responsible for developing reports, get them tested in the Test Instance and get the same moved to Production instance. The initial development is done in Development Instance, Tested in Test instance and finally moved to Production Instance.
There are two steps in moving a report to Production. One is to move the report code, known as .rdf file. And the other is to move the system configuration required to run the report, known as .ldt file. The entire process of movement to Production Instance is handled by the DBA team which is headed by Manager2.
To move the .ldt file to production, the developer will first copy the same from Test Instance and then the DBA team will move the same to production. In this particular case, instead of moving a single .ldt file, the developer moved ALL the .ldt files from Test to Production.
We use a tool called Serena to move any code to Production. Serena provides multiple levels of review of the code before the same gets to Production. The process in Serena is as follows. There are three areas in Serena namely development area, testing area and production area. On developing the report and completing the unit testing, the developer moves the code to the development area in Serena and informs the Technical Lead (Tech Lead). The Tech Lead then does two tasks. One, she moves the code (both .rdf and .ldt) to the Test Instance. Two, moves the code from the development area in Serena to test area in Serena. Once both these tasks are done, the Tech Lead asks the users to test. Once the user completes testing and certifies the result, the Release Manager then moves the code to Production area in Serena and raises a request on the DBA to move the code to Production. The DBA picks the code from Production area in Serena and moves the code to Production Instance.
As you can see, the Code movement is synchronized between Serena and Production. Also there are different responsibilities for moving the code from one Serena area to another thereby ensuring multiple review and oversight.
In this case, the Process was not completely followed. For one, the developer directly developed the code in Test Instance and not in the Development Instance. Secondly, the developer himself (not the Tech Lead) moved the code (.rdf and .ldt) to the Test Instance in Serena. While creating the .ldt file for this specific request to move to Serena, the developer copied the .ldt files of all the objects in Test Instance and moved the same to Serena. While copying the .ldt file, the developer did not follow the basic review process of reviewing the log file. A review of the log file would have helped him to realize his mistake.
On confirmation from the Developer, the Tech Lead moved the code from the Test Area in Serena to the Production Area in Serena and asked the DBA to move the same to Production. The DBA Team picked the code from the Test Area in Serena and moved this to Production as per the request raised by the Tech Lead.
Since the Test Instance was more than 2 months old, all the reports that were modified in the last two months had the wrong .ldt file in the Production Instance !
The complaints started pouring in after about two days. The DBA Team under Manager2 was asked to analyse. They identified the issue and steps were taken for rectification.
Also, the developer who made the mistake was advised to be more careful in the future.
While the issue was under analysis, we had a management meeting. In this meeting, Manager2 highlighted the same as ‘Violation of Serena’ process. Manager1, a veteran in the Industry, took affront at the issue being presented to management without the same being discussed internally between the teams. He felt that we should have waited for a thorough analysis and taken the issue together to the management, rather than, in his perception, one team trying to do ‘one up’ on another team.
Fair enough.
Our organization follows an open culture. We believe that it is better to bring out issues in the open as soon as possible. This will ensure that they are resolved quickly. The objective was to avoid conflicts and blame throwing that follows an unresolved issue. Given the culture of the organization, it was expected that even an expected issue should be presented to the management rather than the same being kept within various teams. This would build the health of the organization and lead to better analysis.
Our organization believes that ‘Crying Wolf’ is better for everyone. Issues gets escalated, reviewed and resolved quickly if brought out in open.
The point made by Manager1 was escalated to the management. Management understood the sentiments of Manager1 and instructed both the teams to analyse the issue and resolve the same quickly. Management also instructed both teams to present a single presentation in all the future meetings. This would ensure effective co-ordination between the teams.
One would have thought that the issue is resolved. It was not to be.
This means that there were two issues. One, the violation of Serena Process. And two, the hurt sentiments of Manager1.
Manager1 started writing nasty mails to Manager2. He focused on identifying the various mistakes committed by the other team. He started looking into mails as old as a year. He started ‘Shouting’ in his emails, by writing in all capital letters.
The members of DBA Team took offense to the tone and tenor the mails.
Our organization underwent a minor restructuring a year ago. Prior to that, Manager1 was handling both the teams. The organization decided that the team was too big to be run by a single person and divided the teams into two and brought the new team under Manager2.
There had been issues with these two Managers in the past. I as the boss of Manager1, had, on multiple times, counseled both managers of the need to work together. I had told them that our teams were new and the Organization had high expectations from the team. Still there were occasional flare-ups and this was the latest in the series.
As the manager of Manager1, the onus was on me to diffuse the situation.
Always in similar situations, there will be many stakeholders. Some of the stakeholders were visible, the Organization, the company management, me, Manager1, my boss etc for example. There were invisible stakeholders too, mainly the teams that report to the Managers 1 and 2.
The first thing that I did was to inform my manager that there was a conflict situation and that I needed his support to resolve this conflict. He offered all the support that he could provide to help me resolve this. That was a relief.
There was one more advantage to this quick escalation. My manager took it upon himself to inform this issue to the senior management. That enabled me to focus on the issue at hand.
My approach to resolving this was to look for win-win. I made a note of the ‘wins’ that should accrue to each stakeholder.
I called a meeting between the two teams. As an introduction, I informed the Manager1 that his behaviour was unacceptable and that was creating disharmony within the organization. I informed him that he had to take personal responsibility for creating this disharmony. I pointed out to him that he was a valuable player of the team and that he was a cog in the wheel of the team. I brought in context by pointing out how his actions were impacting others in his team and in the other team. It was obvious that he understood the consequences of his action.
I moved on to the actual issue that had caused this flare-up in the first place. We quickly identified a process gap and a communication gap that led to this issue. At one point in the Serena process flow, there was a clash of ownership. I quickly plugged this gap by making Manager1 the complete owner of the process.
Then I asked Manager1 as to the cause of his abnormal behaviour. Initially hesitant, once he started he poured forth a litany of complaints against Manager2 going back almost a year. We identified that there was a lot of communication gap between the two teams which had over a period of time deteriorated. We discussed with the concerned managers and put in place a communications mechanism which was supposed to bring out the issues out in the open at an earlier stage in the cycle.
That was it. The issue was resolved as quickly as it had come. Everyone had got their wins.
This was a perfect win-win for all.
They never prepare you for this in
management schools, I thought. There are esoteric case studies on conflict
resolutions, but a real life conflict? That is tough.
The issue started innocuously, as it were. In our management meeting, the manager (Lets call him ‘Manager2’) of DBA team presented an issue which was related to an area managed by the manager (Manager1) of Technical Team.
The problem went like this. Our organization is on ERP. Manager1 heads the technical team which makes technical modifications to the ERP Application. We have multiple instances of ERP Application, Development Instance, Testing Instance and Production Instance.
The technical team is responsible for developing reports, get them tested in the Test Instance and get the same moved to Production instance. The initial development is done in Development Instance, Tested in Test instance and finally moved to Production Instance.
There are two steps in moving a report to Production. One is to move the report code, known as .rdf file. And the other is to move the system configuration required to run the report, known as .ldt file. The entire process of movement to Production Instance is handled by the DBA team which is headed by Manager2.
To move the .ldt file to production, the developer will first copy the same from Test Instance and then the DBA team will move the same to production. In this particular case, instead of moving a single .ldt file, the developer moved ALL the .ldt files from Test to Production.
We use a tool called Serena to move any code to Production. Serena provides multiple levels of review of the code before the same gets to Production. The process in Serena is as follows. There are three areas in Serena namely development area, testing area and production area. On developing the report and completing the unit testing, the developer moves the code to the development area in Serena and informs the Technical Lead (Tech Lead). The Tech Lead then does two tasks. One, she moves the code (both .rdf and .ldt) to the Test Instance. Two, moves the code from the development area in Serena to test area in Serena. Once both these tasks are done, the Tech Lead asks the users to test. Once the user completes testing and certifies the result, the Release Manager then moves the code to Production area in Serena and raises a request on the DBA to move the code to Production. The DBA picks the code from Production area in Serena and moves the code to Production Instance.
As you can see, the Code movement is synchronized between Serena and Production. Also there are different responsibilities for moving the code from one Serena area to another thereby ensuring multiple review and oversight.
In this case, the Process was not completely followed. For one, the developer directly developed the code in Test Instance and not in the Development Instance. Secondly, the developer himself (not the Tech Lead) moved the code (.rdf and .ldt) to the Test Instance in Serena. While creating the .ldt file for this specific request to move to Serena, the developer copied the .ldt files of all the objects in Test Instance and moved the same to Serena. While copying the .ldt file, the developer did not follow the basic review process of reviewing the log file. A review of the log file would have helped him to realize his mistake.
On confirmation from the Developer, the Tech Lead moved the code from the Test Area in Serena to the Production Area in Serena and asked the DBA to move the same to Production. The DBA Team picked the code from the Test Area in Serena and moved this to Production as per the request raised by the Tech Lead.
Since the Test Instance was more than 2 months old, all the reports that were modified in the last two months had the wrong .ldt file in the Production Instance !
The complaints started pouring in after about two days. The DBA Team under Manager2 was asked to analyse. They identified the issue and steps were taken for rectification.
Also, the developer who made the mistake was advised to be more careful in the future.
While the issue was under analysis, we had a management meeting. In this meeting, Manager2 highlighted the same as ‘Violation of Serena’ process. Manager1, a veteran in the Industry, took affront at the issue being presented to management without the same being discussed internally between the teams. He felt that we should have waited for a thorough analysis and taken the issue together to the management, rather than, in his perception, one team trying to do ‘one up’ on another team.
Fair enough.
Our organization follows an open culture. We believe that it is better to bring out issues in the open as soon as possible. This will ensure that they are resolved quickly. The objective was to avoid conflicts and blame throwing that follows an unresolved issue. Given the culture of the organization, it was expected that even an expected issue should be presented to the management rather than the same being kept within various teams. This would build the health of the organization and lead to better analysis.
Our organization believes that ‘Crying Wolf’ is better for everyone. Issues gets escalated, reviewed and resolved quickly if brought out in open.
The point made by Manager1 was escalated to the management. Management understood the sentiments of Manager1 and instructed both the teams to analyse the issue and resolve the same quickly. Management also instructed both teams to present a single presentation in all the future meetings. This would ensure effective co-ordination between the teams.
One would have thought that the issue is resolved. It was not to be.
This means that there were two issues. One, the violation of Serena Process. And two, the hurt sentiments of Manager1.
Manager1 started writing nasty mails to Manager2. He focused on identifying the various mistakes committed by the other team. He started looking into mails as old as a year. He started ‘Shouting’ in his emails, by writing in all capital letters.
The members of DBA Team took offense to the tone and tenor the mails.
Our organization underwent a minor restructuring a year ago. Prior to that, Manager1 was handling both the teams. The organization decided that the team was too big to be run by a single person and divided the teams into two and brought the new team under Manager2.
There had been issues with these two Managers in the past. I as the boss of Manager1, had, on multiple times, counseled both managers of the need to work together. I had told them that our teams were new and the Organization had high expectations from the team. Still there were occasional flare-ups and this was the latest in the series.
As the manager of Manager1, the onus was on me to diffuse the situation.
Always in similar situations, there will be many stakeholders. Some of the stakeholders were visible, the Organization, the company management, me, Manager1, my boss etc for example. There were invisible stakeholders too, mainly the teams that report to the Managers 1 and 2.
The first thing that I did was to inform my manager that there was a conflict situation and that I needed his support to resolve this conflict. He offered all the support that he could provide to help me resolve this. That was a relief.
There was one more advantage to this quick escalation. My manager took it upon himself to inform this issue to the senior management. That enabled me to focus on the issue at hand.
My approach to resolving this was to look for win-win. I made a note of the ‘wins’ that should accrue to each stakeholder.
- The Organization was looking at a quick resolution to the issue and return to normalcy.
- The management of the company was looking at an amicable resolution that will strengthen the teams once the issue is resolved.
- Manager1 was looking for an opportunity for his grievances to be heard, he was also looking for a clarification of the basic issue and a clear guidelines for the future.
- I was looking for a very good resolution that will strengthen the interaction between the teams rather than weaken the same. The basic issue should be brought out, the mistakes made by various stakeholders had to be pointed out and processes should be put in place to ensure a smoother functioning between the teams and personal references to be avoided at all costs.
- My manager was looking for a quick and amicable resolution that will lead to lesser escalations in the future. He also wanted to convey to the management that both the teams comprised of mature individuals who can amicably resolve a conflict.
I had observed that many a times,
in such situations, the issues soon deteriorates into the level of
Personalities thereby clouding the issues. I was determined not to let this
happen.
I called a meeting between the two teams. As an introduction, I informed the Manager1 that his behaviour was unacceptable and that was creating disharmony within the organization. I informed him that he had to take personal responsibility for creating this disharmony. I pointed out to him that he was a valuable player of the team and that he was a cog in the wheel of the team. I brought in context by pointing out how his actions were impacting others in his team and in the other team. It was obvious that he understood the consequences of his action.
I moved on to the actual issue that had caused this flare-up in the first place. We quickly identified a process gap and a communication gap that led to this issue. At one point in the Serena process flow, there was a clash of ownership. I quickly plugged this gap by making Manager1 the complete owner of the process.
Then I asked Manager1 as to the cause of his abnormal behaviour. Initially hesitant, once he started he poured forth a litany of complaints against Manager2 going back almost a year. We identified that there was a lot of communication gap between the two teams which had over a period of time deteriorated. We discussed with the concerned managers and put in place a communications mechanism which was supposed to bring out the issues out in the open at an earlier stage in the cycle.
That was it. The issue was resolved as quickly as it had come. Everyone had got their wins.
This was a perfect win-win for all.
No comments:
Post a Comment