The “Why” Behind Work – Aadil Mamujee
Aligning on “Why” for product development work is always important in work but it’s especially important for distributed teams. When the “Why” is consistently missing, projects end up feeling like a list of context free tasks from ‘up above’ and teams can become demotivated and resentful – no one likes being told what to do all the time.
In synchronous, in person cultures, understanding and reenforcing the “Why” happens more organically in corridor conversations, social time (lunch/after work) that colleagues to have conversations about the reasons behind their work more naturally and transfer energy and enthusiasm to each other (also an important lever for leaders). As a leader, it’s easier to notice misalignment or lower motivation because you can ‘feel it’ and course correction can happen faster by grabbing a room talking through something and emerging with a decision.
In distributed, asynchronous cultures it’s very important that the people doing the actual work have a strong understanding and believe in the “Why” and are rowing in the same direction because detecting misalignment can be slower. This is amplified in importance if you are changing product direction and focus or are working on a new product (with lots of potential directions).
As a leader of these teams, you need to put systems in place to understand if people have a shared understanding of the business or user problem they are solving. Include your teams on the journey towards the decision (to improve shared understanding and acceptance) vs. just communicating the decision in isolation. I would try over-indexing on time spent on the user and business goals with more space reserved for discussion upfront for new projects. The contributing teams need to be able to express concern, propose alternatives and build motivation for the problem space. This can admittedly feel slow, but over the long term it’s better for both the people and the product.
I’d suggest experimenting with more rich media (audio, video, pictures) to allow people to understand your thinking as a complement, not a replacement to longform text which is still the most important as it’s easy to scan, indexable and searchable. I’ve been experimenting with quick Loom Videos to give product feedback or sharing a short video colleagues (in addition to a bullet point summary) to transfer more context of sentiment and detail across, whereas previously I would have defaulted only to text. I think this helps communicate with more personality and context but also preserves some of the benefits of async communication and culture.
As a leader, try not to be be a taskmaster. When you’re trying to align teams, try to have them write the “Why” documents and determine and justify own problem spaces (with your guidance). You can guide and get alignment by asking questions to shape the problem spaces and making decisions about priorities. Being a taskmaster creates single person failure risk (you) and ultimately leads teams being demotivated over the long term. Having to do something ‘because someone senior said so’ is deeply unmotivating over many cycles. There are periods of ‘War Time‘ where being a taskmaster is appropriate, but should is not the case for business as usual work.
We all have to execute things that we don’t fully believe in – it’s just part of the nature of work. In these situations state your position clearly but ‘disagree and commit’ if the decision has been made. When you communicate the problem space and the “Why” to your teams, emphasize on the components you actually agree/believe (versus the areas you don’t), as your team will be able to sense authenticity and energy.
In summary, as a leader of distributed teams, it’ll pay long term dividends to focus more on “The Why” upfront especially for new projects or when you’re changing directions even though it may feel slower at times. Plan for more time and space to get all folks involved to understand the rationale (user and business) and build motivation for their work whenever possible.
A good book on this topic is Simon Sinek’s “Start with Why”.