Connecting with Engineering Teams
When consulting, communication with stakeholders and the business is first nature. In our experience, to really help digital transformations of tech savvy companies it is just as vital to connect effectively with the engineers on the ground.
Things sometimes only an engineers can tell you:
Technical details that will affect how something needs to be
Technical constraints that have steered tactical decisions of the past
Business domain details that will likely complicate product design
A proper understanding of engineering pain points and technical debt
Even more importantly, engineers are the people who most need to be on board in order to effectively bring technical innovation to a project or organization.
Agile methodologies have developed to skirt around tech questions, to convey business needs to engineering resources and to learn from them what is and isn't possible. For technical consultants, there is a need to listen and learn, but also to challenge and explore the substance of perceived constraints.
Too often, sensible caution in one engineer can spread into organizational paranoia, and a once-planned change in technical approach can easily become so remote that the team has talked itself out of it.
Good engineers are confronted all day by snippets of information to store away, some of which will feel like foreshadowing clues of technical woes ahead. Technical narratives develop inside engineering groups which are usually a tricky mix of vital facts that mustn't be ignored with half remembered suspicions. For every tale ask yourself:
Is this a joint narrative of shared experiences, or an anthology of isolated viewpoints?
How far has the narrator seen the code, versus holding onto advice of someone who's already left?
Is this the state of things now, or a story of the journey that went before?
Is there true cause and effect, or is this a convenient explanation of something that hasn't been fully understood?
Or is this the one lurking timebomb that's going to trip up your plan?
Talking through engineering fears is the best way to put a team at ease, and if there really is an impediment to what feels like a great plan, it's always best to know about it up front. Sometimes engineers have just had bad enough experiences in the dark depths of code that they will try hard to avoid stepping there again, even when the gains will drastically improve the tech debt situation.