Structuring Teams

Problem

It's likely that you will not have product management or design for infrastructure, but there will be an engineering team focused on these types of things. This is an instance where it is okay that they do not totally map one for one. However, all features or end user facing products should definitely map one to one as matrixed teams.

Actions taken

• Have the teams focus on a set of metrics or goals by which they measure their progress. Then, you can have the PM pull the data if you are a small company and/or one analyst and designer stretched across a bunch of different things.
• Make sure that the engineers start to become dedicated.
• Stay plugged in as a leader. Think about the organizational structure working every year to six months. This does not mean that it needs to be changed, but have it work more as a validation process to understand the things that pop up, priority shifts, and changes amongst people.
• We struggled with business lines as we went back and forth between whether or not we should have a general manager who owns all operations or cross functional teams with some loose general manager type of responsibility. Eventually, we leaned more towards the latter because we weren't really big enough to have a true general manager. We made sure all teams had different goals, target audiences, and metrics.
• Ideally you want PM's dedicated to each of the different teams, but the reality is that you probably can't afford that. You want to prioritize in a way that can be mirrored by the management team. Do so by having your stack rank of things that need to be done in alignment with the objectives that the CEO had set, as well as, the resources of the teams.
• If you find yourself not having enough time to dedicate to one team because of priority issues, you may have to go to your manager and let them know so they can help you make that happen.

Lessons learned

• Organizational plans get dusty very quickly. You almost want to think about them as if you were walking on the grassy path between two buildings. You want to find that middle part in the grass that is worn out and create a structure around that.
• Usually with GM's, you tend to have a lot more waste and duplication when it comes to reporting back on things. If it becomes more centralized however, there will be less of that, but you lose a little bit of the command and control that you get by having a GM. We tried to blend both so that there was a lead, even though people still functionally reported.
• Once you can put two to three engineers on a problem, there is more ability to dedicate a team to it. A lot of responsibility weighs on engineers in small quantities. A group of three engineers will find themselves having to do everything. However, if you have closer to 10 engineers, you can probably split them into two to three teams for a more balanced approach.
• If the lowest team on your priority list ends up getting the most of your time just because they are the squeaky wheel and need the most help, that is a problem. There is no way to fix that besides discipline and hard conversations.