Make Your Tech Team Fall in Love With You

Win respect in tech teams without writing a single line of code

Photo by TopSphere Media on Unsplash

Developers and architects can spend countless hours discussing frameworks and programming styles.

As a non-technical person, you will have a hard time one-upping them with technological wits.

Here’s the upside: You don’t have to.

The tech world offers a wide variety of non-technical skills you can use to stop misdirected discussions in their tracks and steer them into more useful directions.

Here are three principles that will make you indispensable: advocate for the user, push for conformity with expectations, and promote minimalist documentation.

Be The User’s Advocate

No offense, but when highly capable technical staff join forces, they tend to search for solutions to unclear problems.

This is where you come in.

Make sure that you are the one person on the team who invests time into user research:

• Ask product managers, UX designers, or marketing experts for personas and customer journeys.

• Talk to support colleagues to understand the real-life struggles of your users.

• Try to participate in user interviews.

You’ll get a clear understanding of what makes your users tick.

Before you phase out due to useless discussion, you’ll be the person to guide the team back to centering around the user.

Start by waiting for a small time window in which everybody catches their breath.

Then, dare to ask the question:

Truly great ideas, everyone! But is this really what the user’s need? What problem do we solve?

Followed by:

Here’s what I learned about our users. [Drop your relevant user knowledge here.]

Is this a quick way to make friends?

Well, the last time I did it, the product manager didn’t seem to have become a huge fan of mine.

But it definitely earned me something more useful at work:

The respect of the team.

…And the product manager respected my speaking up eventually, too.

Reinventions vs. Stealing in Style

We’ll stick with your new wisdom surrounding user centricity.

Developers strive for complexity.

They want to solve complex puzzles instead of copying and pasting second-hand code from Stackoverflow.com.

This bears the risk of reinventing what already exists.

When it comes to user interfaces, introducing new paradigms is rarely the right choice.

The reason is simple: Users are used to specific patterns in their products.

• Windows has a Start button in the bottom-left corner.

• When you move your mouse to the upper-right corner of a window, you can close it.

• The menu button is usually in the upper-left corner.

• etc.

When people have epiphanies of changing such paradigms, you will not reap the user’s ovations.

You’ll trigger user frustration (and possibly memes).

Windows 8, I am looking at you!

So, the next time a dev whips out a crazy-unique user interface, you’ll be the pesky UX expert to stop the madness.

If you want to be a wise-ass about it, here’s your term: Conformity with user expectations according to ISO 9241-110.

What it means is to go with whatever the user would expect naturally.

Any introduction of new design ideas needs to be thoroughly questioned.

Weigh the probability of user acceptance against the benefits.

If in doubt, have it tested with users or other stakeholders.

Minimalism Saves Time and Wins Friends

With these two skills, your competence increased, while your popularity might have taken a hit.

So let’s do something about that reputation.

You know what developers hate with a passion?

Documentation!

Here’s the knowledge drop that will help you bring both of the above points across and keep your friendships alive.

Because user-centricity is not only about making the product more successful. If used correctly, it will also make work more efficient.

Because you will:

• Stop developing and maintaining (!) things that aren’t needed or wanted.

• Save time on writing documentation.

While the first one should be clear, the second one needs a bit of an explanation.

According to the state of the art regarding user documentation, you shall not document every little thing the software does.

Too much content in your documentation can cause a needle-in-the-haystack effect.

The users cannot find the right answer simply due to the overwhelming amount of content.

So, your team should only focus on documenting features that either:

• pose a safety risk if misused, or

• cannot be understood intuitively by the target group without additional documentation.

See? You are not the villain. You are the hero who saves the team from writing documentation.

Anything intuitive to the user does not require user documentation.

And if you need to back this up: refer the doubters to the most important horizontal norm for technical documentation: ISO 82079-1 (look up Minimalism).

---

Master these three skills, and you’ll be more than the non-technical teammate.

You’ll be the person who keeps the team grounded, efficient, and, yes, someone they love working with.