Cat McLoughlin

One of the biggest obstacles for many organizations, in any industry, is the bridging the communication gap between technical and non-technical teams.

First, let’s take a moment to define those terms. I come from the perspective of a professional software developer. “Technical,” in our field, refers to someone who reads and writes code for a living. In other fields, however, a “technical” person may be an editor who is proficient in grammar and spelling, a business strategist, or a financial officer. Everyone is technical in their own area of expertise. For the sake of distinction, though, I’ll use the word to refer to those who work on the technological problems that other stakeholders in the business may not understand.

I work on technical problems every day for a living. As a developer, I work to solve problems both within internal systems and as I develop client products. One thing I have learned over the course of my career is that, when working on any technological problem, one of the most challenging components in communicating what I do every day and the problems I’m facing to non-technical stakeholders.

In Paul Ford’s What is Code?, the author references a story about a mid-level manager working with a team of software developers. The business stakeholders work with the developers to establish a timeline and budget for a project, but when that time is up, the development team reports that they have not met their goals. They have come across unforeseen hardships and require more time and money to get the job done. This is a frustrating situation for everyone involved.

Missing deadlines and angering stakeholders are par for the course in our industry. Despite what the others may assume, though, the problem in these scenarios is rarely developer incompetence. Instead, I think the main problem in this story was communication between the engineering team and everyone else involved.

Let’s break down three parts of the development process where better communication strategies might have been used to avoid future frustration.

• Estimation and Planning

I believe the single-most important aspect of planning a software project is setting proper expectations. When new projects or features are drawn up, stakeholders tend to have 2 primary concerns: when they can expect the project to be done and how much it will cost.

This is when the first breakdown in communication tends to occur. From the perspective of a developer, estimating is one of the hardest things we have to do. Building software is not like making something from a blueprint. If the thing we are being asked to build had been made before, the business wouldn’t need us to build it from scratch. Every time we make something in software — whether it’s a small portfolio website or a major enterprise application, we’re doing something that has never been done before. This is why it is so hard to say exactly how long it’s going to take us to finish a project. It’s also why estimations are so often wrong.

What are some strategies for improving conversations regarding estimation and planning?

• Feature stories and release plans.

Whenever we start any project, developers and stakeholders need to work together to break down the project into the smallest possible components and estimate each individually. An estimate of one day to get a blank page with some text up as a first step will likely be much more accurate than if you guessed it will take six months, three weeks, and four days to complete an entire website.

• Address risks as soon as possible.

Whenever we start a new project, the product owner and/or the developer are generally aware of the aspects that may be the hardest to complete. We should not put off talking about those potential roadblocks. Address them now so that they don’t grow into bigger problems after work has been started.

• Be honest.

As a developer, it is never a good idea to sugarcoat problems you foresee with a project. Be honest about how long you think something will take, even if you think the estimate will be larger than what anyone expects. A negative reaction to a large estimate will be far more tempered than a negative reaction to a large underestimate.

In Gerald Weinberg’s Secrets of Consulting, the author tells a story about what he refers to as “The Orange Juice Test”. A caterer is looking to hire a contractor. She says, “I’m going to need 500 glasses of freshly squeezed orange juice ready to go at the beginning of my event.” Some candidates will tell her, “that’s completely impossible.” Of course, she won’t be hiring them because they’re not interested in even trying to solve the problem. She has some candidates tell her, “Sure, I can do that.” These people won’t be hired either because they’re clearly lying! It’s a very difficult problem and they’re either not aware of the challenge or they’re just saying what she wants to hear in order to get hired.

Instead, the people she will consider for the job are those that respond by saying, “That’s a real problem. I can help you with it, and this is how much it will cost.” This is the truthful answer. Every problem is solved at a price, and it’s best to be upfront with the people you work with about that cost.

• Requirements-Setting

Even before the estimation process begins, requirements for what they are being asked to do must be communicated. Developers are often given a mockup or verbal description of the problem at hand. Once the plan has been made, they then go off to their desks, work for a certain period of time, and come back on demo day to show what they’ve done. Sometimes the stakeholders love what they see and everyone is happy. Often, though, demos are a time when stakeholders feel blindsided. The work is not what they actually wanted, or it feels incomplete. In these cases, time and energy has been wasted because the criteria for success had not been properly laid-out.

What are some strategies for improving conversations regarding requirements?

• Be strict about writing acceptance criteria when the work is being defined. Use “As a user…” syntax or Gherkin syntax (e.g., Given…, When…, Then…) to clarify expectations.

• Break down large chunks of work into the smallest possible deliverable pieces. This allows the team to think through every decision that will need to be made. Oftentimes the process of breaking down work enlightens us to complexities that had not previously been considered.

• Avoid shifting requirements by establishing a contract that once a piece of work is begun, no new requirements can be tacked on. Each new requirement deserves its own acceptance criteria and estimation process. When requirements shift in flight, estimations go out the window.

3. Transparency

In many offices there is a physical and cultural divide between the business operations teams and the tech team. The two camps often sit in different parts of the office and only communicate when forced to do so. This can lead to problems for both sides.

For developers, this setup can leave us stuck on “the wrong problem” for a longer amount of time than necessary. It discourages us from asking the questions that may end up saving us time and energy down the road.

For stakeholders, when estimations fail (which they very often do), it takes too long to be notified so they can adapt. Without consistent communication with the developers, they end up being caught off-guard when the project isn’t done on time.

What are some strategies for improving conversations regarding transparency?

• If possible, developers and stakeholders should interact outside of planning / delivery meetings. Although we’re not always in control of this, it’s best to physically sit near each other.

• Daily standups force us to communicate our progress and give us time to ask questions and get clarifications about anything that has come up the previous day.

• Establish a shared vocabulary.

A lot of time, software projects can be a difficult topic to discuss. Words like “component” and “module” become overloaded terms because they’re used as catch-all words to describe all the things we don’t know what to call. Similarly, acronyms are rarely helpful — they are confusing and can slow down the onboarding process because new employee can’t infer meaning from them without being taught.

Instead, try to pick unique names for things and stick with them. Make sure that these terms are used consistently in conversation, writing, and in the code itself.

• Don’t be afraid to discuss failures.

It’s best to be open about what has been difficult and what isn’t working as soon as it becomes apparent. Don’t be afraid to get “technical” about these difficulties either. It’s better to take the time to explain the complexities of a project than to gloss over it and leave people with less information.

Developing a culture of clear, consistent, and honest communication between teams and across functional roles can help to reduce tensions and improve the efficiency and performance of your organization as a whole. Remember to include everyone throughout the process so there is a consistent understanding of the project goals and expectations. Hopefully, these tips will help you avoid some of the struggles that can get in the way of effective communication.

Cat McLoughlin – Bio

Cat McLoughlin is a software crafter at 8th Light, a custom software development company. Since joining 8th Light in 2016, McLoughlin has helped clients of all sizes improve their performance and expand their services by leveraging custom software solutions.

Cat earned her Bachelor degree in history from New York University, with a minor in computer science, and graduated from Chicago’s DevBootcamp. Bringing together her passion for technology and championing inclusive workplace practices, she is involved with Los Angeles’ chapter of Girl Develop It, and also volunteers with the LA Software Craftsmanship MeetUp.