Your job ain't easy

Building a business is difficult. Building software is complicated and confusing. It's no wonder, then, that building a software business is like fighting with both hands tied behind your back. You have to spend a fortune to pay other people to fight and rather than fighting it feels like they stand around talking about fighting, doing a bunch of things that aren't fighting, and eventually come back to you with a list of reasons they can't fight right now.

"If we could just ship this feature I could get a new customer!"

I feel your pain. There could be bazillion reasons why your developers aren't delivering on time, so we'll focus on the most common ones.

Reason 1: Unclear requirements

Think about the last time you asked your developers to build something. Did you call them up and say "hey, I need you to..."? Avoid this if at all possible. It is critical that you give your developers instruction in writing. Even brief written requirements help clarify your thinking, act as a "contract" between you and your developer, and gives him or her time to think and ask questions.

After your developer has had some time (hours, not minutes) to process your written requirements you should schedule a meeting to discuss them. From there you can collaborate, revise the document, and answer questions. Only after this meeting should you ask "so, how long do you think this will take?"

Reason 2: Bad estimates

Providing clear, written requirements to your developers will go a long way towards getting better estimates. Your development team should break your request down into smaller tasks that are easier to estimate, taking in to account the skill level of the team, administrative tasks, deployment, and testing time.

All time estimates are inaccurate, but if your developers are consistently off by a ton then that's a bad sign. Consider asking for help to manage your developers.

Reason 3: Context switching & priorities

The differences in how managers and makers manage their time are well-documented. As a manager it is your responsibility to keep in mind that meetings, switching between projects, and shifting priorities comes at a cost. Here are a few ways you can help your developers stay focused on what matters:

1. Schedule meetings at the beginning or end of the day, or near lunch.
2. Never call a developer on the phone unless production is down.
3. Communicate asynchronously via e-mail, Slack, or project management tool. In writing is always better.
4. Only change priorities if absolutely necessary, and be painfully clear in what order you would like things done.
5. Don't interrupt a developer unless the building is on fire.

Reason 4: Wrong mix of talent

Assessing development needs is a challenge, especially in rapidly changing businesses. It's a constantly moving target: the type of developer you need in year one is not the same as year four. Unless you are technical yourself this keeping this talent mix is nearly impossible. All I can offer is a general rule: your first 3 developers should be senior, the next 3 should be mid-level, and the following 3 should be junior. Juniors cost less financially but more in time, so you should never hire juniors until you have mid-levels to wrangle them.

Reason 5: They're actually slow

Every once in awhile you'll encounter a developer who just can't get his or her act together. I call this the Bartleby, the Developer scenario. Tickets don't get resolved and questions go unanswered. If you have tried all of the above, discussed the problem plainly (and set attainable goals) with the developer, and asked for advice from outside your organization, then you know what you need to do: fire them.