As software consultants, an integral part of our job is communication. This communication takes many shapes, and includes communicating regularly with our clients as well as communicating with our peers.
When we communicate with our fellow developers and designers, we strive to:
- Provide empathetic feedback on peers’ code reviews
- Write clear, concise code that future designers and developers can reason about
- Share what we’ve learned during investment days internally through lightning talks or internal announcements
We spend Fridays as investment days to learn new skills. If someone spends time learning about a new programming paradigm or launches an internal tool but doesn’t spread the knowledge among our team, others within the company aren’t able to benefit, and everything they’ve learned remains siloed. Communication prevents knowledge from being siloed, so we can all grow together.
In our consulting work, we seek to communicate with our clients as transparently as possible. Key communication examples include:
- Outlining acceptance criteria for a client so they’re able to ensure product behavior matches their expectations
- Teaching our clients the “what” and “why” of effective product, development, and design processes through conversation and collaboration
If someone facilitating the weekly retrospective doesn’t convey its importance to a client, the client might question if we’re wasting time talking about the project rather than designing and developing additional features.
The thought experiment “If a tree falls in a forest and no one is around to hear it, does it make a sound?” comes to mind, but through the lens of software consulting.
While a significant portion of our day-to-day involves writing code, it’s never 100% of our time. Because of this, keep an internal rule of 90/10 as a reminder that it’s never only about writing software. 90% of your time might be spent writing code, but focus the remaining 10% on communicating the work you have done.