The power of a good story

Story telling is a key component of managing and marketing an internal IT team. At least, so I have recently come to realize.

How does one market their internal security team? That question was posed to me by Steven Fox recently. Steven is a good friend and he is working on a book. I was hoping to help him, but I was not quite sure how to answer the question. I pushed back. I don’t really think of what I do as branding. But Steven pushed back too, and we got into a great discussion.

I am a firm believer in the power of a good story. Stories can promote the strengths of your team. Cautionary stories of other firms’ failures can help position your team for success. The right anecdote to the right person at the right time is a powerful thing.

I had not thought of this as marketing. But Steven helped me see it in a different light. Story telling provides consistent messaging that helps build a team’s reputation.

Here are some tips on story telling for IT managers:

1. You are story teller rather than the focus of the story. Your team members are the heroes.
2. Keep it real, keep it honest, keep it positive.
3. Maintain a story book or clippings folder for internal success stories and failure stories.
4. Maintain a story book or clippings folder for external stories, particularly
5. Share these stories with your team as well as your stakeholders. A good story celebrating a team member’s accomplishments needs to be shared.

Have a good story? Drop me an email or catch up with me on Twitter.

Wolfgang

Post script: Steven Fox recommended I check out the All Marketers book by Seth Godin.

How often have you heard the following? “I am thinking outside the box here, and if we only had this budget we could make it work.” Or how about this? “I am thinking outside the box but I keep getting shutdown because of the people around here.”

Thinking outside of the box has become synonymous with wishful thinking.

It is great to be different, to be unconventional, and to tackle problems from new perspectives. The box, however, is very real. There are budget constraints. There are time constraints. Possible solutions must make sense to the people who will make the idea a reality. Claiming to “think outside the box” while bemoaning a lack of progress is ineffective.

I say, think inside the box. Come up with creative solutions that incorporate as much of what we know about the industry, the organization, the teams, the people. Come up with creative solutions that we can afford, and solutions that we have the time to implement. Leverage the close relationship you have as an internal IT person to make solutions that outperform those that anyone else could do.

First, think inside the box. Then, understanding the box, we can get creative.

Scope, schedule, and budget. Perhaps no other concept is as deeply driven into the heads of young project managers. It is the iron triangle. The triple constraint. Scope, schedule, and budget define project quality.
However, the iron triangle fails for in-house DevOps teams.

Consider the following scenario. An employee needs a simple AR aging report. Such reports have been around forever, so the scope is tightly defined. The development team comes in and specs the project. They say two weeks. The project manager promises three weeks. The project comes in at two and a half and produces a flawless AR report. In scope, on time, and on budget. That is a success, right?

Now fast forward a few months. Support gets a call that the aging report is blank. But accounting knows that there are old invoices. Clearly, something has gone wrong with the report. Support starts digging into the problem. There is little to no documentation. Hours are wasted trying to ferret out the logic of the reporting process. It turns out to be a simple error in the inputs, something that could have been caught with some defensive programming. Hours more are spent in addressing the source data.

The actual but perceived quality of any deliverable varies over time. The AR aging report was a success on day one. But it was a failure when it was blank a few months later. Assuming the underlying issue does not get resolved (ie, the code bug lingers in input validation), the problem will continue to periodically occur. Come a year or two down the road, the business owner will complain that the aging report is junk and a new project will be started.

In this scenario, we have a simple logic flaw. Worse, assume the program was written without any security controls. Now all someone has to do is insert a check request in the unprotected source data, and create a fraudulent check. Though well within the iron triangle, such an aging report will contain operational and security concerns.

In the beginning, a project manager or a team manager can score a number of successes by strictly meeting the triple constraint. Each success, however, adds to team’s technical debt. I have seen many teams fail because of such successes.

With separate teams, such debt is someone else’s problem. The development manager has a string of successes while the operations manager is spending increasing amounts of time tracking down glitches. With a DevOps team, such debt is everyone’s problem. This means developers end up spending most of their time troubleshooting and patching old code. Development efforts slow because of this friction. Pretty soon, the business is wondering why it takes so long to get anything done.The solution? First, for in-house development efforts, cost is fixed. We are going to pay our folks regardless if they spend most of their time in support or most of their time on new functionality. Schedules are flexible and can be driven by the team. And scope, scope must explicitly include quality aspects driven by operations and security. That is to say, the project must be secure, it must be sound, it must be supportable, and it must meet the business owner’s needs.

Looking back at the AR aging report scenario, I would propose the following. Take the developer’s original estimates. Include estimates for code review. Include time for security review, and for hammer testing the application. Include time for documentation and other meta tasks. Perhaps that now boosts the time for the report from three weeks to six weeks. The project manager may not score a quick win. However, over the lifetime of the report, the business will see this report as more reliable and as higher quality. Further, over time, fewer hours will be required to support broken software. More time will become available for implementing new functionality. Build new functionality to a high standard and we create a positive feedback loop. That loop is key to delivering sustained business value.

Delivering sustained business value requires thinking outside the triangle.

Many IT departments have a less than sterling reputation. Outages are frequent and costly. Projects are unpredictable and over budget.

A survey in 2011 of small business owners found 77% had experienced downtime that caused productivity to suffer in the previous year. A Symantec study found SMBs average five outages a year, with a median loss of $14k a day. Larger organizations have larger impacts, of course, with a Ponemon Institute finding $5k a minute for data center outage with an average of 2.5 outages a year.

