Software-Engineering: Effective communication with 'why', 'how', and 'what'

A few moons ago I read Simon Sinek’s ‘Start With Why’ following Kent C. Dodds’ recommendation in his newsletter. The things that stuck with me the most from that book were the three levels of communicating: ‘Why’, ‘How’, and ‘What’. Simon Sinek modelled this in what he calls ‘The Golden Circle’. These are my thoughts on how this framework of thinking affects effective engineering communication and leadership.

What

This is the simplest form of communicating, and is how we communicate with machines when writing code. The machines don’t care about why we’re doing something. They don’t even care about how we’re doing it, assuming you’ve got the proper abstractions in place.

Unfortunately, this is often also how we communicate as human beings. “Make the UI responsive”, “Fix that bug”, etc. This form of communication can yield quick results in the short term, assuming all parties involved in this conversation have the necessary context. However, at some point you’ll end up with the receiving party not having all the pieces, and is unable to perform the ‘what’ without knowing more about the ‘how’ or ‘why’.

How

In engineering, it is a lot easier coming up with the ‘what’ when you know the ‘how’. Take the following sentences for example: Which do you think communicates better?

• “Make the service give me follower information”
• “Expose a GET endpoint under /user/:userId/followers to retrieve a paginated list of the user’s followers.”

I would argue the latter example is clearer, and as engineers we could probably work with this to establish the desired result. The first example necessitates more communication to figure out any additional context. Assuming the communication remains in a ‘what’ fashion, this would be an arduous affair. “Write a @ResponseHandler with GET as a parameter, or a @GetHandler both of which taking user/:userId/followers (…)“.

Why

In engineering disciplines it’s easy to forget that engineering in and of itself is worthless. Your engineering efforts must meet a business requirement in order for them to be valuable. This is where communicating in terms of ‘why’ comes into play. When leaders speak in terms of why it inspires action. Engineers are skilled at figuring out how to do something when given a purpose and then figure out what exactly to do. Great technology leaders trust their team to take appropriate actions and make appropriate decisions. Great leaders focus on instilling values and beliefs over concrete actions. This isn’t to say that leaders shouldn’t step down to the ‘how’ or even ‘what’ level at times, if necessary. In fact, doing so helps prevent a toxic ‘us-vs-them’ mentality in your company. This is especially true for medium to large sized companies.

Adding another option to the above example, which option do you believe is the most effective form of communication?

• “Make the service give me follower information”
• “Expose a GET endpoint under /user/:userId/followers to retrieve a paginated list of the user’s followers.”
• “We believe that adding a social touch to our product will improve the value our users get out of our service, leading to a better customer relationship which will help us grow in the long run.”

The latter example requires more thought and effort to communicate, and we may not know exactly what to do, but we now have a set of values. These values, in combination with team collaboration and the trust of management as a catalyst, answers the ‘how’ and (as a non-trivial side-benefit) fosters team spirit and a healthy company culture. Figuring out the ‘what’ from that point on is what we call engineering design.

The tradeoffs you make in the centre and on the periphery of the circle

We need all three forms of communication to communicate efficiently. As we navigate towards the centre of Sinek’s Golden Circle we must be aware of the following trade-offs in order to communicate clearly.

• The centre is good for async communication because it tends to minimise follow-up questions. Great for remote teams.
• The periphery is good for synchronous, face to face communication where it’s easy to gauge the level of context everyone has.
• The centre has a high ROI. Because you entrust the details to others, you have more time, while still getting stuff done more or less in the way you expected.
• The periphery gets stuff done. Can be very fast.
• The centre values trust. This begets a healthy company culture.
• The periphery values control. Gets the thing done right.
• The centre is rigid. Changing company values is not done lightly. Ideally your values are set in stone from the very beginning. Nobody wants to work for a company with legacy culture.
• The periphery is flexible. Because of the concreteness of this form of communication changing one concrete command into another is trivial.

Conclusion

I highly recommend that you check out the Start With Why book, or do what I did and listen to it as an audiobook. The book is essentially one simple concept with many real-world examples that help you understand the value of communicating values and beliefs. I’ve started to implement what I’ve learned from this book, but old habits die hard and I still have a way to go.