Agent of Change

Sometimes I struggle to start the next blog post.  Tonight is one of those kind of times.  There are many different potential topics but it seems that not one of them is more important than the others.  Instead of fussing over this, I’ll just to coax out a topic in the first few paragraphs.

One topic is under the category “what would I do if I was in charge?”.  This is an affliction that hits many software engineers.  My case is historically bad because at one point I actually did have a lot of sway in what we did.  A part of me wants to be able to influence things again and perhaps that is why I started blogging.  I’m the kind of person that is attracted to causing a positive change and usually I am willing to voice opinions about what would help.

Sometimes this is seen as a negative attribute.  People in charge typically don’t like being told these kind of things and the more people you have, the more likely conflict will erupt.  In my own naive way, I usually ask if the decision is better for the customer or if it is better for Citrix.  Sometimes it works out to be better for both.

I do have a tendency to highlight problems and also can get a bit dramatic if it seems like no one is listening.  I’ve had some classic moments.  Back in the early days, I said something which was considered too damaging and that it could have been a CLM (career limiting move).  This happened back at IBM working on OS/2 around 1992.  I had been concerned about the perception of “Workplace Shell” by the market.  I had tried to argue with other people including the leader of the project, Tommy Steele (sp?).  The message didn’t seem to get through so instead I dropped a bomb stating that I thought that “Workplace Shell” was a mistake.  It was easy to see that saying this was a mistake after I had said it.

Later my manager, Barbara Odle, explained to me the seriousness of what I had just done and suggested that it might have been a CLM.  She was very patient with me even though I did have a lot of passion about what I thought OS/2 should be.

It didn’t take long to realize that I was on an ocean liner and that any kind of big change in direction was simply not possible.  All of IBM was like that at the time.  When the call came in for Citrix in late 1992, it sounded really good.  After visiting the office, it seemed like heaven compared to OS/2 development.  So, I just left.

The early years at Citrix were full of energy and also an abundance of passion.  We knew what we were shooting for and we went for it.  We took big risks and they paid off.  We disagreed at first on things but we always came together in the end after the debate was over.    Even if you lost, you still felt like you had your chance and that the others were aware of your concerns and your ideas.

As the years progressed, it became harder and harder to make a big difference.  It has gotten to the point that sometimes that I am on that big ship again.  Decisions are made and instead of listening to concerns, it is instead often viewed that the person doing the objections needs to be re-educated about the value of the decision.   Most decisions are held to the top most layers of the company.  From what I understand, projects are controlled in a big way by the Finance department.  In other words, funding is not under the control of the engineering group but rather the central planners.  It is incredibly difficult to build a team to do a project unless Finance understands the value of such a project.  I don’t know details but I do know enough to conclude that this is mostly true.  It is very rare to have a project solely based on input from the engineering group.  I find this odd considering that it assumes that other departments know more about the technology than the group that is going to implement it.

My favorite new word to apply is delegation.  The engineering groups should be able to budget new projects without having to prove everything to the highest levels.  It should be possible to build skunk projects based on business opportunities seen at the customer layer.

There are quite a few examples I could give of things that I don’t think make sense.  Somehow it is just expected that either we will see sense in it or that we will just keep quiet and do it anyways.

One of my worst project experiences comes from how Product Managers  (PMs) are handled.  They are supposed to play a certain role but it is often hard just to get their attention.  It is common for PMs to be re-assigned many times during a project.  Historically, it has been very difficult to get them to produce what we need.  Many times, we have had to build our own requirements documents simply because we couldn’t any PM to work on it.  When they do get involved, it is often too late and with many dubious requirements.  The overall message I get is that they are completely unaccountable.  I would almost classify them as being untouchable.  I’ve never heard of any PM getting in trouble for missing deadlines or making major mistakes.  Part of the problem seems to come from the fact that PMs report to different groups.  I would almost swear that the switching happens between PMs to reduce the exposure to any one PM.  It is incredibly frustrating to see your project deflated by a defective PM.  It happens way too often.  Even when you get a good PM, you are often not allowed to keep them based on some weird internal policy that I don’t understand.  I know of a project close to home that has had at least 15 different PMs.  Honestly, how can this be allowed?  How can any PM be effective if he or she doesn’t stick around?

Obviously there are two important steps to fix this.  First, the PM needs to report to the same group at the same location as the engineering departments.  Second, the PM should be assigned for the duration of the project.  Any changes should only be a special exception.  Accountability and reliability are the goals.

My final CLM option of tonight is the name changing game.  Engineers work hard to build new products.  Projects are usually designated by a codename until it gets closer to being released.  Towards the end, but not too late, a marketing name is announced.  This happens for most projects but sometimes things go a bit wrong.  In the same project that had so many PMs, it had several name changes.  Most people that create name changes must assume that it has zero cost.  The truth is that it can be quite expensive since things are reworked with the new names, built, and tested.  Sometimes the name changes actually lead to breaks.  It can take around a week to clear a name change through the process.  Don’t quote me on that.  The concern happens when the name keeps on changing.  It becomes clear that nobody is quite sure what the name should be and instead of waiting for some kind of final decision, someone pushes the name change button with the hopes that it will stick.

This game is a crazy game to play.  Not only does it waste a lot of time, it doesn’t get any closer to what the real name should be.  The image of people getting together and fighting over names doesn’t seem good for the project.  It can get worse when different levels of management fight over it.  The early victors lose to higher level managers.

It is just a name.  I guess that is why it is easy to dictate changing it.  It would be much harder to get involved with technical aspects and have some good input at the beginning of the product cycle.

The engineering group concluded that it would be far better if only one name was ever specified.  This would force the managers to have their act together and only fire the button once basically to announce what the real name is going to be.

No one ever seems to get in trouble for excessive name changes.  In fact, in the last couple of years it seems to be encouraged behavior.  It seems that this thinking should not be tolerated and that names should be preserved during the product lifetime as much as possible.  Besides confusing customers, changing names can be an expensive marketing proposition.  Just think of all those materials that need to be tossed and new ones printed.

My ending comment is this.

Have you noticed that the Citrix dots have gone black?

Internally it was a point of contention last year.  Since then, radio silence.  Obviously the dark dots won.  Accept it :).

About Jeff Muir

Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide