There’s a very good chance your startup will fail. Nine out of 10 startups do, they say. There are a lot of reasons for this, but many boil down to failed communication.

While many founders attribute failure to forces outside of their control, blame their teams, or chalk it all up to simple bad luck, I keep seeing them make the same mistakes, time and time again.

I’m convinced that a lack of delegation and communication can make your startup go belly up faster than anything else. It might seem like trying to control your team’s every step is the right way to go, but in reality, you’re only compromising its success. I’ll explain what I mean, and how to avoid this fate.

Here are the 4 most common startup communication and delegation mistakes:

 

1. You Aren’t Delegating Enough

 

I get it. Your startup is your baby and you’re used to doing everything on your own. However, for successful startups, you’ll need to delegate tasks.

As your team grows, you naturally continue to feel like you need to have your hand in everything, from making UX decisions to paying electricity bills. But this is where the long line of startup delegation mistakes begins.

While it may feel natural for an entrepreneur, being a control freak is one of the worst things you can do for your product and your team.

This healthcare startup founder I once worked with was convinced nothing would get done unless he controlled every little step of the development process. In addition to this startup, he had a few others where he acted the exact same way. Needless to say, the development was taking a lot longer than it should have. As a result, time-to-market kept stretching, the expenses kept growing, no income was coming in, and the people waiting for the product to come out started to lose trust.

For many startups, all of the above would mean a death sentence.

What Can You Do?

Delegate left and right. A startups founder’s key responsibility is to develop company vision and craft business goals according to that vision. What is not a startup founder’s responsibility is checking every line of code or overseeing deployment—this is what the CTO/tech lead is for.

Similarly, leave the user experience to your designer, the promotion to your marketer, and the bills to your accountant.

Agile methodologies (of which I’m a strong proponent), include a handy planning system known as the Five Levels of Agile Planning, and they illustrate my point brilliantly.

As you see, the product owner—founders usually assume this role—is in charge of product vision and product roadmap (more on these in the next point), and shares the responsibility over release planning with their teams.

All the smaller day-to-day aspects of product development are handled by the teams themselves. Setting up your business this way keeps you in the roles that will push your business forward and allow your team to do what they do best.

Remember, it’s your task to know where you’re going, but it’s your team’s task to know how you’re going to get there. That’s why you hired them, after all. Trust in your employees for successful startups.

 

2. You Aren’t Sharing Your Goals with the Team

 

Communication mistakes in business are pretty commonplace. This problem is much more common in distributed startup teams than in co-located ones, but since 43 percent of employees in the United States alone spend at least some time working remotely, it’s important to mention it.

Far too many times, I’ve worked with startups founders who didn’t care to communicate their product vision and goals to the remote development teams I helped them set up and manage. In most cases this meant the developers would come to work, open the task tracker, see a new task, and get to it without any understanding of where it stands in the grand scheme of things.

Since these developers didn’t fully see the business value of the product, they weren’t able to work as efficiently as they could have and often ended up redoing the work they’d already done. This led to consistently missed deadlines, and the founder being unhappy with the team. Not to mention, having no idea why your work matters is severely demotivating.

What Can You Do?

Communicate your product vision and product roadmap to everyone on your team, not just the management. Better still, have them documented. If you’re not yet sure what your product vision is, these questions should be of great help:

1. Who is going to buy my product?
2. Which customer needs will the product address?
3. Which product features are critical to satisfy these needs?
4. How does the product compare against existing products? What makes it unique?
5. What is the timeframe and budget to develop and launch the product?

Compile these project details into a document and update it continually. All team members need to have access to these documents and be notified of changes. This way, the team’s actions are in line with the founder’s goals.

There’s one more thing I want to note here. As someone who works with distributed teams, I’m aware that the reason some startup founders fail to communicate their product vision isn’t that they don’t think it’s important. It’s that they’re too worried about security.

And they have every right to be. But you’ll have much less to worry about if you establish solid information security practices. These can include signing NDAs with the remote workers, setting up a VPN connection to your infrastructure, installing an antivirus on everyone’s computer, renting a secure office space, and making sure the remote team understands that WiFi in cafes is a no-no. You could also work with a technical partner (this is what I do) that can help you build your remote development team and guarantee all of the above.

 

3. You Don’t Have an Established Communication Process

 

If I had to choose the single most common of the communication mistakes in business that can bring all kinds of chaos, it would definitely be this one. I’ve seen too many promising startups suffer because of a lack of an established communication process.

It’s not hard to imagine what happens to product development when no one knows what their team members do and who they can talk to if they run into a problem—it’s a complete disaster.

The founder doesn’t have accurate information on the progress of the development team, and the development team isn’t notified of changes the founder makes to the product roadmap. Enter a vicious circle of misunderstanding, where nothing gets done on time and everyone blames someone else for it.

