This article is for you, the plucky entrepreneur with an app idea in your heart and a bit of cash in the bank. The diagrams that you’ve scribbled on cocktail napkins will disrupt the entire world, and dump trucks full of money have already been dispatched to your house. To ensure that they arrive on time, here’s some simple advice for making your production cycle run smoothly.

Why You Need A Project Manager In The First Place

“Computer programs are the most complex things that humans make”, says Douglas Crockford. You may not have heard that name before, but he’s pretty famous for a programmer. He’s currently a senior software architect at Paypal, and he has pioneered all sorts of cool technology that is beyond the purview of this article. He is someone who knows a great deal about working on large projects.

As for myself, I’ve been programming for 13 years, and even now, at some point, every project takes me into uncharted territory. There are so many different technologies out there, and new techniques are being devised at such an alarming rate that I never feel I’m completely on top of what’s going on. While every project has its unique challenges, there are some constants:

• The project has time pressure.
• The budget is smaller than I would like.
• I am a more expensive than the client would like.
• I do not listen as perfectly as the client would like.
• The client does not explain things as perfectly as I would like.

Clearly, we need a babysitter. Someone has to step in to establish the ground rules, keep everyone honest and make sure that we’re not forgetting anything important. Someone has to facilitate communication between all parties.

This someone, this hero, is the project manager.

Toptal did not offer contracts with project managers when I began writing this article, but they do now. Synergy! I can only imagine that the powers that be read the following advice and realized that they were missing a great opportunity.

Why A Programmer Does Not Make A Good Project Manager

Certification by the Project Management Institute aside, the most important thing that a project manager can bring to the table is experience. As a result, many programmers would make pretty decent project managers; we have more experience with technical projects than anyone else and our analytical minds are adept at cataloguing information and setting concrete goals.

Goodness knows, you’re paying us enough, so it seems reasonable to expect that we could manage ourselves rather than force you to pay for someone else’s time as well, right?

Well, for starters, you’re paying us to code.

When we come out of our programming daze to make decisions about what to prioritize, or to argue about how much is actually going to get done this week, code is not being written. It then takes at least 10 minutes to get back into “the zone”, especially if we’re stressed out by the conversation that we just had, which is likely if we’re arguing feature priority. Boo hoo, I know, but this is all about making the most efficient use of costly resources.

Most importantly, we really can’t see the forest for the trees. If you take nothing else away from this article, please understand this: When I spend all day staring at a few specific bugs, my brain loses track of the bigger picture.

My brain rewards me when I fix those bugs, and I assume that I’ve done great things and can go play video games now. When someone reminds me that the home page is still broken, it comes as a complete surprise because I have spent the day filling my brain with very detailed knowledge of a very small piece of the overall project and sort of forgot about the rest of it. That’s just how my brain works, and a lot of other programmers have a similar psychological make up.

Why A Client Does Not Make A Good Project Manager

Well then, if we programmers don’t want to take the responsibility for getting project managerial things done, then it must fall to you, the client. It’s your money. It’s your vision. You’re ultimately responsible for the whole thing, anyway.

You, however, also have a lot on your plate.

Many clients are mere mortals with day jobs like the rest of us, and some have even been known to suffer from procrastination or forgetfulness. Although this certainly does not describe you, please entertain the idea of having a Professional Rememberer around so that you can get back to the important work of keeping the whole project alive.

If you have worked on, or overseen, a technical project of similar scope, you may indeed make a good manager for your project. If you have not, please don’t underestimate the value of someone who can predict the issues that may arise. Time estimates are always just estimates, and bugs tend to pop up at the least opportune times. It’s worth the cost of another (if only part-time) employee to have someone around who knows which parts of the process need, or are likely to need, the most attention.

Take quality assurance (QA) for example. Proper QA is essential for getting what you want out of any project, and it never ever gets the attention that it deserves. A good project manager will make the most of limited QA resources, and also quality-assure your programmers for you. Sometimes, we get out of our depth, and sometimes we make mistakes. You need a technically-proficient person in a supervisory role to determine whether your programmer is just having an off day, or if he or she is, in fact, a bad fit for the project. Heading off personnel problems early could mean the difference between life and death for your project.

Lastly, even you, oh glorious client, sometimes need a little check and/or balance. That’s hard for me to write since we computer programmers are not well known for our outspoken natures. Suffice to say, I have worked on many projects where the client was adamant that everything was top priority and absolutely everything needed to get done. While I have no doubt that this was absolutely true, these clients, sadly, did not have control over the number of hours in a day. They did not end up with the positive result they desired and/or deserved, and I feel that this outcome could have been avoided had the client entrusted a project manager with the authority to assess the workload and tactfully, yet firmly, keep things in check. It’s difficult to make the dispassionate judgment calls that most technical projects require when it’s your idea and your money on the line and the computer doesn’t care if you or I cry and scream at it. (I know this to be true because I’ve tried it many times.)

An Incomplete List Of Techniques For Managing A Technical Project

Whether you’ve decided to ignore the previous 1,000-something words and manage your project yourself, or whether you are going to hire someone but want to be more knowledgeable about the process, this list will help you. I have never (officially) been a project manager, so I can’t say which tools any given project manager would use, but I’ve had good success with all of these techniques:

Milestones

When beginning a new project, most people intuitively know that it’s important to split the project into slightly-more-manageable chunks, with each chunk ranging from a couple of weeks to a couple of months worth of work. At the beginning of the project, it’s good to have a kick-off meeting to establish these milestones. It’s OK to be a little vague on how you’ll reach them, the most important thing is to keep checking in after each milestone so as to benefit from everyone’s enhanced understanding of the project, and to make sure that the project’s milestones are still (roughly) the same size as initially believed.

