It's not done until it's communicated

One of my first jobs in the industry was an internship at the Jet Propulsion Lab (JPL), which was part of the public private partnership that ran a portion of JPL as a NASA flight center. I worked on a computer vision application that unfortunately didn’t pan out. What I did take away from my internship was a statement that eventually transformed into a cornerstone of my professional philosophy:

Science isn’t done, if it’s not communicated.

This simple statement is an underpinning of sharing scientific knowledge. Not only does science need to be communicated via journals so that it can be reproduced and verified, but the results of science need to be communicated to the public at large. For NASA, that fosters further technological development by publishing basic science results that engineers can build on to create new technologies like the cell phone in most of our pockets.

There’s also a broader societal impact to this communication. Science communication (especially in planetary science and astrophysics) inspires us. Seeing the technological achievements of landing a rover on Mars helps us all dream bigger. These feats inspire us to reach for the stars and build new things.

All that is fantastic, but there’s also something simpler, more fundamental to the statement. Science is work. You take hypotheses, experimental data, modeling etc and process them into a result. At the end of the work, if it’s not communicated, then I certainly don’t think it’s done. I’ve tried to operate with this in mind. Any time work is done some level of stake holders need to be informed.

Communicating Work with other Devs

Communicating work with our fellow developers seems to be the most straightforward. Unfortunately, with the level of stress and high numbers of tickets that pile up, it’s pretty difficult to make sure that you communicate that the work that another developer might be waiting on is available.

I’ve seen quite a few developers struggle to find a working strategy for this kind of communication. I often try to counsel the developers that I guide as a lead to do some of the following:

Establish open channels of communication

One of the most important communications among fellow Developers is establishing open channels that are topic specific. I almost always have at lest three channels with developers pinned in my Teams client. Those pins are usually comprised of the group chat with all of the developers on my team, and at least two pinned group chats that are feature specific with just the developers working on that specific feature.

I find that this creates an opportunity for more direct communication for the team in the case of the entire team group chat. This chat also provides a clear means of dispatching production issues because a developer can step up to volunteer for an issue raised, which then cuts down on issues where multiple developers jump in to start triage on an issue. When someone does grab an issue via this chat, I find that I can make sure to share documentation that they or QA might need in the course of solving the problem.

This all team chat is great way to disseminate information to the entire group for announcements like new documentation, modifications to our libraries, scripts for handling ad hoc issues. I’ve also been having my team’s JR developer posting our release notes at a scheduled time during the sprint. That way he can integrate more with our release process and eventually start taking turns as the release engineer for a sprint.

Not everyone in the team is going to care about a lot of the ins and outs of developing a feature. While it is nice to see what others are talking about for a feature, if you’re not involved directly or busy with another feature, the whole team chat can become distracting. That’s why I typically try to have feature specific chats. That way we have an open space for just the developers on the feature to discuss how they’re going to tackle the feature.

These feature specific chats also present a chance for roping in folks from other teams. With some of my features that have a heavy dependency on DevOps, I will often hold a kick off meeting with DevOps. Then pin the chat from that kick off meeting to continue discussing the project with DevOps as they build out infrastructure for my feature. Then after we’ve made it out to production, I unpin the feature related chats to make room for new feature chats.

Leverage clear check points in work to communicate progress

Over the years, I’ve developed a good habit of creating small commits. Most of my PRs are trimmed down to be just the changes that are absolutely necessary for making the specific task that was outlined for the user story. That said, not everyone is there yet, and there could also be times where due to ambiguity a developer might have an 80% solution in their branch and needs feedback to get to 100%.

I like to encourage the developers that I work with to leverage these moments to discuss their implementation and ask questions. That way we can use our PRs to sort out issues and hopefully have an well thought out change to merge in by the end of the discussion.

We once had an architect that forbade this practice in our department, so I know this might not be the way most people would be willing to use PRs. I have found that this is a very effective way for a JR programmer to ask questions, since it can help contextualize the question in the code, so I’ve just ignored that architect’s advice for the last 5 years. I think work check points like PR submissions are great times to discuss questions and get clarification.

Outline and review work to make sure that it’s shovel ready

My team has within the last year or so introduced a ritual of reviewing the stories with the team before starting. The developer that has been assigned to the story needs to not only prepare a task breakdown but a detailed outline of how they plan on tackling the story. That way we can make sure that the story is shovel ready.

We can then come together in pre-scheduled meetings review the pre-work that the engineer has put together. This has helped open up our designs more, we’ve put more upfront work in, and since QA is included in these meetings, they can become more familiar with the test cases that they need to create before the story is resolved.

Communicating Work with QAs

As my team finished with work the meetings to review story plans would change to focus more on engineers handing the work off to QA. This was an extension of an approach that I started as a senior engineer, where I always put down a task in my stories to hand off the work to QA. That way I wasn’t just marking a story as resolved. I was writing either documentation to help the QA understand the state of story that I was delivering or making sure to make contact over Teams or email to communicate that the work was done. The latter communication often lead to questions either asynchronously over Teams or a call to talk over the story.

Eventually because I kept up with this habit, my manager scaled it to the rest of the team and it evolved to be the meetings I described before. Whatever form/ritual existed, I found that this helped reduce the number of bugs and an increase in quality. QA understood the work we were delivering better, and by making sure that the story was in the test environment and ready, I caught more potential issues with the patch before QA could.

Communicating Work with Stakeholders

On the marketing tools team we had to work very closely with a group that was in charge of creating custom property ads. We often had to take communication directly from that team instead of waiting for it to bubble up from Business Analysts or Product Managers. One of the things that I’ve trained a lot of my junior engineers to do is to at the very minimum send an acknowledgement when they’ve received an issue from stakeholders. People like to feel heard, and sending an immediate acknowledgement shows that you’ve seen their email and that the work is getting queued up. This acknowledgement is also a great place set expectations. The stakeholder can be told that you’re working on priority X and that their need might not be met until later in the week.

I’ve also worked with my juniors on making sure that they have a timely update to the stakeholders when work is completed. I often encouraged them to make sure to do some redundant communication. Inboxes can become quite full, and there may be a lot of Teams messages waiting to be looked at. Sending an appropriate amount of redundant messages can help the busy folks on the other end see that their concern has been addressed. I was once admonished by a director of engineering at CoStar that “it’s better to over communicate than to under communicate.”