Hey, we’re getting somewhere! If you’ve read the previous 3 entries in this series, then hopefully you’re in good shape. If you haven’t, give them a quick read!
The first three parts of the series focus on getting the project off the ground. The next three will focus on the build out. This is that special time where you might start off all optimistic and confident and then near the end of the build you’re searching for some extra budget in the couch cushions and wondering if somehow this calendar year skipped a month. No one ever wants to be over budget and over schedule, but it happens all the time in our industry. At Ashday we’ve worked hard to make this a non issue. Let’s talk about ways to improve the build process that might help us avoid this common problem.
Because good things come in 3s (wise men, musketeers, visually impaired rodents), let’s stick with it. Here are 3 key components to the build phase.
- Torrential Communication
- Constant Collaboration
- Constructive Accountability
Today (or whatever day you’re reading this), we’ll focus on the first - Torrential Communication. Let’s break this one in three parts just for the heck of it.
Everyone will know everything
One thing that drives me nuts is when people start making a point with a disclaimer. (disclaimer: I’m about to do that). So we obviously don’t expect EVERYONE to know EVERYTHING, but when it comes to understanding the guts of what’s being built, the whole dev team better understand it. Why? Well, it allows for sharing of ideas, identification of bugs, recognition of slipping requirements, flexibility of resources, etc, etc, etc. One of the more frustrating things that can happen in a project is to end up with a team of silos where Dev A has no idea how the SOLR search integration works that Dev B built and Dev B has no idea what Dev C did with lead gathering. Then bugs or questions come and you’ve gotta find “that guy” who knows. Not good. Silo’d workers (over a longer period of time) also get tunnel vision and no longer see what they’re missing. So one part of torrential communication is for the team to keep updating themselves on architectural approaches, requirements adjustments, priority adjustments, etc so that there’s a sense of context with what everyone is working on.
Everything begins and ends with chatter
Key 2 - everything beginning and ending with discussion - is a crucial element in executing the approach described in Key 1. It’s so easy to start to assume that people are picking things up, are communicating, are on track. The reality is - our work just requires too much of our brain in the day to keep track of what’s been kept track of. That’s why implementing morning stand-ups, end of day wrap-ups, sprint kickoffs and retrospectives - whatever the effort requires - is so important because it’s a “stop for a moment and think of anything that the team should know.” Sometimes it’s just “hey, did everyone catch that we’re renaming widgets to thingamajigs” and sometimes it’s “hey, this new Paypal integration is awesome, and here’s how we implemented it.” It’s a predictable and open invite to go over workflow business and small details so that you’re not relying on each individual to take on full responsibility for that.
Comprehension vs affirmation
This is a biggie. In the middle of a build, weighed down by a lot of details and micro-decisions, it can be tempting to gloss over communication and not take the critical step of ensuring that people actually understand what’s being communicated. So we’re not looking for an affirmation - a “yeah, gotcha”. We’re looking for signs of understanding via follow-up questions or active engagement in the conversation. There’s nothing more irritating (maybe other than disclaimers) than taking the time to communicate what’s going on only to find out that it was forgotten or misunderstood at a later point when it’s much more painful to correct.
That’s all it takes. Talk, talk, talk. And understand. All the time. That’s about it! Easy, right? Next time we’ll get past the words and into the actions and see the strong parallels between the two.