You have 1 article left to read this month before you need to register a free LeadDev.com account.
Changes in priority, scope, or personnel can leave teams feeling unsettled. Knowing how to properly combat these shifts to improve performance and morale is a key skill when leading engineering teams.
“The only constant is change.” It’s an often-said, but not particularly helpful statement. Especially when you’re in the midst of a transition that’s proving to be distracting, overwhelming, and difficult to navigate. As a developer, working through change requires leadership and intentionality. But how does one lead through change?
Tackling scope changes
Most of us are familiar with changes in scope. Commonly, people dealing with an increase in scope are being asked to do more with less. This could be through adding new features, speeding up processes, or addressing previously unknown requirements.
Despite how frequently these shifts take place, most of us have not become any more comfortable maneuvering through them. More often than not, because we have usually experienced these challenges firsthand, our initial reaction is one of concern. How badly could this all turn out?
Important questions to ask when navigating scope changes
When initially confronted with scope changes, you have to start by giving your team the opportunity to lay it all on the table. Where do they see challenges arising? What knee-jerk reactions of fear are they having? Calling out the icebergs you’re trying to avoid provides you with a more complete picture. Only once you have addressed these pain points can you get to work tackling this new problem.
Scope changes require the team to get candid; be honest about the team’s capacity to complete their workload.
Start by breaking all your obligations down into the smallest reasonable tasks. Get honest about a realistic timeline for that work; avoid a “best-case scenario” because we know that won’t happen. Look at the other responsibilities on your plate and see if there is anything you can offload or pause. Get behind your ability as engineers to solve problems, and then you can start executing.
Scope changes are challenging because the constraints are always somewhat different; timelines, resources, and complexity are all part of the equation you’re trying to solve. However, coming together as a team to tackle the challenge gives you the best possible motivation.
Changes as a response to reprioritization
Tackling scope changes is one thing, but what happens when you get two months down the road on this problem and management comes in to tell you priorities have changed? The team rallied, they’ve been doing the work, and now you have to pivot to something else.
Changes in priorities are demoralizing. Whether it’s work you’ve done that is suddenly incomplete or unimportant, or new work that you don’t find interesting or motivating, it’s often hard to get excited about this type of change.
The first step is to account for work in progress. Dropping everything and picking up new tasks in response to prioritization changes is not necessarily the right approach. Consider instead, phasing in the changes on a short timeline.
If there has been substantial investment in pieces of work that are small enough to be completed and delivered, think about doing so if it makes business sense. If some percentage of the team can hit the ground running on the initial stages of the new work, have them get started. That gives others the opportunity to focus on leaving their current tasks in a good state to be picked up down the line, and that’s a worthwhile use of time.
The thing about priority changes is that there often isn’t a lot of room to react to such a big adjustment in your day-to-day. Giving teams the opportunity to consciously pause or complete their previous work before turning their attention to a whole new challenge can help a lot.
Reshuffling of personnel
The common thread in navigating change is that it isn’t chiefly about the engineering challenges. Most of the time, it’s about working through the impact on the team that’s affected; never more so than when you’re working through personnel changes.
Personnel changes manifest in a number of different ways, all with their own unique challenges. Layoffs, re-orgs, resignations, and team transfers all have a serious impact on both team culture and the work product. Consequently, you’re forced to navigate change on a number of levels, simultaneously.
Nurture your team
If you jump straight to problem-solving the Rubik’s cube of work to be done, then you’ve already made a crucial mistake. Start by recognizing the impact on the rest of the team. Sit down and talk about it as a team or in 1:1 conversations – however feels most comfortable.
Different people will be affected in different ways. For some, the change can be a positive opportunity for growth. For others, a more personal loss of a friend and a colleague. Sometimes, it’s the uncertainty of change itself that’s getting to them. Talking about the impact doesn’t mean making everyone feel better – that’s often impossible – but pretending the circumstances don’t affect them because their roles haven’t changed is naive.
Once you turn your attention to the work that has to be done you will likely face a combination of the two types of changes discussed earlier – adjustments to your scope as a team and the reprioritization of tasks.
Importantly, you need to re-prioritize to account for the developers you currently have. Do not skip this step! If you don’t adjust priorities all you’re doing is pushing an untenable amount of work on your team. There will, however, be some scope changes. It’s inevitable. But if you’ve had the necessary tough conversations the team will be ready to tackle them.
Final thoughts
Change may be constant, but that doesn’t make it easy. The reality of leading engineering teams is that you’ll often be asked to keep moving in the face of that change; features still need to be written, bugs need to be fixed, systems need to keep running. Accomplishing that requires a clear recognition that humans are doing this work, not machines. And, as it turns out, humans are far better at adapting to change when they can lean on others.
