(The title is a bit awkward but I loved the alliteration!)

Tell me if this sounds familiar…

…“We want to build trust. We want to have a seat at the table. What can we do to WOW our customers and build trust in our expertise and capabilities?”

It’s familiar to me. In every organization in which I’ve lead IT transformations, this thought makes its way to the fore, early and often. And for good reason. It’s critical to be engaged if you want a true partnership. One bit of often overlooked advice for those wanting to earn their way to “the table”:

Over deliver when it comes to supporting, protecting, and stewarding your production applications and environments.

Our customers rely heavily on the systems we build for them. In some cases thousands of people rely on these systems to do their jobs…all day long. Other systems we build help our customers get paid and plan for their future. If you put yourself in the shoes of these customers, the most important thing we can get right is supporting *current products*. I don’t want to undervalue new product development, but those products typically don’t already have hundreds or thousands of people relying on them (yet). It’s the legacy stuff…the stuff no one wants to talk about or touch, that tends to catch us flat-footed. We are judged every day, by each and every one of those “ticking time bombs” that “were developed by someone else”. Those tools that we haven’t touched in 6 years are the ones that can kill us, erode trust, increase our risk, and get us forcibly removed from “the table”.

Implicit Contracts

Many companies don’t have explicit service contracts for their internal products, especially the legacy one’s built by “someone else”, but you better believe there’s an implicit one in place. Every time you roll something into production, you are telling your customers,

“Here is a product of our end-to-end IT capability (project management, business analysis, QA, development, deployment, network and infrastructure). This is what you can expect from our teams.”

Customers pick up these products and USE them. Many times they build their worlds around them. Some by choice, some by force. We’ve handed them a tool with a smile and a handshake and said,

“Here. Use this.”

What do you think their expectations are in this interaction?

The distance in time and space between today’s staff and “old” products and commitments makes this problem tough to stomach. But it shouldn’t make it hard to understand. Customers don’t care when we use the term “legacy code”, “classic ASP”, “VB6”, or “spaghetti code”….. THEY – DON’T – CARE. They are in pain because of a product IT built. We are IT. By the transitive property, WE are causing them pain. This is implicit, but that doesn’t mean it’s imaginary. It means it exists whether we say it or have agreed to it or not.

Ok, after we breathe deep and swallow hard, how do we go about fixing this issue? One way is to live by and teach some very specific values.

The Boyscout Rule

“Leave things better than you found them.”

As simple as it sounds, when everyone on your teams (not just developers) live by the boyscout rule, systems will improve dramatically. In an awesome twist of fate, this is especially true in organizations that have lots of issues. Why? Because there are dozens of opportunities every day to make systems better. Every help desk call, nightly failure, small scale enhancement, and upgrade is an opportunity to clean and polish a tiny section of the system, its documentation, and its “broken-ness”. You’re already putting effort into these systems. Teach your staff how to focus their effort on cleaning up as they go.

(please refer to my favorite scene in “Ratatouille” where Colette (the rôtisseur) is teaching Linguine (the main character) how to be a chef. “Look at this mess! Your sleeves look like you threw up on them! Keep your station clean, or I’ll kill you!”)

Your Professional Signature

Make everything visible. All the hard work, blood, sweat and tears to hold the line on quality should be visible to everyone in the organization. Every time you touch a system, tell people what you did to make it better. Look at every system interaction as a chance to show the team that you have their best interest in mind and you refuse to deliver a Rube Goldberg into production. I’m telling you this is not only a punch in the stomach of our customers, it’s also a kick to the shins of your peers. The person who made the mess RARELY is the one who deals with the second and third order problems it causes. Refuse to make that “normal”. Your professional signature should go on EVERYTHING you touch. What better way can you show respect than that.

Shared Accountability

Related to your professional signature, HELP your teammates deliver. Hold one another accountable. Discuss. Debate. Raise concerns. One thing I’ve recognized through the years is that one person will never solve this problem. Go to your peers with an attitude of compassion, understanding, and help. Don’t refuse their work. Show them what you expect and help them get there.

Safari!

In the spirit of Lean and Kanban, ask your teams involved in IT to visualize their value stream and hold daily stand-ups. This gives the rest of the organization the ability (and opportunity) to do safaris to the other teams stand-ups. We’ve found these incredibly useful as we now can hear and see our partners pain points (with us and others) and can take proactive steps to resolve any quality issues we might witness. For example, take the opportunity to listen to the support teams talk about your product portfolio. If you hear them bash certain products, repeat the names of the same systems over and over, or roll their eyes, you have a culprit to deal with.

Conclusion

