Tag Archives: visibility

Talk, Talk, Talk

I wrote an article about the many ways that managers inadvertently plug the communication pipeline (free registration required). In doing so, they deprive themselves of the information they need to do their jobs. It reminded me of one of the most common ways managers block information–talking too much, listening too little. Some advice for managers…


I recently observed a manager meeting with a team member. The manager gave the low-down on a leadership change at the top of the company, speculated on the economy, described his plans for the future, and detailed his mother’s heart attack.

At the end of the meeting, the manager smiled at the team member and said, “Keep up the good work. You’re doing a great job!”

How would he know?

The team member barely got a word in edgewise, and certainly didn’t have an opportunity to describe what he was working on.

Watch the Conversational Balance

In a social situation, a 50/50 balance between talking and listening feels comfortable. But management conversations are different. Managers need to understand how people are working, and where they need help. Managers need to understand the status of work, risks, and obstacles. The manager described above talked 95 percent of the time and listened 5 percent of the time. 30 percent talking and 70 percent listening is a more appropriate balance for management conversations.

Prime the Pump

Aiming for a 30/70 balance doesn’t mean you sit there silently and wait for the other person to fill the silence. Nor does it mean that you need to listen to a rambling monologue that doesn’t provide the information you need to do your management job.

Hone your questioning skills to help you explore the work and understand your team members. Ask open-ended questions, questions that invite expansion, to draw out relevant information. Open-ended questions often start with “What” or “How”.

Some of the questions I find useful in starting conversations with team members are:

• What’s going well?
• What’s keeping you up at night?
• What obstacles are you running into?
• How did you approach the ____________ issue we discussed last week?
• Tell me about your work on __________.

Ask probing questions to gain further insight:

• What else?
• Can you give me an example?
• What’s behind that?
• What else have you tried?
• What other information would be helpful?

Closed questions often start with “Can”, “Do”, “Are” or “Is.” Closed questions naturally lead to a one-word answer. A steady stream of closed questions feels like an interrogation: use closed questions when you want to confirm specific information.

• Did you check with Fred on that?
• Did you try the transaction under load?

Avoid “Why?” Questions

Of course, you want to know why, but asking “Why?” isn’t always the best way to find out. “Why?” questions put people on the defensive. Try asking questions that start with “How” or “What” to understand the reasons behind an action, approach, or decision.

• How did you arrive at that conclusion?
• What factors did you consider?

Ask One Question at a Time

I once sat in on a planning session where the leader started by asking a series of questions — eight of them (I counted). “Well, what are your answers?” he asked, looking expectantly at the dazed group. No one knew where to start. Should they start with the first question (if they remembered it)? The last? Some where in the middle?

Compound questions have the same effect:

“How are you doing on the performance tests – and are we getting anywhere with the memory leak – or is Ted handling that now, and is he able to work independently on that or is Sally helping him and how is that effecting the load testing?”

If you really want answers, ask one question at a time, and then…

Wait for an Answer

Some people like to think then talk. Others like to talk as they think. Our industry tends to have more people who like to think, then talk. So when you ask a question, give the other person some time to answer, pause, and count to ten. Wait patiently. The other person will answer.

The Other Side of the Desk

What can you do when your manager doesn’t leave room to get a word in edgewise?

Based on what I’ve seen, many people, like the 95 percent talk manager I observed, are unaware of that they are dominating the conversation. Some managers are uncomfortable with silence. Others assume that since the other person isn’t jumping in, they don’t have anything to say.

The trouble is, when you don’t share the same style, jumping vocally can be difficult. Try telegraphing your desire to speak in other ways:

• Send an email ahead of time with the topics you’d like to cover. Bring a copy with you to the meeting. Before the manager builds up a head of steam, gently push the topic list across the desk.
• Lean forward, open your mouth as if you are about to speak, and raise your hand slightly. Clear your throat, then begin speaking.
• Wait until your manager takes a breath (everyone has to inhale sooner or later). Start talking.
• Raise your index finger and place it in front of your lips. Most people recognize this as a sign you want them to be quiet for a while.
• If you are comfortable jumping into the monologue, say something like, “Excuse me, I have some information I think you need to know.” Then keep talking.

Managers need excellent communication skills and that doesn’t just mean talking. Part of good communication involves knowing when to ask a question and when to be silent and listen.

