Leading in Times of Organizational Uncertainty

This is a guest post by Peter G. Walen

Change is probably the only thing we can count on when working in tech areas. For teams to continue to function effectively and deliver value, leaders must get in front of the organizational change management curve and actively engage the uncertainty their teams face.

There’s a secret that many organizations don’t seem to know about. If they did, it is likely they might do things a little bit differently. Here’s the secret: Being a leader requires the “soft skills” most tech organizations downplay as less important than the hard, technical skills.

Management (including being a “team lead” or “supervisor”) takes a different set of skills than those of an individual contributor. As with most things, simply having had a manager does not qualify you to be a manager. You might have experienced behaviors to avoid thanks to bad managers, but that does not automagically give you what you need to be a manager, let alone a leader.

I realize that, particularly in technical, knowledge-work environments, a manager/leader needs a solid understanding of the ins-and-outs of the actual work. They need to “get” the problems facing the teams. They need to “get” the other obstacles the team will likely encounter.

Over the years I’ve seen many different versions of this play out:

There is a person who is good, sometimes very good, in a technical role. They find themselves at the top of the pay scale for an “individual contributor” and have nowhere else to go. The company solves this by “promoting” them into the lower ranks of management.

Most people working in tech of any sort have seen something like this. It makes perfect sense much of the time. The problem arises when that is as far as it goes.

Under normal circumstances, most people can muddle through. They won’t be very good at the outset, but with diligence and determination, they might become a good manager or leader. Other people simply won’t cut it at most organizations.

When the predictable world is shaken and the safe, known patterns are disrupted, problems are revealed.

Modern Test Case Management Software for QA and Development Teams

Change

When change impacts an organization, those impacted the most are often the furthest away from the decision-making process and information around the reasons, methods and purpose of the change. They also tend to be the most removed from meaningful, accurate information about what the change means to teams and individuals.

Team members will be looking to their leads, supervisors, and managers for guidance and reassurance. It is incumbent on the management chain to share what information can be shared, even if the message is “I know as much as you do.”

Ideally, one might expect the follow up statement to be something like “I’ve asked and am not getting any answers.” An even stronger statement could be added. Something like, “As soon as I get an answer, I’ll share it with everyone.” The point is to present a calm, reassuring message to the team.

Unfortunately, many tech workers promoted into some level of management often do not get the “soft” skill training they need to be actual leaders. This results in the people doing the work, the ones the organization needs to keep producing good work, and the ones impacted the most by the uncertainty, getting no feeling or measure of if they will be “OK” during the change. Instead of empathy recognizing their concerns, there is no response.

Here’s what I mean.

The Realignment

A few years ago, a company I know of announced a large “realignment” that would require all staff to learn specific development and coding skills that needed to be common to all team members in all teams. At the same time, it was announced that the entire team would be responsible for testing and writing test automation scripts.

Some people began speculating over what this could mean. Everything from “everyone is being fired” to “we’re all getting promotions.” Neither were true of course. The balance of the rumors involved variations of this. There were some training courses made available. However, most required on-site participation, even though a good portion of the people who needed the training worked remote, and travel for the training was not approved.

Some supervisors were very direct, telling people they did not know what was happening and perhaps it was time to “find a new job.” There were internal positions that could be applied for, and the offer of internal recommendations seemed pretty good.

Some supervisors were more nuanced saying “Maybe this is a time for all of us to re-evaluate what we want to do.” These talked with people from their team who seemed vulnerable. They spoke in reassuring tones of using this as an “opportunity” to consider what it is they really want to do. They spoke of how they were doing the same thing and it helped them feel reassured a bit.

Some supervisors said nothing at all and would allow no speculation in team meetings.

There was a mix of rumor and speculation. Many of the team members who felt most vulnerable found they had no one to turn to for real information or advice.

Roughly nine months after the initial realignment announcement, it was announced that anyone not demonstrating “proficiency” of specific tasks would be let go. This included a ramp-up time for proficiency in demonstrable coding skills. When asked about a corresponding ramp-up time for people to learn testing and test automation, there was no answer.

