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”.
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.
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.
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.
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.