Trust is the most powerful aspect of leadership. I’ve blogged before about the importance of trust, of how cultivating trust gives you the ability to more effectively influence teams and organizations, and can ultimately drive truly durable results. But how does one develop trust? How do we build relationships that have trust at the core?

In order to know how to develop trust, we need to talk about what trust actually is. I believe that trust is the perception of motivation. In other words, our internal yardstick for measuring how much we trust someone is based on our understanding of their motivations. When motivations aren’t made clear, we will make our own assumptions about motivation; often not in a good way.

As a leader, this can pose a bit of a problem. No matter how well-meaning we might believe we are, if we haven’t done the work to establish our motivations, trust will be held in reserve.

It’s important to note here that trusting someone and liking someone are not the same things. In fact, we can like people that we don’t trust and trust people that we don’t like. We can have common interests or a common background with others, but this often gets conflated with motivation. We shortcut our perception by thinking along the lines of “they are like me so they must be motivated like me.” We should not rely on this shortcut (and in fact this is a core element of implicit bias, but that’s a topic for another time).

So, you need to make your motivations clear in order to develop trust, and ultimately those motivations need to have your team’s interests in mind. The simplest way to do this is to state your motivations in any interaction. This doesn’t need to be a long oratory and can typically be handled with a single sentence. Instead of saying something like “You all need to work weekends for the next month” and leaving it at that, explain why you’re asking. Saying instead something like “If we don’t get this project completed on time, our competition will beat us and potentially put us out of business. We need to do whatever it takes to get this done” will go a lot further in helping people understand that you’re not just trying to bully them but that there’s a general concern for everyone’s well being. 

This mindset is in stark contrast to how we should perceive others. As a leader, you should assume positive motivations in the people that you lead until proven that you can’t. This means we need to take what can feel like harsh criticism, questioning our intelligence, challenging our direction etc. in good spirit. If our team members care enough to stay and criticize instead of leave for greener pastures, it’s worth understanding criticism in the context of them actually wanting to improve their work environment.

To close, I want to again emphasize that we can’t assume the reverse. It’s not enough to simply mean well and hope that everyone sees that. This is where transparency becomes important, especially when you are too organizationally distant to have a relationship with everyone in your organization. Being up front about the “why” of decisions, actions, policies, etc. goes a long way, especially when followed up with talking about the impact of those decisions once made. Also, understand that if you’re not equally transparent about all categories of decisions, the trust from your organization can be categorized as well, not generalized. 

It may not seem fair that we have to carry the load in our professional relationships, but that’s part of what it means to lead. Instead of worrying about why you’re being misunderstood, focus on being clear in your motivations and you’ll go far in developing trust and building an effective team.

As a leader, my job is all about people - throughout the day I’m coaching, teaching, directing, guiding, facilitating, motivating, rallying, and leading. As with many of you, this means that I spend a lot of time in meetings. I know some people don’t like the word “meeting”, that some prefer to say “working session” and other euphemisms because meetings are perceived as “bad”, but by any other name it gets down to the same thing: I spend a lot of time interacting with individuals and groups of people as a direct mechanism of my work. In fact, in spite of how much of a bad rap meetings can get in the professional world, my most valuable and effective time as a leader is spent in meetings. So, it’s really important to get these things right.

There’s a lot of advice out there on how to make meetings more effective including “start on time”, “make sure everyone participates”, and of course “have an agenda”. The last is considered so important that many advise that you shouldn’t attend a meeting that doesn’t have an agenda. It’s almost like a magic spell - if you have an agenda, everyone shows on time, you follow the agenda precisely and everything is good right?

The problem with agenda-driven meetings is that we start measuring the value of a meeting by how well we stick to the timeslots instead of the outcomes, which often means you might not actually accomplish anything but kicking stuff down the road. So as far as agendas go, they are a means, not the end, and should be discarded if they get in the way of useful activity. As Eisenhower once said “planning is everything, but plans are nothing.”
This of course begs the question “if an agenda isn’t the most important thing, what is?” I’d suggest getting the following components right will lead to your most productive meetings:

