Door 1: Increasing visibility by learning and working in public

One of the most effective ways I’ve found to increase my visibility as a technical leader to my management as well as my peers, is by adopting a habit of working and learning in public. 

Learning in public, as Shawn Wang puts it, is “to have a habit of creating learning exhaust.” Learning in public doesn’t mean putting together a perfectly written dissertation on the topic you’re learning about, but the more persistent, visible, and accessible, the better. This could be a simple post in Slack (or whatever chat app your company uses) with a “today I learned…” (TIL). It could be a document that’s accessible to and discoverable by others, which you use as a diary or log as you go. You could create a channel where you can dump your learnings, and those who want to follow along can join the channel. You could record a quick video demonstrating how to do something you just learned. 

Learning in public also brings the added benefit of showing management what you’ve been continuing to invest in your skills. Not only this, but you’re also trying to help and lift up others in the process. Showing others what you’re learning about normalizes not knowing something – regardless of technical seniority – and can foster an environment of continual learning and sharing. 

Working in public is an approach where you publicly share your progress as you work on a given task, project, or the troubleshooting of an issue. As you work on the given task, log your thoughts, theories, actions, results, etc., as you go. The most obvious benefit is that you are making it very easy for management and others to see the work you’re doing in a very unfiltered, genuine way. Additionally, you are documenting the history of your steps, reasonings, trials, and how you came to a certain result – helping others learn. Working openly like this also makes it very easy for stakeholders to keep up with your status, as well as allowing others to weigh in, ask questions, and even collaborate with your effort. 

Employing these techniques takes some courage to show your authentic, imperfect self at times, but the benefits to you are great, and the benefits to others can be even greater! 

Door 3: How to mitigate clashes in priority on cross-team projects

Clashes in priorities are a common problem across teams. Often, this comes about because one team does not necessarily have all the expertise or resources to deliver a feature end-to-end, so outsourcing is required. Inevitably, a situation will arise that makes it difficult to get the dependencies delivered in a timeline that works for everyone. I have found that setting up a system of continuous cross-team communication early in the process and developing shared roadmaps will ensure the best chance of adjusting to delivery conflicts. 

Identify all of the teams involved in the delivery of the feature and key personnel involved in both decision-making and technical design. Then, establish a meeting cadence for each of these purposes where shared roadmaps and design and/or implementation details are regularly reviewed. Having those shared roadmaps is critical when going to upper management to lobby for priority adjustments.  

Talking about a problem will not fix it. However, there is a much better chance of identifying and heading off bottlenecks with creative problem-solving. If a team is blocked waiting for a module to be code complete, think about leaning on mocks instead. If velocity needs to be increased, there may be room to incur a short-term tech debt to help move faster. Generally, it’s prudent to consider what other calculated risks can be taken in order to deliver customer value sooner.

In a project requiring cross-team collaboration, none of the decisions should be made in a vacuum. Frequent, transparent conversations about what and when each team can deliver, makes a difficult process a bit smoother.