Why is your app always behind schedule?

Does your development feel like it’s always trailing behind, but you don’t know why?

Can you relate to any of the following common frustrations of the software development process?

  • Bugs are popping up all over your product.

  • You have to add things last minute to a sprint.

  • Tickets never move across the board.

  • Features are unfinished but deployed anyway.

  • Your brain is moving faster than your product roadmap.

  • It took 6 months to deploy the feature your customers asked for.

And you find yourself fighting the urge to cc your entire engineering team on a Friday afternoon email that reads:

There is a better way, and it might not be your team’s fault

As a non-technical founder, it can be easy to sense that things could be “better,” without knowing exactly how to make your team the well-oiled machine you envision.

When it feels like your team is falling short of expectations, it’s natural to assume that you’re having a skillset issue - they’re “just too junior” or “too lazy” or “[insert your preferred assumption].” But when you sense things are falling behind, it’s often a symptom of a larger issue.

When things aren’t right with your development process, it is rarely a skillset issue. You are more likely having a communication issue.

We see a lot of codebases (…a lot). Some are ours (they’re obviously great 😉), and some are legacy code we’re taking over. It’s rare that we find a “bad” codebase. Founders are smart - they’re vetting developers, talking to references, and picking developers who were a good fit for them at the time. It’s unlikely they picked a total lemon. Most developers are good people, doing the best they can with the resources they have available.

What’s more common is that founders don’t understand tradeoffs that were made in the code as a consequence of certain requests the founder made or deadlines they pushed, or developers are trying to deliver on competing priorities without knowing how to evaluate what is most important to the company — so they choose to do something in a way you wouldn’t have.

The way you manage your tech team determines the quality of your app

If you find yourself not getting what you need from your tech team, it might be that you’re not making those needs clear.

We’re going to make a generalization here, but the way you run your sales meetings is probably pretty different from how you run your dev stand-ups. In sales, you might have a shared goal you’re each individually contributing to and tracking toward. In stand-ups, you’re probably asking for feature updates and getting lost in responses about technical nuance. One focuses on a goal and everyone’s actions towards that goal. One focuses on a task list. See the difference?

If you’re consistently not feeling aligned with your tech team, it’s safe to guess that they also feel misaligned with you. There’s two-way communication going on - you translate business priorities to your team and your team translates how the tech is solving those problems back to you. In order to keep that communication effective, there are three things to keep in mind:

  1. Your goal should not be to understand every technical nuance.

    As a leader, you’re not replying individually to every customer review; you hired a customer success manager to summarize trends. Your tech team should be the same - you don’t need to know how to enforce technical protocol, but you should be able to communicate its importance to your business goals.

  2. Know how your tech is supporting not only your ten-year vision but your two-month goals.

    Communicate how your team is meant to reach that ten-year vision through short-term implementation - that way no one is guessing “where to start.” Give them a vision for what your app should accomplish after 30 days, 120 days, and 365 days, not just the grand vision.

  3. Be able to effectively manage tradeoff decisions and prioritization frameworks.

    If you’re involved in every decision for your tech, you become a major bottleneck. Instead, give your team the ability to make decisions that align with your key metrics, and then hold them accountable for those decisions.

Building shared frameworks for decision making

When your team shares the same context, they’re more likely to make decisions that track to company goals.

Shared frameworks for decision-making help your team:

  1. Prioritize your top requirement and deliver it regularly.

  2. Contextualize the importance of the top requirement to build for long-term success.

  3. Communicate clearly about the single most important metric of success.

  4. Focus on what users can do, not just features.

  5. Build for scale while focusing on short-term goals.

There are a few ways we’ve found that are helpful for creating these shared frameworks (if you have any that have been successful for you, let us know):

Objectives and Key Results (OKRs)

We’ve found OKRs wildly useful with technical teams as well. By focusing on objectives (rather than features), we can focus on what users need to accomplish and often design even better ways to accomplish those tasks.

2x2 Diagram

A simple exercise to plot out your two top priorities, the effort to achieve them, and where features fall towards accomplishing those goals helps eliminate features that aren’t serving top priorities.

Weekly Meetings

Weekly meetings that track toward goals is a great way to ensure open lines of communication and consistent check-ins toward goals. We’ll often use the meeting schedule below to stay up-to-date on our OKR progress:

Whatever framework you choose for communicating business priorities with your team will take practice. But over time, you’ll see clarified vision, unified progress, and a lot less “Why are we always behind schedule?”

Better communication builds better apps

Next time you find yourself wondering why things are falling behind, pause to consider if you’re having a communication issue on the team.

In order to best communicate with your tech team, you don’t have to understand every technical nuance, but you should be able to communicate business priorities and understand how your tech is meeting those needs. Be able to communicate how you expect your tech to function in one month in order to stay on track and achieve 10-year goals. Share your personal and business prioritization framework with your technical team. Give them the ability to make decisions that align with key metrics and hold them accountable for their decisions.

By focusing on shared context and outcomes, you’ll find a more neutral playing field for communicating with your team about progress towards goals - and for understanding whether or not “your app is behind schedule.”


Enjoy this article? Sign up for more CTO Insights delivered right to your inbox.

Previous
Previous

ThinkNimble Career Lattice

Next
Next

An Introduction to Software Quality Attributes for Non-Technical Founders