The Relationship Between Trust And Leadership

An article I was reading this morning got me thinking about how the quality of leadership within an organization relates to the level of trust that you'll find there. I'm not sure that it's a perfect model that I've come up with, but it seems to fit most of the scenarios that I've observed in my travels.

Basically, the relationship seems to be quite simple: the better the leadership, the more trust exists. This is one of those situations where you can perceive the effect (trusting and trustworthy players vs distrust between parties) in direct proportion to the causal factor (effective vs dysfunctional leadership), but it also can work in the opposite direction at times. I dedicated an entire chapter to this in my second AgileMan book (Issue # 46: Who Do You Trust?) but I think that I was still too close to the proceedings at that point to really see just how tightly tied together the two things were.

For example, a leader may start off willing to extend a great deal of trust out to his or her employees, only to feel "betrayed" by them if the same good faith isn't extended back. Imagine a team promising to complete some vital feature, giving "thumbs up" reports on it throughout the Iteration, and then falling well short of the goal in the end. That kind of result can cause a well-intentioned leader to change gears and begin compromising principles: becoming more of a micromanager, reducing the amount of freedom allowed to the team, or just generally dictating more of "how" on future work. In one way, I suppose, we could still characterize that unhappy outcome as being the result of poor leadership. After all, in an Agile environment at least, we expect leadership to emerge within teams, as well. So in my sample scenario, the team that "green-shifted" their situation right up until the end failed to demonstrate the type of maturity, honesty and transparency that we'd expect from a well-performing Agile group.

Just as likely, though, it's the manager or executive who failed to fulfill his or her responsibilities that leads to the breakdown. I certainly saw numerous instances of that in my role as Agile Manager, and in each case the result was a weakening of the bonds of trust between the organizational layers of the corporate pyramid. If a Product Manager promises to be available but isn't; if an executive fails to provide a vision of where the company is going; if team members are blamed for dropped balls that were actually someone else's responsibility... each of these qualities of poor leadership eat away at the foundation of trust within the organization. And that's not just a bad thing on paper, either.

Among the many ways in which a lack of trust hurts an organization, I saw:

• time wasted as people (in both groups) sat around and bitched about how they couldn't trust the other group any longer
• wasteful defensive measures planned out and enacted as ways to guard against the possibility of being let down or thrown under the bus by the other group
• the baggage of past betrayals brought up, again and again, in almost every new interaction, making it nearly impossible to ever achieve a fresh start
• a complete reversal of the empowerment model that Agile depends on, as more and more of the conversations would devolve into "contract negotiation" as each side would want detailed recordings of exactly what was discussed in order to fend off future allegations of failure
• a very unhealthy "us vs them" attitude that benefited no one and drove morale to continually lower levels everywhere

I suspect that superior leadership can overcome many of these threats, but it's definitely not easy. Each time I was a Feature Lead, for example, I felt the unmistakable pull of distrust exerted between me and my new team. They weren't sure that I wasn't there to take over and remove their decision-making powers, and I was never quite confident (at first, anyway) that they would do what it takes to get the job done. I'm pretty sure that's a typical place to start, and it's no wonder that so many people in leadership roles find it impossible to resist that gravitational force that's urging them back to familiar, top-down approaches.

What that tells us, of course, is that choosing your leaders in an Agile environment is all the more important, and not something that should necessarily be done by the same old rules of the past. If you make that mistake, chances are you'll be dealing with trust issues for years to come.

Separating The How From The What

Poor AgileBoy!

One of the most common forms of "oppression" that I used to hear about in my role as Agile Manager involved Product people (or other representatives of management) going well beyond their mandate of providing "the "what" as they ventured into the thorny territory of "the how". I doubt that it was ever intended maliciously, no matter how much conspiratorial spice was attributed to it by the development team members... but if that's true, then why did it happen?

First, though, I suppose I should explain what I'm talking about. In most Agile methodologies, there's a principle that says that the Product Owner indicates what the team should work on - in the form of a prioritized Product Backlog - and the team itself figures out how best to deliver it. Thus, "the what" is the province of Product and "the how" is up to the team. It seems like a pretty sensible, straightforward arrangement, and yet it often goes off the rails. Why?

One cause for a blurring between the two can be Product people with technical backgrounds. We certainly had that in spades with our (aptly named) Technical Product Owners, most of whom were former "star coders" who had moved up through the programming ranks into management earlier in their careers. I'm sure it must have been very difficult for some of them to limit themselves to "the what" when they no doubt had all kinds of ideas - good or bad - about what form "the how" should take. In the most extreme cases, I suspect that there were times when our TPOs actually did have better ideas on how to implement certain features than the more junior team members did... but dictating "the how" still wasn't their job. In that sort of setup (where the Product area is made up of technical gurus), what would have been preferable would have been an arrangement where those TPOs could have coached the team members on design principles and architectural considerations in general, as part of the technical aspect of their title. That healthier response would have still accomplished what I assume was their goal - leading the team to better software choices - without overstepping their bounds and causing a schism between product and development.

Another factor that can result in people not responsible for "the how" trying to exert their influence on those who are, is a simple lack of trust. Again, I saw this in action many times as the Agile Manager. I'm not going to paint a black and white picture and pretend that it was always warranted, nor that it was never warranted. But the important point here is that dictating "the how" downward in that manner usually did more harm than good, and it certainly did nothing to close the trust gap. For one thing, having "the how" taken out of their hands gave those developers who were already skeptical about management's support of Agile more ammunition with which to say, "See? It's all just lip service! We're not really being empowered here!" It was also true, in some cases at least, that "the how" being supplied wasn't particularly well suited to the new development environment that was emerging. What with all of its automated tests, refactoring and focus on peer reviews, the code was resembling what "the old guard" remembered less and less with each passing Iteration. I experienced this first hand, as I'd make some small suggestion about how to tackle something that I thought might be helpful, only to get a condescending look and "Uh, it actually doesn't work like that anymore" from someone half my age. Yeah, that's tough on the ego, but it's also completely the right response.

As for why the trust gap was there in the first place, well... as both of my AgileMan books lay out in gory detail, lots of mistakes and missteps were being made. It wasn't exactly smooth sailing, let's say. The result of that, however, was that some among management apparently felt that the teams couldn't be trusted, and so they attempted to exert more and more control over them, in whatever ways they could. Had they simply applied that energy to improving the requirements gathering techniques being used within our organization, though, it would've benefited us more. Providing clear sets of Acceptance Criteria and good, well thought out constraints would certainly have done more to improve the product features that our teams were developing than any amount of "meddling" in the mechanics of the software development process itself ever did.

I imagine that it's often difficult to keep "the how" separated from "the what" as you work in an Agile environment, but it's critical that you do. After all, the people doing the work are in the best position to know how to do it, and that principle has helped make Toyota one of the premiere auto manufacturers in the world. We could do a lot worse than to follow their example in the Information Technology business!

A Horse Of A Different Colour

I'm venturing back into the work force on Monday, but with a twist. After 22 years of full-time employment, this will be my first experience as a contractor. Also, the work I'll be doing looks to be at least somewhat unlike anything I've ever done before.

I'll be performing a review of the development environment of a local company, in order to provide some guidance as they continue to refine their practices and processes. I think that I landed the contract on the strength of a couple factors in particular: my rather far-reaching involvement throughout my last employment as the Agile Manager, as well as the general breadth and depth of my resume, to date.

On that former point, it seemed relevant in the job interview that I had had some recent experience bringing change to an organization. I talked about how much I'd learned in the process, especially regarding the importance of being patient with people as they absorb information and evaluate it through their own personal filters. There's also naturally an element of trust required in something like that. I likened it to the expression about leading a horse to water but not being able to make it drink. My job often seemed to involve repeating that process, over and over again, until the horse finally trusted me enough (or maybe just got thirsty enough!) to take its first sip. (Not that I think of co-workers as horses! It's just an analogy!!)

By the same token, I think that the wide-ranging roles that I've performed over the past two decades also helped get me a foot in this particular door. I've worked on big mainframes and small client/server infrastructures; I've coded procedural algorithms (COBOL, C, Assembly language) as well as Object-Oriented solutions (C++, Java); I've been a "do-er" and a manager ("do-nothing-er"?); I've worked within well-understood roles but at other times had to define my own job. In fact, my resume, when I take the time to actually look at it (usually when I'm updating it), speaks volumes about the fact that I like new challenges. I've tended to change "jobs" (but not employers) at a pretty predictable rate of roughly every two years or so! And that's been true all along, showing that even as a wet-behind-the-ears programmer back in the 80s I was always looking for change as soon as I got comfortable with what I was doing. I think the pattern usually went: a few months of being a newbie, a year or maybe two of competence or better, and then on to the next thing. That cycle has given me a lot of varying experiences to draw on by now, it seems.

At any rate, I'll definitely be learning about a whole new set of parameters, starting next week. I'll be comparing what I see in front of me to my mental backlog of best practices. I'll be discovering what strengths and opportunities are in effect in an environment that's quite different than anywhere I've worked before, and making recommendations on each. And I'll be building up a bunch of new relationships, right from scratch. All of which sounds like something that should be right up my alley, I hope!

It's All Relative

A friend of mine was recently describing his workplace to me, and I couldn't help but evaluate it (in my head) as if it were supposed to be an Agile environment (which it isn't). I realize that that's a bit of a strange reaction to have, but it happened nonetheless.

