You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 7 minutes
Reorganizations happen constantly in growing tech companies, and they often leave engineering teams directionless and demoralized.
Reorgs have always been stressful ordeals. But in the AI era, priorities are shifting faster, and job insecurity sits closer to the surface than most people admit. What can leaders do to get teams back on track after the fact?
This is a question I wrestled with after inheriting a team that had been through multiple reorganizations and was scrambling to find impactful work. Rather than waiting for leadership to assign purpose, I proactively experimented with a four-step approach that transformed them into an energized team consistently delivering impactful projects.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Understanding what the team was facing
To understand why these four steps mattered, you need to know what my team was actually dealing with.
The repeated reorganizations had created damage beyond just feeling directionless. My engineers were frustrated with a pattern they’d seen play out multiple times: they’d build systems that would then get moved to another team. Or they’d finally find their purpose only to have it taken away because another team was doing the same thing. This lack of ownership bled into unclear career paths and feelings of irrelevance, which created real apprehension about job security.
During 1:1s, I heard things like:
- “We lack a backlog of work and I feel like our team always gets put into work that others don’t want to do.”
- “When we finally found something that we’re responsible for, it gets taken away from us.”
- “I want to grow into a senior engineer, but I’m not sure if this team has the right opportunities for me to grow into that.”
The disengagement showed up in meetings. There was pent-up negative energy. Whenever new work came up, the team would question it with “are you sure this is what leadership wants?” They’d become defensive and skeptical because they’d been burned before.
Here’s what made it complicated: other teams saw us as the most helpful team because we never said no to doing work or helping launch their priorities. But internally, we were a team that worked on siloed projects.
The team was worried about being disbanded. Even though they were frustrated with the situation, they genuinely liked working with each other and didn’t want to lose that.
The challenge was about proving our value as a team so we could own something meaningful and stop being the catch-all for everyone else’s overflow work. Simply assigning them more random work wouldn’t fix this. Waiting for leadership direction would take forever, given how many priorities they were juggling.
What they needed was a way to find genuine purpose that we could own and defend, and a sense of agency in shaping our own path forward.
1. Diagnose the real gaps
I started by talking to my immediate manager about high-level organizational gaps in a bid to move beyond assumptions about where our team should fit. But the real insights came from conversations with people actually doing the work.
I reached out to cross-functional partners and engineers, especially those adjacent to where we might fit.
Questions that worked well:
- “What have been the biggest pain points when building out a new user experience?”
- “What problems do you wish someone was solving?”
- “Where have we been getting the most incidents?”
- “Which step in the user journey has it been taking long to deliver given the complexities of our systems?”
What I was looking for were patterns. Not just complaints, but systemic issues affecting multiple teams. These conversations revealed that teams were duplicating work, trying to solve the same underlying problems. It was creating inefficiency and inconsistent user experiences, which are classic signs of an organizational gap.
You want to distinguish between genuine organizational needs and team-specific frustrations. A genuine organizational need shows up in specific ways: it’s slowing down product launches, requiring too many teams to ship one thing, or forcing teams to build bespoke solutions for the same problem over and over.
In my case, I knew we’d found something real because user experiences hadn’t been updated in a while, and delays were preventing the business from getting quick learnings to iterate on what users actually wanted. The duplication was costing us time, money, and the ability to move fast.
2. Find your team’s unique value proposition
Once I had a list of organizational gaps, I had to figure out which ones my team was actually positioned to solve.
I evaluated each gap against our capabilities:
- What technical expertise did we have that was relevant?
- Did we have the right skills, or could we learn them quickly?
- Would solving this leverage our existing knowledge and relationships?
- Was the scope appropriate for our team size?
But I also thought about strategic value:
- Would this challenge and grow my engineers?
- Does it connect to broader company goals?
- Would success position us well for future opportunities?
- Could we realistically make a significant impact?
In our case, the team’s background was a perfect fit for the organization’s need to consolidate account management systems. The scope felt manageable, and success would mean owning a critical path that multiple teams depended on. That gave us both purpose and influence.
When I raised the account management consolidation opportunity to my team, I didn’t just present it as “here’s what we’re doing next.” I framed it around what they cared about: we’d be adopting both web and mobile surfaces, the system hadn’t been refactored and needed simplification, and this work would have real visibility across the organization. I also made it clear I wasn’t prescribing a solution, and they would fully own the technical strategy and how to solve it.
What made this different from the work they’d been doing before was that this was an actual system they would own, with room for it to evolve over time. It wasn’t just executing someone else’s plan. The technical challenge excited them, and for the first time in a while, they’d be tackling the same problem together instead of working in silos.
Through continuous conversations as a group and in 1:1s, I made sure they understood this wasn’t just another assignment. It was their opportunity to shape something meaningful.
3. Shift from reactive to proactive ownership
Finding the right domain gave my team purpose, but they still needed to feel genuine ownership over the approach. I had to transform our dynamics from “tell us what to build” to “we know what needs to be built and how to get there.”
To get there, I started inviting my engineers to roadmapping conversations, which had originally been held just between my product partner and me. Here, they received context on what we needed to improve technically to achieve product goals and influence how we planned for future cycles. For quick updates, I’d relay information during standup or through Slack, but the key was getting them directly involved in the planning.
I also gave my team full autonomy to design system architecture and make key decisions about what our systems should look like. My role shifted to providing the tools and resources they needed to succeed, while reminding them not to reinvent the wheel when existing solutions could work.
The transformation was obvious when engineers started engaging beyond our team boundaries. They got more involved with the teams we depended on and the adjacent teams that depended on us. They found confidence in their work and could articulate how our systems fit into the larger ecosystem.
4. Make your impact visible
Even when your team delivers great work and feels ownership, that impact can go unnoticed if you don’t actively make it visible. I learned this lesson the hard way.
Stakeholders wanted to deliver a new product that required new technical functionality on surfaces my team owned. Without understanding our technical roadmap, they expected us to deliver the product immediately. But an underlying system needed to be built first before we could even think about supporting the new product.
When we pushed back on their shorter timelines, we faced intense pressure. This could have been minimized if I had initially volunteered my team to present on the system they had to pre-build. Presenting to stakeholders would have created empathy for our work. Importantly, it would have helped them understand the sequencing required and how the technical work enables business goals. Showing them the dependencies, explaining the foundational work needed, and helping them see how investing in the right technical solutions now prevents problems later was the key.
When stakeholders finally understood our approach, they started favoring generalized solutions that could be reused across different use cases. This prevented duplication of effort and created more sustainable technical practices.
Making it work for your team
Reorganizations don’t have to leave teams directionless. You can’t control organizational changes, but you can control how your team responds. The key is shifting from passively waiting for clarity to actively creating purpose and ownership.
If your team is struggling with purpose after organizational changes, pick one step to start this week. Schedule conversations with three peer managers to understand their pain points, or bring your team into your next roadmapping discussion. Small changes in how you operate can create significant shifts in team motivation and effectiveness.
Purpose isn’t something that gets assigned to your team; it’s something you actively create by connecting their capabilities to organizational needs. When engineers understand not just what they’re building, but why it matters and how they can influence the outcome, they transform from executors into owners.