• Focus 
• Attendee 
• Duration

Focus on Outcomes
Being clear on the intended outcome(s) of a meeting is the single most important aspect of successful meetings, followed closely by having someone who owns driving to those outcomes.

Our first questions should be “what are we trying to achieve with this meeting” and “could that outcome be achieved through email, a wiki, etc.?” We should be clear on this when we schedule the meeting: do we need a decision made? A problem solved? Advice on how to proceed? Coaching on how to perform better? New ideas generated?

Is your Scrum standup simply people reading what everyone can see on the board or is the outcome of the standup to ensure your team is following the right priorities and will meet the sprint commitment?

Some meetings have clearer outcomes than others. I find that some of the least focused meetings are status meetings. These can become unruly if you don’t know why you’re delivering status. If it’s a factual reading of a report...that can probably just be emailed. If you’re actually taking other’s people time, why are you discussing status? So they can make a decision? So they can advise the team? So they can ask for more money? So they can deliver a difficult message?

Ultimately, being clear on outcome at the start will help you keep everyone on the right track and also help ensure you bring the right people to the meeting.

Attendee Lists and Behavior
When building the attendee list, remember that meetings aren’t about making people feel good for being invited but for actually accomplishing things. Meeting attendees should either provide value or receive value (or both ideally). You should know in advance when you invite people what that expectation is and make sure they know as well. It’s also worth noting that the people receiving value may need to cater to the people providing value when it comes to meeting timing. 

Even more importantly, when evaluating if you should attend a meeting you should understand if you are receiving or providing value. If the answer is “neither”, then you shouldn’t attend. I’m also a fan of creating a minimal set of attendees. If someone else is attending that can provide the same value that I can, I probably don’t need to be there.

Which leads to the next attendee consideration - meeting size. There’s been a lot of research on this and the general conclusion is that if the nature of your meeting requires inquiry - that is, exploration of ideas, pushing back and forth, discovering new thoughts, etc. - you need to limit your meeting to no more than 6-8 people. You can potentially get away with more with a good facilitator and/or using grouping techniques, but in general, sticking to a smaller size will yield a higher quality discussion. Of course not all meetings require this type of interaction and can be larger if it makes sense.

Lastly for attendees, they should all embrace the principle of “Be Present”. This should be easier than it appears to be, but if attendees know the expected outcome of the meeting and they know how they are providing and/or receiving value, they should understand the importance of their time in the meeting and not let themselves be distracted. Multi-tasking isn’t a real thing, at least not in a short timeframe. If something else is more important than the meeting, apologize and excuse yourself. Otherwise, ignore any email, text, direct messaging, etc. and make sure you are fully attentive. Anything else means you’re doing at best a half job on everything (which may be a good way to not be invited to meetings in the future).

Duration
A meeting should end precisely when it needs to, neither before nor after. Yet somehow, agenda-driven meetings always fill the planned time. People will circle around the same points over again, drag out the conversation, or other things to simply fill the time. If your meeting is guided by outcomes rather than agenda, you know it’s time to end when you’ve reached those outcomes, plain and simple. You’ll also find that if you are clear on outcomes and on the value to/for attendees, they will trust you to set the meeting timeframe appropriately because they know it won’t be wasted.


I find these three areas to be the most helpful in ensuring quality time spent with colleagues, but would love to hear other suggestions.

Our industry is rife with trendy technologies such as clouds, microservices, digital experience platforms, AR/VR, and voice interfaces. We’re faced with trendy processes such as Agile, lean startup, and design thinking. And if you listen to some experts you would think that we have reached the final stage of advancement and these technologies and processes are all we need to be successful. Yet years ago our industry felt the same way about things like EJBs, UML, client server, structured waterfall and the like.

