While I’ve mostly been writing about the tech, lately, my primary interest has been engineering management. This note is an observation of what I’ve seen as a successful pattern being part of at least 2 new teams spawned at work.
The time comes to spawn a new team, either from a group of people that are already working together or from a mix from different groups who don’t know each other really well. This may happen for various reasons, for example, desire to give autonomy to a couple people on the team who’re already working on a pretty isolated thing, or some reorg at the company.
Forming a team may often feel uncomfortable for its members. Maybe they haven’t worked together, and they don’t know what to expect from each other, or they are frustrated by having to set up their own agenda, which before was dictated by the larger group. The team forms and now they to figure out the roadmap. Sometimes that team would be started for a specific project in mind, sometimes they’d have a blank list to work on an area that has been underinvested (“our CI/CD process has not been great, let’s start a team that would invest into that“).
To my experience, the best thing to do for a new team is to take on a less ambitious project that already has a high chance of success. This could be something that has already been well explored by others but didn’t have enough stuffing to do.
The team would have a higher chance to get that done well (compared to taking on something ambitious but complex and more likely to fail), and shipping a successful thing together will create trust between members and something to celebrate.
As they all become confident in the domain and generate new ideas on the way, this will create a solid base to take on something more ambitious as the next project. Then, having a team that trusts each other and has an exciting momentum will only increase the chance to succeed for that “high impact, but many unknowns” project.
Of course, there are exceptions to my statement. If the new team consists of senior individual contributors who already have high trust battery and domain knowledge, it might not be as risky to allow them to undertake more ambitious goals from day one. But in the rest cases, letting the team start slowly with projects that have fewer unknowns is a lot more likely to give you a healthy team that can sustain long-term.
