One thing that is important to me as an engineer that I don’t think I’ve seen put in writing is something I have distilled into the term passively transparent.

It should be obvious to the people in leadership what is motivating you to work and what you are working on (transparency), and it should not require an on-demand effort on your part to communicate this to them (passive access).

You should be transparent for the reason that you are setting a baseline of what you are expecting to share with your manager: if they feel like you aren’t giving good status it gives them tacit permission to ask too many questions or questions that are inappropriately deep. Calibrate the level of communication by setting it yourself: keep your management at an arm’s length in how they use your time and attention. “I refer you to this query on GitHub, which you may access at any time” when someone asks about your deliverables should be a response you aspire for and your leadership accepts.

You should be passively available for the reason that you are setting a baseline of when and how you are making yourself available to your manager: you, as my lead, should not have to wait for things to escalate to me openly broadcasting a crisis state before reaching out. You should also be able to do a pulse check without requiring my intervention. My time is precious, and I should not be forced to choose which time I give to you via a scheduled 1:1 if I can choose to give you the time that matters, when I have it to share progress.

A lot of the agile software movement and its offshoots attempt to codify and formalize processes of behavior that boil down to expressing these values:

Keep Track Of What You Are Working On

If a manager or peer wants to see what you are working on, they shouldn’t have to ask for a status update: they should be able to figure it out on their own at any time on demand.

• Open a draft PR the second you begin coding, push to it regularly. Hourly, during a standard working day, if you can.
• Broadcast your current status on your issue tracking site: it is more work in the short run, but give you warm fuzzies (line go down on burndown) and lets you give high-value opportunities to course correct before going too far.
  • Keep tickets at a 1-3 working day granularity and
  • Move them along the started -> in progress -> finished pipeline quickly to telegraph to your management that you are working
    1. Independently
    2. On the right things
    3. At a reasonable pace.

Share What You Are Doing With Others

• Set permissions by default to commenter or editor on every document and web site you start.
• Assume if someone is curious enough to want to know something that they are a stakeholder, whether they like it or not. Let them know. Pull them in.
• Share everything: use public Slack channels. Private channels and DMs are for shit talking and performance reviews, not for day-to-day work.

Don’t Let When Something Happens Influence How And Why It Happens Too Much

This is something that has always mattered to me, doubly so with the forced async-by-default working world inflicted on us by the pandemic years and working with multi-time-zone teams.

Make decisions (choose one end, these are opposite ends of a continuum):

• As quickly as possible with minimal consensus but easy to change course on
• As late as possible with as long as reasonable to get input on

Encourage This Behavior In Others

One way to promote this way of working is to practice it yourself: when working in a team, engage with your peers with the assumption that they are working in a passively transparent manner themselves.

Quick, no-expectations messages on Slack can do wonders in a non-forceful way by gently framing your working style as conventionial:

• “I was reading your draft PR, looks good”
• “Is there a Jira queue I’m not watching where you’re doing daily updates?”