In their time, none of these were bad in and of themselves, but the collective hopping on the bandwagon that happens with each wave creates a potential for missing the actual benefit of the advances and often leads to organizations serving the means rather than serving their business. This behavior manifests in comments such as “that’s a bad requirement because it doesn’t fit our architecture”, “that’s not good storytelling”, “that design breaks the conversational interaction”, and “that’s not Agile!” In fact, we as an industry can become very dogmatic around the means as if that is our purpose rather than them merely being tools for solving problems. 

Said another way, all technologies, platforms, techniques, methodologies, etc. are simply tools or means for solving different kinds of problems. If we don’t know what problem we’re trying to solve with them, we won’t be effective.  

Peter Senge, in his book The Fifth Discipline, said “In the absence of great dreams, pettiness prevails.” Said another way, if we don’t have a measuring stick for checking the value of our work, all things are equal and decision making becomes arbitrary.​ 

Going deeper, if we decide we’re going to “implement a DXP”, “do Agile”, or “do Design Thinking” without understanding why, how do we know if we’ve done it correctly? In the absence of an actual business problem we’re trying to solve it’s hard to actually measure the value of what we’ve done. Which is why we as leaders should embrace the following principle:

In other words, we need to remember that we are solving problems for our business and for our customers, and that ultimately our approaches, be they process, technology, technique, etc., only have value when they achieve an end. 

In the digital world, and perhaps especially at large companies, team members can feel distant from the overall value of the company we work for, so we focus on what we can control to make our lives interesting. However, I believe that feeling that our work is well-aligned with the overall success of the companies we work for is a very rewarding feeling and provides the greatest motivation for our teams. 

Putting this into practice means understanding that our business needs don’t serve our architectures, our design methodologies, our internal approval processes, but rather that all of those should be wired to enable us to achieve something great.

Each of the approaches mentioned at the start are (or were) good at solving specific problems and were considered the modern approach in their time, but “modernizing” in and of itself is not an end. “Modernizing” doesn’t give us guidance into how to best leverage a digital experience platform, Agile or whatever the next wave will be. Understanding the end goals - be it organizational agility, horizontal scalability to minimize downtime at high loads, easy accessibility for the vision impaired, or some other need, will help us make better decisions on how to approach our work.

If we can understand when we should and shouldn’t use new practices, methods, and technologies, how they better solve problems than past approaches, and how to apply them to solve problems facing our companies, we will be able to make the right decisions.

Note: a different version of this article appears in 97 Things Every Engineering Manager Should Know

​A while ago I was asked the following at a conference: "I’ve had a mentor suggest that given my style is very direct to learn how to hone that into its most effective form. Is this a good idea?" My answer was not a direct yes/no because there are several things to consider. 

First, we need to have a good definition of leadership. I’ve posted this in the past, but my definition is:

Next we need to consider leadership styles. Finding a leadership style can be challenging, especially if you are just emerging from being an individual contributor, but even long-time leaders struggle with finding the right style. A leadership style should balance: adapting to what’s most comfortable for you, close alignment with your principles (which isn’t always the most comfortable!), and being the most effective with the people you lead. This can be a juggling act that has factors that can seem at odds with each other.

We can categorize leadership styles into three broad categories: Boss, Mentor, Servant. 

The Boss style tends to be more authoritarian: telling people what to do and how to do it, micromanaging, and things of that nature. On the positive side, there is often a lot of clarity with the boss type. 

The Mentor style tends to be more one of coaching: providing guidance and teaching as a way of instruction. At its worst, it can still have an underlying message of “there’s one way to do this - my way” and that is what needs to be taught.
​
The Servant style tends to be more one of empowering and enabling: setting goals with your team members, letting them reach success through their own means, and removing barriers to their success. At its worst, this style can be too hands off or mistaken for simply doing whatever your team members want you to do.

