Confusing Strategy with Tactics

This seems to happen all the time. I, personally, encounter it with disturbing frequency. One of the most common mistakes I see made is the mixing of strategy and tactics by managers. I can feel some of you pulling away from me. Before you do that, though, let me explain. It is the job of management to enterprise strategy or "corporate vision," if you prefer cheezy management buzz phrases. With that, I couldn't agree more. Management has the encompassing goals and they are the ones who must solidify these goals and transmit them to the rest of the enterprise. In short, they define the "what" portion of the overall equation, in the sense of "Here is what we are going to do." Where I often see things go awry, though, is when management then goes into micromanagement mode and proceeds to tell the engineers how to meet these goals.

It is important to understand that I'm not saying that management should be completely hands off. It is their job to provide guidance and to set the rules of engagement, so to speak. Once those rules are set, though, they should step back and let the engineers work their mojo. Having been given the strategy ("what"), which includes the rules of engagement, it is the job engineers to determine the tactics ("how") appropriate for accomplishing that strategy. Let me provide an example to illustrate my point.

I once worked for Company X in the capacity of information security analyst. Though the company was fairly large, there were only two of us who were security analysts, so we were stretched pretty thin. We had a monthly enterprise vulnerability assessment that required sifting through a mountain of data. We were using a commercial vulnerability scanner that could only export the data as PDF files or as HTML files, so to do any real work with the data, PDF was out of the question, so we had to dump the data as HTML files. Fine. An inelegant solution, but still workable. Once exported to HTMl files, though, each file had to be opened individually and certain rows of data had to be exported to Excel. From there, we performed some calculations and data normalization (much of which had to be done by hand), and they that data was copied into a Word document, which was, in turn, converted into a PDF file for the final report. When I first encountered this absurd series of events, my first thought was "wow...too much effort. I'll put together a Linux box with Nessus and then I'll write some Perl scripts to parse the Nessus data and create the reports." So with the approval of my manager, I did this and I successfully reduced the amount of time required to collected the data and generate the final report from several weeks to a little more than a day. I showed the end result to my manager and he was pleased, so we were poised to roll out the new solution. As luck would have it, just prior to the roll out, the CIO decided to put forth a new corporate vision: we were to be a 100% Microsoft shop. I assumed that he meant that we were to use Microsoft products except for those cases where there was no Microsoft product, as in the case of the vulnerability scan and the subsequent report. As it turned out, I was wrong. So we had to scrap the whole project just before it was ready to go into production. The situation was explained to the CIO by my manager, at which time the CIO actually became somewhat combative and slammed his fist on his desk saying "I said that we are going to be Microsoft only, and I meant it!"

So there I was, back to having to jump through a comical number of hoops to generate what ended up being a report of less than 10 pages. "Well," I thought, "instead of having to extract this data by hand from these HTML files, I'll put together a perl script to do it for me. That'll speed things up a little bit." It was at this time that I got a call from another of the managers.

"Uh, yeah, you can't do that."

I blinked, stunned. "Can't do what, exactly?"

"Those scripts. Yeah, you can't write those in perl."

"Why not?"

"Perl isn't an approved language here at Company X."

"But they're just for my own use on my own machine. I'm just going to use them to parse some data that I'd otherwise have to parse by hand."

"Yeah, I know, but you still can't write them in perl. If you want to write them in Javascript, which is approved, that'd be ok. But you just can't write them in perl."

So there you have it. What I desperately wanted to say (and rightly did not) was "I have a job to do. If you want me to do it, then get out of my way and let me do it." This is what happens when management confuses strategy with tactics.

Managers: set the strategy, define the goals, set the rules of engagement, and convey that information to the masses. Then kindly step back a little bit and let the engineers do their jobs. Don't micromanage. It is irritating and insulting to the engineers and doesn't speak too well of your management skill.

Engineers: listen carefully and respectfully when you are given strategy, goals, and rules of engagement. Then do everything within your power to achieve those goals as quickly, efficiently, and effectively as possible. Play by the rules and give regular progress reports. And don't be patronizing. It gives us all a bad name. Besides, it never pays to antagonize management.