Hugo Troche's blog

Motivation of a Manager

Over time I have observed many managers and executives. They each have their own management style and effectiveness. I never went beyond superficial analysis on their management style. Yet, I noted an interesting trend among their motivation as a manager. I defined motivation as to whom the manager feels she is working for. I found three distinct types:

a) Working for her superiors. This is the manager that does everything she can to achieve her superior's objectives. It is all about making the boss job easier. Nothing has a higher priority than a request from the boss. I have seen this type of manager in larger corporations, particularly in middle management.

b) Working for her customers. This is the manager that is always thinking about her customers. For this manager the customers are always the first priority. You will find this type of managers in startups, small consultancies and a few big companies. One company well known for this attitude is Intuit.

c) Working for her employees. I have not seen this type of leader very often in corporate America. You will find this type of manager in the military. Good officers are very concerned about their people and their well being. They truly believe they are serving their people, not the other way around. They even have a expression for it: "The burden of command." This is the type of leadership that leads managers to never ask her reports to do something they wouldn't do, to stay late if her reports have to stay late, to be the first one to arrive in the morning and the last one to leave at night.

I am not arguing that any of the motivations is better than another. I think each has its own place. A business development MBA will be great with type a). Type b) is perfect for Service Managers and Program Managers and type c) is an excellent fit for a Director of Engineering. On the other hand executives need to balance all three.

Cloud Computing and IT Ops. The Development/Ops mashup.

In the JEE world in many shops there has usually been a wall between the IT Ops departments and the internal  Software Development departments. The process is usually as follows:

- An internal engineering team develops a great application.
- If the engineering team has good project management skills, they involve IT Ops early in the development process.
- IT Ops provides engineering with resources necessary to run the application in development, staging and production environments.
- The engineering team and IT Ops team agree on a deployment methodology.
- The IT Ops team uses a monitoring solution.
- And so on.

This common interaction framework is based on one simple rule: IT Ops provides engineering with defined, limited resources for a project. IT Ops provides 4, 6, 8, etc servers to run the application. Even with the advent of virtualization the framework remains the same. Instead of servers, IT just provides VMs. Yet, IT still controls how many VMs to provide and what resources should be in those VMs.

This is going to change with Cloud Computing. The Cloud Computing concept of elasticity turns the resource management practices of an IT Ops department on its head. Elasticity is the ability to increase computing power in the form of more servers, more storage, etc dynamically, by the application running in the infrastructure.

Pure elasticity will mean that engineers developing an enterprise application will decide how many resources their application will use at any time. This decision could be implemented in the form of an algorithm calculating necessary memory and CPU according to transaction times, or according to number of users. The application will decide by itself how many servers to use, and it will contract and expand dynamically.

Then, how does an IT Ops department manage resources? All of the sudden, they don't know what resources will be used by which application.  One obvious solution will be to implement pods, a silo of resources that limit the maximum resources a set of application can consume. Yet, to fully get the ROI from a Cloud infrastructure, a company can't create silos. You want idle resources in other silos to not be waisted.

If Cloud Computing becomes the predominant platform in the enterprise, elasticity will change a long standing division of responsibilities and functions. Maybe this factor alone will slow the adoption of internal Clouds in big IT shops. That, and the fact that there are very few vendors that can actually implement a EC2 like Cloud environment.

Managing by Controlling Information Flow

Controlling information has gotten quite a bad reputation in the last few years. This reputation is well earned and should be respected. No matter how clever the ploy is, if it involves not devolving information internally to manipulate someone, you are going to get hurt.

Let me tell you two cautionary stories from my extensive vault of anecdotes. The first one is an example of of information hoarding by a non manager. The second story of manager that decided to outmaneuver another manager by not providing the whole picture.

The story of Tom

Tom was a developer/system administrator at a medium size company called XYZ Financial. Tom had been with XYZ for over 20 years. Tom's network inside XYZ was extensive. He was a good friend of   the CIO. They started at about the same time. He was also in good terms with two of the three VPs reporting to the CIO. Tom had survived many layoffs. Tom felt secure.