While I am a huge proponent of the notions of servant leadership, I’ve learned over the years that sometimes it’s not enough to set goals and let people run. Sometimes people need to be taught, and sometimes people need to be told what to do. The challenge is knowing when each is needed. I use the following principle to help guide:

Hopefully you'll find that a simple mantra to remember the tools ​in that order. Meaning, we should focus first on enabling people - making the desired outcomes clear along with any constraints and context and give them the autonomy to decide. If that isn’t working we should teach people how to reach those outcomes, and if they aren’t able to pick up on the learning we need to tell them what to do and how to do it.

So to bring it all together, I look at that initial question as “will being very direct enable me to influence individuals to effectively deliver durable results?”  The answer is “yes, but it depends on what you’re being direct about.” Your first priority as leader is to enable, in which case you should be direct about the outcomes they need to achieve (e.g. “handle 100,000 transactions per minute”). If that doesn't work, you switch to mentoring / teaching, where you should be direct about what they should do to reach those outcomes (e.g. “Think about elasticity and making sure you don’t lose any of the requests”). And when that doesn't work, you have to tell - to be direct about how they should reach those outcomes (e.g. “implement a queue and multiple processing servers”).

One of my leadership principles is that our team members are our top priority. People are our work and as leaders we need to make ourselves available to support them to ensure their success. However, we can’t effectively support them if we don’t take care of ourselves. 

Years ago I went on a kayaking trip to the Apostle Islands in Lake Superior with my son and his scout troop. Our trip was run by a local outfitter; the man who ran the outfitter and our trip in particular guides adventure trips around the world and has logged some of the most miles in the Arctic and Antarctic of any living guide today. He and I chatted quite a bit as he has a lot of interesting stories, but his hiring strategy stood out to me. As he explained it, he not only needs guides that know their craft well, they have to know it so well that they can take care of themselves transparently while making sure everyone else on the trip was safe and cared for.

This extends the principle of making our team members our priority with the notion that our problems, our feelings, shouldn’t impact our teams. In fact, I’d offer that our feelings and problems don’t really matter to our teams, especially when they have struggles of their own. More to the point, when they look to us for leadership and guidance, we can’t respond with our own problems as an excuse for not helping them. 

Imagine if I was on this kayaking trip trying to figure out how to put up my tent (I was) and the guide, instead of helping me, told me he didn’t like the tone I took and wandered away. Or if on an Antarctic trip with him, I told him I was worried about frostbite and his response was “yeah no doubt, i’m pretty sure I’ll need a couple toes cut off when we’re done.” The former is infuriating as we see our leaders’ job is to help us regardless. The latter would make us question the competence of who is in charge. 

On the other hand, I don’t think we should try to appear perfect and invulnerable. We are human after all and demonstrating that is one of the best ways to build loyalty and trust as a leader. 

In the balance, it is our responsibility to provide a steady, human hand to our teams, especially in the face of difficult situations. As I edit this we are faced with a pandemic the likes of which is unprecedented in my lifetime and this principle needs to hold more than ever to make sure we provide our teams what they need, at least as best we can. Our team members are going through a lot of stress, anxiety, and a gamut of emotions we may not be aware of. We are likely to encounter more difficult discussions than normal because of the escalated emotional stakes in our current world environment. This includes us leaders as we are all under increased stress, and yet we still need to provide a steady hand.

This doesn’t mean we should bury our stress or emotions. Going back to my guide’s original statement, he didn’t talk about sacrifice, burying needs, or not having to struggle. A good guide gets their group moving and gives them focus and support in a way that still enables the guides to have time to take care of themselves. On the trip I was on, the guides would get us all working together to set up a tent or the cooking area and then would quietly and quickly step away to set up their own area without us even realizing it.

A good leader needs to do the same - in fact we have to. In order for us to provide the stability required by our teams in difficult times, we need to make sure we are feeling sane and calm enough, even in the face of high stress. 

