Managing or working with developers if you're not one yourself can be challenging. You may not understand what they do or how they do it, or even the words they use when they try to explain it. But don't worry. Here is some advice for non-developers on how to work alongside the techies in your team.
Don't sweat the lingo
First of all, language. It's very easy to get lost when talking to developers - they say strange words and use familiar ones in unfamiliar contexts. Sometimes it might seem like they're not even speaking the same language as you. How can a non-developer possibly cope?
The fact is that working with developers doesn't require you to know everything about what they do. Often, the perspective you can offer as a non-technical person can actually give fresh insight into problems. I once knew a manager who had to deal with an exasperated developer whose code wasn't compiling. After listening carefully to the problem and not understanding most of it, the manager asked politely if the developer had tried using a different computer - and that fixed the problem.
If you don't know what the right words are or what they mean, then just ask. Developers are usually more than happy to explain what they're talking about, and if you're not a developer yourself they won't expect you to understand every aspect of what they do.
Understand what developers need
The various people involved in a project need to know different things. A project manager, for example, needs to know how many days are allocated to the project; an account manager might need to know the milestones achieved so far and what's next. Developers need to know exactly what needs building. For example, let's say your webpage needs an image carousel. Here are some of the questions a developer might ask about it.
- What's the content of each slide of the carousel?
- Which slide should the carousel start on? Should it be the same each time, or start on a random slide?
- What's the transition effect between each slide? How long should that transition take?
- Should the carousel move by itself, or wait for user input? If it moves by itself, how long should the delay between slides be? Will the user have any way of interrupting this movement?
- Should the carousel work on touchscreen devices using swipe gestures?
- What happens when the carousel reaches the last slide? Does it stop, or loop round to the beginning again?
- Can the carousel be navigated only by next and previous controls, or can the user go straight to a particular slide by clicking on the progress indicator?
Some of these questions might have obvious answers that can be found simply by looking at the design or by using common sense - but the fact is that a developer still needs those answers, not just for relatively simple things like this, but for every aspect of the software. This is why documentation for a proposed system can run to hundreds of pages.
At the start of a project there can be no reasonable expectation that answers to questions like those above exist yet, but the project cannot be completed until those answers are known. Developers like to know ahead of time what they're building, so identifying and answering these questions earlier will make them happier.
Estimating is hard.
No, really. I could go into a long speech about how the nature of development means even projects that look very similar can end up having wildly different timescales. Or how sometimes a bit of a website might look complete but then it turns out there's a weird bug when you look at it in a specific browser that's going to take another three days to fix. Or even that you're asking for an estimate of something that hasn't been properly defined yet... but all of that would just detract from the point. Estimating is hard. If you get an estimate from a developer, consider it just that - an estimate.
Better yet, try a system where specific time estimates aren't needed. Instead of asking 'how long will this take?' ask 'can you get this done by this date?'.
Give clear feedback
One of the things guaranteed to cause eye rolling among any group of developers is poorly written bug reports. Here are some examples, based on real ones I've received.
- “this text/image is wrong” (correct text/image not supplied)
- “[some functionality] is broken” (details of how it's broken not supplied)
- “on [some page], [some problem]” (no indication given of which page referred to)
- “this is rubbish” (no suggestion given on how it isn't good enough or how it might be made better)
- “this is wrong, it should be like this instead” (in direct contradiction of previous statements)
Other classics include poorly written, confusing or literally self-contradicting reports. The theme here is clarity - if a developer has to ask a question about a bug report, that bug report is inadequate. Good testers don't just find a problem and point it out, they go to lengths to ensure that the problem is carefully detailed, reproducable and even investigated a little as to the exact cause.
Did that help
It may be that after reading this article you still feel bewildered when working with developers. All I can say is that if you're not a developer, don't worry about trying to understand them too much. It's not your job, it's theirs.
And if you're managing a team of developers, again, relax. It doesn't take a developer to manage developers - I've worked with plenty of people who prove that. Encourage, enquire, help, steer. Or however management works. I have no idea - I'm a developer.