Modern Middle Manager
Primarily my musings on the practical application of technology and management principles at a financial services company.
Change Your Mind?

Wednesday, January 03, 2007  

One of my favorite stories goes like this: after being given a very disturbing prognosis delivered in an offhand manner by a medical resident, a real doctor came in to examine my condition. He was far less flippant and weighed the risk of the resident's prognosis as highly unlikely. The resident, still eager to show off how intelligent he was, declared my condition to be the result of damage to a particular nerve. The response from the doctor was, "Are you sure?" The resident, slightly less confident, repeated his conjecture. Once again, the doctor stated, "Are you sure?" Even after years of management, I know when you're being given a second or third chance to get the right answer, so I helped the resident by saying, "Sounds like you need to change your answer." I rather enjoyed getting in that barb.

On Friday the 29th, I had a conversation with the senior manager of our biggest business unit (we'll call him BK for Big Kahuna) about how to approach his extremely important make-or-break the company and his career project for 2007. I gave him my perspective, which he initially found appealing. The following Tuesday I called him to find out if he had accepted my solution. The conversation went something like this:

Me: I was wondering if you made a decision on our approach to the Really Big Initiative.

BK: Yes, you were going to send me a recommendation.

Me: I was? {Note: This part should not have been voiced. Duh.}

BK: Yes.

Me: I thought I gave you my suggestion on Friday. {Note: See how I grow denser.}

BK: You need to factor in [thus and so].

Me: [Finally catching on.] I will have my analysis and recommendation to you by Friday.

To recap: I made an practical, appealing suggestion on Friday that I thought was all but a done deal. On Tuesday, it was turned into "you are going to give me a recommendation." But I already had. That was my hint. And so I wrote the recommendation up, giving weight to the "thus and so." And he had the answer that affirmed the approach he already wanted me to take.

That is how office politics is done.

posted by Henry Jenkins | 1/03/2007 10:31:00 AM
(0) comments

Sunday, December 31, 2006  

Sunday morning before a flight to Paso Robles and my mind turns to...projects. Specifically, keeping the project stakeholders coordinated the business unit manager doesn't think anything's moving forward. Out of a portfolio of 12 projects, we have one project that suffers from substandard programming and will be moved to our offshore team. The remaining projects are either 1) in development or 2) awaiting the requirements phase, meaning that the project owners aren't writing a specification, they want the imaginary BSA that the IT department doesn't have available to write the spec. That's a shame and it holds up our projects. However, it also means we'll keep Orange County's job rate low. So we're procuring a body.

In the meantime, the business unit manager (and also my boss) thinks that someone needs to be in a position to coerce both the projects group (not a PMO, mind you...more an application development group) and the business unit product manager to "move things forward." So I may see the development of a project management office (PMO) that reports to me, or him, or someone else and partially runs my IT projects group. Or the IT project group may report to the product manager. Or to my boss, who would prefer to be more hands-on sometimes and less hands-on at other times. I smell a reorg coming (again). My empire has both grown and been sacked by the barbarians before, so I roll with it. In the long term, the Visigoths find that managing really isn't to their taste and doesn't accomplish what they desire: agility and speed to market without planning. I do not think that is a worthy target.

posted by Henry Jenkins | 12/31/2006 06:57:00 AM
(3) comments
Here's a Challenge for You...

Thursday, December 28, 2006  

The COO of the company says that he has a major initiative that will involve a great deal of software development. Without actually starting the design and specification process, he wants to hire more programmer (specifically, software developers located at a subsidiary in India). Do you:

1. Calmly explain that it is unlikely that we can hire the right number of people before we even know what is involved in the creation of this application / suite?

2. Say, "Yes, sir," and try hiring a half-dozen developers who very well may sit on their ass for weeks and leave out of sheer boredom before development begins?

3. Try to find another route, such as hiring a well-known offshore development firm to start the project, and then scale up the Indian subsidiary as phases are completed?

You decide!

posted by Henry Jenkins | 12/28/2006 08:19:00 PM
(0) comments
What Happened to 2006?

Wednesday, December 27, 2006  

This has been a tumultuous year for us. We've tackled multifactor authentication, established an offshore development group, reorganized the department, gained people, lost people and accomplished a few business initiatives along the way. I've made some people happy, frustrated others and finally proven once and for all that third party examiners are a cross between Homer Simpson and Satan. Homer Satan. That sounds about right.

On a personal note, I got married in April, became a private pilot in November and gained about 20 pounds during the course of this year. I look forward to making that disappear in 2007.

posted by Henry Jenkins | 12/27/2006 07:28:00 AM
(0) comments
Driving Desktop Operational Costs Down

Sunday, February 19, 2006  

What a droll title for a post. Next week my group is working on two intertwined projects in an effort to drive down our ongoing operational costs. I've mentioned one guiding principal in doing that -- server-based computing. We use Citrix's MetaFrame XP product at this time, presenting the entire desktop on a Citrix server. Our proof of concept over the first part next week will encompass the following changes:

1. Moving to the enterprise version of Presentation Server 4.0.
2. Incorporating the Citrix Access Gateway to provide an SSL VPN and customize the kind of access that can be had to internal network resources.

The goals will be to gain the advantages of PS 4.0 (better printing, CPU usage control, server load balancing at the software level) with the addition of the CAG's security options. I forsee existing costs going down because we eliminate the #1 and #2 problems our end-users have with the existing platforms (i.e., printing issues and the follow-me desktop). In addition, we will be able to provide a secure method to publish certain applications for clients that require a highly secure connection, slashing the necessity to maintain private networks to those client sites.

