Transparency

Transparency comes hand in hand with accountability, and accountability is terrifying in the same way that this:

$ git blame 

feels like a dirty task.

Let’s get rid of that stigma and help each other do our best work.

 

For a bit of context, when I first joined Slack as an intern, the first thing I noticed was how quickly I was onboarded. I got there one day, and the next day, I was creating my own spec and pushed my first line of code. This boggled my mind. A task that was normally viewed as a dread and drag to the team was eliminated. Yet, I didn’t feel lost. I didn’t sit through a week of onboarding sessions learning about things that may or may not come in handy for me during my internship, their training was short and concise because they trusted us to learn the rest in our own time. I didn’t need to set up a meeting with my manager to ask when the team generally comes into work, how code reviews will work, templates for PRs, how to set up accounts etc. because they were all available directly on our instance of Slack, sitting just a search away. I knew what all my teammates were doing at all times. In fact, I knew what everyone was doing at all times (if I wanted to). I saw this again when I came back to Microsoft. This is transparency.

 

Here’s an example scenario: 

Alex has worked on a team for 15 years so she knows what everyone has worked on, what they are working on, and she can probably predict what they will work on in the next fiscal year. And then whenever a new project comes up for her, she sits down and thinks about whether her work overlaps / will overlap with anyone else’s and contacts all her potential stakeholders. She pulls them into a meeting and discusses how they will collaborate together to achieve the best results together. She sends over meeting minutes directly to everyone who was involved in the meeting right after. She ends up with a successful project that she and her team are proud of!

 

The problem? 

Jim—Alex’s coworker doesn’t have the 15 years behind him. Without the connections and the experience, he doesn’t know that any of that was happening, and there is little to no way for him to find out. Maybe most of the time, this is okay. But on occasions where his work starts to overlap with other people’s, he wouldn’t know. In the best case, he duplicates already completed work. In the worst case, he messes up fundamental architectures of a product and ends up eating into other people’s time to fix what he missed out on. Either way, this could have all been prevented if only Jim had the knowledge that Alex did. So how do we fix this?

 

Transparency is a 2 way street—I like to boil the solution to all of this down to 2 points.

 

1)    Exhibit transparency

  • Start sharing our work on public and shared channels and ask for feedback (a win-win)!

  • Avoid private DMs as much as possible.

  • Provide details on our work—maybe Alex and Jim are both working on creating a new website but one calls it a “site”, and the other calls it an “app”. Without further context, they would have no idea they are working on the exact same thing.

2)    Encourage transparency

  • Pay attention to what other people are saying during standup / team syncs.

  • Take the time to find and go over the work that other people have shared. Leave comments and leave feedback.

  • Tell others to share their work, whether it be online, through team meetings or through brown bag sessions. People dismiss how important their work is to others, it’s easy to be scared, or forget—give them the push they need.

  • Talk to coworkers. There’s a reason why they’re coworkers! 😊

 

When knowledge in the workplace becomes a commodity, we can all start doing our best work.