I'll also add that process is pretty bad at dealing with new circumstances. If your team is going to stay the same size and the challenges are going to stay pretty consistent, you might be able to lean on process, but when new challenges pop up out of nowhere, culture needs to take over for process while a new process is created.
We have a small, but growing team and technical challenge, so process is really important, but in constant flux, and it's the culture that needs to guide us in the unknown. Culture also needs to change over time to respond to new circumstances, but it's much less brittle than process.
Great article overall. Definitely jive with the lessons. What do you think @jess
and @maestromac
?
Like Ben mentioned, our processes are in constant flux which is great because we're always trying to get better and stay communicative and productive, but it also means we need people to re-buy-in every time.
@pbeekums
you expanded a lot on #3: testing and code reviews, any thoughts on the processes surrounding:
1) Ensuring everyone is working on the most important thing
2) Coordinating efforts to distribute work effectively?
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.
This is something I recently started thinking about. As someone who's tasked with handling processes, I can see it time-consuming and disruptive to other's workflow. Reading this gave me a new perspective. I really like that food-seasoning metaphor. Great stuff!
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'll also add that process is pretty bad at dealing with new circumstances. If your team is going to stay the same size and the challenges are going to stay pretty consistent, you might be able to lean on process, but when new challenges pop up out of nowhere, culture needs to take over for process while a new process is created.
We have a small, but growing team and technical challenge, so process is really important, but in constant flux, and it's the culture that needs to guide us in the unknown. Culture also needs to change over time to respond to new circumstances, but it's much less brittle than process.
Great article overall. Definitely jive with the lessons. What do you think @jess and @maestromac ?
Like Ben mentioned, our processes are in constant flux which is great because we're always trying to get better and stay communicative and productive, but it also means we need people to re-buy-in every time.
@pbeekums you expanded a lot on #3: testing and code reviews, any thoughts on the processes surrounding:
1) Ensuring everyone is working on the most important thing
2) Coordinating efforts to distribute work effectively?
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.
This is something I recently started thinking about. As someone who's tasked with handling processes, I can see it time-consuming and disruptive to other's workflow. Reading this gave me a new perspective. I really like that food-seasoning metaphor. Great stuff!