Dealing with developers isn’t always easy. This post is chock-full of advice for how to maintain your sanity (and theirs) and how to get the most out of your developers while your project is underway.
1. Help Them Understand the Vision
This is important for obvious motivational reasons, but it also saves you some work. Understanding why a solution is needed gives developers the macro perspective to evaluate fluctuating priorities as a project is underway. It helps make sure your engineers work on the most important things and that they feel involved in the process.Instead of creating a comprehensive set of directions (which is way harder than it sounds) you can share the destination. That way, you also share the work in figuring out how best to get there. You hired professionals, so allow them to use their knowledge to help you find better ways instead of prescribing the entire path from the outset.
Share the Customer Perspective
“Who” is just as important as the “Why.” The empathetic experience of putting yourself in your users’ shoes is a core component of product design. Knowing the user, their problems, their tendencies, and what knowledge they have all helps drive the user experience, and when the people building your product understand their user they can do a better job appealing to them.
Outline Major Concepts
If your application is domain specific it can be useful to discuss major concepts. Developers are usually pretty smart, but they might not know everything about your domain. We have butt-loads of our own acronyms to keep track of, but we probably don’t know all of yours, so sharing the jargon early can be helpful from a communication and implementation standpoint.2. Use Precise, Non-prescriptive Communication
Doing issue tracking? When reporting bugs, use phrasing like:
“As a ___, when I do ____, ____ happens. I expected ____ to happen.”
Here are a couple of examples:
“As a logged out user when I type in the wrong password I get an error page. I expected the error to show up on the form and let me try again.”
This structure (called a user story) is important because it allows the developers to reproduce the issue by precisely defining the scenario in which it occurs. A report like “Login has errors” is sort of like saying “I live in San Francisco” instead of giving your cross streets to the cabbie.
Design Passing
Most projects begin as an outline of features. That’s because it’s the format that requires the least amount of time and energy to put together while still getting across the broad strokes of an application. The sad truth is they typically miss or assume a huge amount of work that isn’t represented. Low fidelity wireframes add a few more details and let the customer validate the proposed solution, an important part of the customer’s role.
Feedback beyond this point can often be frustrating. As my cofounder Wil is fond of saying, “the more colors you use, the closer you get to brown.” The fewer people involved in the process, the better your design will be. It will also be easier and cheaper to create.
Another point that customers often miss is that the most important thing to do when giving feedback on designs is to explain why changes are being made. Without the why, designers are left guessing and may miss the point. The golden rule of effective feedback does a really great job of explaining this. You’ve hired professionals, so tell us what’s important to you and allow us to do our job.
Tell Us How to Communicate with You
Developers aren’t the chattiest bunch of people, so we typically don’t go out of our way to update interested parties. If you want regular updates, you need to tell us that along with when and how often you expect them. If you want to see the issues as we’re tracking them, ask for access. Lots of people get scared by this, so it’s not something we offer to everyone, but if you have the technical savvy for it, it can be a nice way to keep up with what’s happening.
Must Win recently launched a tool called Scoreboard that helps manage this process via automatic daily updates and easy to create weekly updates (along with invoicing, payments, and more) for our clients so they can always be in the loop.
3. Make Using Tools and Code Easy
Onboarding
Getting new developers up to speed is an expensive part of software projects. How expensive depends on the person and the project — most sources say it takes at least a few weeks on non-trivial projects. There is a lot that can be done to mitigate this expense. System documentation in the form of UML diagrams or entity relationships can be very useful to give developers the big picture. Scope documentation, a working test suite, and documentation outlining any APIs or unusual code patterns also go a long way to helping a new developer navigate their new application.Ease of Use
The best way to demotivate your developer is to make it hard for them to do their job. Developers feed on the little joys that come from solving problems, and the farther you separate them from that experience the less rewarding it is. Compile times or test suites that run for hours and month-long QA processes all dis-incentivize us from pursuing good behaviors. I’m way more inclined to write tests if I can write them quickly, make sure they work, and they don’t add any delay to my gratification every time I change something. When I have to wait a month to see my changes in the product, I’m not excited about them anymore.4. Grant Them Access
Giving developers full access to everything that might be relevant to them helps facilitate communication, keeps them unblocked and can accelerate knowledge transfer and even help debug problems.Shared Source Code
When I can see the source of other projects I’m working with, I can solve problems for myself. On the other hand, when I get a black box with half-assed documentation, its pretty hard to figure out why it doesn’t work. Then I have to go pester whoever gave me said box and take them away from whatever presumably productive thing they were doing.Access to Decision Makers (Clients/PMs/Designers)
A short feedback cycle between developers and decision makers helps to ensure the client, whoever they are, actually gets what they want. Direct access to them allows for high-bandwidth communication and means that nothing is lost in translation on the way to the people doing the work. It also means they can foresee blockers and work to get them removed before running into them.Other Engineers
For new engineers, or just engineers on a new project, nothing replaces access to the people that originally built the system. Often, having a five-minute conversation about a particular issue with the right person can save hours of tedious work.There’s a lot to keep track of here, but by following this advice, you’re helping your developers help you. Helping them understand the vision means you have super smart people on the front lines making the right decisions for you. Giving them access to code and the tools they need means morale will be high and nothing will be held up by time-consuming processes. Developers are happy because they can deliver without being bogged down by unclear communications or expectations, and you’re happy because you get the right amount of involvement for you needs. As we say at Must Win, it’s win-win-win.