6 ways staff engineers help reach clarity

Why?

Until we reach singularity, businesses are run by people. People come from different backgrounds and bring different perspectives to the table. Every person hired to the company, adds to its DNA. And just like DNA, those nucleobases (generally noted as C, G, A or T), people need to be aligned with each other and the organisational goal to deliver the maximum impact. Unfortunately this also means that no matter how great the employees are, misalignment can ruin the end result.

source: LinkedIn

What?

At its core, clarity is about understanding. One of the key value propositions for staff engineers is to reach collective understanding across teams.

source: itlaw.fandom.com

How?

The lack of clarity presents itself in two common ways:

  1. Passive: The output from the person/team shows that they are operating with the wrong assumptions and their truth and perspective is not aligned with that of the business.
  • How open are they? Have they failed and acknowledge that they need a different perspective?
  • Where is the truth? In one person? Another team? Behind an experiment or passage of time?

0. Build the base

All the clarity methods discussed in the rest of this article depend on having a strong base yourself to be able to help others. You need to have a good understanding of:

  • Domain: What’s the problem that the business is solving? What objects, relations, data and processes build the solution? etc.
  • Tech: What services are in place? Where do they run? How do they interact? How are they tested, deployed, monitored? etc.

1. You have the answer

This is the simplest scenario where an individual or team needs help and the answer is within your domain of knowledge, mandate or responsibility.

  • Mandate: instead of gatekeeping and acting as a benevolent babysitter, aim to establish processes which allow the team to autonomously make decisions.
  • Responsibility: if the knowledge and mandate are adjusted as pointed above, there’s no reason that the responsibility should reside outside the team with the staff engineer.

Some days, you’re the go-to.

2. The answer is within

Sometimes the person asking the question also has the answer. They just don’t see it that way.

  • Mob programming: multiple people work on the same problem but for a solution to go through the keyboard, is has to go through someone else’s hands (hence mitigating the biggest risk with pair programming)

Some days, you’re a mentor.

3. The answer is out there

There are a few scenarios where the answer is out there and you approach it together.

3.1 Another person/team has the answer

Often for larger organisations and/or higher level questions, the answer is in another team but due to the knowledge silos or lack of ownership the clarity falls between the cracks. It goes faster if the staff engineer has visibility into the other team but that’s not always the case. Besides when you are new or the company has recently gone through reorg, it is tricky to even find the start of the rope.

Some days, you’re just a catalyst!

3.2 The answer is scattered across multiple teams/people

Many staff engineers operate across multiple teams. Well executed ownership trio may lead to silos. One of the main value propositions for the staff engineer role is to break knowledge silos. To be able to bring clarity, they need to actively involve themselves outside their immediate teams and have visibility across the larger organisation.

Some days, you are a detective.

3.3 The answer hasn’t trickled down

Sometimes the insight is in leadership’s head but it hasn’t trickled down in an actionable form. Sure everyone got the memo or internal newsletter but in a world where we’re bombarded with information, sometimes it is not so obvious what a specific message impacts the day to day lives of its target.

Some days, you’re just a communicator.

4. The answer is behind an experiment

Sometimes the clarity cannot be reached without doing some experiments. This is often the case for technical questions and how they fit together to build a solution. A PoC (proof of concept) is one solution. Sometimes the teams confuse a successful PoC with an MVP (minimum viable product) worthy to go to production. In those cases, a risk assessment is in order to make sure that the full implication of taking an experiment to the customer is understood.

Some days, you’re a researcher.

5. The answer is in the future

This is an interesting one. Sometimes, the most reliable way to reach clarity is to wait and see. How will the market react to a new feature? How will the upcoming legislation impact our business? How will the new leadership change our daily lives? etc.

Some days you just wait, but hopefully not idle!

6. The answer is unknown

Occasionally, it may turn out that something is not clear and no experiment or passage of time is going to make it clearer. It is out of our control.

Some days, you work around the unknown.

Conclusion

We mentioned 6 ways to reach clarity. Some are easy, some are hard and expensive. In practice however, a combination of those methods are used to reach clarity.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alex Ewerlöf

Alex Ewerlöf

Sr. Staff Engineer, Knowledge Worker, MSc Systems Engineering, Tech Lead, Web Developer