Separation of concern, just not in code
`Concerns` is a term used in computer science for scoping out the different behavior of the code and `Separation of concern` is a design principle for separating a computer program into distinct sections. I like this philosophy as this tells you how important it is to keep your code organized by separating concerns. The same applies to how you organize your engineering teams as well. There is a need for understanding, organizing and separating concerns of individuals. When the concerns/objective are separated you get a clear focus. With clear focus comes in quality and speed.
The first thing which is important is having goals for teams. Having clear goals brings in focus, which helps the team members plan things accordingly and it brings speed & quality. Also, a team should not be very small, and it shouldn’t be too big. Your team members should be capable of working end to end. When I say end to end, it is with respect to stack not with the diverse knowledge of code. Having full stack teams reduces dependencies and you can ship finished products instead of components, which would then need to be assembled by someone. That would result in a lot of cross talks, wastage of time over communication across a wide set of things, etc.
Next is separating concerns of individuals. This will bring in more ownership approach, which gives individuals confidence in making decisions. And if the decisions are being made, trust me you will automatically start moving faster. Most of the time what slows us down is the lack of decision-making process or decision makers. Data, facts, arguments etc. might support everyone’s perspective, but you cannot move forward in all the directions, you need to choose one and move. To find the right direction we start evaluating everyone’s argument which consumes time, you have to be quick with that as well. Now you will say that if I don’t cover up all the angles I might end up making a wrong decision, to that I will say that if you waste a lot of time just to find the right approach you will be too late. Fine, let’s take a decision. But wait everyone is right, in which direction should we move forward. That’s where the decision maker comes into the picture. He/She is the one who takes that risk and responsibility of moving in a certain direction. He/She might be right or wrong but that you will come to know only if you move forward. If you are just stuck on deciding what’s right you won’t be able to move forward. Hence, one of the concerns is decision making. So identify individuals good with that and vest them with that responsibility. This will just add another booster to your team.
So building teams with separate concerns, and identification of decision makers will help you move way faster than you can imagine. I have seen engineering cultures with flat hierarchy having a potential of 2x working at x just because of lack of these simple structures, this won’t make your organization an MNC, this would just add a bit of professionalism to your company and let you scale. This would help you produce leaders which will then be very valuable to you when you scale to larger organizations.