Submitted by Irene Papuc at Toptal
Authored by Ethan James, Freelance Software Engineer at Toptal
This abridged version was edited by Lynn Patra
This article is for you, the plucky entrepreneur with an app idea in your heart and cash in the bank. Diagrams you’ve scribbled on cocktail napkins will disrupt the world, and dump trucks full of money have been dispatched to your house. To ensure timely arrival, here’s 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, a senior software architect at Paypal who has pioneered various cool technology. He is someone with expertise about working on large projects.
As someone with 13 years of programming expertise, even now, I find that every project eventually enters uncharted territory. With many different technologies and techniques being devised at an alarming rate, I never feel completely on top of what’s going on. Every project has unique challenges and constants:
- The project is time sensitive.
- The budget is smaller than I prefer.
- I am more expensive than the client prefers.
- I do not listen as well as the client prefers.
- The client does not explain things as well as I prefer.
Clearly, we need a babysitter to establish ground rules, keep everyone honest, and track anything important. Someone must facilitate communication between all parties.
This someone, this hero, is the project manager.
Why is the product manager in a box? He’s a cat. Cats love boxes.
Toptal did not offer contracts with project managers at the writing this article, but they do now. Synergy! Perhaps the powers that be read the following advice and recognized the missed opportunity.
Why A Programmer Does Not Make A Good Project Manager
Aside from Project Management Institute certification, most importantly, a project manager brings experience to the table. Consequently, many programmers make decent project managers, with more experience with technical projects than others and analytical minds that adeptly catalog information and set concrete goals.
Goodness knows, you’re paying us enough, so it seems reasonable that we could manage ourselves rather than having you pay for another’s time as well, right?
However, you’re paying us to code.
When emerging from our programming daze to prioritize or to argue about how much is getting done this week, code is not being written. It then takes at least 10 minutes to return to “the zone,” especially if the conversation was stressful – likely if we’re arguing feature priority. Boo-hoo, I know, but this is about efficiently using costly resources.
Most importantly, we can’t see the forest for the trees. While staring at specific bugs all day, I lose 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 play video games now. When someone mentions that the home page is still broken, it comes as a surprise because I spent the day attuned to very detailed knowledge of a very small piece of the overall project and overlooked the rest. Many programmers have a similar psychological make-up.
When we come out of our programming daze to make project decisions, code is not being written.
Why A Client Does Not Make A Good Project Manager
If programmers aren’t responsible for project management, it falls to you, the client. It’s your money and vision. You’re ultimately responsible for it, anyway.
You, however, also have much on your plate.
Many clients have day jobs like many others, and some even suffer from procrastination or forgetfulness. Although this may not describe you, consider employing a Professional Rememberer so you can focus on 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. If not, don’t underestimate the value of someone who can anticipate potential issues. Time estimates are always just estimates, and bugs often pop up at inopportune times. It’s worth the cost to have another (perhaps part-time) employee who knows which parts of the process need the most attention.
Quality assurance (QA), for example, is essential for getting what you want out of any project but never gets proper attention. Good project managers make the most of QA resources and quality-assure your programmers for you. Sometimes, we get out of our depth and make mistakes. A technically-proficient supervisor can determine whether your programmer is having an off day or is a bad fit for the project. Solving personnel problems early means the difference between life and death for your project.
Even you, glorious client, may need a little check and balance. That’s hard for me to write since we computer programmers are not generally outspoken. I have worked on projects where the client insisted that everything was top priority and everything needed to get done. While this is undoubtedly true, these clients, sadly, could not control the number of hours in a day. They did not receive the positive result they desired and deserved, and this could have been avoided by entrusting a project manager to assess the workload and tactfully, yet firmly, keep things in check. Making dispassionate judgment calls that most technical projects require is difficult when it’s your idea and money on the line, and the computer doesn’t care if someone cries and screams at it. (I know, 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 plan to hire but want more knowledge about the process, this list will help. I have never (officially) been a project manager, so I can’t say which tools any given project manager would use, but I’ve succeeded with these techniques:
In the beginning, it’s important to split the project into manageable chunks ranging from a couple of weeks’ to a couple of months’ worth of work. When the project begins, have a kick-off meeting to establish these milestones. It’s OK to be a little vague on how you’ll reach them. What’s most important is to check in after each milestone to benefit from everyone’s enhanced understanding of the project and ensure the project’s milestones are still (roughly) similar to initial perception.
Programmers detest estimates because we know they will be wrong and because they will be used against us. It’s OK that they’re wrong because, by definition, they’re based on some 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 now and again.
Ask for estimates when work begins on a new milestone. Expect a line or two for each major feature and a rough estimate of how long that feature will take. Make an optimistic estimate, then double it. This extra time accounts for unseen pitfalls.
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 be fit on an index card, and often accompanied by a little drawing. More importantly, they are a bridge between the client’s vision and what the programmer must tell the computer. They are simple enough for clients to knock out in minutes, but detailed enough for programmers to work with.
For quick info on user stories, see the high-quality, succinct tutorials by Mountain Goat Software and Roman Pichler. For information on the “Agile Project Management” philosophy see Paul Barnes’ The Ultimate Introduction To Agile Project Management.
This is not an article about why designers are needed. However, enormous productivity gains are possible when concrete, well-considered designs are provided to programmers. When making design decisions programmers must leave “the zone.” Every time we return to change something because we weren’t provided with the final draft, well, do the math… I’m not complaining. Design is fun but this is the No. 1 source of avoidable, extra billable hours.
Most designers provide compositions, or “comps,” in Adobe Photoshop, Adobe Illustrator, or Sketch. If you are undertaking it yourself, you can choose from countless online tools such as Balsamiq or InVision. The comp’s colors and styles don’t have to match the finished product (since these can easily be changed later), but ensure all UI elements are present and accounted for.
Long meetings are sometimes unavoidable, but avoid overloading programmers or taking more of their time than is necessary. Clients who expected everything that was said during a two-and-a-half hour meeting would be remembered were sorely disappointed. A stand-up meeting is generally limited to 15 minutes, and it’s customary to stand for the duration. This helps ensure that everyone is participating and that the meeting is brief.
During stand-ups, everyone takes turns providing a brief status report, keeping all team members up-to-date on each others’ progress. Find out more about stand ups at ExtremeProgramming.Org. If you all work remotely and don’t want to get everyone on Skype every day, try a fun, alternative tool such as 15Five. 15Five lets team members provide input at their convenience and prompts them with survey questions to elicit in-depth responses.
A system of sticky notes and Google Docs (with everyone’s tasks highlighted in different colors) is not necessary. This problem has been solved. Basecamp and Trello are famed for ease-of-use while Pivotal aims to encapsulate the “agile” philosophy into a slick package. Whatever your choice, a good ticketing system allows you to:
- create tasks
- assign priority and due date
- link tasks and subtasks
- assign different resolutions such as “completed” or “failed testing”
- show tasks assigned to a certain user
When shown 40 bright red top-priority tickets that are due on the same day, you will understand the value of this bird’s-eye view of the project.
You don’t have to use sticky notes to track open bugs.
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) on projects that have existed for a while. Github allows hosting unlimited public repositories for free (and contains most of the world’s open-source projects), while Bitbucket allows hosting unlimited private repositories and is favored for commercial projects.
Whichever version control system chosen, it stores code remotely for safekeeping and tracks each time we “commit” code to it while forcing us to provide short written descriptions of what we worked on. This prevents different developers from overwriting another’s code, makes changes implemented over a given time period visible, and allows us to create new code branches to store features that aren’t going live immediately. A command called “blame” shows who was responsible for a given line of code and when it was committed.
Source control is the greatest.
This is relatively expensive, meaning it’s infrequently employed in projects with budgets limited to a couple of freelancers. Don’t feel badly for neglecting it, but I emphasize this 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 pop-up opens with a username field in it.
The beauty of tests is, once written, they can be run with one command. If I have 200 tests written, I can run them after releasing a new version of the app to ensure no bugs were introduced into the 200 features. This is as close as we can get to guaranteeing bug-free (bug-lite, at least) apps.
The original, unabridged article appeared on Toptal