So here's a thumbnail sketch of what I envisioned as I heard more about the office in question:

1. Leadership style - From what I could tell, it sounded like a very Command & Control setup, although I was interpreting from just one person's comments. The managers keep a very tight grip on all of the decision-making, to the degree that the expression "micro management" kept coming to mind as he related some of the day-to-day occurrences. In his view, this level of hands-on guidance was completely normal and expected from management, but I marveled at how unaccustomed to that style I'd become in recent years.
2. Trust - People in the office are all on fairly short leashes in terms of working hours, as one example of where trust is lacking. Even back in my pre-Agile days as a manager, I think I established a fairly easy-going attitude when it came to things like people needing to shift their hours around or take time off for personal stuff. Therefore it was quite eye-opening to hear about a white collar shop, in 2009, that still operates under very rigid rules in that regard. When I asked about it, I was told that "someone in the past had abused [flex time], and so now they don't allow that sort of thing." Rather than simply penalizing the person in question and extending trust to the rest, I guess the decision was made not to trust anyone with that kind of latitude.
3. Transparency - The funniest example I heard involved some data that was being gathered about productivity within the group. At first I was excited to hear that metrics were being used, but then it turned out that the information wasn't going to be shared with the "rank and file" because of fears that they'd adjust their behaviour (in the wrong direction) if they saw the data! That was just mind-blowing to me, but it probably shouldn't have been. After all, transparency is certainly not the norm, no matter how much we might want it to be.
   
