Build trust with proactive communication
When you don’t understand something, it’s human nature to find it hard to trust in those that will be doing it. Think about the feeling you get when you go looking for a new mechanic. In business it’s common to find a similar unease with the engineering department. The usual compensation for this lack of trust comes in the form of heavy handed process or interference.
The unfortunate tendency I’ve seen in most teams is the disposition to back off, get quiet, and lean on some interfacing role to try to translate reality outward. This leads to a mistrust spiral that exacerbates the issue further. For whatever reason quietness is interpreted as a slew of bad signs. It can equate to laziness, lack of caring, and distraction to name just a few.
Often when devs run into a challenge, rather than taking a moment to communicate the road block they’ve run into, they dive right in and get to work. Sometimes this is because the amount of time to fix it is deceptive. Like chasing a mirage through the desert you feel like you’re perpetually almost there. One of the easiest things a dev can do is fire off a quick message and let the product manager know there was an unexpected difficulty and as soon as you know more you’ll get back to them. This proactive approach will give warm fuzzies to the PM and let them know not only do you care but you’re not going to hide anything along the way.
A recent example of this I witnessed: Our mobile team is working on a brand new green field project. They are building an MVP to test a few assumptions around banking data. The team is working hard and doing a great job of trimming down the feature set to try to get to the first release. New projects, especially ones involving third party integration, are nearly impossible to predict the total complexity involved. After a couple weeks of heads down progress the product manager was getting pretty anxious that he wasn’t able to predict the finish line. He began to express this anxiety with constant questions to the dev team, asking for progress reports, or expected delivery dates. Everyone involved was getting frustrated. The short term solution was adding a project manager as a buffer between the engineers and the product owner. This served mostly as a temporary relief, a translation layer that only seemed to lessen the anxieties.
The reason for this anxiety is a lack of understanding on the distance to completion. Rather than arbitrary times like two week sprints, which may or may not divide the work logically, define logical deliverable milestones. Each week you could review progress towards the nearest milestone. If they are granular enough that you are regularly discussing the completion of one and your progress on the next it’s going to feel like things are getting done to those watching from the outside. For example, some milestones of a mobile project nearing completion:
Deliver the sign-up experience to QA.
Deliver the full experience to QA.
Publish the beta to the app store.
Since we can’t be sure how long the QA process will be, it doesn’t make sense to try to set a delivery date. If we could predict the number of bugs, we’d be magic and probably wouldn’t have written them in the first place.
Back to the original point, if something comes up that is going to unexpectedly slow you down, say something! Even better, you finished your milestone, celebrate. We rarely stop enough to get excited about those little successes we have. Don’t wait for your PM to come to you, proactively reach out. At a Startup Weekend I attended once, you’d often hear spontaneous clapping as a team had a breakthrough on a problem they were struggling with. Not that you should interrupt your office flow with random celebrations, but it was a fun example of getting excited about the small wins.
Good communication is an art. One that is often neglected by our developer community. Those touch points between engineering and the rest of the business will greatly appreciate your efforts to be better. Good luck to improving your art.