What Can You Do?

Document the roles and responsibilities of every team member—even if your organization structure is flat, even if you only have five other people on your team.

You can use a RACI matrix for this purpose. It allows you to clearly specify the person (R)esponsible for completing a certain task, the person (A)ccountable for its correct completion, the people who have the necessary information and can be (C)onsulted while the task is being completed (two-way communication), and the people who need to be kept (I)nformed of the task’s progress (one-way communication).

You might think that this scheme is a little old-fashioned or too complex for the needs of a startup, but some sort of mechanism still needs to be there. If you’re not a fan of the RACI matrix, feel free to adapt it to your needs or create a completely custom communication document. What matters is that it has the names, the positions, and the responsibilities of all team members, as well as the types of meetings they take part in.

Speaking of meetings, they also need to be part of your documented communication process. Write down what types of meetings you have, what you discuss during each meeting, and how often they take place.

Scrum is my favorite among Agile frameworks, as it offers a predefined set of roles, responsibilities, and meetings, making the life of a startup a lot easier. It also minimizes time-to-market and helps deliver business value in much shorter terms.

Within Scrum, teams break their work into tasks that can be completed within timeboxed iterations called sprints, which usually last two weeks. There are daily, planning, sprint review, and retrospective meetings which allow teams to stay on track of each other’s progress, plan their actions together, review what works and what doesn’t, and plan their next actions accordingly.

Even if you don’t plan to use this framework, I still recommend that you read the Scrum Guide, as it’s a great starting point for planning your communication routine.

Ultimately, it doesn’t matter which communication process you choose. What matters is that you’ve got one (and it’s documented).

 

4. Your Estimation Process Isn’t Working

 

You come up with a task for your development team and then invite the tech lead or one of the senior engineers to give you an estimate of how long it’s going to take the team to complete it. This sounds like a perfectly reasonable approach to estimation.

But is it really? Then why do most companies that use it end up with regularly missed deadlines, overspending, and demotivated developers. 

What Can You Do?

The team lead may have all the experience in the world, but if they aren’t actually going to do the work, the value of their estimate is close to zero. What you need is the wisdom of the crowd. Invite everyone who is going to be involved in completing the task in question to take part in the estimation process. This is the only way to get the “expert judgment” technique to be accurate.

You can do expert judgment the usual way (i.e. just asking people how many hours they’ll need to complete a task), but you can also do it the fun way. I’m talking about planning poker—an estimation game in which team members estimate how many story points will be required to implement a piece of work by playing numbered cards, face down.

 

Story points are relative values used to express an estimate of the overall effort required to complete a piece of work. A task that is assigned a 2 should take twice as much effort as a task that is assigned a 1, and two-thirds the effort that would go into completing a task that is estimated as 3 story points. When estimating effort in this context, the team should consider the amount of work to do, its complexity, and any associated risks or uncertainties.

In planning poker, story points are represented as numbers on cards. Each “player” gets a deck of cards with typical values of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. The estimators discuss the task at hand and privately select a card. The cards are then revealed simultaneously.

If all estimators have selected the same number of story points, that becomes the estimate. If not, they discuss their choices, with the high and low estimators taking special care to share the reasons behind their estimates. After this, the cards are reselected and revealed again. This process repeats until the team reach a consensus, or until they decide they don’t have enough information at the moment to select an accurate estimate.

Story points may be a hard concept to grasp at first, and planning poker might seem like too much effort if you’re used to just asking your tech lead to give you an estimate off the top of their head. But I strongly encourage you to give this technique a go.

Based on my experience, the estimates that planning poker can produce are much more accurate than those produced by any other estimation technique. This is possible because planning poker brings together multiple expert opinions and because team members are called upon their peers to justify their estimates.

 

Take Action And Give Up Control

 

Running a startup is like being in a relationship. Would you rather be with a controlling partner who never shares their feelings and plans, or with someone who trusts you and isn’t afraid of opening up?

Letting go of control will feel scary at first, but it’s absolutely necessary. You have to free up headspace to be able to focus on your grand goals and steer the team in that direction.

Delegating your responsibilities doesn’t automatically mean you’ll no longer know what’s going on with your product. Remember to follow these important principles:

• Delegate as much as possible.
• Share your vision and roadmap with your team.
• Develop and stick to an effective communication routine.
• Make sure estimation isn’t a guessing game.

When you do, you’ll know exactly where your product stands at any given moment, and what steps you need to take next.

I’m nearly done with this post, which means it’s time for you to take action. Make a list of things you’ve been doing so far but should have delegated. Find time to update (and document!) your product goals and share changes with the team. Test a new meeting schedule. Give planning poker a try.

Changes are never easy, but if you’ve been struggling with startup management, they’re unavoidable.

 

4 Mistakes That Sink Startups was originally published on Foundr