Strategy. The Final Frontier.

In my company’s Research department, there’s a role known as Director of Technology Strategy. I might just be one

At this point in the company’s sad and sordid history, it might not be unreasonable to think that this job is devolving from a company critical and highly engaging thought-leadership role into an utterly toothless middle-management role.

It was understood that those bright lads who were offered this position would own the authority needed to drive new research directions, and additionally be responsible for broad communication and interfacing with executives and business leaders regarding the strategic bets Research was making. The Strategy Directors would manage project leaders, who would have day-to-day operational execution authority, coupling strategy with execution. How refreshing, right?

In fact, what has happened is quite a bit different:

• The CTO has personally dictated all research activities, down to minute detail.
• As such, the number of projects overseen by the strategy directors has been substantially reduced, while the projects have grown in size.
• The  Corporate Strategy organization (previously-tucked-away-in-the-back-corner-doing-dozens-of-value-destroying-acquisitions), has crafted a corporate strategic framework, without any consultation or dialog with the research strategy directors.
• Underlings who have no decision-making authority, but are currently enrolled in a business/management training program, have been given access to corporate strategy well ahead of strategy directors and other members of the research organization’s management team with the authority to actually act on it.
• An upcoming “bottom-up” strategy initiative, sponsored not by the corporate strategy department but by the COO, is apparently planning to bypass the research strategy directors as well.

As such, these so called “Directors” have had less input to drive strategy than almost anyone else in the organization. And since they have no direct reports (matrix issue) and no projects to manage execution of themselves, one may reasonably wonder — what do these folks do all day?

consultants, transversal groups, and software tools

Listen:

Once upon a time, there was a little company. The little company made things that lots of people wanted, and the company made money. The company also patented a lot of the ideas that went into the things, and even licensed the patents to other companies, that made similar things.

Everybody made money and was happy making new cool things that people wanted.

The company got the idea that there were other companies that made different things, that some of the same people wanted also. So they bought a few other companies, and became a Big Company.

These new companies had their own ways of doing things, which were sometimes a little and sometimes a lot different than the Big Company’s ways. Not necessarily better or worse — just different.

By the way, it turned out that some of the new companies that were bought were actually selling their things to different people than the Big Company sold to when they were a little company, and perhaps the different ways served the different markets more efficiently.

Or not. Who knows?

Now, all the little companies had engineers — software, hardware, firmware, even bloatware. (Bloatware doesn’t grow on trees, you know.)

When the Big Company bought these little companies, the engineers didn’t all wind up reporting to a Big Technology Mastermind who had been instrumental in the acquisitions. The Big Technology Mastermind may not have thought that these acquisitions were a good idea.

Or maybe he did. Who knows?

Instead, the little BusinessUnitProfitCenterThingsThatUsedToBeALittleCompany continued to report more or less into their little company’s organization, the way they did before Big Company bought them.

In other words, the Big Company’s fundamental organizational structure was now Market Oriented, not Functionally Oriented. This is one way of doing things, and it has some advantages and some disadvantages compared to other ways of organizing a company.

One of the theoretical advantages of this structure is that the engineers should be closely connected to the marketing and sales teams for their products, and quickly learn about customer needs and wants.

One of the theoretical disadvantages of this structure is that the engineers in one of the little companies don’t have much interaction with the engineers in any of the other little companies.

I.E., the way things were now, the technology and know-how that keep the company in business is not easily shared or reused. The overall strategic goal of the acquisition of the little companies is not connected to the day-to-day activitities of the engineers.

And so…

The Big Company starts to struggle to make things that people want. The things are not getting done on time. Sometimes they get done on time, but people don’t want them. And because of this, the Big People at the Big Company are getting their little white asses kicked by some stock market guys, who have put cold hard cash in the hands of the Big People, hoping that in a short time they’ll be given more cold hard cash in return.

The Big People don’t like getting their asses kicked much. (As far as we know.) But — they really don’t know what goes on with the engineers on a day-to-day basis, so they are utterly clueless about how to fix the problem.