This article originally appeared on stickuyminds.com.

Building Trust, One Iteration at a Time

A while back I talked to a CEO of a contract development shop.  He wondered how Agile could help him with fixed price, fixed scope contracts to deliver software.

Of course, the requirements that come with these contracts are never complete or completely accurate. The first thing that comes to mind is to stop making impossible contracts.  For this CEO, that doesn’t seem possible, at least at this time, given the context he does business in.

In any fixed cost/scope contract there comes a time when the two parties must have a conversation about the short-comings of the requirements, the delivered software, and the budget.

In a waterfall delivery, all progress reports are proxies. You’re reporting on intangibles–designs, test cases, or code that isn’t fully integrated or tested. This is all reporting on faith, because it is not verified by working software.

When a change request does come up, it’s unanchored from the experience of how actually using the software. It’s only words, and the impacts are made tangible in cost thinking, how much it will cost to modify existing artifacts, ripple effects through the code, test cases, documentation.  There’s usually some accounting for the benefit and risks, but those tend to feel subject to inflation, based on conjecture, squishy. What does feel clear is that the change request process takes up time, and approving the change will cost more money. More often than not, the interaction feels like a tug of war. One side is arguing to spend more money, and the other is working with equal vigor for the opposite.

When the moment of truth arrives–the long tail of testing–it becomes apparent that all the progress reports up until that point weren’t reliable. After you’ve made the up-front promises and signed on the line, you have one big opportunity to build trust. If you blow it, you’re sunk. At that point, it’s difficult to have a conversation about meeting goals–especially when the lawyers get involved.

However, if you are using agile methods, you demonstrate some small piece of software every few weeks. People on both sides of the contract see tangible progress.  They have a chance to correct misunderstandings about requirements, and fill in the gaps in each others understanding. People on both sides of the contract can see and experience the short-coming in the requirements, so it’s not the tug of war a traditional change process sets up. People on both sides have more reliable data on which to make decisions.

Most important though, both parties have had many opportunities to build trust based on something real–working software.

So when that point comes, when both parties to the contract must have a conversation about meeting the aim of the contract, it’s a very different conversation.  The moment of truth will probably come sooner, when people have more options.  The conversation will be based on shared understanding of progress and trust.  And that’s a very different conversation.

Pendulum Swings and Oscillating Systems

An effective hierarchy provides enough central control for coordinated action in achieving the aim of the organization. At the same time, the hierarchy must provides enough autonomy for subsystems to function, self-organize, flourish.

Yes.  But how to do that? Let me walk you through a scenario that describes the challenge.

I’ve seen a number of organizations decentralize control and decision making, only to pull it back to the home office. If you watch long enough, many of these companies after experiencing centralized control for a while, go back to decentralized control–like a pendulum swinging back and forth.

Here’s how it goes.

As a result of centralized control, decisions are slow.  Slow decisions and top down plans that require an act of god to change lead to poor financial performance, and customer dissatisfaction. Because people are effectively denied discretion, creativity plummets. Rigid plans and targets don’t allow people to take advantage of new opportunities.

When the financial results start to trend down, senior management notices.  They want faster decisions, and front-line people who are responsive to customers. They want creativity, innovation. They want to seize emergent opportunities and respond nimbly to change.  They want better financial results.  Who wouldn’t want all those things.  So they decentralize.

After the initial flush of enthusiasm, they start noticing problems. Visibility decreases. Decision making and spending feel out of control. Some subunits make inappropriate decisions. Subunits optimize at their level, forgetting the overall goal of the organization. Some subunit managers go rogue, and strike out in directions that make no sense for the overall company strategy. Financial results dip.

And the managers want a return to clear lines of communication and authority. They want visibility, coordinated action. They want predictability, consistency. They want CONTROL. So the pull decision making, planning, budgeting back to the center.

While the supposed solution seems to be swinging between two poles, the organization and the people in it experiencing an oscillating effect.

In truth, the company doesn’t want either end of the pole.  They want the upside of both centralized control and decentralized control.  They want enough control to effectively coordinate actions of the various parts of the system to achieve the goal of the organization,  And they want enough autonomy so that all parts of the system can flourish, self-organize and respond to opportunities and change.