Time Estimates

We programmers absolutely detest estimates because we know they will be wrong and we know they will be used against us. It’s OK that they’re wrong because, by definition, they’re based on a handful of unknowns. It’s also OK that they’re used against us because our jobs are pretty cushy and it doesn’t hurt to have the whip cracked every now and again.

So feel free to ask for estimates every time work begins on a new milestone. You should expect a line or two for each major feature along with a rough estimate of how long that feature will take. I usually make an optimistic estimate, then double it. More often than not, this extra time accounts for unseen pitfalls.

User Stories

User stories are brief descriptions of a single piece of functionality within the app. They are useful as a record of important features and should be bite-sized, able to fit on an index card and often accompanied by a little drawing. More importantly, they serve as a bridge between what the client wants and what the programmer has to tell the computer. They are simple enough for you, the client, to knock out in a couple of minutes, but detailed enough for us, the programmers, to sink our teeth into.

For some quick info on user stories, I found these tutorials by Mountain Goat Software and Roman Pichler to be high-quality and succinct. For more information on the entire philosophy of “Agile Project Management”, try this Toptal blog post The Ultimate Introduction To Agile Project Management by Paul Barnes.

Compositions (mock-ups)

This is not an article about why you need a designer because I feel like most clients already understand that, but it bears repeating because you will see enormous productivity gains if you slap a concrete, well-considered design in front of your programmers. Every time we have to make a design decision we have to leave “the zone,” and every time we have to go back and change something because we weren’t provided with the final draft, well, you do the math… I’m not complaining because design is fun, but in my experience, this is the No. 1 source of avoidable, extra billable hours.

Most designers provide compositions, also known as comps, in Adobe Photoshop, Adobe Illustrator, or Sketch. If you are doing it yourself, you can use one of the countless online tools such as Balsamiq or InVision. The comp doesn’t have to have the same colors and styles as the finished product (since these can be easily changed later), but please take extra time to ensure that all UI elements are present and accounted for.

Stand-Up Meetings

Long meetings are sometimes unavoidable, but you really don’t want to overload your programmers or take up more of their time than is necessary. I’ve had clients who seemed to expect me to remember everything that was said during a two-and-a-half hour meeting; they were sorely disappointed. A stand-up meeting is generally limited to 15 minutes, and it’s customary to stand for the duration. The standing aspect is supposed to ensure that everyone is participating, as well as to keep the meeting short.

During stand-ups, everyone goes around in a circle to provide a brief status report, keeping all team members up-to-date on each others’ progress. You can find more about stand ups at ExtremeProgramming.Org. If you all work remotely and don’t want to get everyone on Skype every day, you could try a fun tool such as 15Five as an alternative to stand-ups. 15Five lets team members provide their input whenever it’s convenient for them, and it will prompt them with survey questions to tease out more in-depth responses.

Ticketing System

While anyone can maintain a system of sticky notes and Google Docs (with everyone’s tasks highlighted in different colors), it’s really not necessary; plenty of people have tried to solve this problem for you. Basecamp and Trello are famed for their ease-of-use, while Pivotal tries to encapsulate the whole “agile” philosophy into a very slick package. Whatever your choice, a good ticketing system will allow you, at minimum, to:

• create tasks
• assign priority and due date
• link tasks and subtasks
• assign different resolutions such as “completed” or “failed testing”
• show all tasks assigned to a certain user

When a project manager shows you 40 bright red top-priority tickets all due on the same day, you will truly understand the value of this bird’s-eye view of the project.

Source Control

You may never even look at the code in your project’s version control system, but source control (or versioning) is one of the most important tools at our disposal, the greatest backup system imaginable.

Most modern projects use Git, although sometimes you’ll run into Subversion (SVN) when working on projects that have been around for a while. Github allows you to host unlimited public repositories for free (plus, it contains most of the world’s open-source projects), while Bitbucket allows you to host unlimited private repositories and is therefore the favored choice for commercial projects.

Whichever version control system you choose, it stores our code remotely in case anything happens, plus tracks each time we “commit” code to it while forcing us to write a little message describing what we were working on. This prevents different developers from overwriting each other’s code, it lets us see all changes that were made over a given time period, and it lets us create new code branches to store features that aren’t going live right away. It even has a command called “blame” that shows who was responsible for a given line of code, and when it was committed.

Source control is the greatest.

Test-driven Development

This is a relatively expensive practice, which means it’s not frequently employed in projects where the budget is limited to a couple of freelancers. So you, as a start up, shouldn’t feel too bad for not doing this, but I must dangle the idea in front of you because it provides the ultimate defense against bugs. Basically, your programmers spend additional precious hours writing tests (small code blocks) that ensure certain parts of the app behave in specific, predictable and repeatable ways. For example, I might write a test asserting that when the “login” button is clicked, a popup opens with a username field in it.

The beauty of tests is that once I’ve written them, I can run them all with a single command. If I have 200 tests written, I can run them after releasing a new version of the app to make sure that no bugs have been introduced into any of those 200 features. It’s not perfect, but it’s as close as we can get to guaranteeing bug-free (bug-lite, at least) apps.

Wrap-up

That’s about all I know about project management. I’m not sure how much of this would pass muster over at the Project Management Institute, but it’s all stuff that I’ve picked up by working on web projects over the course of the last decade. Of course, I recommend that you hire someone in order to get the benefit of his or her experience, but I hope you find this information helpful even if that’s not something that you’re able to do. You will be the ultimate authority on this project, so the more you understand about its inner workings, the more likely you are to lead it to victory.

This article originally appeared on Toptal.