Stop Demoing Tech to Non-Tech Folks
Just this week I heard from another coach that a team ended their demo early because they assumed their audience of non-technical stakeholders wouldn't want to know that the team replaced?hard-coded code for configurable code.
Some back story, the team added the hard-coded bit as a way to validate a change. Once it was accepted by customers, they swapped it for the configurable version. Cool! Their incremental approach is fantastically agile.
The value of the configurable code is significant: a developer is no longer required to configure that part of the application, the release time is down to seconds because the team is not dependent on a code release cycle, rollback is a snap, and the risk of mishaps is virtually eliminated. The list could go on and on. Unfortunately, no one outside of the team has awareness of this awesomeness.
Imagine what questions or realizations may have come out of sharing this win. Here are some possibilities:
Don't Demo?
I believe the issue teams run into with demoing tech to non-tech is the act of demonstration. With UI changes you are demonstrating the changes in a click-by-click fashion. If we follow the same demonstration method for the hard-coded code scenario that would mean we are demonstrating code. Are we surprised that non-tech stakeholders are checked out? Intimidated? Lost? We shouldn't be. Why should they care about the code that's being shown to them? All they see is a smart developer dude showing them nerdy code stuff.
It's time to get out of the code editor and explain the impact. Why did the team dedicate time to do this work? Have a human, collaborative conversation.
"We switched the hard-coded code for configurable code because it promotes time-savings, efficiency, peace of mind, and dependency reduction. Here's why and how:"
领英推荐
Boom. No technical jargon. No code editors. Pure goodness that everyone can relate to and respond to.
Long story longer: adjust your delivery to best engage your stakeholders.
Best,
Jess
*Don't forget that architects are stakeholders. An architect's perspective is a unique blend of?strategy and down-in-the-weeds technical which makes them inherently inquisitive, adding value to the broader demo conversation. Oh, and they tend to be left out and called in later when things get bad. Avoidable pain, folks!
RN, NI-BC | Artificial Intelligence + Healthcare @ Microsoft | Life-long learner who’s figuring out what I want to be when I grow up.
2 年?? This. Yasss!
Cybersecurity writer, blogger, and content creator with a focus on growing more educational awareness about cybersecurity and online safety.
2 年Great points here, Jess Brock.
Senior Consultant
2 年Being able to explain the business value of the technical work is key!
Engineering Operations practitioner
2 年At Dashlane we’ve got a value of Customer > Company > Team Quite simply we need to embed that into the work we do to better claim the win. Engineering is a classic scapegoat when things go wrong, but even when we make awesome changes we often fail to sell the results, for our internal and external customers. My biggest peeve is when someone gives me a “backend vs front end” update and I’m screaming “but what can the customer DO NOW that they couldn’t do before?!” Literally what’s in it for me? (WIIFM?) Such an important reminder for everybody especially in a time of doing more with less!