This is the first post in what is planned to be a sweeping arc of discussion on the place of language in engineering teams.
Over the years I’ve spent in software development, and in particular those I’ve spent doing product management and product ownership, I’ve come to the realization that our use of language – in particular the words that we choose to communicate with – plays a surprisingly significant role in determining how successfully we work.
Tom and Mary Poppendieck 1 refer to earlier discussions when they state that communication is the key to achieving something they call “integrity”. Two types of integrity are introduced: “conceptual integrity” – which might roughly correspond to most people’s concept of “well-engineered”; and “perceived integrity” – or how well the thing in question satisfies the expectations of its audience (users or customers). These are both different types of “quality”.
Going further, between team members is the most important factor leading to high conceptual integrity; while communication between teams and customers is the most important factor leading to high perceived integrity.
Copyright © 2003 Addison-Wesley
Given how important communication is in determining quality then, and given that communication (written and verbal) is based on a foundation of language, it stands to reason that our choice of language is a highly significant factor when it comes to the quality of what engineering teams produce.
Despite this fairly reasonable conclusion, listen to any conversation between team members or between teams and customers and you’ll find that stream of communication rife with lazy, ambiguous and general low quality language. How many times have you heard the complaints: “You must have misunderstood…” or “you’re not listening…” or “that’s not what I meant…” or “that’s not what I asked for…” or “perhaps I’m not making myself clear…” or…or…the list goes on. Each time one of these “mis-communications” occurs, it wastes some time – the time which was spent attempting the original communication. But if the original communication was actually actioned, and especially if the mis-communication was not detected promptly, the potential costs could be disastrous!
What if “that’s not what I asked for…” refers to something which has actually been built?
This is not idle melodrama. Engineers build the “wrong” thing all the time, and all too often are blamed for not listening hard enough. But responsibility for communication lies on both sides, and when lazy language is used to specify it should not be surprising that misunderstandings will necessarily result.
In the next three posts, I identify and discuss three main types of problematic language: