Skip to main content

How do you communicate?

Ariel Villanea
Solutions Architect, Software Engineer, and Pragmatic Problem Solver

Over the course of my career, I have been particularly skilled at two things: Championing the needs/concerns of non-technical stakeholders while supporting the needs/concerns of technical stakeholders, and bridging the gap between the two skillsets in a considerate and collaborative fashion.

My development of these skillsets has made me realize a few things.

IT vs Everyone

It's everywhere. Sometimes it's different departments. Sometimes it has a different reason, but it is phenomenal how often I will join a team and hear that Marketing and IT are known for butting heads, or that the Call Center team can't seem to get the AppDev team to help them with their legacy systems, or that InfoSec is struggling to get the Executives to agree to the value of writing hardened software instead of buying blackbox solutions.

These kinds of things are not unique, but they've, for some reason, become an accepted norm; an expected necessity of doing work with IT departments and technologists. I never understood that.

In separate roles, I had clients and co-workers alike who looked at these massive, shiny offers for solutions, and retreated immediately. They were overwhelmed by the scope and the technical jargon; promises like, "We're going to build a Mobile-First Website with out-of-the-box Search Engine Optimization and Structured Data. We'll implement a Continuous Improvement/Continuous Delivery Pipeline and even stand up and provide support for your state-of-the-art Web Application Firewall hosted on Microsoft's Azure Cloud." might excite engineers and technologists, but this word salad means nothing to the average business owner who knows Roofing inside and out, or the Finance stakeholder who was told nothing more than, "We need a better way to handle special assets." by their leadership and given a budget, or even the Call Center agent who has found every annoying workaround in their system but has been told not to bother IT with requests to have the workarounds replaced by permanent fixes; sometimes, they don't even know that was ever an option.

These issues are all too common, and when they're ignored, they slowly fester and breed disdain. This is the beginning of that classic, "Ugh... now I gotta email IT." And once that mindset starts, it snowballs and becomes damn near impossible to get rid of.

Two Solutions?

In my career, I've found two potential solutions to this issue. Obviously, secret option #3 is, don't let it happen to begin with... but how?

Option 1: Practice Active Listening

It sounds so simple and yet it seems to be one of the most difficult things for some organizations to do.

I once had a client who was pitched a massive project by my team and we nearly scared them away from the very beginning. I'm paraphrasing, but the overall situation played out like so:

The client seemed a bit distant by the end of the pitch and didn't really seem to have many questions. Before the meeting ended, I interrupted and said, "So, we just dumped a ton of info on you, and ultimately, I'd like you to keep all that in the back of your mind. You don't need to memorize or even be excited about any of it, but now that you've heard all of this, can you tell us: Did you, at any point, hear anything that fixes the problems you're trying to address with your current website?"

She shook her head. "No; I don't know. Don't get me wrong, I'm impressed by all of this, it sounds super fancy, and I suspect you're all very smart, but I have no idea what you're asking me to commit to right now. I just wanted my website to be higher up on Google, and now you're telling me I have to have some application firewall for that to happen?"

This killed me. We were so excited about the technological improvements we could offer, that we completely overlooked her fundamental reason for coming to us: She just wanted some help placing higher on Google.

We were able to salvage the relationship by simply taking the time to talk about her needs and expectations. We turned the sales pitch into a collaborative discussion about needs and wants instead of a one-dimensional info dump with a big price tag and pushy request for a signature.

Option 2: Change Team Structures

At one of my jobs, I stumbled into something that I never considered beforehand, but now would swear by. I was hired as a Software Engineer, but I wasn't hired by their IT department; I was hired by Marketing.

At first, the IT department was very confused as to why an engineer was hired outside of IT despite them having a whole army of .NET Engineers. Some of the Marketing folks also were confused about my role, even.

I got to know the Marketing team closely and understand their frustrations and blockers first-hand. Soon, the Marketing team felt empowered to request new work because there wasn't a soulless ticketing system between them and an endless backlog; it was a desk they would walk to, a face they could speak to, and a person who could at least fully relate to them when giving them bad news about why initiatives would need to be put on pause or be re-explored for viability.

Meanwhile, IT found a new friend and champion for them embedded into a team that had, for years, been at odds with them. Marketing and IT suddenly stopped arguing with each other. Instead, they came to me with their concerns, their feedback, and their requests. Eventually, the lone engineer in Marketing became two more engineers, a QA, a content manager, a project manager, and me.

While you could argue that this story has the same hero as the first (Communication), I would argue something more. I think this scenario is something we need to look at across the corporate world.

I want to ask: Why do we have to have a separate IT Department? Now, don't get me wrong, I understand the value of having an InfoSec team, and standardized development practices across an organization... but why do all the technologists need to be tucked away in their own silo, away from the people who actually use and need the software they're working on?

Some might argue: Well, if the engineers sit with the rest of the teams, they'll be constantly asked to work on additional work and distracted from crucial deliverables. But I don't think that's a valid concern. That isn't an issue with seating arrangements, that's an issue with boundary training and project management processes.

Break Down Barriers

Ultimately, both Option 1 and Option 2 boil down to one singular need: Break Down Barriers.

So, in a world where every single barrier snowballs into hours upon days of lost efficiency, why aren't we trying to break down the simplest of all of these barriers? Open, truthful, shameless, and sometimes difficult communication solves more issues than we often care to admit.

We have one bad experience, then a second, then a pattern develops and an expectation blossoms. We treat each other with these expectations out of the gate and we've already walked into conversations assuming their outcome. Suddenly, no one wants to "call IT" anymore.

So, my question to you is: How do you communicate? How are you addressing these issues in your workplace? I'd love to hear from you on LinkedIn if you have a perspective I haven't considered or if you just want to share your story. Thank you!