4. Empowerment - Because it's always been a favourite topic of mine, I tried to ask the sort of questions that would give me some sense of how empowered employees were at this company. The impression I got was that some of the leaders play what I like to refer to as "the false empowerment game", which goes as follows: I tell you to do something but I don't tell you how or give you many details. When you proceed to do what you think I wanted done, then I look at the results and say, "That's not right. I want it to be more like this." After a few more iterations like that, we finally end up with the correct product. (So, in one sense at least, they're doing iterative development!) The problem with that approach is that it wastes a lot of time and teaches the staff not to make decisions.

Now, as I say: this isn't an Agile office that I was hearing about, so there's no reason why they should be expected to live up to Agile principles. And yet I couldn't help but wonder just how much better they might be doing if it were, and they were.

Where's The Happy Medium Between Gold-Plating And Shoddy Work?

I think sometimes the line between "not good enough" and "better than it needs to be" is about the width of a razor blade (not that I know all that much about razors!). And that slim of a margin for error is not a very easy target to hit, especially amidst the chaos, pressure and distractions of most software projects. So what can we do to make the situation better?

Well, first I think that we need to examine what's really happening whenever accusations of "gold-plating" come up. I've seen it often enough in the past 22 years to at least have some ideas on it by this point in my career. The most common culprit always seems to be time, in the sense of there never being enough of it. When a customer, or project manager, or really any stakeholder with their ass on the line has their eye on the calendar, "finishing touches" can quite easily take on the appearance of "make work projects" or "endless tweaking" (and I don't mean the kind that requires amphetamines!).

To appreciate that perspective, just imagine that you've gone to pick up your car after a repair. You're in a hurry because someone's waiting for you and you told them that you'd be there by now, only to take longer than expected to get to the garage and then find out that the car's almost-but-not-quite ready. You then catch a glimpse of the mechanic busily doing what looks for all the world to you like a polishing job on your hubcaps! Of course you'd be frustrated at that scene, because as far as you're concerned you'd much rather get where you need to be right now with dirty hubcaps than arrive there later with 'caps that look brand new. But what if what was really going on was that the mechanic was checking out your tire pressure and using a rag to clear the tire well enough that he could read what the pressure should be? Most people would agree that having your tires checked is hardly "gold-plating," but you may not even know that that's what is actually happening from your vantage point. And on a more relaxed schedule, you'd simply trust that the mechanic knows what he's doing rather than jumping to any unfortunate conclusions. Start the clock ticking, though, and that whole willingness to extend trust may go right out the window... unless we make a conscious effort to be aware of that trap, and avoid it.

Now, that first point assumes that it's a simple lack of understanding that's creating the conflict. The software developer, in that case, is engaged in some activity that he or she has every reason to believe is required, in their expert opinion; meanwhile someone less involved leaps to the wrong conclusion about it being unnecessary. That's certainly not going to be the only scenario that can result in "gold-plating" charges being thrown around, though. Another possible cause is that there actually is work being done that is above and beyond what's needed to complete the job satisfactorily. So how do developers know when they've reached "good enough" with a piece of functionality?

One obvious way to answer that question is to ask another one: "What's the likely result if I don't do this next bit of work?" If that query can be posed and subsequently answered honestly, then I think we'd have far fewer confrontations of the sort discussed in this blog post. Most of the time, though, I suspect the question's not even being asked; and of those times when it is, then all too often the answer offered up is at least somewhat disingenuous. Why would a developer not honestly answer it? Because they may have an agenda (hidden or otherwise) that's not necessarily related to customer satisfaction. Some examples would be:

• "This code is too hard to work with unless I change it to look like what I'm used to."
• "The customer might ask for this functionality in the future so I need to put it in now."
• "I've thought of a case that will probably never happen, but if it did this code might possibly break so I'd better rewrite it."

That's not to say that any of those responses are categorically bad; just that they might not be reason enough to dictate that something's not ready, and therefore delay a release. And even a whiff of that sort of thing can cause the cries of "Gold-plating!" to go out.

So there we have two of the many ways in which this unfortunate situation can arise. To guard against them requires greater transparency, communication and honesty than we might naturally demonstrate if we just went about our business with our heads stuck in the sand. Living up that higher standard is a lot to ask of us all, to be sure; but as skilled professionals who take pride in our work, we can do it... can't we?

Trust Isn't An Option... It's The Only Option!

I was reading an article on the woes of "The Detroit Three" (automakers) this afternoon, and came across this fascinating bit about the New United Motor Manufacturing Inc (NUMMI) plant that was a joint venture between GM and Toyota, starting in 1984:

"The plant had [previously] been one of GM's worst; the Toyota system made it one of GM's best.

Detroiters made the pilgrimage... en masse to see the miracle of NUMMI. Some dismissed what should have become a model for the entire industry. True, the technology wasn't that innovative. But Toyota made the workforce integral to improving the system. Workers were not mere labor inputs. GM had no problem understanding the just-in-time inventory system Toyota used, but executing it required a buy-in from the shop floor so that everyone was dedicated to improvement. The Toyota system, says John MacDuffie, a manufacturing expert at Pennsylvania's Wharton School of Business, 'relies on contributions from employees. It feels vulnerable, but your willingness to be open to that vulnerability is what helps you make it work.' In the 1980s and part of the 90s, the top-down culture of the Big Three could not absorb that kind of deep trust."
- Bill Saporito, "Is This Detroit's Last Winter?", Time magazine, Dec 15/08

Those who've read the 2nd AgileMan book, especially Issue # 46, Who Do You Trust?, will perhaps recognize that the preceding description bears at least some similarity to what I observed in my role as Agile Manager. Lean manufacturing (as Toyota created and mastered), like Agile software development, requires that a greater degree of trust be extended to the "rank and file" than many traditional management types are ready, willing or able to accomplish. It sounds like the Big Three suffered from that, and I certainly saw lots of evidence of the same issue in the workplace over the last several years.

So just how can you place trust in the employee base and be comfortable in doing so? Well, we didn't pull it off all that successfully, but I still believe I learned a thing or two along the way. Here's what I think it takes on the part of those in charge:

1. Clearly communicate what's expected of those you're entrusting. In our software environment, that means telling everyone "the what" and empowering them to come up with "the how". I personally think it's unreasonable (and doomed to failure) to dictate both "the what" and the "by when", but others may disagree with that.
   
2. Establish how the results will be measured, make them well known, and then follow through on what you established. Metrics are tricky business (as I wrote about in the 1st AgileMan book), but just because they're hard to do right doesn't mean that you get off the hook for producing them! The temptation to shift around the measurements as time goes by is often very strong, but also completely unfair to the people whose hard work is being evaluated. The onus is ultimately on management to set the yardsticks and then to live by them. Failure to do so causes the staff to believe that you're changing the rules as you go... because you are!
   
3. Treat the inevitable failures that will occur as opportunities for learning. This is another tough pill to swallow, because those who live by the Blame Game rules (and who have long since mastered "Cover Your Ass" as an integral skillset) will find it difficult to re-wire their brains to this new way of thinking. Finger-pointing and general CYA attitudes, however, do more to erode trust than just about anything else you can throw into the mix.
4. Celebrate successes, large and small. This was perhaps the biggest disappointment for me in my previous job: the focus always seemed to be on what had gone wrong, rather than on what had gone right. If one Feature Team did really well, management would only want to talk about the ones who were still struggling. If a team got their bug count significantly reduced, the focus would go on to how "late" their new features were. Despite providing hundreds of features in our first 2 years of Agile, I repeatedly heard executives say, "We haven't delivered a single thing since we started Agile!" That sort of skewed perspective is certainly not a good way to build trust between the layers of the company!

If you can pull those four areas off, you'll probably do very well in creating an empowered, high-performing environment in which everyone will succeed. If, on the other hand, you regard trust as an optional add-on, like power windows or leather seats, then you'll probably be sorely disappointed in the results you get each time you "cheap-out" in that regard.