It is more than outages that hit the pocketbook. IT projects, those engines of value creation, are often at risk as well. In fact, a good 73% of IT management believes projects are doomed right from the get-go. Usually or always, there are problems from the start. From the same survey, by Geneca, 80% of the IT teams surveyed spend at least half their time in rework. Another survey, by PM Solutions, finds that an average SMB company has $74m in at risk projects yearly.

Ouch. PM Solutions lists five top causes of project failures. Curiously, these map very closely to the top causes of data center outages. From the ZDNet article:

• Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
• Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
• Schedules: Too tight, unrealistic, overly optimistic.
• Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
• Risks: Unidentified or assumed, not managed.

What’s wrong with the requirements? Quite likely, the person gathering the requirements and defining the scope did not have enough experience with the problem domain or knowledge with the solution domain. Put differently, the person didn’t quite get the industry they were in or the technology they were using. Resources and schedules? Same thing. The people doing work that was not scoped out sufficiently, and perhaps subsequently getting burned out and leaving the firm. Identifying risks, providing good estimates, and producing quality results all requires experienced and knowledgeable professionals.

Training and tools. It is all about getting the right folks, giving them the right training, and providing the right tools. Recognizing, too, that what is right today is wrong tomorrow. This is an ongoing process.

It is more than tools. When people ask how my team is able to run a complex infrastructure with 9 folks when it used to take 26, a good emphasis is placed on virtualization and automation. That is appropriate insofar as good tools are a vital component of the strategy. However, giving me a stone Hearth Deck oven along with the utensils and ingredients puts me no closer to having a tasty artisan sandwich. That requires training and experience.

It was disappointing, therefore, to see the State of IT Skills survey that hit last week. “9 in 10 business managers see gaps in workers’ skill sets, yet organizations are more likely to outsource a task or hire someone new than invest in training an existing staff.” That does not fill me full of confidence. I outsource a number of commodity services today. I have to tell you, I am rarely impressed by their support or maintenance. I call outsourcing McDonald’s IT for a reason. You get what you pay for.

90% of IT managers are running their departments into the ground. That is my take on the State of IT Skills survey. Projects continue to come in late and over budget. Outages continue to occur. The studies above are talking about tens of thousands, hundreds of thousands, to millions of dollars in losses. Perhaps at one time, IT departments could get away with such things. There was not as much on IT, of course, and there was not much competition.

Today, IT is dial-tone. Today, competition is a telephone call away to the nearest cloud vendor. Tomorrow, if we continue on a path of equipping our teams for failure, perhaps only 10% of internal IT departments will remain. Those are the 1 in 10 IT managers who hire and retain the right people, and who train and equip their teams.

Local hamburger shops cannot compete head-to-head with McDonald’s. Clothes stores cannot compete head-to-head with Walmart. Local book stores? Yep. They, too, cannot compete head-to-head with Barnes and Nobles. Makes sense.

Why compete head-to-head with cloud (IaaS, PaaS, SaaS) providers? *

Take a look at thriving local restaurants, groceries, shops, and book stores. What do they have in common? It is a single-minded dedication to customer service. These thriving businesses do not complete head-to-head. Rather, they carve their own niche within the market and create a monopoly within that niche.

The second step in managing an IT team is to define and carve that niche. This begins by having a very clear understanding of our firm’s industry, organization, business units, and professionals. How does the firm compete in the industry? How are the goods bought and sold? Who are the people on the critical path, and what can our IT team do to improve their abilities?

When was the last time an IT team discussed these questions? For me, it was about two weeks back. During a knowledge sharing meeting, a teammate reviewed how my firm’s products are bought and sold, and how the technology he was building impacted that process. How about your team?

No one can understand an organization and its people better than the internal IT team. McDonald’s does not make a custom crafted burger for you. Walmart cannot custom stock products just for your needs. The same goes with Barnes and Nobles, and the slew of cloud providers tackling the commodity IT market. No one knows you like those closest to you.

The competitive advantage the IT team must cultivate and sustain is customer closeness. Know the people, know the business, know the industry. Then leverage commodity services while out competing on value-add services. Be the bistro to the cloud’s McDonald’s.

Wolfgang

* Now a good argument can be made that cloud providers do not actually cut costs. In particular, this seems apparent with IaaS providers. Check this out for yourself. Price out two servers that can host 16 vms with HA. Now take your lease rate for, say, three years. Add in your price for power and hosting. Compare that price with your IaaS vendor of choice. I find IaaS for consistent loads to cost almost four times that of a DYI infrastructure. But it does require a three year lock-in and cannot scale up and down with load demands. This finding gets to the “own the base and rent the spike” strategy.

Klint Finley on SiliconAngle put up a good article last week on what he calls the “Emerging Anti-Stupid Movement“. He quotes Linda Musthalher as saying, “There is a shortage of companies willing to invest in the training and development of enthusiastic and committed employees.” What is anti-stupid? Investing in your team to support and enable them in producing quality work.

Check out the article. Finley has some interesting stats; such as the average IT pro putting in 71 hours a week and about 1/3 of the IT pros dissatisfied and looking for another job.

I talk a lot about how my team works. My management style comes from years of running small consulting teams. My style is people-centric and focuses on the value proposition.

I talk a lot about it. But as was recently pointed out to me, I do not write a lot about it. Practically nothing, actually. Over the next few weeks, I am going to do a series of Management Monday posts. Perhaps the time is right to build on this “Anti-Stupid Movement“.