We all want to get better at what we do, and as leaders we should all want our teams to get better at what they do, both individually and collectively. However, a pattern I have seen at many clients is that they focus on “improvement” to accomplish this rather than “development”. On the surface this probably sounds like splitting hairs, and perhaps it is, but I believe that the underlying philosophy behind each approach is fundamentally different.

When I hear about “improvement” efforts, they typically involve implementing new processes, new measurements, and new overhead. There’s also an implicit drive to create efficiency for its own sake, but often in the absence of a more meaningful business goal. I believe that the urge to add or change processes when we want our people to get better at what they do often only creates a distance between ourselves and our team members that will worsen the problem.

A big challenge is that it’s hard to define what “better” means when we are talking about our team members. And so we often lean on the things that we can measure and decide that’s what we need to measure. 

Measurement can be a powerful driver for behavior, and so it should be used sparingly and only when well-aligned with meaningful business goals. Said another way, measurement and improvement efforts aren’t bad per se, but should be used to address systemic problems. It’s my belief that more often than not individual and team performance issues aren’t systemic but rather localized, yet we nonetheless throw process at the problem.

Development, on the other hand, is a focus on continually getting better at what we do. It’s laying out a clear path as to what “better” actually means and ideally is driven by outcomes more than task proficiency. It takes a real relationship to achieve this rather than simply a measurement that is viewed in a report. 

It has often (although not always) been my experience that poor performance is directly tied to a lack of understanding of expectations. There have been several times in my career where I’ve had to put someone on a performance plan and in the process discovered that the team member didn’t understand what was expected of them. Once expectations were made clear, these people turned around quickly and became highly functional members of the team. There was no process improvement effort that could have changed that.

Even clearly documented expectations aren’t typically enough. The best way for knowledge workers to learn is by doing and by getting coaching when they struggle. I’ve seen places where team members have struggled for years because of a lack of attention. Their leadership knew they were struggling, but not until the leaders spent time working directly with them did they suddenly flourish. 

In all of these development cases, there wasn’t a systemic problem that required a new process for how the team members did their work. If anything, the systemic problem was that a leader didn’t spend enough time with their teams and the people their team members work with to truly understand how the team members were doing, nor were the making an active effort to help their team members. So if a process “fix” was required in these cases, it was not in how the team worked day-to-day, but rather in how leadership performed their work.

Leadership is a human skill, not an abstracted, number-driven process. If we truly want to get the best out of our teams we need to know them, support them, and coach them to success. 

“Words have meaning.”

This is an often-used phrase to try and push for clarity. The problem is that words have lots of meanings. What does it mean for something “to be in the cloud”? What are microservices? What is Agile? Our industry is full of buzzwords which rather than clarifying things only serve to obscure conversations, especially when you take into account product vendors wanting to latch on to the latest trend.

Even forgetting about buzzwords, we assume because we know what a word or phrase means to us that it should mean the same to everyone else. We also often feel that we don’t need to state the obvious, but I can tell you after many years in the industry there is no such thing as the obvious. What’s obvious to us as individuals is usually the result of unique chain of experiences and insights that make the obvious less so to different people. 

This gets down to the notion of ambiguity and how so many of our professional conversations are riddled with ambiguity. I’ve discussed in a previous blog that most of the time when we’re in meetings where everyone nods their heads in agreement they leave with different understandings of what was discussed and that we need to take ownership to improve this situation. 

So how do we take ownership and break past ambiguity?

One of my favorite tools is readback, which can be used to both validate that you’ve understood others and that others have understood you.

Let’s first tackle making sure you’ve understood others as it is easier to control. The challenge for some of us is that we fear looking bad by not understanding things and asking questions. I can assure you we look a lot worse in the end if we make mistakes because we *didn’t* ask questions.

I’ll try to use a couple different techniques. The first is a simple restatement along the lines of “what I hear you saying is…” or “ok, so my understanding is…” and then rephrase what you’ve heard with your own words. This will usually create some back and forth discussion which is good! The whole idea is to keep reading back until both sides feel communication has actually happened. 

Taking that further, you can structure with something like “to summarize, you want to do three things….”  Quantifying what you’ve heard helps create a quick framework to the discussion. The speaker might think they told you two or four things, so even though it might sound right, there’s a distinction to be clarified.

Now we can flip that around and make sure people have understood us by asking them to repeat back what they’ve heard! Try something like “what were the 3 key reasons for choosing…” to give them a structure for reading back. Or “can you summarize next steps?” Listen closely to the results and push to make sure they really understand what you wanted them to get out of the discussion. 

I’ll often close with asking “what didn’t make sense?” I used to (and sometimes still) ask “does that make sense?” The problem with the latter phrasing is that most people want to say say “yes”. If you ask what didn’t make sense, you’re taking on the burden of unsuccessful communication rather than pushing it to them. This approach makes people more likely to actually respond with details. And instead of a yes/no question you’re assuming there’s a more detailed answer which will trigger a better response.

I know some of us don’t like asking questions, that we want to appear like we get everything. However, people will appreciate that you care enough to take the time to get things right, and more importantly, you will get things right rather than just hope that you have.