The second proof of concept going on next week is a test of Softricity's SoftGrid. We will be determining if software virtualization is all it's cracked up to be. If so, imagine no need to image desktops anymore. Take them out of the box from your favorite provider, patch, install your favorite client antivirus/firewall software, join the domain. That's it. This dovetails the server-based computing initiative by virtualizing the software running under Metaframe. Set up the basic Citrix server, join the farm & domain, publish the virtual apps for whomever logs in. Done. No more software conflicts. Disaster recovery procedures practically write themselves, similar to the ease of recovery we've experienced from virtualizing our servers. I'm sure that the devil is in the details (i.e., actually "sequencing" the application to virtualize it). However, if it is a a one-time major pain followed by the occasional patch, I can't see it will be worse than the current software deployment and patch management nightmare.

posted by Henry Jenkins | 2/19/2006 03:13:00 PM
(0) comments
Goals & Rants

Friday, January 06, 2006  

On Thursday I laid out the 30 and 90 day objectives for my staff. The good news is that none of them looked like deer caught in the headlights. The bad news is that I didn't get a lot of questions. There was a lot of nodding, which means I'll have a private follow up for the people who didn't want to talk in public. Management also means reading between the lines.

Ninety day objectives remind me of Optimize, a magazine that I have a love-hate relationship with. There's usually one article that I find very useful and the rest are just a waste of time. Maybe with all of this tagging and such, a group can smart tag the good articles so I don't have to waste my time looking for them. I want Cliff's Notes for every industry magazine with some kind of Usefulness rating from my peer group. That would be helpful.

posted by Henry Jenkins | 1/06/2006 04:19:00 PM
(0) comments
Microsoft IT Organization

Monday, January 02, 2006  

Looking for benchmarks I came across this page on Microsoft's IT organization. What caught my eye was two things:

1. Microsoft's organization is broken into two pretty standard groups, infrastructure and application development (internal IT services is basically infrastructure as far as I can tell). This is similar to the ideal division drawn up by Baschab & Piot in The Executive's Guide to Information Technology.

2. They rely heavily on contractors. That point doesn't sound as stupidly obvious as you might think. Yes, I am well aware of their use (and abuse) of contractors. However, I think I've missed something important over the years.

Once upon a time, I thought I'd never use contractors because I believed that you should hire employees, mold them the way you wanted to fit the corporate culture, invest time and energy into them and nuture them into great corporate citizens. That sounds great (OK, it sound like naive horse manure) but it doesn't necessarily work out. What happens when project demand is not smooth? What about keeping up the employee's technology skills while still getting the work done?

The answer may lie in exploring contract labor. For the first eight years with my current company, we institutionally feared outsourcing and contracting. Two years ago we broke the outsourcing fear and have outsourced/hosted several important support applications. Last year we used offshore development for the first time, implementing a software project that paid for itself before it was implemented in its entirety. This year will be the year we break the contracting taboo. I have a small cadre of very bright people working for me who are just not able to absorb any more training without significantly impacting their ability to execute. I do not believe that you use smart people by working them to death -- the more people work 50-70 hours per week, the stupider they get. So it's time to supplement our labor pool.

As I see it, contracted labor can be used in two ways -- to augment existing staff and on a per-project basis. I have need for both. The downside of contract labor is that their accumulated knowledge walks off the job probably every 6-24 months as a new person rotates in. The upside is that a contractor can be dismissed for any reason without turning the department inside-out if he/she turns into a problem. Bad employees are time sinks and it takes a long time to get marginal employees out.

posted by Henry Jenkins | 1/02/2006 07:34:00 PM
(0) comments
Spending Metrics  

I started in on a book called "The Professional Services Bible" by John Baschab and Jon Piot. Messrs. Baschab and Piot have written yet another tome weighing in at 500+ pages. The virtue of their books is that they don't waste time with appetizers before serving the meaty topics. Within the first three chapters they have given the outline for the book and delved into professional services organization, management and benchmarking. Much of the book looks like it can be applied to any business organization.

Benchmarking is one such chapter. Some benchmarks may not be indicative of company success and should be viewed with a dim eye according to Christopher Koch of CIO Magazine. On the other hand, where do you start?

Our company took 3 metrics from the META Group (now a part of Gartner). Those metrics are:
1. IT spending as a percentage of revenue (Koch's least favorite).
2. Ratio of IT support personnel to total employees.
3. IT spending per employee.

We have managed our company to within 10% of META group's banking industry average for #1 and #2, including operational costs (something Koch contends is not included in the revenue metric). #3 confounds me, because I'm consistently 20-30% over the benchmark. I assume it's because we're a small company leveraging a lot of technology. I believe it's because we leverage technology in a big way and senior management agrees. Part of my argument is showing the return for specific revenue-enhancing projects and how they've paid off in a short amount of time.

Looking around on Google, I'm hard pressed to find more (free) information on metrics. One article I came across from 2002 is from Baseline and includes several more metrics.

Koch is correct in that picking benchmarks for the right reason is important and that trust should not be placed in a number for its own sake. I remember hearing Zig Ziglar say once that you will manage your organization to whatever you're measuring. Ultimately I (and the organization) need to ask whether the IT department is worth the 1/13th of every dollar of revenue we get. If we don't contribute more to the bottom line by helping to bring in more money, peel away expenses or mitigate appropriate business risk then we're a sinkhole.

posted by Henry Jenkins | 1/02/2006 06:28:00 PM
(3) comments
the author
open source