The main reason why Tom was important, was because he was the only one who knew how to modify, start, shutdown and restore two critical legacy applications. He developed those applications originally and today only he knew how they worked. XYZ tried to update those two applications to newer platforms twice. Both times the efforts failed. The talk in the grapevine was that Tom was a main factor in those efforts failing. Tom never shared any information. He did not teach anybody how to do anything to the applications. His excuse always was: “I am too busy, these application need to run and I don't have time for anything else.” Whenever the heat got too intense for him to release information he went to the CIO and VPs to complain. For old times sake, these executives backed him.

This was the situation that I found myself going into in a consulting engagement. My main function was to create a technical plan to migrate the applications to a new platform. The person in charge of the project was an enterprising manager called Bob. Now, Bob was an interesting fellow. He had very little technical knowledge, yet he managed to rise to a director position in a technical organization. Nobody liked Bob, except the consultants he hired. Bob was a smart guy, he hired good consultants to help him in technical issues. Bob made sure that you got paid on time and he always wanted honest and brutal advice. Bob specialty was office politics. He was simply the master of it. One afternoon after a series of though meetings, we went to a bar and Bob told me that he found out on the Internet that there were Medici's of Florence among his ancestors. I believed him.

Our problem with the project was Tom. He was doing everything in his power to make the project fail. He only answered very specific questions after two days of us asking them. He refused to document anything about the system. He refused and procrastinated to provide access to the system. He made us get sign offs from at least two executives to get any kind of access. He monitored our access of the applications and asked extensive questions in front of other managers and executives about why we did what did in the system. Then he hinted about problems we created that he had to solve. In short, the project would have failed if Tom had anything to with it. Yet, if Tom was not involved it would have been impossible to finish the project.

This conundrum did not worry Bob at all. He told me he had figured out how to deal with Tom. I was expecting a few warnings, plus a serious talk and a formal reprimand. Bob was simply too cunning to just do that. He told that he would promote Tom to management. He created a small temporary team with what he called “low performing” engineers for Tom to lead. I was able to guess the rest. He would use the promotion to get all the information out of Tom, promote him to an non performing group, then when times got though he would layoff everyone in that group including Tom. I was wrong on only one account, Bob already knew he would have to do cuts next quarter and was planning to lay off all these people, with the agreement of the VP that did not like Tom. Bob was scary in that way.

Everything went according to plan, Tom was elated with his promotion, gave up all the information, moved to the lead a group and was not an impediment to the project at all. I left after the architecture and project plan was finished. So, I did not witness the demise of Tom. Later I heard that Tom's group was laid off.

The moral of the story is, do not hoard information, don't mess with people related to renaissance Florence royalty, and the only way to get ahead is to make sure others can do your job. Why do  you think Tom was in the same position for over 20 years?

The story of Jennifer

Jennifer was a great manager at NN Corporation. She delivered complex technical projects on time. She understood the scope, time, cost trade offs. Her employees respected her. She rose from an engineering position to a Director position in five years. He was the youngest Director in NN. Jennifer's only Achilles heel was her propensity to intrigue. She just loved to have secrets. She used secrets to cement trust between her and other managers. She would share some information to create relationships. She did the same with her employees. She would tell employees she wanted to build rapport with about future company plans, while she kept other employees out of the loop. Secrets and information was how she rewarded people. Information was her currency.

Jennifer lived in a “need to know world.” Her question always was “What is the least amount of information an employee needs to perform a job?” She actually believed that an employee was better off in the dark, since he or she “could not get the whole context in the current position.” Jennifer managed by controlling the information flow.

Jennifer hated for other departments to find out about her plans. She was clear on the relationship that her engineers should have with the sales team, don't tell them anything. She thought that outside opinions and interests will simply wreck her tightly managed projects. What happened next was obvious, the engineers she did not share her plans with, usually got mad and kept everyone else in the company informed about the status of their work. This irked Jennifer.

Jennifer did not like to stop ideas or projects for lack of consensus or buy in. If she couldn't sell an idea to her peers, she would still implement it and try to get what she wanted with intrigue. That was the reason behind her obsession with information control. She thought that if she could only control who knew what when, and then present everyone with finished projects she would be able to push her agenda. Instead all she got was leaky engineers and peers that did not trust her.