There’s something special about working with a small team, alignment comes easy and feeling heard is a norm as opposed to something you have to actively seek or fight for. This is usually a great recipe for success, and before you know it your organization is betting on your product and increasing its visibility. This usually means more hiring, and with hiring the team structure will likely change. From a single manager to multiple managers, and manager of managers, and directors of multiple disciplines. Before you know it you became a product line.
Getting alignment became much harder and we decided to split this big product line into multiple small teams so they can work more or less in isolation, like our original small team that were so successful in the past. But how do we support our new hires? Let’s make sure that every one of these small teams can have at least a senior with plenty of context so they can onboard people successfully.
Our original team ends up being split into multiple teams and the onboarding can progress, but that also means that our development speed across teams slows down since our senior developers will need time to share context and ramp up new hires. This is fine, right? But with high visibility and buy-in from the organization comes more pressure to perform and leadership (remember all those managers and directors?) are pressured to deliver more ambitious projects. Not happy with the slow down in development speed leadership decides to micro optimize.
This feature needs to be delivered in two weeks and we have this next project lined up that should be done in a month. This shouldn’t take more than one developer to tackle and half a developer to help review
This drives the sense of belonging within the team down and the stress up, we soon notice people mentioning that they need to take a break after a certain deadline passes or that people are not taking breaks at all. We also notice that the cross team communication is suffering with every team member focused on their own deadlines and timelines. People are now fighting to seek alignment and feel heard.
As a manager, what should you be aware of in this hypothetical situation?
Be aware of team micro optimizations
Few things are more demotivating for a team member than to work alone in a project while being remote, the sense of belonging deteriorates quite fast. This might yield faster results in the short term, but we are compromising our team in the long term. It’s equally important to pay attention when people are shifting around small features and projects regularly since this doesn’t give them the opportunity to feel like they are part of a single team.
Pay attention to lined up projects
It’s important for a team to have a solid and clear roadmap, but making it too time constrained becomes problematic when the team doesn’t have time to learn from a project launch and refactor or fix existing issues within the codebase. A project is not considered done if there’s no documentation for it and the code is not in a good state. Again, moving a bit slower will help us move faster in the long run.
The business will always require more, but the team comes first.
Pay attention to knowledge silos
Having multiple teams being able to tackle things simultaneously is a blessing, but it’s also a recipe for knowledge silos. As managers it’s our job to build a culture that values and recognizes knowledge sharing and that also treats documentation as a first party citizen.
Pay attention when hiring faster than the time it takes to onboard new hires
At some point your team will reach a situation where every developer with context is already onboarding one or more new hires. At this point it’s highly recommended to push back on hiring while the team normalizes their level of context. Having an idea of how long a developer or senior developer takes to be productive on a codebase helps to guide the hiring speed.
Create conditions for success
Improve relationships, improve your tools and systems, improve your communication. The team from today should be better than the one from yesterday.
Pay attention to growth opportunities
Listen to your team members and try to manage and fulfill your team’s expectations. Having a clear picture of which challenges people are eager to face and matching these challenges with the right people goes a long way to keep the team engaged and performant. If you don’t know what someone is aiming for within your team you should ask that person right now.
Be careful when you share your technical ideas
This is a subtle concept, but one worth paying attention to. As someone that is part of leadership your voice tends to carry a certain weight, and building a team comfortable enough to challenge you is not a given. By sharing a technical proposal you might be taking space from your peers to think critically about a certain problem from the ground up. Try instead to detail the current status of the system, the existing constraints and our goals and help the team to think and come up with their own solution. Ultimately the team will be responsible for maintaining that code or architecture.