If you want to WOW your customers, give them incredible service on the things they have already come to rely on. If you can’t get that right, STOP BUILDING NEW PRODUCTS until you get it right. For the same reasons, you won’t win friends (trust, respect, legitimacy) rolling out products that no one can support either. There are definitely times when building new tools and products gives our customers a stunning advantage in the market, clear efficiency in daily work, and the ability to evolve their business. I don’t think anyone would argue that. What I hear regularly is minimization for the need to support and maintain our systems (time, effort, pain, importance, focus), and to build them well – right out of the gate.

Interestingly (and poetically) the more time, effort, focus, and pride you and your teams put into supporting and maintaining systems, the LESS time you’ll actually spend doing it. Not only that, your partners will build you a permanent seat at “the table” when you get it right.

First of all, I’m SO sorry for the terrible Top Gun reference in the title. The best title was already used and this one is less than awesome. OK, now on to it.

Recently Jim Benson (author of Personal Kanban) asked that I provide him some feedback on a piece he is writing called “Reading is (Still) Fundamental” (said title from above). He wanted to know my thoughts on reading, and encouraging reading in the workplace. I thought it was an interesting topic so decided to share my response.

My Response:

A staff that is willing and equipped to read is a staff that understands the need for continuous improvement. In that regard, reading, reflecting, and learning is crucial. To understand why, let’s simply look at one of the most common reasons given (to me) for why some don’t read.

“I learn enough through experience! Everything I know I’ve learned through the school of hard knocks. What could a book *possibly* tell me that I can’t get from experience?”

While it’s true that experience is likely the most powerful means of learning, the sad truth is that we don’t have as much experience as we think we do. As I’ve learned (in books no less) most of us rarely have “20 years of experience”. We typically have one year of experience FOR 20 CONSECUTIVE YEARS. That’s right. If we reflect on our past, occasionally we have brand new experiences that indeed teach us quite a lot. But for the bulk of our past, we tend to repeat what we know over, and over (and over) again. In that way, I would argue we need to step outside the boundary of experience-based learning and learn from others collective experiences. You do that in books, articles, websites, blogs, and yes, tweets.

As you might guess, it’s important that your teams are “willing” to read. Just as important, they need to be “equipped” to read.

As employers, we can help control the second of these two statements. Our obligation while building learning organizations is to model behavior, challenge assumptions, infuse an attitude of curiosity, and generally create conditions that allow (and encourage) people to read and reflect. After all, as adults, quiet reflection is critical to our growth. We are therefore obligated to not only “allow” people to read at work, but to encourage and incent them to read at work as well. In that way, each employee becomes a wellspring of “new” ideas, and a potential catalyst for infusing those ideas in our organizations.

In Homer’s epic “The Odyssey”, Odysseus, King of Ithaca spends 10 years traveling home from the Trojan War. On his journey through the lower world, Odysseus was warned by Circe, daughter of the Sun, to be wary of the Sirens on his journey home. The fate of sailors hearing the beautiful Siren Song was to be lulled into lethargy, and subsequently smashed against the rocks of the Sirens island. “Their song, though irresistibly sweet, was no less sad than sweet, and lapped both body and soul in a fatal lethargy”.

Odysseus, a brilliant leader, had the foresight to heed Circe’s warning and filled his crews ears with beeswax. He then instructed his men to tie him to the mast of the ship and under no circumstances release him, no matter how much he pleaded. When he heard the Siren Song, Odysseus implored his men to release him, but they bound him tighter. When they had passed out of earshot, Odysseus demonstrated with his frowns to be released.

So what can we learn in the world of technology from Homer’s eponymous hero?

The seductive Siren Song we hear, in today’s parlance, is the relentless call for “faster, short-term, tactical” solutions to problems. Our business partners and customers enchant us with the beauty and promise of feature after lovely feature. We are lulled into a belief that the opportunity to deliver today will *always* outweigh the problems we might encounter later.

Not unlike Odysseus’s crew, we need leaders. We need a leader that will tell us to stay the course and shield us from the merciless call for the quick win. We need the type of leader that has the foresight to save us from the rocky shores. We need leaders with enough fortitude to plan for the perilous attraction of the Sirens Song. Someone who won’t allow us to hear it, and will make plans to keep us from the short sighted problems it will cause. Yes, we need them in IT, but we mainly need them to come from the business. The sad fact is that this is *their* ship….they are the captains and stand to lose the most. We need to find them and ask them to take responsibility.

It isn’t enough to pretend that most technologists, especially in corporate IT, have the ability to resist this call on their own. In almost every way, IT practitioners act as a crew on a sailing ship, dutifully delivering value and doing everything in their power to serve the needs of the captain leading them. It’s romantic to think that one of these folks will rise up and steer the ship away from the rocks. This is sadly the exception, not the rule.

We need an Odysseus, a leader in the business, to face the Sirens. Our duty as steward and custodian is to find them.