Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...
I focused a lot on #3 because that's where I've seen people take things too far the most.
1 & 2 are usually tied together pretty tightly. This tends to be very specific to various situations.
For example, when projects are small there is less data. A lot of decisions have to be made intuitively. Whose intuition is trusted the most? I don't think there is a right or wrong answer here. Plenty of companies have succeeded with the single product visionary.
My personal preference though is that things are discussed as a team and that teams make decisions together. I believe it gives everyone a greater sense of ownership and that will help motivate them to do better work in whatever their role is. This does require an entire team to be product motivated though. A great developer who is only interested in fun technical problems will contribute a lot to the implementation, but very little in the discussion on what to build.
Projects with lots of users have lots of data. This makes some things easier because you can just look at the data on what are important things to focus on. If there's a conversion funnel and one step has a significantly larger drop than every other step, it makes sense to work on things to optimize that step. But this is also a reactive way to build things. The product is going to get optimized, but very little actual innovation will happen. Some intuition is going to be required to balance the need to optimize existing functionality versus building new functionality. This goes back to the previous point on whose intuition to trust.
All of this is further complicated by the business. It is really easy to involve an entire team in a discussion around what to build in a consumer application. Ideally every member of the team is also a user of the product. That gives them the necessary perspective in thinking about how to make things better for all users.
That gets much harder in a B2B product since most of the team members won't be consumers. Even if they were, the person buying the software and the person using the software are often not the same people. I think product managers are relied on more here to make decisions because it'll be there job to spend endless hours talking to users, buyers, sales teams, customer support teams, dev teams, investors, etc. and find some way to balance the needs of everyone. A developer is less capable of making product decisions here because they don't have time to get that context and build software. Not unless they like working 20 hour days.
As I've learned the hard way, this is similar for education products. You can never be your own user when you're building content for others.
Once priorities are decided, regardless of how they're decided, we then have the problem of distributing work. There are more factors involved than I can list, but in general I really like standups. I think it's important to discuss where every team member is at and whether progress is going faster or slower than expected. It helps redistribution of work.
This is a hard area to say generic things about so I'll use a specific example. Let's say someone is working on a tough algorithm. They think they had it handled, but hit a bunch of unexpected use cases. Pair programming didn't make sense originally because it seemed easier at first, but now it might. So someone gets pulled off their current task and paired up because the algorithm is the most important piece.
Or maybe a feature was given a high priority, but it has taken 5x more time than expected with no end in sight. At that point the value of the feature versus the time needed to finish it makes it less worthwhile. That's time that can be spent on other things that bring value.
The hardest bit is when there is a big feature that needs to be done quickly. I think most managers these days understand the mythical man month, but there are ways to break things up to manage adding more developers to a project. At that point it's a matter of breaking up various systems, figuring out where potential merge conflicts are going to be, trying to assign as many de-coupled pieces as possible, and determining the absolute maximum number of people that can be involved before the diminishing returns turn negative. That's all very vague, but this really depends on the specific system involved.
Also, I said "standups" and not "daily standups". Sometimes once a day is not enough. I've switched from daily to three times a day to back to daily, all with the same team. It just happened to be necessary depending on the situation we were in.
I just made a very long spiel that can be summed up by: "It depends."
Would be happy to talk about specific situations if you'd like.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I focused a lot on #3 because that's where I've seen people take things too far the most.
1 & 2 are usually tied together pretty tightly. This tends to be very specific to various situations.
For example, when projects are small there is less data. A lot of decisions have to be made intuitively. Whose intuition is trusted the most? I don't think there is a right or wrong answer here. Plenty of companies have succeeded with the single product visionary.
My personal preference though is that things are discussed as a team and that teams make decisions together. I believe it gives everyone a greater sense of ownership and that will help motivate them to do better work in whatever their role is. This does require an entire team to be product motivated though. A great developer who is only interested in fun technical problems will contribute a lot to the implementation, but very little in the discussion on what to build.
Projects with lots of users have lots of data. This makes some things easier because you can just look at the data on what are important things to focus on. If there's a conversion funnel and one step has a significantly larger drop than every other step, it makes sense to work on things to optimize that step. But this is also a reactive way to build things. The product is going to get optimized, but very little actual innovation will happen. Some intuition is going to be required to balance the need to optimize existing functionality versus building new functionality. This goes back to the previous point on whose intuition to trust.
All of this is further complicated by the business. It is really easy to involve an entire team in a discussion around what to build in a consumer application. Ideally every member of the team is also a user of the product. That gives them the necessary perspective in thinking about how to make things better for all users.
That gets much harder in a B2B product since most of the team members won't be consumers. Even if they were, the person buying the software and the person using the software are often not the same people. I think product managers are relied on more here to make decisions because it'll be there job to spend endless hours talking to users, buyers, sales teams, customer support teams, dev teams, investors, etc. and find some way to balance the needs of everyone. A developer is less capable of making product decisions here because they don't have time to get that context and build software. Not unless they like working 20 hour days.
As I've learned the hard way, this is similar for education products. You can never be your own user when you're building content for others.
Once priorities are decided, regardless of how they're decided, we then have the problem of distributing work. There are more factors involved than I can list, but in general I really like standups. I think it's important to discuss where every team member is at and whether progress is going faster or slower than expected. It helps redistribution of work.
This is a hard area to say generic things about so I'll use a specific example. Let's say someone is working on a tough algorithm. They think they had it handled, but hit a bunch of unexpected use cases. Pair programming didn't make sense originally because it seemed easier at first, but now it might. So someone gets pulled off their current task and paired up because the algorithm is the most important piece.
Or maybe a feature was given a high priority, but it has taken 5x more time than expected with no end in sight. At that point the value of the feature versus the time needed to finish it makes it less worthwhile. That's time that can be spent on other things that bring value.
The hardest bit is when there is a big feature that needs to be done quickly. I think most managers these days understand the mythical man month, but there are ways to break things up to manage adding more developers to a project. At that point it's a matter of breaking up various systems, figuring out where potential merge conflicts are going to be, trying to assign as many de-coupled pieces as possible, and determining the absolute maximum number of people that can be involved before the diminishing returns turn negative. That's all very vague, but this really depends on the specific system involved.
Also, I said "standups" and not "daily standups". Sometimes once a day is not enough. I've switched from daily to three times a day to back to daily, all with the same team. It just happened to be necessary depending on the situation we were in.
I just made a very long spiel that can be summed up by: "It depends."
Would be happy to talk about specific situations if you'd like.