Starting New Engineering Teams
From Reorgs to New Products
Engineering teams, like any other business unit, evolve over time. When you join a company, you’re looking at a snapshot of it through its evolution. Whether you’re in a small or a large company, change is always imminent.
If you look back far enough, you’ll see imprints of previous org changes in the technical systems that survived them. There are code patterns, design decisions and old forgotten “TODOs” buried in there. This also serves as a good reminder to avoid blaming those technical decisions on anyone because a lot of it is out of the hands of its implementers. As business requirements change, so would your priorities and so would your code.
Stay stagnant, and the company might not exist for very long.
These changes could be because of updates in existing business strategy (a.k.a. “reorg”) or new business opportunities that lead to new teams being formed. Through these changes, new teams emerge from previous team structures.
This also creates a requirement to have engineering leaders who can lead these new teams. Throughout my career, I have been lucky to experience leading teams from both perspectives. The specifics might vary, but the overall strategy of leading new teams is usually the same — bring product clarity and build team confidence to deliver on it.
Let’s look at managing teams from both types of changes.
Leading New Teams (Zero to One)
One example from my experience was of a new product idea to automate complex client onboarding processes. We narrowed the requirement down to first building a service that could serve complicated client legal entities. With two borrowed engineers, we were quickly able to prototype and get quick feedback from stakeholders & engineering teams.
Only after that we talked about scaling this up and building a roadmap. Like hooking it up to an external website that could give clients a clear view of the onboarding process and to internal systems to keep them consistent with progress.
Few things that worked —
Before you begin — clearly establish the broader product goal, initial milestones and stakeholder involvement. It’s much harder to work these out later. Like if stakeholders aren’t willing to give you time to validate your progress, it’s almost impossible to build the right product.
Find the right people — You might need to borrow resources “on loan” from existing teams. This heavily depends on the skill sets needed to quickly build. Lean on the senior leadership to help get what you need.
Be agile — Quick stakeholder feedback is important to confirm you’re headed in the right direction. Be comfortable with showing throw-away work. Keep the 0–1 mentality and focus on the Minimal Viable Product (MVP).
Once the product idea is proved —
It’s important to switch towards establishing the team and product. Ensure there is consensus on team structure and a product roadmap that includes room for releasing production quality code.
Then establish team norms, roles & responsibilities to keep delivering on the product roadmap.
Leading Teams After Reorgs (One-N)
In my experience, most reorgs have been due to consolidation. Either similar teams get combined or business units merge. But there are also reorgs to support updated business strategy. Reorgs by themselves might not always make sense, or even might seem counterintuitive. They do serve an important function — to update the team structures in order to meet updated business needs.
Leading teams post-reorg requires bringing a sense of stability first. Then you can focus on (re)creating an effective team that has — shared purpose, trust and collaborative spirit.
End of the day, mentally safe teams will outperform teams dealing with uncertainty.
Few things to keep in mind —
Start with the people — As the eng leader, team will look at you for answers. Clarify the reasons for the changes, its impact and avoid leaving too many unknowns. Some details might need to be reiterated.
Update team rhythm — Sprint ceremonies, regular 1:1s, team activities, stakeholder demos are all things that help the team get into a rhythm. It also limits unpredictability.
Roles and responsibilities — Running sprint ceremonies and doing stakeholder communication are some of the responsibilities that should be clarified early.
Agree on team norms — For developer specific norms, work with the engineers on best practices. Including team documents (design, code and project) review guidelines, testing expectations and any on-call responsibilities.
Communicate up — As you learn about the team and its ownership area, it’s important to communicate gaps or structural issues to people who planned the reorg.
Eventually, things will start to stabilize.
It’s a good sign when the team starts to make decisions together.
As you see the big picture, start aligning opportunities to your reports to interests and growth areas. This will create more satisfaction long term.
Also, remember to celebrate wins and individual contributions along the way. It’s important to have recognition!
Organizational changes are crucial to a company’s growth and profitability. But their success hinges on leaders who can adapt to different types of transitions — whether restructuring or new team formation. These leaders focus on guiding teams through transitions, fostering collaboration, and ensuring a clear sense of direction for successful outcomes.
Would love to hear more from your experience and any lessons learned!
A pragmatic view on team building and reorg to nurture them for greater output…an interesting read !!👍👍