It’s been at least 10 years since I’ve cobbled together a few lines of code, or INIT 6’d a server, so I feel as though I can practically qualify as a non-technical CEO in a technology startup. It is for this reason that I can empathize with the plight of the unindoctrinated, those of us who come from non-computer science backgrounds working with software developers. We all have a contribution to make in advancing the state of any software project—and let’s face it, you’d be hard-pressed to run any business these days without undertaking some form of software development. In that spirit allow me to humbly suggest how you, dear reader, can maintain and enhance the respect of your software druids while maintaining your sanity.
1) Don’t be Chicken Little
Awesome. You found something wrong. Your impulse will be to tell the team (this is a good impulse) and help the members understand why this is important to you. The matter of importance is usually where the non-techies get into trouble, because one has to remember that when you find a bug, it’s probably the result of someone’s mistake—and they’re likely to feel bad about it. But the sky probably isn’t falling. If you layer too much hyperbole on the affair then you’re likely to take them from feeling guilty to feeling offended. Then they will begin to debate the importance, versus fixing the bug, and time gets lost. Also bear in mind that any given day for a software developer is spent slaying a vast array of similar bugs; they might have a different understanding of your bug’s importance than you do. Providing context for why a malfunction is affecting things is good. Freaking out and demanding immediate action is bad.
2) Use the tools they do
These days most software teams use workflow management and issue tracking tools (like Pivotal Tracker). These are usually web-based tools that are easy to learn. Take the time to learn them. When you have an idea for a feature or discover a bug, rather than barking out an email and CCing the world it is generally appreciated by all when you submit these via the issue tracker. The team members will also appreciate your interest in learning how they manage their tasks, so when you ask for a little training on the tracker they will probably be pretty jazzed to help you out. This has an added bonus: once submitted to the tracker, your idea is kept in a safe place, not buried in months of email and convoluted threads. So nobody can claim they forgot about it and lost your suggestion.
3) Take things as far as you can
Say you’re at a cocktail party and Dmitri tells you there’s a problem with your website on his computer. You’re obviously going to want to tell the team. However, this information alone is not particularly useful. Who’s Dmitri? Where can he be reached? What kind of computer was he using? What web browser? Is he a user? Or trying to sign up? Or trying to buy something? Chase down as much context as you can so that when someone rolls in to tackle this heinousness, they have already grabbed some of the information from you to save them time. You’re also showing respect for the team in not sending them on a wild goose chase. Many such reports can be dismissed with even the most cursory information: “Oh, he’s running Windows ME and Internet Explorer 6 on an ACER Palmtop? That’s hisproblem.”
4) Be interested in the process
Prioritizing tasks within a software team is black art. Mapping these to the business objectives of your company is where you come in. But you don’t necessarily get to put one thing in front of the other without understanding that even writing software effectively requires strategic thinking. Sometimes you need to make three left turns in order to head right. Sometimes the best way to do something takes longer, and other times, you just want to bash something out. There are many many schools of thought on this like “lean” and “agile,” but in 21 years of creating software within teams I can assure you that we’ve never done it the same way twice. There is no cookie-cutter methodology, and anyone who tells you there is is trying to sell you their book. Work collaboratively within the team, and allow every voice to contribute. This is also a good way to learn who your smarter players are.
5) Encourage yes men
This is worthy of an entire piece, which we’ll get to some other day. The easiest way to sound smart in a group is to be a blocker. When an idea is floated, the expert will scoff “no, because…” and provide some poorly strung together but authoritative diatribe on why something can’t be done. The temptation is for the crew to lean back in awe of the dissident’s expertise. But in the context of a startup it’s wrong. Don’t be that person. Don’t allow that person in the room. The correct response to pushing the envelope of the possible is “Yes, If…” and explore what conditions need to change for something to be possible. Maybe those conditions are impractical, or maybe someone else in the group knows how to meet that “if” requirement to cross the chasm. If the whole discussions stops at a “No” and a self-professed expert digs their heels in, then you’ll never really know, will you?
6) Don’t be a feature creep
When teams get good at working together, they get better at understanding how long it will take to do something. Agreeing on a timeline for a specific set of objectives is good and, though these’ll be soft, the one thing that tends to lead to massive expansion in the length of a project is a continuous stream of “Oh, another thing…” suggestions which we call “feature creep.” New ideas will pop up as you proceed, sure, but try to understand what’s substantial and what’s negligible in terms of impact to the development timeline. To minimize delays, before you start it’s important to sit down and sketch out both the objectives of the project and its detailed requirements. Writing them down into a document doesn’t hurt. But poking your head into the development team’s work area and saying “you know what would be great?…” will lead to rolling eyeballs and stretched timelines. The more you know at the outset, the better off you are.
Creating good software is collaborative and iterative and successful projects are rarely managed in a truly top-down fashion. Be understanding that developers’ time, like yours, is pretty valuable. By doing the things that you can do to ease their job, working within the set of tools they use to guide their work weeks, and by actually communicating with the team as a peer, you can both learn a whole lot about the process and ensure that everyone is aligned on the goals and timelines of the project. It’ll also enhance the team’s respect for your contribution as the business/marketing/sales/support/warehouse/etc. person, a role they likely only vaguely understand.
The basis of making everybody smarter is good communication. These techniques are a key part of being successful in any software endeavour, and though I don’t have a book to sell you they are an excellent starting point in diving into the process of creating new technology. And if this all seems like a lot of work to you? Time to hire a product manager.
Ian Bell has been bending bits into business since 1993 and is creator of Tingle, RosterBot and other things celebrated and ignominious. Follow him @ianb on Twitter. This article originally appeared in Profit Guide magazine.