6 ways staff engineers help reach clarity

Why?

source: LinkedIn

What?

source: itlaw.fandom.com

How?

  1. Active: The person/team reaches out with a concrete question or request for feedback.
  2. 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 invested are they in their truth? How much work has been implemented?
  • 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

  • People: who does what? What does the org look like? What are the organisational dynamics and forces? Who are the stakeholders and users? etc.
  • 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

  • Knowledge: the team should have the knowledge to operate independently and when needed acquire that knowledge autonomously cheaper than having to go to you.
  • 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

  • Pair programming: we solve the problem together. There’s a risk that one person takes the lead and leaves the other one in the dust. It is important to use this time effectively as a coaching for gaining hands-on experience.
  • 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

3.1 Another person/team has the answer

Some days, you’re just a catalyst!

3.2 The answer is scattered across multiple teams/people

Some days, you are a detective.

3.3 The answer hasn’t trickled down

Some days, you’re just a communicator.

4. The answer is behind an experiment

Some days, you’re a researcher.

5. The answer is in the future

Some days you just wait, but hopefully not idle!

6. The answer is unknown

Some days, you work around the unknown.

Conclusion

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Monolith to Event-Driven Microservices with Apache Kafka

How to Stand Out as an Entry-Level Software Engineer

No, I Swear My iOS App Doesn’t Crash on Startup!

The boundary conditions of software systems

Provisioning a Network Load Balancer with Terraform

Installing Ceph Object Storage on an Openshift 4.X cluster via the Rook Operator.

Top 5 reasons to use the Apache Cassandra Database

Sitecore ContentSync with Azure DevOps

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

More from Medium

Staff Engineering at Carta

Structural Lessons in Engineering Management

Engineering Principles (v1) at Nextdoor

Transitioning from TL to EM