Everyone working on software has a baseline competency with communication, yet it’s not unusual to see the time required to communicate effectively viewed as a distraction from the real task at hand. People seeking to deliver valuable software in a more timely and reliable fashion tend to turn to concrete changes – a new ticket system or software tool, more developers, performance bonuses – rather than delve into developing communication skills, despite the many concrete ways improved communication can increase a project’s momentum.
Set and Communicate Goals for Response Time
You’ve probably experienced some form of the information black hole. Maybe you put in a request to have an account created but have no idea if it will be minutes or months until the request is fulfilled. It’s important, but not urgent, and you don’t want to be “that person” who demands immediate attention. If only you knew how long it should take, you could set aside the stress of not knowing. Then, if a response didn’t arrive when it should have, you’d know it was time to double-check.
Both individuals and teams can:
- Set honest response times;
- Communicate them clearly and visibly;
- Monitor how they’re living up to those goals;
- Adjust processes or goals accordingly.
People are free to focus on other things when they know how long they have to wait.
Setting such expectations also frees you from more “Is it ready yet?” e-mails. Sending an auto-reply or a cut-and-paste acknowledgement like this should do the trick:
“If your request hasn’t been answered in three working days, something has gone amiss. Poke us with a stick by e-mailing stick@ourcompany.com.”
It can be as formal or as playful as suits your needs.
Goal-setting applies equally to long processes. Don’t underestimate how helpful it can be to let people know if you have no idea when something will be done, but you’re sure it won’t happen before some specific time. For example, when I applied for a volunteer position that required a police background check, they were clear up-front that there was no chance of placement in less than six months. They knew that was too long for many people to wait. By telling me, I didn’t need to hold space or put off shorter-term opportunities wondering if they might call me at any time. Yes, the long process meant they lost potential volunteers, but they didn’t create the kind of ill-will or persistent “Are we there yet?” inquiries that not knowing creates.
If you find that your response time is too unpredictable, or takes so long you’re embarrassed to say it publicly, being honest and clear is more respectful. Perhaps more important, it increases the chance that the underlying problems will get addressed.
Question How You Think About Time
It’s not unusual on development projects to think about how long something will take in terms of the hours the task itself will require. Questions may come in form of: “How hard would it be …?” “How long would it take …?” “How much longer is this going to take? You’re already four hours over!” “How many of these hours are billable?”
People typically answer such questions by saying how long it will take to do their part of it. A developer, for example, might consider the time it will take to figure out a solution and implement it. She might not consider the amount of time the rest of the team will have to spend communicating changes, testing, configuring, documenting, deploying, or training. Indeed, it’s difficult to know everything the team does in support, and harder still to estimate how long it will take to do their part. (And there’s almost never enough time allowed to account for the time spent making and adjusting the estimates!)
I’m no fan of {n}-hour estimates. Are people talking about {n} perfectly productive consecutive hours? Or just perfect hours? I get much more utility from asking, “What’s the least amount of time this could possibly take?” and “What’s the soonest you can imagine this being deployed?” That’s useful information, and its surprising how many times re-asking an estimation question this way will end up with a longer estimate than “How long would this take?” Murky as it may be, it’s still helpful to keep an eye on how hourly estimates match up to reality. If specific kinds of work aren’t being included, it’s likely to affect the sense of progress.
“How long will this take?” can also turn into “How long should this take?” which can affect momentum in a couple of ways.
First, when there are overlapping skill sets among people with varying degrees of expertise, it’s easy to think things like, “Oh, she can export this to a feature much faster than I can. It’ll be five minutes for her, and I know it’s going to take me forever. I’ll open an issue for that.” Sometimes that’s just the right thing to do. But it’s not unusual to find out that it does not, after all, take someone less time than you. They just dislike the work less or endure it more quietly.
Someone else is better/faster/smarter insidiously affects the overall project momentum. Perhaps 30 minutes was allocated for a feature export. I look at the ticket. I have time do it, even though I’m pretty sure it will take at least two full hours. I could pass it by to let someone more skilled handle it. On the surface, I’d be saving one-and-a-half (or more) hours of effort, but I know that this skilled person doesn’t have time to do it right now. If they take a day or two to get to it, from an overall project momentum standpoint, it’s not an hour-and-a-half savings; it’s a 24-48 hour delay.
For some issues, this matters. For others, less so. There’s a good chance that some degree of latency like this exists in your projects and may be a prime opportunity for increasing the overall momentum. Try focusing on overall impact instead of a narrow sense of how long a task should take.
Cultivate Information Wayfinders
If you’ve tried to navigate a maze of bureaucracy and had the good fortune to find that one person willing and knowledgeable enough to tell you who to talk to, what forms to submit, who has the answer you need, then you’ve met an information wayfinder.
In their own way, software projects can become as complex as bureaucracies. But whereas bureaucracy tends to have massive, entrenched, and formalized ways of doing things, the pace of technological change and the relative youth of software development is less maze-like and more akin to traveling through uncharted territories. Depending on the organization, you may have to succeed at both traversing the labyrinth and blazing a trail through the wilderness.
In either of these environments, wayfinders channel the energy of participants into the project itself, rather than leaving individuals to struggle through the jungle or navigate the maze on their own.
Developing the Skills of a Wayfinder
Wayfinders have many skills, and even if you don’t see yourself as suited for the role, you can still acquire a few of the skills:
- Learn how to reach people. Wayfinders know the preferred communication media of the team members and stakeholders for both regular and urgent communication. For example, if you’re aware that someone checks their e-mail once a day but responds to a text in seconds, you can remove hours or days of latency. It's usually best to stick to official project communication channels first and use alternates only when something is stuck or urgent.
- Learn people’s work style. What time of day are they typically most effective? At what tasks? When do they benefit from a break? Wayfinders help people shine.
- Learn who’s who. Wayfinders learn the work well enough to know who has the answer to what kinds of question; they make connections between people who need information and people who have it. You may not know anything about the caching layer of Drupal, but if you know who does, and someone is lost, you can point them in the right direction.
- Amplify the connections you make. Amplify what you know and what you discover by creating shared resources: documentation, FAQs, and tools that increase the chance of someone finding information on their own or can figure out where to turn.
- Monitor flow. Keep a casual but continuous eye on asynchronous communication channels (mailing lists, issue queues, etc.) for communication that isn’t responded to within the project’s target response time.
Wayfinders tend to be generalists, knowing a little about a lot of areas; they can be difficult to find and keep in the software world. When talk is silver and code is gold, in workplaces that maintain different pay rates for people who code and the people who amplify the effectiveness of the code, it’s not surprising that wayfinders don’t stick around in great numbers.
Support Each Other
If this sounds like a lot of work, it is. Even the most skilled communicators can become unfocused, exhausted, distracted, or otherwise unable to support the emotional and information needs of others. Independent of specific roles, people who rely on teammates – when they find themselves in a position where they can’t communicate effectively – can still benefit both the team and the project.
I’ve been talking about removing unnecessary communication delays, but it’s just as important to know when delays are beneficial. It’s good to hold back when you’re too angry to be responsible; to take time to heal when you’re sick; to recognize when you need to recharge or take a fresh look.
When Your Communication-fu is Low
- Clearly adjust response expectations. Like a vacation reply or the warning on a support line, telling people they’ll encounter an atypical delay can relieve pressure.
- Don’t just go silent. If you’re busy working and it suits the nature of that work, show progress. It isn’t always possible, but frequently pushing code, making drafts visible, or otherwise letting your work speak for you can reduce other people’s uncertainty of where you’re at and make it less necessary for them to interrupt you.
- Seek support. Look for people you can trust to filter for you when you need to focus, when you’ve been pushed to your limit, or when you’re overwhelmed with other priorities. Enlist them to lend a hand. Look for opportunities to reciprocate by doing the same for them or exchanging disparate skills.
- Don’t take emotional labor for granted. No one is entitled to being supported this way. It takes time and energy. Asking for what you need doesn’t guarantee you get it.
Protect the Zone
It takes extraordinary energy to communicate deliberately. It takes enormous focus to write complex code. It takes both to learn new systems and document them. It takes focus and diligence to test and provide feedback. Visual design, project coordination, marketing, sales: the myriad roles on a team all have a “zone.” Protect yours. Respect others’.
Don’t expect a person tasked to deliver in one area to excel in the others. Avoid asking people to switch in and out of different modes of thinking. Even someone skilled in multiple areas and fluent at switching pays a price for task-switching. It’s the energy equivalent of driving in stop-and-go traffic. A lot more fuel gets burned. Sometimes it may be necessary, but it’s seldom desirable.
Ways Individuals can Protect the Zone
- Respect boundaries. If someone sets “Do not disturb” flags, don’t disturb them.
- Set your own boundaries. Make space for yourself to be effective. Set your own do-not-disturb flags, create time when you’re not in company chat, take a break when you need it. Do what works for you.
- Employ empathy. Maybe someone working hard to get a production server back up isn’t able to communicate nicely. People pulled from their zone have often temporarily lost the ability to empathize and can get cranky. When someone is struggling, look for ways to help them rather than unleashing judgment, which moves everyone away from what they’re good at and creates friction.
Organizations and Projects Can Protect the Zone
The specific context of a project will affect both what is possible and what works, but here are some things that can help people find their productive zone and stay there:
- Allow work-from-home time for office-based teams.
- Designate collaborative time where people can count on getting questions answered.
- Designate quiet time where people are automatically protected from interruption.
- Maintain a release cadence. Predictable release cycles allow participants to budget their time and energy accordingly.
It’s much easier to see and quantify what is missing and confused in the artifacts of software development: unimplemented key features, crashed servers, failed tests, contradictory documentation, difficult user experience, spaghetti code. It’s harder to put a figure on the effect of communication and information flow on time, budget, and morale. Too often, people think it’s just the way things work and don’t realize that communication skills can be honed as surely as technical skills. But everyone is affected by the energy drain of poor communication and buoyed when the information is flowing well.
Every software project has a quality with which it moves. Is it difficult to get anything done or nearly impossible to keep up? Is it filled with hurry-up-and-wait or does it hum along seemingly without effort? When the course needs adjustment, are we talking the lumbering performance of a cruise ship or the dangerous course-correction of a speed boat?
In the same way that the distance to be traveled, the strength of the engine, the cargo, the size and skill of the crew, the needs of the passengers, the weather conditions, the available fuel, the quality of maps, and more will characterize a journey by sea, software development has myriad factors that affect the journey, too. Any of them can be adjusted or reconfigured in order to affect the project’s momentum: more staff, fewer features, different timeline, fewer meetings, more demos.
Communication skills may seem like the water and wind, things we must have and respond to, but over which we have little control. But the way we communicate greatly affects the ease and speed of our software development journey, and we can strategically improve communication skills as surely as we can improve technical skills.