Why do systems oscillate?  Delayed feedback and an over-vigorous correction.  This happens on the organizational level, but it can also happen on a smaller scale anywhere in the system where feedback is slow and well-intentioned people over-correct when they do get feedback on system performance.

In order to achieve the upsides, organizations need to manage the downsides.  And that requires faster and more robust feedback loops. Those feedback loops will provide information about system behavior sooner, and allow smaller more nuanced adjustments.

I’ll write about some of those feedback loops next.

Musings on Management: Moving away from Command & Control

When companies decide they want the benefit of the team effect, or adopt agile methods, they (sometimes) realize that they need to update their management style as well.  And too often, they enter an 4-step dance of oscillation.

Managers feel overburdened and overwhelmed. Teams are disengaged.  They want teams to take more responsibility, and show more engagement.  The managers stop telling teams what to do, and wait for teams to step up, take responsibility, and morale to flip into the positive zone. So the managers step back, and the 4-step starts, and usually ends up back where it started–overburdened managers, disengaged teams, and an uptick in cynicism.

If you are in this pattern, you are not alone.  It comes from trying to solve a problem, when what you have is a polarity.  There are upsides and downsides and you have to attend to both.

You don’t have to get stuck in the 4-step oscillation. If your organization wants to move from command and control management to something more like servant leadership, here’s some help for the journey.

Here are  things a managers can do to move, and manage the upside and downside of becoming servant leader to a team.

1) Redefine the decision boundaries

2) Calibrate your interventions

3) Increase the overlap between contextual and day-to-day knowledge

4) Shift focus off events and onto patterns and system structures

5) Change your questions

My slides from Much Ado About Agile, Vancouver, BC 2010

Musings on Management Work, I

In two recent posts, I offered cautionary tales for managers of self-organizing agile teams:

Tale of a Yo-Yo Manager

Tale of a Too Hands Off Manager.

So what is it that managers should do to move from big boss to partnership?  It’s actually quite a long list, so let’s get started.

Expand Contextual Knowledge

In June, I wrote on how knowledge is bifurcated in many organizations.  People at the top of the hierarchy know about the business model and the context (at least we hope they do) and people closer to the bottom of the hierarchy know how things really work, have technical knowledge and skills to build what ever it is the company builds.  People at the top don’t know much about what it takes to get work done, and people doing the work don’t know so much about how the context. The extent of the bifurcation varies in different organizations, but once there is a hierarchy–even a fairly flat one–it shows up.

So one job is to extend the overlap between contextual and “how things really work” knowledge.

expand the overlap
Expand the overlap of contextual and "how things really work" knowledge

So part of what managers Dev teams need to know how their company makes money. This may seem painfully obvious, but somewhere in my distant past, I met a group of programmers in a financial services company who suggested that the fund managers avoid trading options because programming for options was proving difficult.

Once the programmers understood how much money there was to be made trading options, they figured out how to write the programs.

Dev teams need to understand how their company fits into the market and what their company’s aspirations are. For example, one manager communicated that the company aspired to handle 100,000 simultaneous users. Team members had this fact in their minds as they built the Web site incrementally. While the software they built in the first few iterations couldn’t handle the load, they made choices that made it feasible to build up to that level.

Some teams explicitly defer  all decisions about the cost and benefit of building features to a product owner. But I find that the more team members know, the more they can ask intelligent and relevant questions that hone not only their own thinking but also that of their product owner partners.

The best way to understand customers is to see them in their natural environment, using the product.

You might use this little map (from Osterwalder and Pigneur) to talk about these topics.

Business Model Map

What is our value proposition?

Who are our customers?

How do we build and maintain a relationship with our customers?

By what channels does our value proposition reach our customers?

What are our revenue streams?

What’s our cost structure?

What are our important people and resources?

What are our key partnerships?

Of course, we’re not looking for a mind-meld, where everybody knows everything that everyone else does.  But when people understand what it takes to do work and how the work fits in the big picture, partnership becomes a possibility.

Curing System Blindness

I’ve been writing about seeing systems, and got to thinking about a company I did some work for a few years ago–because they were a great example of how focusing on events leads to blame and prevents people from seeing patterns.

Here’s the story.  The customer service organization in this company had serious problems with availability of a whole slew of systems that their reps relied on.

