|
|
This is a series of posts that I am writing about the dynamics of a team, and how it came to be that we started getting push back from the team about pushing them too hard, which lead to a series of introspective discussions (Pushing the team too hard) about whether we had gone too far, and what should be the next steps. In the previous post, I started writing about how the team was being pushed to be more aggressive, and this in turn was causing additional risk to projects that the team was taking up.
In this post, I will be talking about the problems that an aggressive manager was inadvertently causing to the team. Morale of the people involved is a big deal for teams that are supposed to be highly productive, and the organization needs to continue doing efforts that would make sure nothing is happening that would reduce the morale of team members. However, this can get problematic when you have a manager who can put a lot of pressure on team members to the extent that this would reduce morale and make them feel down and out.
As part of the efforts to improve the productivity of the team and make it a top performing team, the organization brought in a new manager who was reputed to turn around teams. The manager was a high energy person, and you could see that fairly fast into his introduction into the role. He would monitor implementation of projects, directly moving among the team members and had a good idea about team members who were effectively shirking work. This tactic worked pretty effectively, since it also encouraged the various team managers to monitor the performance of their team to a greater extent and ensure that anybody shirking or not working as much as required was spoken to and provided feedback.
However, there is a fine transition between being aggressive and starting to cause frustration in the team members. When people believe that they are working at a good pace and feel proud of what they have accomplished, they seek to hear good words; but when you have a person who can be aggressive, it can turn out pretty good in terms of driving the team (but this happens when the team members believe that the overall manager is actually a great driver and visionary and then neglect or ignore his hard driving efforts). However, if the team members start to feel that the manager is actually not appreciative of their work when they have put in some great effort, it can be very bad for morale.
In our case, this is what was starting to happen. The manager would push people to get work done fast, and for some time, those team members who liked doing great work were very impressed. However, when they could see that the manager was all about push, and more push, and it was hard to actually hear some words of praise from the manager, there started a wave of people expressing issues or feeling hurt after the interaction with the boss. What made it worse was that the team members would share their own stories, and this made the issue of morale even more difficult; and of course, since the team was performing at a high level, the manager was seen as a success story.
However, after this much analysis, and after the HR Department also got involved, the management prepared an exit path for the manager and decided to bring in another manager who was passionate, but who had also got a reputation for appreciating good work.
Continued in the next part …
| Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness |
How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results |
Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity |
|
|
|
The previous post (Pushing the team, maybe too hard) detailed some of the problems that a team that was under-performing started experiencing when it decided that it would not longer under-perform and started to move up the performance chain, but in the end, the focus on productivity started taking a toll on the team members. There were a number of factors that were not considered when it started becoming a bit more clear that the team was getting fatigued.
One of the biggest factors that we had to re-consider was the notion that we would not say no to a request or a project without doing a lot of deliberation, and if there was a chance, then we would be aggressive and push for doing the project. This worked beautifully for a while, since earlier we would be conservative, and when we would do a resource and risk assessment, if there was a chance of some risk (around 20-30%), we would say no to the project. This was giving the group the title as a No saying group. So, we worked hard at this aspect. Over a period of time, when a project was proposed and we were evaluating the project, we would do a calculation of the risk, but we would also do a strong focus on seeing whether the risks could be mitigated. So, when there were risks, senior members of the team which was doing the evaluation would be encouraged to take a look at the risks, and see whether there were steps that could be taken to manage these risks, and even if this required extra effort, it would be worthwhile to take the extra effort and get these things done. In addition, an incentive was given to the team, in terms of promises of higher rewards for higher productivity, and with differentiation between team members based on the effort that they would undertake (and this was a big deal in terms of encouraging people – if many team members felt that extra effort was being recognized, you had several of them putting in an hour or two of extra effort on a daily basis in order to show that they were capable of doing more effort).
Well, all this had the desired effort. This factor about being more aggressive had an important effect on the reputation of the team, and we were being known as the team that could get work done that seemed more difficult for the other teams. But, at the same time, there was a risk in terms of what we were doing. Since we were taking more chances on the risk front, we were pushing the envelope, and this did hit us in a couple of occasions where we ended up taking last minute risks with the project, and in one case, had to get people from other groups, else the project was a goner. These cases did cause some amount of re-thinking, but not a drastic change in policy, and we continued on. So, what were some of the pointers to the fact that we were heading towards a case where we were trying to chew more than we could do ? Well, for one, we had people from other teams and from senior management asking the team management whether we knew our limits / constraints, and was our risk calculations on the right side of sanity ? These queries were coming up more recently, and these also started a re-think on the level of aggressiveness we were following.
Continued in the next part …
| Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness |
How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results |
Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity |
|
|
|
The topic for this post came up from a recent discussion that we started having. The managers of the team were astounded when, at yet another weekend, when members of the team were called for work (since yet another milestone was approaching), almost 90% of the team came up with excuses individually, and finally, the managers were shocked and decided to not call the team for the weekend. This particular episode led to some soul-searching about what is the right thing to do, and what this mean for the future, since the team is in a group which believes that hard driving is something that is part of the job.
So, there was a discussion that was animated about the reasons, and whether this is part of a trend. This was also true because overall, one could see that the number of leaves that people were taking had also increased (people never seemed to be able to fully use up their leaves, would go in for cashing in of the remainder of the leaves, and now suddenly, we had more cases of people having to be docked part of their salary since their leave balance was getting to be very high).
Following were some of the points of the discussion, and what we ended up concluding (and if employees / managers of other companies are reading, and are in a familiar position, do let me know through comments, since we are looking at modulating some of these points and seeing whether there is something we are missing).
There was an immediate conclusion that probably we were pushing very hard. Around two years back, we had got some feedback from top management that analysis had shown that our group had a productivity level that was in the lower half of the company, and this was hurting revenue (and also hurting margins, which is a big issue). Based on this, there had been some changes in middle management, with more aggressive managers drawn in, who proceeded to light up a fire. We actually called several meetings of team members to show them data, show them the analysis about costs and revenue, and compared this with other groups and across the industry, always with the unsaid announcement that such lower productivity levels cannot go on, and the company might be forced to go in for harder steps.
We started monitoring data around productivity much more closely, and there was a realization that we needed to see multiple quarters where the productivity levels of the group went on increasing. Hence, managers were pushed to keep on pushing their employees, and for some time, people kept on working with this trend, since the information about the previous low levels of productivity remained in their mind. The attempt was to use this information to push the group into a higher performing group within the company, a group that would star appearing in company reports as a group to emulate, the one that would win awards within the company for its performance.
And, this worked. People were pushed for their performance, people were pushed to do better, were pushed to spend more time on getting things done. Maybe, the rush to make these changes went without a check limit, since the team started feeling strained, and you could see people getting more listless, less enthusiastic when somebody suggested that there was an immediate deadline around the corner that had to be met.
Will continue this in Part 2 ..
| Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness |
How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results |
Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity |
|
|
|
In previous posts (bug ageing and processes), I have been talking about the importance of bug ageing, and in the previous post, I talked about some of the reasons for tracking bug ageing and ensuring that bugs do not delayed in terms of when they are finally seen by the development team. In this post, I will talk about more reasons for ensuring that bug ageing is critical to monitor for the team:
- Morale. We have found that it makes a lot of difference to the overall morale of the team, and specifically of the QE members of the team. Consider the case where a member of the team does his / her job, finds bugs and like anybody else, expects that those bugs will be seen. However, when a number of bugs are not seen for many weeks or months, the QE starts feeling dispirited. In one particularly bad episode, we had a situation where as many as 30% of the bugs were only getting looked at after around a month. The QE manager was finding it hard to control issues of morale where the QE team started feeling that their work was unimportant, and even regular assurances were not making any difference. You have a happy team and good team dynamics when team members feel valued and feel that whatever work they are doing is respected.
- Attrition and bugs devolving on other QE: We felt this most critically in a couple of cases, at a time when attrition rates had gone up. In such times, for some critical bugs, by the time that the Dev team members had started looking at the bugs, they found that the QE who had filed them had actually moved off the team, and the time it took to resolve these bugs was at least double the time it would have taken if the original tester had been looking at the bugs, rather than somebody else who had to go by the steps and assume that whatever was written was the correct sequence in trying to reproduce the defect. This problem has led to bugs not being found again when they were attempted to be reproduced.
Based on the factors described in this post and in the previous posts, it should be clear that bug aging is an important factor that any development team should take into account as part of their bug tracking processes.
| Software Testing |
Lessons Learned in Software Testing
|
Introduction to Software Testing |
|
Software Jobs If you have the following profile, and are looking for a job in India or in the US, please send an email to getitjobsindia@gmail.com
1. Software developer in Java / C / C++ / C# with experience more than 2 years
2. Software quality tester with experience more than 2 years
3. Product Management for a software company
4. Program Manager / Project Manager for a software company
5. User Interface Designer / Graphics Designer / Visual Designer
6. Tech Writer
7. Software products support
|
Recent Comments