Home > Blogs > Local Maximum

Recall back to your college days, there was likely a time when you needed to calculate the maximum value for a given 3-dimensional function. There are a number of algorithms available, but many fall into the trap of only finding a local peak, rather than the absolute maximum. I'm sure that most of you asked yourselves whether you would ever use this in the real world. I'm sure I did, even the second time I took that infernal course. It turns out that the problem of reaching local maxima seems to occur in a team environment all the time, where it is not as rigorously understood that it is even a problem. While there is far less math involved, the solution can end up being just as difficult to implement.

In one workshop that I run, we participate in a simulation where the group is split into three teams to build different parts of a product, along with a management team to make sure the whole thing comes together. The simulation is crafted such that two of the three component parts are relatively simple to build, while one is so complex that there is no way that team will complete their task in the allotted time. When we debrief the first round, I ask each sub-team to rank their success on a scale of 1-10. Invariably, the two teams that completed their parts quickly suggest that they nailed it, and give themselves a 10. The other groups don't fare so well, and rank themselves much lower.

As a client for the whole operation, I make it clear that what I received as a final product - nothing - suggests that if the whole operation failed, then everyone in that operation failed as well. Nobody gets a 10.

With large teams, we see the local maximum problem manifest itself as silos. It might be the development team throwing stuff over the wall to the test team, or both ignoring the customer support people, or some other dysfunctional structure that drives one group to declare a local victory and point at others as the problem when the project doesn't come through on time. We often see project schedules that are compartmentalized into different phases by department, where this can occur as well. One group early in the project slips a bit, and 'project management by optimism' drives us to hope for overall success by nibbling away at downstream activities, preserving the original end-date. I've seen projects where almost all of the integration time has vaporized before that group can get a peek at the product, and they are left holding the bag as the project runs over budget.

We don't need big org-charts and departmental silos for this issue to occur, though. Even in the smallest of teams, we can easily fall into the trap of looking out for ourselves, at the cost of others who are contributing to the overall product. The likelihood for this to happen increases significantly as project pressures, usually schedule or budget, increase. There is often the perception that interruptions from other groups are preventing us from getting our job done. While that may literally be the case, it is important to recognize that these interruptions are seldom without reason. There is often a need for collaboration that drives this interruption, and ignoring that need is done only at the peril of the entire operation.

And we all need to remember that it is the success of the entire operation that matters, not just our part.

To avoid the local maximum problem, we need to immerse ourselves in the knowledge of the entire domain. We need to appreciate others' needs and express our needs to others, then find the right balance where all these needs are addressed. We need to plan together to do this, and we need to collaborate in an ongoing fashion to ensure we are continuing to work towards the best overall product we can deliver. If one component is running behind, the entire group needs to work together to resolve the problem and move forward. If I'm late, I'd like the team to work with me to creatively bring us all back on schedule.

We all need to focus on overall delivered value, not just that our part gets done. A local maximum is fine if you are genuinely the only component of the solution that matters, but it has been my experience that this has rarely been the case since I finished those assignments back in college.

Become an InformIT Member