It was such a problem that they created a new role and a new department to deal with the issue.  The “availability analysts” were charged with collecting data, analyzing the data and supporting a solution to the problem(s).

And collect data they did.  They had data on system performance, run times, crashes, errors, and abnormal conditions;  server up time, server down time, software outages (by application and system component); problem escalations, helpdesk calls, and trouble tickets.

When they weren’t collecting data, they were busy creating “the deck” for the (dreaded) management meeting.  The deck was pages and pages thick. Page one listed the lost productivity figures for the month, in “productive FTE minutes” lost. Page two listed the number of incidents.

pie chart
Source Contributions to Total Outage Minutes for the Month

But page five was the big event:  a pie chart  that showed all the sources of lost productive FTE minutes for the month.    The availability analyst walked the group pointing out that 25% of the outage minutes were due to network problems, 20% due to Mainframe outages, and so forth.

At the end of the pie chart report, the highest ranking manager would demand, “What are you going to do about this?”   Everyone else at the table tried to look small.  After some squirming, one of the lower ranking people would put forth an idea.  “I’ll expect a progress report next month,” the top manager would say, sounding stern.  And that was the end of the meeting.

Then, the availability analysts scrambled out to start chasing the problem of the month.

And it all started again the next month when the new pie chart was published.

Events, Patterns, Structure
Events, Patterns, Structure

Both analysts and managers were firmly focused on a snap shot of events, and missed the patterns.  The way they were presenting information helped hide the patterns and keep the focus on the latest hot issue.

I worked to help them see the patterns, which lead to understanding structure and dynamics–and taking meaningful action.

Now, they did need to respond to events–bring the network back up, or swap out a server for example.  They needed to adapt to some of the patterns.  For example, figuring out how to deal with certain types of outages more effectively until deeper changes took hold.

But as long as they only focused on short-term events–the monthly outage minutes–there was little chance of improving the overall situation. They were system blind.

Start Seeing Software — the concept in action

Tim Van Tongeren gives an example of how posting project information publicly can open up communicaiton on the project team

This just won’t happen if the plan is sitting in a scheduling tool (MS Project or your favorite flavor) on the project manager’s computer. Not even when the plan is on a network.

When information about the project is visible, everyone on the team can see what’s going on and everyone on the team becomes involved in solving problems.

Nice example of creating visibility so we can start seeing software.

Start Seeing Software

I found this on Joe Ely’s weblog Learning About Lean:

Central to any Lean system is Management by Sight. An effective system is very visual. In less than two minutes, any associate must be able to assess if the system is in or out of compliance.

He tells a little story about a colleague looking out the window and seeing an activity gave him important information about a problem with their production process (the are in the buildings business).

How can we apply “Management by Sight” to software?

Create visibility into the product.

–Test first development. When the code passes the test you know it works.

–Technical reviews. People with the relevant technical expertise examine a product (a feature, a design, a spec…what ever) and assess whether the product will do the job it’s intended to do. Make the review team’s recommendation public information (but not the issues list, please).

–Satisfaction surveys. Send out a little survey that asks the designers (or developers or testers… whoever) how they rate the product. (Here’s a short article on using surveys to “see” into the product.)

–Unit tests. Run unit tests and post the results.

–Track defects. Make the information public.

Create visibility into the project.

–Create a Public Project Poster or Deliverable Map. Put it up on the wall and post review recommendations, status, estimated and actual effort and duration. Trouble cannot hide!

–Milestone reviews. Look at planned and actual progress. Look at what’s changed, what assumptions have turned out to be correct and which have not; what risks have come home to roost.

–Track and display metrics. Defects, Fault Feedback Ratio, requirements changes, effort….. this list of possible choices is long. Pick a few key metrics and make them public (always in aggregate, metrics on individuals should stay private). Let your data tell a story.

–Hold a retrospective. Hold sprint retrospectives at frequent, short intervals. Ask the team: “How do you rate the product at this time? How do you rate our process at this time? How do you rate our teamwork at this time?” Use a 1-10 scale. Make a histogram. Figure out what it means. Choose what to change.

–Hold another retrospective at the end of the project or release. Recreate the timeline on a wall, a visual reconstruction of the project. It amazing what people will see about patterns of process and behavior when it’s up there on the wall in black and white and color.