So,

They Big People do what all Big People at all Big Companies seem to do. They call up a Big Consulting Firm. They pay those guys a lot of money and ask them to fix their Big Company for them.
The Big Consulting Firm thoroughly compares their company with other companies. Not necessarily other companies who make similar things to their company. Just other companies.

Allow me to interject a subjective opinion at this juncture:

This might not be very smart, since the Big Company makes things that require highly specialized high-tech skills, while other companies make things out of rubber and cement and lima beans and wheat.

So the Big People and Big Consultants come to the conclusion that the real problem with Big Company is that we have no “transversal” activity, to unify the tools and methods that the engineers use. So a “transversal” organization is put in place, to study which tools and methodologies would make all the engineers stop fucking things up for the Big People with the Wall Street Ass-Kickers.

The Transversal People meddle with the Engineers, because this is their job. They tell them that they must change how they do what they do. The Engineers have no choice but to take time away from doing the work they need to do, and do what the Transversal People say. In particular, the Engineers implement CMM, a system invented for the US Government, which is supposed to make them more efficient at their software engineering jobs.

Allow me to interject another subjective opinion at this juncture. That opinion is this:

The US Government is probably not the best role model for efficiency available on Planet Earth at the current time, for software development or anything else.

Some of the Engineers find clever and efficient ways to actually become compliant with CMM, while still finding the time to get real work done most of the time. (Being Engineers, they are actually pretty good at problem-solving, you know.)

The Transversal People, who only tell other people what to do, and who do not make anything the company can sell at all, are viewed as heroes by the Big People. They give the Transversal People a new job to do.

That job is this: Make all the Engineers use the same set of tools.

Sounds like a good idea, doesn’t it?

Well, there’s an old saying, “if it ain’t broke, don’t fix it.” You’ve probably heard this saying. I bet you have, really.

The Engineers have spent some time to learn to work with the tools they use, and they probably don’t use broken tools. (Unless Big Company was too cheap to pay for the tools they really wanted. Who knows?)

In the meantime, some people even use free tools, and like them!
And as we’ve noted earlier, the Engineers are not putting Lima Beans in a can. They are doing highly specialized high-tech work.

And sometimes, specialized work calls for specialized tools. (Oops, that’s another one of those darned subjective opinions, isn’t it?)

And now the Transversal People (who don’t use these tools themselves — these are tools for Engineers that do Real Work, like Bloatware) are telling the Engineers that they can use any tool they want, as long as it’s the Big Expensive Tool That The Transversal People Have Recommended.

And although we don’t really know for sure, it could be that’s because the Big Software Vendor Sales Dudes took the Transversal People out to lunch a few times and told them that the Free Tools and all the competitors’ tools are just crap.

(Not that they would lie or anything to sell thousands of software licenses. I’m sure they were being 100% objective about it.)

Hmmm.

So, I wonder what is more likely to fix the Big Problem of the Late and Wrong Products (and resulting Big People with Red Sore Asses)

1. Getting the Big Expensive Tool for everyone — paying for it and getting the Engineers to learn how to use it and getting the IT Group (we’ll save that topic for another post) to administer it

2. Leaving things alone and letting the Engineers get things done using tools they already have and use well.

Allow me to interject yet another a subjective opinion at this juncture. That opinion is this:

Big Company will make the most money if it chooses #2, and also shoots the Transversal Group and Big Consultants in the head. Big Company needs to stop fucking wasting money on bullshitters. Big Company needs to get back to hiring Smart Engineers who Make Things that People Want.
And also,

It wouldn’t hurt if the people who are supposed to support the Engineers (such as IT but I promised I’d save that one) would actually put tools in place that let the Engineers talk to each other across Market Segments. Things like Blogs and Web Forums and even good ‘ol Newsgroups and Instant Messaging and Really Fast Net Connections.

Because right now, the Engineers don’t know each other, and if they do, the only tool that they can use to communicate is Email.

But that’s another post.