As Staff-level engineers, we work in ambiguous roles and solve difficult problems. Our involvement with a team or an area can ebb and flow as the needs of the business change. Given this fluidity, our colleagues often have a fragmented view of what Staff+ engineers actually do. For example, we may jump into a troubled project mid-way, or leave before delivery because the danger has passed.

These conflicting or incomplete pictures of the work can create serious problems. People at all levels of an organization question the value that we bring. Our leaders often have an unrealistic view of our capacity for new work. Aspiring engineers can’t see clearly what Staff+ roles involve.

However, we can communicate a more coherent and complete picture by practicing greater transparency and visibility of our work. This is not just about managing expectations – although that’s a big part of it. By modeling good behaviour, sharing the context we have, and leading a culture of openness and accountability, we provide a valuable service to others.

Operating transparently as a Staff+ engineer is not easy to do well. We have to strike a balance between showing our work and avoiding information overload. There are risks in sharing uncertain or incomplete information. As leaders, we need to be aware of the impact of what we share and how we frame things. Denise Yu’s rule of thumb is useful in this context: “In every conversation you're part of, create clarity and reduce chaos.”

What I do

Make daily work visible, learn in the open, and stay aligned on what’s important.

• “Snippets” are brief notes and reflections on what I’ve done over the week. I’ve maintained them for nearly 20 years; these days I post them in the local wiki. Many colleagues have joined in, and our #snippets Slack channel is full of links each week. We learn a ton from each other by skimming these.
• I regularly rewrite my job description and share it broadly. The format varies, but the idea is to set down what I think my job is, and get aligned on that with my colleagues. A peer took up the practice recently and found it scary at the start, but ultimately it cut out a lot of ambiguity and anxiety for them.
• In a yearly personal retrospective, I look back over my work and try to learn as much as I can. I do this openly and my colleagues appreciate the perspective, with several of them taking up the practice themselves.
• I maintain structured 1:1 notes with my manager and some peers with sections for  “happenings”; “feelings”; “questions”; and “priorities”. The latter is especially important for me as I try not to carry more than three priorities at any one time. Usually one of these areas takes up the majority of my focus time, one is a smaller yet still sizeable chunk, and one forms a background thread. I share these regularly and communicate if they change, making it easy to stay aligned.

How I think

Explore and clarify perspectives and mental models.

• A common activity for me is to take a deep dive on a particular problem or organization. I always try to share some reusable artifact of that work – an analysis or synthesis of what I’ve learned. As well as making the work itself visible, it can illuminate factors that we might otherwise overlook, and serve as concise context for future investigations.
• I often write problem statement documents, stating the problem before we start exploring the solution space. I do this either to build a "problem portfolio" in a particular space – that is, with no immediate intent to prioritize work – or to set up a more difficult problem or collaboration for success. It’s often much easier to align on a problem than on a detailed solution. As engineers, we have a habit of skipping straight to solutions.
• Now and then I extend my weekly snippets with short internal blog posts covering topics from how I work, through to how I’m thinking about specific problems. I find myself referring to these often, either to remember specifics or to share an idea with a colleague.

What I know

Share context from discussions and forums that others might miss.

• As an engineering leader, I have access to information and context that my colleagues lack. While some information is sensitive, much can be summarized and shared. I do this in various ways: sharing directly in meetings, short blog posts, and trip reports for leadership summits and similar events. There’s a danger of “in-group” thinking in leadership circles, where we discuss and socialize a decision and forget to share intermediate results. To colleagues with less access, the output can seem arbitrary and sudden. Being a bridge for this context is a role I am well placed to play.
• When I attend a meeting I make sure we have notes. Meeting minutes may be ancient technology, but they’re pretty magical. Getting decisions written down and notes summarized makes everything run more smoothly. It’s easier for people outside the room and for our future selves to understand what we were thinking and why.

While the ideas above have worked well for me and my colleagues, you will need to adapt, add, and discard parts to fit your unique context and organizational culture.

Behaving transparently takes time, intention, and practice. It helps us effectively manage expectations around our work and is a practical exercise of empathy for our colleagues, both giving them the context they need and clearly modeling good engineering behavior. 

No matter what your particular approach is, remember what Tanya Reilly says in The Staff Engineer’s Path: “Do a good job and let others see it.”