As leaders, we need to make sure we are checking in on our teams and giving the support they need, but to not forget that we too need support and to seek it out (from peers, from our leaders) when we need it. In any kind of crisis it is easy to be overwhelmed by the stress and dump it down on the team, but we need to do our best to not let that happen.

Some of this can seem more challenging for folks that are moving to remote work for the first time, but the basic steps are easy:

• Set regular time to connect with your team
• Be adaptable as our teams are adjusting to environment and schedule changes
• Be understanding of the additional stress people are under
• Schedule block time to unplug, de-stress, exercise, or whatever works for you to keep you in balance

Ultimately, our job as leaders is to take care of others, but we can’t do that without taking care of ourselves.

Perhaps the best way to appear more like a leader is to learn to speak in terms of outcomes rather than simply tasks, timelines, and deliverables. In fact, one of the best ways to be a better leader (and contributor) is to think in terms of outcomes. 

There are two broad categories of outcomes: intended and unintended. Intended outcomes are the impacts we are deliberately seeking to make. Unintended outcomes are the impacts that we inadvertently make (e.g. making a team work extensive overtime to hit a deadline can result in poor quality and team attrition as unintended outcomes). It’s important as a leader to expand our mindset to embrace both. 

It’s easy to confuse outcomes with tasks, deliverables, etc., so I’ll provide an example to help clarify, starting with intended outcomes. Let’s say we want our leadership team to be informed regularly of our financial status, so we decide we need a monthly report. Creating the financial report is a task. The report itself is a deliverable or artifact. People receiving and reading the report can create the outcome of being informed.

This is where good outcome-focused thinking really makes a difference. What have we achieved by sending out this report? If the driving outcome is only to inform people, it’s likely that we’ll develop a report that is so full of information and data points that no one knows what to do with it and so it gets ignored. Sound familiar? 

Instead, what if the intended outcome was to “enable our leadership team to actively make resource allocation decisions to improve our margin.” This isn’t simply informing or building knowledge. This drives to truly achieving something - improved margin through better resource stewardship. Depending on the environment a report may or may not be the right means of achieving this. But if a report is the right vehicle, there is far more clarity on why we’re building the report that we are far more assured that it will actually be useful.

Outcome focus is so important in my mind that it forms a core principle for my approach to leadership: 

​When people talk about team building we typically mean finding ways to build a greater rapport and trust between our team members. When done well, this can have a positive impact on team productivity, and fortunately there’s a lot of material out there on this subject to help us all. Instead of working with an existing team, I want to talk about another aspect of team building: actually building the team. 

I believe the single most important type of decision we make as leaders is how we hire and assemble a team. These decisions have far-reaching impacts on our teams and on our own work and shouldn’t be delegated away as a nuisance.

There’s a lot of data to support this. Recent data shows that employee turnover costs $223B annually, that disengaged workers have a 37% higher absenteeism and 60% more errors, and that workplace incivility can cost $14k/person annually in lost productivity.

In spite of this data, I’ve encountered managers at tech and digital companies that brag about hiring the “brilliant jerk” type of employee. They’ll say things like “I don’t care whether they play nice with others, they’re some of the smartest people I know”.  This stems from a mistaken belief that tech organizations function as meritocracies. Unfortunately, this simply isn’t true. In most organizations I’ve seen, the “best” ideas don’t rise to the top no matter how much we want to believe in a meritocracy. In an unhealthy culture it’s the loudest ideas and those promoted by the biggest bully that rise to the top.

And in part, while these brilliant jerk types may or may not actually be the smartest people in the room, they often believe they are. Believing you have no room for improvement or no room to learn is a fast path to mediocrity, and hiring people like this will lead to mediocre results at best.

At the other end of the spectrum are people I refer to as “pleasant poison”. These are the people that are great cultural fits in that people like to be around them, but are not competent at their job. Sometimes hiring folks like this is an overcompensation to the brilliant jerk trope, but can be just as deadly. Simply getting along isn’t enough, and in fact, over time your valuable team members won’t enjoy working with this type. They become a poison as they linger in the organization because team members start wondering why someone who isn’t competent is still here. These pleasant poison team members can actually be harder to get rid of because they’ll fly under the radar longer due to their pleasantness and both team members and management have a hard time having the difficult conversation with or about them. 

