I loved the first 10 years of my working career and hated the last 25.

I studied electrical engineering and got a BSEE and subsequently entered the workplace full of confidence. I followed my interests in low-voltage communications systems and in the doing somewhere along the way got sucked into the whole IT funnel cloud.

I began my career in oil and gas down in Texas back when engineering was still a gentleman’s game but ended it when rampant technical worker immigration and Cisco ‘certificates’ began to undermine the profession.

I foolishly left oil and gas to follow in Jed Clampett’s footsteps to California which is where my profession began its death spiral.

I started working for Intel in ’89  and it was there things – namely my career – got twisted.

Example – decision making at Intel IT back in the ‘90s worked something like this: an engineer goes to his manager and asks a question regarding one of his projects. Manager’s response is crafted in a format more akin to a riddle but the direction, more typical than not is that the employee needs to go back and do a bunch more things. These things were typically about satisfying some of the finer points of business process and usually involved educating someone else about the project. That next someone else generally had concerns or questions that could only be comprehended if yet still one or more other people were brought into loop.

No decisions are being made at this point but more work is being generated. And in many instances the value of the project is determined not by the intrinsic nature of the project or the result, but determined by a manager based upon his/her perception of the value and the potential exposure that will result from the project. In other words, if a project was designed to solve problem, but the problem or potential solution was not understood by the manager, or was not a problem that the manager had to personally deal with, or the potential solution would not get sufficient notoriety, then the project was deemed unworthy. Often this results in busy work that requires an effort to prove that the project got properly vetted by the right people.

Things as seemingly innocuous like new self –empowered work teams, while timely and necessary (because if for no other reason than to expedite the decision making for the little issues), further complicate the management/decision making process.  1) By pushing decision making into such far corners of organization that the decisions that are produced are typically throw out at some point later because a) the decisions weren’t effectively collated for future reference b) or just something as stupid as moving targets creating extenuating circumstances 2) management is no longer the sole repository for the decision making process and as an end result is no longer being held accountable for decisions.

I had experienced a project plan that was stuck in both simultaneous management and peer reviews; and in different states of indetermination.

I had also experienced managing a project which necessitated gathering requirements, doing a design, and seeking funds conterminously; which was fundamentally absurd because one could infer that there both was and wasn’t a problem occupying the same space in time.

Here is a real example of what I am talking about: ‘We need you to design an Information System that will allow us to better understand the costs associated with the voice network. It needs to do this, this, and this.’

‘Okay. What are the (rest of the) requirements’?

‘You and your team need to develop those.’

‘What is my budget’?

‘It depends on the requirements.’

‘Who is my customer then’?

‘You and your team, all of the site PBX folks, and business groups A,B, and C (and expectedly a bunch of other folks who wouldn’t be identified until some time out in the future).’

‘What’s my success criteria’?

‘Making everyone happy’.

In the older and infinitely more pure ‘design/build’ world, the work process flow was pretty straight forward – a customer created a need, funding was created to satisfy the need, the funding enabled a design and so on.

The questions always were: Where did projects get screwed up? Why did they get screwed up? And why did they get screwed up more times then not?

This example project had cross-organizational implications with regard to not just providing varying degrees of benefit but also different cost burdens depending on where you were in the information stream. It was here at this point that management never provided to build the communication bridges at the management layer and clearly define how corporate objectives were going to be translated into work and getting that done and  in agreement before pushing it down the food chain into engineering and assigning it to a design PM.

I made my 1st mistake in assuming that it was clear to everyone that there was a problem (no real visibility into voice network costs) and therefore I was tasked to design an IS to provide a solution to that problem. Part of my assumption was that management had dotted all of their ‘i’s and crossed all of their‘t’s further up stream (or why else give it to engineering and say, ‘design me an IS’?).

So I didn’t see that I was letting myself get set up to fail, which had to be imminent, because there was never any really clear picture of an objective other than the a couple of managers who had a desire to have a new capability (and then only in the abstract), and no clear understanding of ‘customer’, except in the vaguest sense.

The design/build process starts breaking down when you as the PM (as well as the design engineer) are in certain respects your own customer, or at least in that particular example where I was asked to design that new IS where my group would be one of chief end-users. I knew what my group wanted in a system. And I could design and build a system that would meet what I perceived as corporate objectives but there wasn’t one system that would serve to satisfy every last PBX admin in the company.  That was of course presuming that any admin had an original thought regarding capacity planning (I know what I am talking about here as I interviewed most of them). But the fact of the matter is that management allowed them input into the design because as end-users that somehow gave them stakeholder status. Which in and of itself wasn’t necessarily the problem. The problem was more about wasting critical design cycles training the admins in system design; a clear violation of IS design best practices. Another problem was, though try as I could to freeze the design after consensus had been finally reached on the major design points, we always at some point managed to revisit individual design elements typically because there was a new face, a new manager, or a new opinion resulting in numerous resets.

It would have been okay if one was allowed to build a prototype or to model the IS to a point where it could quantitatively be defended but as the project plan and the design proposals got pushed through the various and every changing peer and management reviews there was always something that would cause my team to get periodically reset to zero.

I remember on another project presenting a solution in my boss’s boss’ staff after which one manager hotly remarked that he didn’t even know that there was a problem ‘so what did we need it for’?

I had been working on that particular project for over a year. It was assigned to me by the manager in whose staff I was presenting and it was one of his people who ‘didn’t know that we had a problem’.

The very same manager who assigned me to design that solution turned around 180 degrees and in front of everyone told me that ‘I needed to do more work on selling the problem’.

So the long and short of all of this was that the organization runs the risk of the staff being perpetually lost, dazed,  and confused because management isn’t doing their job.

And yes this is/was a waste of resources all because middle management is/was able to side step the pesky little problems of doing their jobs pushing decision making down the food chain but then reserve by virtue of being management to always second guess.

And the net result is that projects rarely got finished; they merely evolved or morphed into something else. One project always begat at minimum an additional 20 ancillary line items (begits as in begats, ‘…and Joshua begat Loab who begat Isaiah who…’)

This partially explains why service organizations without direct P&L responsibilities are more or less hopelessly broken. And this state is self –perpetuating because people get used to working in an organization that allows their managers to shirk their responsibility. The sad thing of it is that while we all get used to it, the manifestations of operating in this perpetually screwed up way is that we get severe anxiety thinking that it’s our fault -think about your performance reviews –  If we only did our jobs a little bit better and if we could just get this next re-org behind us everything will be better.

But it never is.

It’s always screwed up and management’s solution is to re-org and of course the supreme irony is always to add yet another layer of management.

Does any of this sound familiar?