Lesson 6: Being understood trumps being accurate

Background

During a consulting project with a data warehousing and resale company, I attended a particular meeting with several people regarding a problem one of the teams encountered. During the conversation, everyone kept using the term “ETL”. They would say, “we need an ETL for this process” or “we can put an ETL between these two systems”.

Outcomes

Being relatively new to the data side of software, I asked “what does ETL mean?” Not a single person in the room could answer the question. Had I stumped them? Why were they using this word if they didn’t know what it meant?

As an aside, “ETL” stands for “Extract-Transform-Load”. It’s a term in the software development industry meaning a process that we create which will extract data from one system, do any number of transformations on the data, and then load it into a second system.

Mistakes & Lessons Learned

I naively believed that the mistake was everyone else’s in using a term for which they didn’t have a solid understanding; however, the mistake was mine. I fell for the TFASN trap, that is “These Fools Are Speaking Nonsense.” TFASN is the mistaken belief that people shouldn’t use words for which they don’t have a precise definition. During this time, I valued accuracy and precision of information and words, and I didn’t have a healthy appreciation that human communication is less about precision and more about creating shared meaning. The people in the room (who were all brilliant, by the way) didn’t need to know a specific definition of ETL to convey a shared intent of creating data loading processes between the various subsystems. They were doing a very good job of creating shared meaning with each other; I was the only one that was lost.

Agile Reinforcement

There is a particular principle from the Manifesto for Agile Software development at play here: “Business people and developers must work together daily throughout the project.” So many times, we fall into the trap of thinking that we have accurately conveyed information and requirements when we have written them down, documented them, or added them to our project tracking system. What’s important about communication is creating a shared intent or meaning among the people involved. That can only happen with conversation, never with documentation. Working together daily is important because it lets the participants develop a shared vocabulary, jargon, and shorthand with each other. This is exactly what the people in my example did: they didn’t need a universally objective definition of “ETL” to create shared meaning among themselves. Never curtail a development team’s ability to work together daily (and several times a day) with the various businesspeople and stakeholders.

SAFe Reinforcement

While there are a few principles from the Scaled Agile Framework that could apply here, I want to talk specifically to “Organize around value.” In many organizations, people are organized around skills, functional capabilities, or shared services. For example, there are often Human Resource, Account, Database, or Testing departments with their own managers and hierarchies. Because the people in these departments are largely working within their own departments each day, the shorthand and shared meaning they create is very siloed. SAFe reminds us that it is critical to understand our value streams and how value is delivered across these departments rather than within them. So, conversations must happen between and across the people in these departments if we are to understand and improve the flow of value. This is a challenge for all of us, and one we must rise to meet if we are to get better results for the benefit of our customers.

I hope my struggles and failures can help teach you this important lesson: Being understood trumps being accurate.