Beyond Code: Tools to Connect with Stakeholders as a Technical Leader

In 2019, I started volunteering for the dog adoption agency The Barking Lot. The most important part of its website is the adoption form, and I wanted to help the owner optimize it by reducing its fields (more fields = more chances of getting overwhelmed & bouncing).

I decided to create a Google Sheet with all the form fields. The spreadsheet had a drop down for each field so the owner could help decide which fields we should keep. The outcome: we were able to remove 20% of the form fields and shave 5 mins off the average form completion time.

This is an example of an unexpected work product that drastically helped me gather stakeholder requirements and complete a project successfully — no code involved.

Your Toolbox

The outcome above would not have been possible without a medium that checked these requirements: I needed feedback from the owner on each of the fields, and needed some degree of interactivity so she could make those changes inline.

Because of those constraints, a series of emails would have been nightmarish, but even a Google Doc with its collaborative abilities would have slowed the process down.

This doesn’t mean that the other formats don’t come in handy. I’ve had to use a bunch of different tools and present information in different ways over my career so far.

Here are examples of different work products and tools I used:

• Presentations (PowerPoint, Google Slides)
• Documents (Notion, Confluence, Google Docs, Word)
  Notion makes it incredibly easy to create rich, interactive documents.
• Analytics, Usage Reports (Mixpanel, SQL via Redash, Google Analytics, Segment)
  Redash is a SQL editor with visualizations that you can self-host on most cloud providers. You can make an unlimited number of accounts for your team and share queries and visualizations with them.
• General communication (Emails, Slack, Meetings)
• Diagrams (Mural, InDesign Freehand)
  Freehand is a free tool to create diagrams and collaborative whiteboarding sessions. I’ve used it to show anything from SDLC lifecycles to architecture diagrams.
• Real Platform Data for Designs (SQL via Redash)

Choosing which one to use can be a challenge too. Consider each tool you have your disposal and weigh it against the type of information you’re trying to convey and any requirements you know of. Take stock of the audience as well. In some cases this will immediately reveal a clear winner. Other times, you may have to dig around the toolbox
a bit.

If nothing fits, you may need a new tool entirely.

“If you get stuck, draw with a different pen.
Change your tools; it may free your thinking.”Paul Arden

Learning new tools

Being open and curious about new tools is a crucial aspect of growth. Both as an individual contributor and as a leader, your success hinges on your ability to: keep up with the latest and greatest tools, use them effectively, and encourage their adoption.

Technology moves fast, so you’ll need to constantly be on the lookout and work your learning muscles.

Once you have something in mind, roll up your sleeves and start to use it. If you have teammates, colleagues, or friends that have used it before, ask them to show you around. Getting a rundown for even five minutes and seeing how someone uses it in real time will save you hours down the line.

Conversely, strive to return the favor by doing the same for them. I’ve always found that teaching someone is a great way to strengthen my skills and thought processes. As you teach others, they also bring new use-cases that challenge your abilities and offer a fresh perspective.

When possible, try to record any training meetings you host or participate in. It’s a small action that pays dividends later on!

The tools you use will change with your career

In the beginning of my career, as a web designer/developer, my output was pretty concrete: produce designs or develop websites based on a combination of design and spec. These were detailed tasks, with requirements gathered by someone else upstream, and they were well thought-out before landing on my desk.

Once I took on a tech lead role within my team, my output started to shift — I had to zoom out from the individual tasks and focus on the team’s collective workflow. My work product became the organization of tasks, technical plans, reports, and communication with stakeholders.

Moving up the chain of communication also means meeting stakeholders where they are at — using language that is proportionate to their level, and when possible, using tools that they are familiar with.

The presentational skills/tools covered here are discussed far less than their technical counterparts but they are equally, if not more important (especially as you advance into leadership).

Ultimately, by embracing this aspect of your career, you will master the most important skill of all: the ability to successfully convey your ideas.