6 IT Adages I Know to be True

We all know the power of storytelling in helping teams coalesce around a goal. We use allegory, examples from previous experience, reference to moments in history, and other accounts to create a narrative to guide a change, a project, or a period of austerity or investment. Storytelling makes it easier for large teams to understand and align with the “why” of the effort more than the “how”.

Oftentimes, though, an IT leader needs a similar rhetorical tool to bring teams together around the “how” as well. I have found the use of “sayings” helps embed in a culture how we expect our teams to approach the problems they face.

The power of an adage as a deliberate construct became clear to me many years ago during a conversation I was having with Martha Heller. I said: “Tech debt is like the iceberg beneath the water line.” It was a throwaway line, or so I thought. But it resonated with both of us, and we found ourselves repeating that maxim over and over again because it captured both the scale and risk of the tech debt problem while acknowledging the difficulty of seeing it all.

In the years since, I have found a few other sayings that — though, perhaps not altogether original — have been equally valuable as a leader of IT teams. Here are five more of them. I hope they’ll prove useful to you, too.

Heat maps and burndown charts are your friends. 

Internal alignment and expectation setting are essential to accomplishing anything in enterprise IT. I’ve found two tools particularly invaluable to getting teams on track — and staying on track. A heat map helps everyone understand the total scope and current state of the problem area they’re trying to tackle. A burndown chart — a useful graphic representation of the time and effort needed to finish a project — helps teams visualize their progress by illustrating how much work remains and whether the team is on target to meet its goals.

In one organization, I operationalized this into a three-letter acronym: CCA — coverage, completeness, and accuracy. This mnemonic shortcut ensured that everyone knew they needed to define the scope of their project, its completeness and how accurate the incoming data was. “What’s your CCA for the project?” became common parlance. Instead of “We’re going live with solution X,” team leaders would say “We plan to cover all subsidiaries, but so far, we have completed three out of seven. In those three we have the total tool set deployed, and the data we are getting is average today but will be good in three months”. That empowered everyone to be more realistic about progress and results.

It's not faster or safer, it's faster and safer — and that requires engineering.

The prevailing wisdom holds that you can only deliver an outcome more quickly if you take more risk — say, by spending less time testing to meet an earlier deliverable date. The reality, however, is that our role in IT is to empower the organization to go faster more safely. and you can only do this with a conscious investment in engineering solutions. Implementing more test automation, for example, enables you to review more test cases in less time — faster and safer. I’ve found in  large organizations comprised of many teams working on disparate projects, when everyone understands that this is the standard they have to meet, they rise to the challenge.

If everyone actually agrees on the problem, the solutions are easier to find.

I cannot tell you how many times a senior-level escalation regarding concerns about a particular solution choice has turned into a meeting in which everyone realizes that they never agreed on the problem they were trying to solve in the first place. Different stakeholders will naturally have different views on what the problem is, but they will often talk past each other in the rush to get to a solution discussion. Pulling people back to problem definition — or spending more time on it upfront — often makes solution choices much more straightforward and saves wasted time and effort involved in going down the wrong path.

Every decision you make will be wrong — eventually.

No one wants to make a bad decision. But there’s also a cost to being too precious about making a choice. Easy decisions are easy. It’s important not to overcomplicate them. The tough ones, on the other hand, will be judged over time. And, sooner or later, there will be new data points to consider and options that did not exist when the original choice was made. Flexibility is key; it’s OK to reexamine a conclusion when new information or situations arise. It’s also important to grant some grace to the people that made the previous decision. More likely than not, it was the best choice at the time. Just because things have changed does not make the original choice dumb. You’ll find that’s true for your own decision as well.

It’s all about the people.

It’s obvious. It’s a cliché. And it’s true. While IT may seem to be about getting things done, that can only happen when the humans that drive the IT engine are driven and equipped to do so. It’s essential for IT leaders to take time to focus on how people feel in their roles, not just on what they think or do. This can be a tough one for those of us brought up as engineers. But for any IT leader who has witnessed the higher performance of teams that feel the right way about working together toward the right mission, it’s obvious that we are in the people business first and the technology business second. 
 
While I can’t claim full authorship on any of these sayings, they’ve become an essential aspect of my leadership style. And I’ll bet you have some powerful adages of your own. (I’d love to hear about them if you’d like to share with me on LinkedIn.)