Balancing competing interests in software projects

Effective communication combined with incremental adjustments to plans and practices can turn even the most challenging work situations around.

By Gregory Brown
June 8, 2017
Balance Balance (source: jbdeboer)

The typical software shop is both overcommitted and poorly coordinated. These conditions form a vicious cycle: a lack of effective communication leads to inefficient work, which in turn leads to a permanent state of being too busy to communicate with one another.

The traditional remedy to this problem is something along the lines of “do less stuff, better.” When it can be pulled off, it is super effective! But in most places, the idea of waving a magic “do less” wand tends to be rejected out of hand, or at least kicked down the road to be considered in quieter times that never come.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

If you find yourself in a situation where your team can’t immediately solve its overcommitment problems, that’s a sign that it’s time to focus on improving coordination. Recognizing that busy people generally don’t have the time or patience for revolutionary transformations, your goal is to look for small adjustments here and there that when taken in aggregate lead to a massive reduction in friction.

Consider for example, the following scenario:

  • There is a large new feature that your team has been working on for the last three weeks, but it’s running a bit behind schedule.
  • The sales team is constantly asking for status updates, emphasizing in the strongest possible terms that they want this work done as soon as possible. Your project manager has been trying to keep it as the top priority for your team, but a trickle of other requests keep coming through which interrupt your progress from time to time.
  • Meanwhile, the customer support team is frustrated, because your project manager has been telling them that they’ll need to wait for all but the most urgent, show-stopping bug fixes for anything that’s already in production. They’ve heard this several times in the last few months, and it seems like a never-ending cycle where only the highest severity issues get dealt with and all the low-to-mid-level issues are deferred indefinitely. The end result of this is a near constant flow of problem reports from customers, which is getting harder and harder to keep up with.
  • The designer you’re working with on this new feature is also feeling strained, because they’ve been asked to shift their focus to the next major piece of work that’s in the pipeline for a few weeks down the line, but what they’ve seen so far from the developers for the current work-in-progress feature is still pretty far away from their ideal vision of how things should work, and even has some major usability flaws and inconsistencies that are likely to be noticeable to customers.
  • The company’s founder has a gut feeling that some new feature idea is really promising, and is taking time here and there from everyone on the team to explore the new idea, even though it’s purely speculative and not tied to anyone else’s priorities.
  • The product’s customers are writing negative reviews, and some are cancelling their accounts, but no one is tracking this information because they’re all too busy with everything else to notice.

In all of the above, we didn’t even get to talk about the headaches that the development team is dealing with because of all the tech debt they’ve been racking up! With so many tension points, it seems like such a team is destined to fail hard and never recover.

But is it really that bad? Imagine if all of the following points were true, but were simply not communicated because no one had asked the right questions or offered the information:

  • The sales team has a big demo coming up with a group of prospective customers. They’ve already discussed with their prospects in broad strokes what they’ll see at that demo, and the date can’t be easily moved because it was scheduled to align with a conference that happens only once every two years. However, only three of the five deliverables they’ve asked for from the team are truly necessary for the demo, and the other two could be substantially simplified or mocked up if needed.
  • More than half of the problems being reported to customer support are related to a single core issue that would take a single developer one day to fix. A quarter of the remaining issues could be picked off easily with a half hour here, an hour there. The remaining issues would be harder to deal with, but their impact could potentially be reduced by producing better troubleshooting checklists, more informative error messages, and other forms of workarounds.
  • Of the designer’s main concerns with the current work in progress, more than half of the issues are with the two features that conceivably could be cut or greatly simplified. Most of the remaining issues (and many of the designer’s ongoing concerns) could potentially be solved by developing a house style guide. Spending even an hour or two per week on that guide might lead to much less rework and confusion in future work moving forward.
  • The project manager has been letting a few requests “jump the line” because in each of those cases there was a specific and urgent business reason why it was necessary to do so. However, these reasons were not communicated particularly well to everyone else involved, and so they were perceived as unwanted distractions from the main task at hand, and furthermore the requests were not formally time boxed so developers frequently spent more time on them than the project manager would have considered “worth it” relative to how that time could have been spent elsewhere.
  • The founder’s “gut feeling” project is based on conversations with a potential investor, and so isn’t something that’s being worked on completely on a whim, but the founder is also not completely aware of the fact that the team is running behind schedule because this news has been expressed in vague and optimistic terms during high level prioritization meetings.
  • There is real tech debt accumulating in the project, but not all of it has equal impact. A strategy involving a “three strike rule” where when difficulty is encountered in a particular area of a codebase three times will trigger a cleanup session lasting up to an hour might lead to great improvements with a minimal investment.
  • It’s not that no one has time to read and respond to customer reviews and feedback, it’s that there isn’t an explicit place carved out in the schedule for doing that or a specific person responsible for coordinating that work, so it gets deferred indefinitely.

When looked at from this angle, this sounds less like a team that is “trying everything they possibly can and still coming up short” and more like a high friction environment that mostly has a lack of coordination to blame. If you pick any one of the points above and make a small change to how things are done, it’ll lead to an immediate incremental improvement. If you address most or all of them simultaneously, you’ll see large non-linear returns in recovered time in a period of days or weeks.

In order to apply these ideas in your own work, you only need to remember three things:

  1. Make sure you understand what the real needs of your collaborators are, rather than making assumptions based solely on what they’ve requested from you. In other words, understand the “why” behind the “what” in every situation.
  2. Recognize that costs and benefits on software projects are almost never proportional. Look for the areas where a half hour, an hour, or half a day of work can generate massive non-linear returns. And conversely, avoid situations where you invest large amounts of time for only minimal gains. Communicate these tradeoffs to others on your team rather than assuming they will figure out the ratios for themselves.
  3. Realize that an organization’s decision making process is only as good as the information it has available when decisions are made. Provide accurate, timely, and relevant information to help avoid disconnects and misjudgments during prioritization.

In stressful environments, people don’t always have the patience for detailed analysis or the vision for how to make sweeping changes in how things are done day to day. But when it comes down to it, if you can show how all the parts fit into the whole and have good ideas for small adjustments that might lead to big wins, people will listen to you.

So pay attention, speak up, and keep making things better!

Post topics: Software Engineering
Share: