Why having a single "technical lead" to make all the technical decissions in a team might not be such a good idea
Over the past years I had some interesting experiences at work, interesting as in not bad, and I learned some curious facts about working as a team on features from their technical design to coding them. I am not a technical leader and I didn't implement any of these concepts, I just noticed them. But I still need more experience with these. That's why I am writing about this. I also have to do a presentation about this and this post is a bit of practice for the presentation.
There might be other better approaches, but currently this is what seems best to me.
So I had to work on the same team with two different approaches: one in which a single person was designed as a technical lead making all the important decisions and the other in which there was no person that made all the technical decisions.
In the first approach that person had to come up with the entire technical solution for something and all the other people had to follow and code that design blindly. In technical meetings he would just sketch out the solution on the blackboard and explain it to everyone else.
Now this works well especially in teams where there is a single senior technical person and a lot of juniors. But even then it might not be such a good idea because in order for the junior people to advance they need to practice working on technical solutions themselves too. If they are served the solution directly they might develop their ability to come up with their own solutions much more harder. They should be let free to come up with their own solution and then get their solution validated by the senior person in the team. Or it might work in teams where there are a lot of new people that don't know the application very well.
But for teams with more experienced people without gaps between them that know the software project well this approach is not so good. Firstly, one single person can never come up every single time with the best solution. It's statistically impossible and everyone screws up from time to time, he might have a bad day and come up with some bad decisions. He might not know all the areas of the application in depth, which is pretty much guaranteed in a big project. Because of this he might not come up with the best technical approach for a feature while some other member of the team with more experience in that area can come up with a better solution just because he know it more in depth with all it's issues.
The second approach involves everyone thinking and coming up with their own solutions. And then each person explains their solution at the blackboard and discuss with the rest of the team all the advantages and disadvantages of his design. Because everyone has a say in this and has to explain his ideas, the technical meetings might last a bit longer. But because everyone has to come up with an approach, the problem is viewed from multiple angles and is better understood by everyone. Even if all the proposed designs are bad, the best approach usually surfaces and crystalizes during the meeting.
A lot of times, all the ideas are partially good. In this case they might be combined together to come up with a better implementation or design. When working on complex features they have many parts each of which can be reused from each individual design from all the team members. So the final solution is patched up from each individual idea from every member of the team. This is good because a serios big feature might cover multiple areas inside an application and usually some members have more knowledge in various areas which means they can come up with a better implementation or idea for that area.
But to use this approach it takes a bit more effort overall and everyone has to do a bit of self reflection. Often times, a single person comes up with ideas faster than the rest of the team and the rest of the team stops thinking about their own approaches when they see that someone already has an idea. Even if that idea might not be the best one. So the team has to become aware of this and everyone must start to think of other possible solutions every time.
And it's tricky because it requires some objective ways to measure the feasibility and impact that each candidate solution has. It's very hard to come up with some objective measurements to prove that an idea is actually better than another idea.
Usually when members start using phrases that sound like the ones bellow they are on the right track:
- Using my approach we only have to change one or two areas in the application to achieve the desired effect instead of 6 areas or more.
- Using this approach we can reuse the existing tested code for this feature too which also reduces the number of possible bugs and duplicate code.
- Using this approach we can extend it in the future for the next planned features easily
- Using this approach we are not changing existing critical functionality and we are not risking breaking anything badly
- Using this approach we can split the feature into smaller functionalities which can be implemented in parallel by multiple team members.
- We use and display a lot of lists in our webpage. Using "X" technology allows us to easily display these lists.
- We need to use a lot of similar things to display information to the user in our webpages. We can use "X" technology because it allows us to write our own components and reuse them everywhere.
The technical lead will be just responsible for assuring that this process happens and development is done this way. He has to make sure that everyone has something to say and an idea. He also has to make sure that the final solution is the best one using objective standards and arguments as the ones mentioned above. But everything will be a collaborative process. I like this approach more because you can't screw up as much. If everyone thinks and designs a new feature then you will have your back covered by them. If your idea wasn't so good or had a serious flaw, some other team member would have noticed it. I am not a technical lead or anything, this is how I noticed stuff is done in my team.
And technical meetings should be split in 2 shorter meetings. There is a tendency or urgency to come up with a solution every time during a technical meeting which is not good. I think a bit of time needs to pass and a bit of reflection has to be done in order for the right solution to become obvious. That's why 2 shorter meetings are better for this approach. During the first meeting the requirements of the feature will be discussed and some possible solutions too. It shouldn't be longer than an hour. Anything more than that is just useless talk that leads to nowhere. After that, there should be a break ranging from a couple of hours to a day or too. During this time everyone will unconciously reflect about the meeting at least a bit and it will give them some time for things to settle down. In the second shorter meeting everything will be much more obvious and people will also come with a different perspective than in the first meeting which will give more insight into the finer details of the feature being discussed.
Now usually teams begin with the first approach but as time passes and the team becomes more cemented and experienced there will be a gradual and natural transition from the first approach to the second approach. People just have to let it happen. But this doesn't happen instantly, usually after around 2 years the signs of the second approach start to appear and after 3 or 4 years development will be mostly done in the second way. At least that's how it seemed to me.
There might be other better approaches, but currently this is what seems best to me.
So I had to work on the same team with two different approaches: one in which a single person was designed as a technical lead making all the important decisions and the other in which there was no person that made all the technical decisions.
In the first approach that person had to come up with the entire technical solution for something and all the other people had to follow and code that design blindly. In technical meetings he would just sketch out the solution on the blackboard and explain it to everyone else.
Now this works well especially in teams where there is a single senior technical person and a lot of juniors. But even then it might not be such a good idea because in order for the junior people to advance they need to practice working on technical solutions themselves too. If they are served the solution directly they might develop their ability to come up with their own solutions much more harder. They should be let free to come up with their own solution and then get their solution validated by the senior person in the team. Or it might work in teams where there are a lot of new people that don't know the application very well.
But for teams with more experienced people without gaps between them that know the software project well this approach is not so good. Firstly, one single person can never come up every single time with the best solution. It's statistically impossible and everyone screws up from time to time, he might have a bad day and come up with some bad decisions. He might not know all the areas of the application in depth, which is pretty much guaranteed in a big project. Because of this he might not come up with the best technical approach for a feature while some other member of the team with more experience in that area can come up with a better solution just because he know it more in depth with all it's issues.
The second approach involves everyone thinking and coming up with their own solutions. And then each person explains their solution at the blackboard and discuss with the rest of the team all the advantages and disadvantages of his design. Because everyone has a say in this and has to explain his ideas, the technical meetings might last a bit longer. But because everyone has to come up with an approach, the problem is viewed from multiple angles and is better understood by everyone. Even if all the proposed designs are bad, the best approach usually surfaces and crystalizes during the meeting.
A lot of times, all the ideas are partially good. In this case they might be combined together to come up with a better implementation or design. When working on complex features they have many parts each of which can be reused from each individual design from all the team members. So the final solution is patched up from each individual idea from every member of the team. This is good because a serios big feature might cover multiple areas inside an application and usually some members have more knowledge in various areas which means they can come up with a better implementation or idea for that area.
But to use this approach it takes a bit more effort overall and everyone has to do a bit of self reflection. Often times, a single person comes up with ideas faster than the rest of the team and the rest of the team stops thinking about their own approaches when they see that someone already has an idea. Even if that idea might not be the best one. So the team has to become aware of this and everyone must start to think of other possible solutions every time.
And it's tricky because it requires some objective ways to measure the feasibility and impact that each candidate solution has. It's very hard to come up with some objective measurements to prove that an idea is actually better than another idea.
Usually when members start using phrases that sound like the ones bellow they are on the right track:
- Using my approach we only have to change one or two areas in the application to achieve the desired effect instead of 6 areas or more.
- Using this approach we can reuse the existing tested code for this feature too which also reduces the number of possible bugs and duplicate code.
- Using this approach we can extend it in the future for the next planned features easily
- Using this approach we are not changing existing critical functionality and we are not risking breaking anything badly
- Using this approach we can split the feature into smaller functionalities which can be implemented in parallel by multiple team members.
- We use and display a lot of lists in our webpage. Using "X" technology allows us to easily display these lists.
- We need to use a lot of similar things to display information to the user in our webpages. We can use "X" technology because it allows us to write our own components and reuse them everywhere.
The technical lead will be just responsible for assuring that this process happens and development is done this way. He has to make sure that everyone has something to say and an idea. He also has to make sure that the final solution is the best one using objective standards and arguments as the ones mentioned above. But everything will be a collaborative process. I like this approach more because you can't screw up as much. If everyone thinks and designs a new feature then you will have your back covered by them. If your idea wasn't so good or had a serious flaw, some other team member would have noticed it. I am not a technical lead or anything, this is how I noticed stuff is done in my team.
And technical meetings should be split in 2 shorter meetings. There is a tendency or urgency to come up with a solution every time during a technical meeting which is not good. I think a bit of time needs to pass and a bit of reflection has to be done in order for the right solution to become obvious. That's why 2 shorter meetings are better for this approach. During the first meeting the requirements of the feature will be discussed and some possible solutions too. It shouldn't be longer than an hour. Anything more than that is just useless talk that leads to nowhere. After that, there should be a break ranging from a couple of hours to a day or too. During this time everyone will unconciously reflect about the meeting at least a bit and it will give them some time for things to settle down. In the second shorter meeting everything will be much more obvious and people will also come with a different perspective than in the first meeting which will give more insight into the finer details of the feature being discussed.
Now usually teams begin with the first approach but as time passes and the team becomes more cemented and experienced there will be a gradual and natural transition from the first approach to the second approach. People just have to let it happen. But this doesn't happen instantly, usually after around 2 years the signs of the second approach start to appear and after 3 or 4 years development will be mostly done in the second way. At least that's how it seemed to me.
Comments
Post a Comment