People and Stakeholder Management in Times of Pressure and UncertaintyRecognizing Outside Pressures and How to Best Solve Them
26 November, 2019
I was a consultant on a program that was not doing very well. They had brought in a lot of folks, including a local person to run the overall program. I had a team of about 20 people who were in test roles and we encountered several problems during this time.
- As a program, wWe had taken onout a lot of scope and were behind in finalizingputting together a complete set of requirements as a large consulting firm. Due to this, the development was delayed and often prone to error. When featuresthings came to the test team test, we completed testing and provided feedback fairly quicklywere testing fairly quick, but we struggled with 2 things: 1) the workload was high and difficult to anticipate from a workload planning and management perspective, and 2) we (correctly) failed features often, which meant they would be up for retest in future (adding to the workload management issue). we found that it was difficult to keep up with the volume because we couldn't anticipate when things would drop. As a result, we were often passing things back saying that they had failed because they didn't meet requirements. The program was under a great deal of pressure to deliver on time - it was one of our first engagements with this client, and it was a high-visibility effort. Our test team was under a great deal of pressure because we were the final gate before feature launch. There wasn't a focus on understanding why features were failing and addressing the issue at the root (unclear requirements, no time for tech design, etc); instead, the test team was constantly being asked how fast they could complete a test to call it "done" (with the implicit message that perhaps they should inaccurately mark something as a "pass" rather than a "fail") in order for the program to pass the gate for launch. It felt dishonest, and like we were being asked to kick the can down the road and push discovery of issues to a later date, after launch). The pressure the program was we were getting was that as a whole consulting company, we needed to deliver the product which included the requirements and development complete and that it passed testing. With testing at the end, there is an enormous amount of pressure to be ready to launch.
- Program leadership implemented policies I did not agree with to drive delivery:
- A program executive stood by the office door and noted when each person left for the day (sending the message that folks needed to work late, from the office, to drive the program forward). All teams were already working long hours, and many people needed to leave the office at a scheduled time for personal reasons. This tactic sparked intimidation and fear, and wasn't constructive given most of the team would continue their work from home, and that there were limited positive results to working long hours with no rest. Along with the pressures from the testing front, we were dealing with some behaviors from leadership on the larger project that I was not particularly fond of. The program leadership would wait by the door and would write the names down of people who were leaving early.
- Every member of the program was obliged to log hours worked, which would be billed to the client. The same program executive reviewed the hours logged over the past few weeks and gave each person letter grades - A for 80+ hours worked, B for 70+ hours, and so on. If you worked the normal 40 hours, you received a failing grade. Most people on the program were working more than 40 hours on the program, but implicit in the grading was the expectation that it wasn't enough, and that excellence meant working 80+ hours per week, every week. In the course of my time on the program, 1 colleague was hospitalized due to a heart attack exacerbated by undiscovered health issues and the pressured he experienced on the program; another person was hospitalized due to severe anxiety. We also had difficulty recruiting staff to join the program, because of the poor reputation it has earned for overworking people.
- On a personal level, I had been asked to remain on this program much longer (several years), and to move to the client's city. This was not a program on which I wanted to continue working, for many of the reasons listed above. I also didn't want to leave the test team or the program in the lurch though.
- There was another scenario, wherein consulting you cataloged the hours you worked because they are then sent to your client. My issue with this was that they were then grading you on how many hours a week you were working. At 40 hours a week, you were seen as effectively failing. There was a lot of pressure that came with this not only to work late but to work an enormous amount of hours. Then on top of that, understanding when you are going to be done with testing, as if that were the roadblock of being able to launch.
- In regards to workload planning, I connected with a subject matter expert in software development test management, who happened to be an executive in another department unrelated to this program. He helped me put together a burn down report listing test cases to pass to launch and estimated time to execute test cases based on velocity; the report took into account the impact of test case failures and defects on the estimate to complete. I implemented the report and put together a process to update it daily using our existing reporting mechanisms and some manual work. The report gave program stakeholders a logical, mathematical outlook on the outlook of launch, and very clearly demonstrated the impact of defects (the existence of which was outside the control of the test team) on the launch milestone. I had to put a few solutions in place. The first being working with someone who had come on as a consultant to the consultants in order to put together a burndown chart to gauge when we would be done with testing.
- As for the pressures from the program executive, I took a few steps:
- I informed my team of what was happening, and reminded them that we had a side door, and that no one could prevent them from leaving the office if they wanted to. A second solution, although not necessarily constructive, but one that I thought was necessary, was that I told people to go out of the side door instead of the front door. They needed to be able to actually leave work to get dinner, workout, or see their family if they wanted to.
- I spoke with a previous manager who was a colleague mutual to myself and the program executive, and explained the tactics the program executive was taking. Not only did he agree with me that the tactics were inappropriate, but he also informed me that they were violations of company policies and the law (because the policies implicitly encouraged billing more hours to receive a better grade). That manager took it upon himself to speak to the program executive, and the letter grading stopped. -
- As for the letter gradings, I spoke to a mentor who knew the program manager from having previously worked together. I told him that I felt really uncomfortable showcasing to my team that they were getting letter grades for the number of hours they had worked.
- I reminded my team that they were doing the best they could under the circumstances, and that the best way forward was to maintain focus on timely and accurate test execution. I also enforced with stakeholders that I was their point of contact for status, frustration, etc., and that the test team reporting to me was off-limits - part of the case was that requests for status were (accurately) a distraction from test execution. Shielding the team from stakeholders, reminding them of the confidence I had in them, and regular dissemination of the burn down report alleviated some of the pressure on the team and allowed them to focus on their work.
- It look 4-5 months of long hours and high pressure to get to a release that, while not defect-free, was viable for launch (significantly longer than the program had initially promised the client).
In terms of actually completing the test program, we went through a good four to five months of long hours and lots of testing until we were able to just keep churning out and get to a release that was more stable. I also went to leadership and committed that I would remain on the program through launch, but would look for a new assignment thereafter, and that they needed to begin searching for another consultant to take my place. They identified a local consultant to whom I transitioned the team after launch. said that as a consultant, I would be here for the portion of the project that I owned, but that I did not want to stay long term. From there, they ended up identifying a local test manager. I then transitioned the project over to the new resource after our first release.
- The new consultant My replacement was actually pretty appalled by the pressures we were under as well. I had to point out to him that he would have to work just as hard to mitigate some of that pressure or to push it back so as to defend and hold out for his new team. I also encouraged him to strategically consider how to more effectively drive results on the team and on the program - we may have gotten that far, but the methods we used for not sustainable long term. suggested for him to think of creative ways to actually complete the work offered because we were in a position to reduce the scope for which we were supposed to be pushing out to release.
- Quantitative status reports are very effective, especially when escalating issues. Burn down charts are especially useful because they answer everyone's favorite question (when will it be done?)!
- It's a manager's job to look out for the well-being of their reports, which includes recognizing what we can and cannot do to drive work. Additionally, there are diminishing returns on effort (in hours), and there are boundaries to what we can and cannot ask of people.
- Pushing back when I disagreed with the grading method was the right course - it was against company policy and, if I had succumbed to pressure and gone along with it, I would have been in trouble with my company and with the law. (I also learned that people managers can be held personally liable in situations like these.)
- In speaking with the mentor about working hours being graded, he pointed out that it was good that I hadn't shown those grades because of it actually being a legal concern. You can not set expectations that people should be working a great deal more than expected when they sign onto the job. Also, because we were billing the hours to our government clients, they are expecting that we are certifying all of that work. Therefore, by encouraging people to work more hours, it could be perceived that we are in violation of that.
- Early and often is the rule for escalation, even if resolution doesn't happen the first time around.
- Managing up can be a full time job.
- If I could go back, I think I would have raised the flag earlier in concern to the volume of work we were expected to do.
- Having the numbers in the form of a burndown chart, something I didn't do until a couple of months in, would have also been helpful to do earlier on. I was thinking about managing a team from a resource manager perspective of workload coming in, how we knew its coming in, and how it should be allocated. At the program level, however, where we were also struggling, leadership was looking at it from the perspective of how to tell our clients approximately when we want to be done. They were also looking at a much higher level of what it means to be done. While the pressure made it look a lot like they were hammering on a single time, now that I can look at it with hindsight, they also just needed to be able to understand when they had to pull the trigger or what to do if from a quantitative approach, the work volume was too large for the resources available to complete it or alternatively if the defect rate was too high. Without that quantitative approach and just the anecdotal evidence or the information I was providing them at that point, it was not sufficient enough for them to be able to make that decision. For that reason, the pressure stayed on until we were able to show the numbers.
Maria Petrova, Principal Product Manager at Zalando details how she strategically mapped out features using a KPI tree to drive measurement, ultimately helping the development team understand their role.
Principal Product Manager at Zalando
Tarani Vishwanatha, Senior Engineering Manager at Scribd, shared a story where he dealt with the conflict of an upset engineer that did not get a promotion he believed he was entitled to. He explains the distinction between being the most technical and being well rounded. Vishwanatha talks about the importance of being self-aware as it's essential to career growth.
Senior Engineering Manager at Scribd
Stefan Gruber, VP of Engineering at Bitmovin, shares how he successfully mediated the conflict between two of his employees.
VP of Engineering at Bitmovin
Peter Maddison, Founder at Xodiac, delves into all the important details of moving legacy applications into the cloud.
Founder at Xodiac
Wayne Haber, Director of Engineering at GitLab, explains how he successfully turned a proof of concept to a full product.
Director of Engineering at GitLab
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.