It’s common for business owners and leaders to suddenly find themselves responsible for overseeing a custom software development project. Maybe you’ve had an idea for a new product, or maybe your business is expanding into new opportunities. Maybe your business has done tasks manually that you’ve grown too large to sustain. At some point, most businesses become tech businesses to some extent, and this can be a very daunting shift that puts leaders well outside their comfort zone.

This situation sets leadership up to fail, and by extension, their projects and people become more likely to struggle. It’s easy to feel a lack of control at a time when you’re feeling the most vulnerable as you take new risks with your business. When projects start to go sideways, it can be very easy to identify what is going wrong, but identifying why can be dramatically more difficult. Leaders often default to a sense of suspicion about their product development teams that can further derail progress in a number of ways.

The good news is that there is a very common set of mistakes that can be avoided with the right tools and perspective. We’ll be discussing a few of these in this article.

The Impact of Rapidly Shifting Priorities on Custom Software Development Projects

Small businesses often live or die by their ability to adapt to shifting markets. Business stakeholders in sales, marketing, and leadership can be understandably driven to pivot rapidly as new trends are identified. Custom software development teams must be able to pivot and adapt to support the business and take advantage of these new opportunities.

Partially-finished software projects rapidly become useless, and switching priorities has a real cost. Let’s consider an example: a software engineer is given a task to develop Feature A. This new and exciting feature requires extensive modifications to many parts of the codebase. One week into the project, the software engineer is asked to pivot to implement Feature B instead. Feature A was incomplete and unstable, so those changes have to be set aside so that they don’t cause bugs in the implementation of Feature B. Unfortunately, Feature B requires that many of the same parts of the code be modified. After the software engineer finishes Feature B and goes back to resume work on A, they discover that the work they did on A can’t be easily re-integrated into the code after the changes for B. They’re left having to either go carefully back through A to merge the two sets of changes together or start completely over.

As a non-technical leader of a technical project, this can be confusing and frustrating. Feature A was halfway done and the developer originally said it would take two weeks; they put a week into it; when they pick it back up, they should have a week remaining, right? So why are they now saying it will take three weeks to complete?! Surely they’re just complaining, or maybe even outright lying!

This experience is equally frustrating for software engineers, who can feel that they never get to see an idea through completely. They may also feel that they’re distrusted unfairly when they’re doing their best to produce quality work for the business.

Strategic leadership in this situation means hiring people you can trust, then trusting them. This issue can also be made much less complicated by ensuring that the right roles exist on your software development team so that communication flows smoothly in both directions.

Expecting Transparency Without the Right Resources

Custom software development can be painfully expensive, and drawing financial resources away from other opportunities can create an uncomfortable level of business risk. It’s understandable that business leaders want to know that they’re getting what they paid for and that they aren’t heading for any nasty surprises. Ongoing communication and transparency are necessary on both sides of the relationship to ensure that projects are successful.

Trouble can show up when the software development team doesn’t have the time, expertise, or skill to manage stakeholder communications. Communicating team status is a specialized skill set that most software engineers don’t have. They may also feel pressure from approaching deadlines or budgetary constraints that make it hard for them to do anything but write code.

It’s absolutely reasonable to expect a team to be transparent while they work, as long as the team has the people they need to provide it. This job is shared between the Project Manager and the Product Manager. If these roles don’t exist, transparency becomes effectively impossible without unacceptable compromises in the team’s throughput.

If you need transparency on a project, make sure you have the right Project Manager and Product Manager.

Undervaluing Team Input

Imagine you’re building a house for a client. The client asks, “How long would it take to build a house according to this design?” In this situation, you could perform a detailed analysis of cost and scope and come back with a confident estimate of the work. You can be confident in your estimate because you haven’t been given a time constraint; all you have to do is determine how long it will take. Given the what, you can adjust the when.

Imagine the same client asks, “How much house can you build me in six months? How close could you get to this design?” As above, you could consult with the experts on your team to put together a detailed plan that you feel is achievable within the stated constraints. You can be sure you hit the deadline by adjusting how large of a house you build, what construction techniques you use, etc. Given the when, you can adjust the what.

Now, imagine a client comes to you and says, “I need the exact house in this design built within 6 months with a fixed budget of $500,000.” You are given both the what and the when. If the plans are realistic within that time window, you don’t have a problem. You can complete the project on time. But what if you can’t build the house by the deadline within the provided budget?

The client might eventually get the house they want, but only if they go back and fix these shortcuts later. And, of course, it’s much harder to fix the plumbing and electrical after the drywall is up, so the fixes later will be harder and more expensive than doing it right the first time.

It’s reasonable to ask a product development team if they can accomplish a fixed set of requirements within a predetermined deadline, as long as you’re willing to accept “No” as an answer. In this case, you can have a constructive conversation about what is actually realistic.

If you give the team a hard deadline, you have to hear them out on what they can deliver by that deadline.

If you give them a hard set of requirements, you have to ask how long it will take.

Fixing what and when without team input will inevitably lead to compromises on how well that will come back to you later with interest.