The organization’s leaders were failing the people who depended on them. Some 18 months after the original announcement, 80 people, around 90% of the people most vulnerable and less than 3% of the total number of employees from that organization, had their positions eliminated.

Some were absolutely blindsided. Some had been bracing themselves as best they could. Some could not believe how they had been treated by a company that talked about “family.”

The next release to customers was delayed by over 2 months.

The Acquisition

A few years ago, I was working for a small company that was growing and growing rapidly. The customer base was growing. Customer satisfaction was improving steadily.

Then the company was bought by their largest competitor.

It was announced that nothing was really going to change “for now.” Also, the stock options were transferred over and everyone got a fair-sized bonus check from this. Then a short time later, emails went out about a series of meetings everyone would be in within a few weeks, instructing employees to keep calendars open over three specific days.

Some of the employees warned the rest not to spend the money from the bonus, and not to make any significant expenditures. They said they had a “bad feeling” about what was happening. …

People began getting emails from people at the new parent company about responsibilities and how they might contribute. People were scheduled in to “interviews” with “experts” from the parent company about how they could contribute to the new structure.

Some people asked questions and had those answered almost immediately. Other people asked questions and got no response.

Here, the immediate team supervisors presented the information they had, as clearly as they could. Even in private conversations, the message was “I’m not getting any new information from the new org. I know you aren’t either. Everything I have I’ve shared…”

In team meetings, supervisors and managers spoke calmly and reminded people that we had customers waiting for what we were working on. They encouraged them to stay focused on our customers’ needs and what we could deliver. In private, they shared anxiety and concern, but in meetings and outside closed doors, they projected professional calm.

Upper management shared nothing with managers and supervisors. This is not uncommon in acquisitions, particularly when there will be significant reductions in the acquired company. And this is what happened. Just over 30 days after the acquisition was completed, every manager and supervisor except one was walked out the door, replaced by supervisors from the acquiring company. With them went roughly half the employees.

Two weeks later, the next major release was deployed to customers, one week late.

The Lessons

In both these instances, people turned to other team members for advice and confirmation. These unofficial Leaders helped provide a space where people could express their fears and anxieties in a space free of recrimination. They helped fill the void by speaking from experience and what they had seen in the past.

Informal structures can help contribute to team continuity and support supervisors and managers. However, for that to happen, managers need to stay involved and in contact with their teams.

People who would be leaders cannot afford the luxury of publicly worrying about their own jobs. They cannot afford not supporting their teams and allowing their own fears and concerns to overcome the needs of the people they are expected to lead.

Teams being successful depend in no small measure on the team believing the lead, supervisor and manager have their back. Developing the trust of the team takes hard work on the part of every leader, particularly those who are new to leadership, or those for whom a sense of empathy and emotional connection does not come easily.

The “soft” skills needed to support a diverse team and engender trust are among the most difficult skills for a leader coming from a technical background to master. Without those skills, and the resulting trust, their teams will not reach their potential, and will be hard-pressed to weather periods of uncertainty.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform

Peter G. Walen has over 25 years of experience in software development, testing, and agile practices. He works hard to help teams understand how their software works and interacts with other software and the people using it. He is a member of the Agile Alliance, the Scrum Alliance and the American Society for Quality (ASQ) and an active participant in software meetups and frequent conference speaker.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

Agile

Agile QA Process: Principles, Steps, and Best Practices

The agile QA (Quality Assurance) process is a set of practices and methodologies aimed at ensuring that software developed within an Agile framework meets the desired quality standards. It aligns with Agile development principles, emphasizing collaboration,...

Agile

Regression Testing in Agile

In TestRail, you can triage risks faster by monitoring the progress of all your regression testing activities in one place

Agile

Crafting a Robust Test Strategy: 6 Key Approaches

Effective testing isn’t a stroke of luck; it’s meticulous planning. Detecting and resolving issues early is the crux. This necessitates a well-crafted test strategy that sheds light on the entire testing process.