This is why hiring is such an important process and decision. And for good or ill, what you look for you will get and what you don’t look for you leave to chance. 

So what characteristics do you look for when you build a team? Just expertise in their domain, be it coding, designing, project management etc.? Do you hire developers that are deep in a stack or do you also assess their problem solving skills? Do you hire designers primarily because of tool familiarity or is client interfacing an equal consideration? Are you thinking about if you’d like to work with that person or do you think about whether or not they are a good cultural fit for the organization (or neither)?

Ultimately, we need to be explicit in what we are looking for and what we aren’t looking for when we assemble a team. Doing the work up front will have a far greater impact than any team-building exercises brought to bear once the team is formed. Constructing your team with a holistic team view will help create a true team rather than a collection of individuals. If we fail to do this, the results can be disastrous.

Conflict is often seen as a bad word, yet conflict is a necessary component of high performing teams. Part of the problem is that conflict is an overloaded word which can mean anything from simple disagreement to an all out screaming match. 

Let’s get the bad type of conflict out of the way first. We’ll call it friction. Friction refers to the conflict of people, and is often based on history, personal biases and dislikes, or ulterior motives. Friction is often negatively intended, or perhaps more generously, friction has an absence of positive intention. Regardless, friction is the type of conflict we want to avoid. It drives dysfunctional team behavior and is costly to let it run wild.

The good kind of conflict can be thought of as the conflict of ideas. We’ll call this type of conflict tension, conceptually similar to any good movie has a source of tension that needs to be resolved for a positive outcome. Our teams should absolutely have the conflict of ideas when problem solving. We should each be bringing our unique insights and experiences to the table for a fair consideration. When guided by positive intention to reach the same ultimate goal, this exchange of different points of view can push all of us to create something better than we would have if left to our own devices.

I feel it’s useful to clarify the different types of conflict because I believe that many people and organizations are conflict-avoidant, but organizations with a low tolerance for conflict of ideas will ultimately reduce the height of their achievements. When there’s a low tolerance for conflict, team members stop wanting to deliver bad news or contrary ideas and it becomes easier to just declare victory instead of dealing with the tension. All of this ultimately lowers our standards.

Our organizations must embrace healthy tension to bring out our best results.

This doesn’t mean we have to fight or bicker - healthy teams can and should resolve conflict without friction. As an example, team members have commented that a colleague of mine and I always seem to agree on things. I’ve explained to them that nothing could be further from the truth. We disagree a lot, but we’ve worked together long enough that our conflict doesn’t appear to be anything other than a normal (and often quick) discussion. This is a pretty ideal state for any long-running team.

Said another way, we have a responsibility to raise our hands if we have a different point of view. Nodding in agreement with someone when you really think that their idea will never work just for the sake of “team harmony” is bad. False harmony is just as destructive and demoralizing as friction. Sometimes this can manifest in teams that profess to really like each other. I’ve seen teams go on about how great everybody is, which is a good thing up to a point. But when they go past the point of being positive to a culture of falsely avoiding disagreement they are hurting themselves. 

It’s natural for human beings to disagree with each other, especially at work, especially on cross functional teams. Suppressing that doesn’t make any sense. The quality of all relationships, work or otherwise, is ultimately driven by how they handle conflict. If our teams tend to avoid conflict they will be rewarded with mediocrity.

This is why team composition is so important and warrants careful consideration. If I surround myself with people who thought like me, why would I need them? How would I get challenged and continue to grow? How would my team be anything but a monolith of singular thought? No single one of us has all the answers. We achieve excellence when we are surrounded with good teammates pushing and pulling each other to reach our best.

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.