A profit center is a unit of an organization that generates both revenue and expenses. Its goal is to have revenue exceed expenses.  A cost center is a unit of an organization that generates expenses and has no responsibility for generating revenue. Its goal is to adhere to expense budgets. - AllBusiness Business Glossary

Not much wiggle room in that definition which is why I never trusted people who start blog posts by quoting dictionaries to make their points.  Ahem, anyway, IT is a cost center in the hearts and minds of many excellent business people that I have worked with over the years.  This has not changed much and the reason is thanks partially to and adherence to the canonical meaning of revenue and expenses that accounting teaches today.  I have a different view of IT which comes from my own experiences with departmental revenue and expenses.  I believe that IT can generate departmental “revenue” for a non-tech focused company by allowing that company to reduce expenses and increase sales.  Let me explain by revisiting our definitions.

Here is my modified definition of cost center.  A cost center is a unit of organization who’s costs of operation are not offset by the combination of both revenue and savings allocated to the organization.  Revenue allocation is something I will discuss in the next post, so lets table it for now.  Savings allocation sounds fishy, I know, but hear me out.  All departments have an operations cost associated with them which covers the salary overhead, equipment, training, etc.  For a fictitious department X, lets say operating costs are 100K.  Now, believe it or not, there are whole companies dedicated to doing from the outside what department X does for you internally.  They represent the real costs of having a need but not filling that need internally.  Lets say company Y can do what department X does for 75K.  Now, department X is a cost center because it has no savings for the company.  Fact is, this company may be looking at calling company Y in this case.

Now here comes IT to the rescue because they are able to write an application that drops the cost of operations of department X to 70K.  IT looks like a hero, department X is back in black and the company can keep 30K more next quarter thanks to automation.  This is what IT can bring to the table, the ability to find labor saving technology, processes, systems, services and solutions that make internal departments cheaper to operate.  Since in our definition of cost center we dealt with ‘allocated’ values, we can now see that 30K in savings is allocated to IT as way of saying ‘this is money that we saved because we have invested in our IT department’ .  The beauty of an good internal IT department is that the automation options exist throughout the company in all departments.  Savings allocations, even when conservatively estimated, can add up to huge sums in favor of classifying an IT department as a profit center.

Photo by uberculture

I’m tired of talking about how great I am.  What about you, what do you think of me?

There may have been a point in time when someone understood all that there was to understand about computers.  Early on there may have been one person who could stand above his fellow scientists and claim to be the authority on everything in this young field.  Where wizards stay up late makes a good case for a few individuals who may have filled that natural desire we have for an overall authority on a subject.  Yet those men, great scientists and tremendous minds in an unproven field of study, were some of the most humble ambassadors of technology we will likely ever see.

Today we have no overall authorities.  No normal person can hope to represent enough deep expertise to be considered an expert in more than one specialty.  Exceptional people may be able to handle two or three fields before being overwhelmed by the fire hose of information needed to keep up.  Hollywood has it wrong, again, about smart people in technology because there are no generalists out there that know everything.  Computers is similar to any other complex system like medicine, law, scientific research and finance.  It demands that you specialize to do be considered an expert.  (This may also be why I like House as a show but have problems with a plot device that pretends there are doctors that can ever know everything.)  Anyone who either pretends to be an expert on the whole of technology or really has convinced themselves that they are will be doomed to huge management failures.

Pete Johnson Chief Architect at HP and a guy who clearly knows what he is doing around a computer wrote up good article on Dzone about why programmers hate working for Software Architects.  Pete’s experiences run parallel to my own as a manager of programmers and his first point sums up my advice to anyone who wants to lead a programmer.

• Be humble
• Ask your people for advice on subjects you don’t know.
• Make it public knowledge that you are the least important person in the room.
• Stand back and let them shine before your customers, but stand in front of them to take blame.
• Programmers can sniff out BS.  Honestly admit when you’re unsure of a direction.
• Keep them informed and let them know when you are giving fact and when its your opinion
• Ask only what you would be willing to do yourself.  Prove it by doing it occasionally for them
• Keep a diverse RSS list and forward on good information to experts in your group
• Be humble

What’s on your list?

If you liked this article, consider subscribing to this blog via email or RSS. Also, consider subscribing to have our free weekly newsletter sent to your email inbox.

Photo attributed to SuperFantastic on Flickr CC

Yesterday morning, Google made a little announcement.  You may have heard of it already.  Tuesday’s blog reader was like a million tiny voices all calling out the same word.  That cacophony continued on through today and I suspect it will remain as such throughout the month, or at least until Apple releases something shiny.  So much has been made of this small release, that I have vowed not to refer to it by name in this post.

The internets chattier apologists are already manuvering into position to hand Google the gold-painted plastic trophy of ‘Best Browser Ever‘ despite its current 0% adoption share, buggy Javascript, or total lack of support for my fruit-themed notebook.  I think this is a mistake.

Remember how quick we were to jump over to Microsoft’s camp when they announced IE would free us from paying for a browser?  Or when Firefox shook us out of that complacent stupor, slapped our faces and told us we didn’t need 10 windows open at once and that hey, we might like these super useful user created plugins?

Google isn’t putting out this reflective metallic bauble because it want’s to convert the masses.  They know they cannot see into the future, so any effort to corner the browser market is likely effort in vain.  Overlooked in the hype was a message that I heard loud and clear - and it was coming from Google.  Somewhere around the discussion of open sourcing the software, they made a very strange statement.  ‘We want others to copy our ideas, improve them, do it better, and reinvent the internet for us all’.

If that is true, why make their own browser?  Why not simply put their mental might behind Firefox, which is fully open sourced and free to fork off?  I truly don’t know, though I suspect that is what they did.  Looking under the hood (or more accurately read under the press releases), much of the plumbing is changed.  Multi-process based instead of single process with rewritten javascript JIT compiler makes the app different from firefox as steam locomotion is from gas combustion.  Still, there are pieces that are coming from Mozilla and WebKit which makes this more of a reinterpretation than a reinvention.  WebKit is the JavaScript renderer used in Safari and iPhone, so I would suspect to see this also be adopted in Google’s mobile OS, Android, as well.

I can’t say that Google will not come out ahead of the pact with this mirror-like offering.  Once they get their sea legs they will have their half-tillion dollar geek cred behind them.  Even so, I can say is that no one should be calling this race over.  The brower wars are heating up again and only the gentle sob of your company’s web designer is heard above the blogging din to mark the occasion.  Hell, that ‘Best Browser Ever’ trophy was stolen anyway, years ago, by the Opera fanatics.  Rumor says it is buried somewhere in Norway.

Ruby on Rails

Business type people, cover your eyes for a sec. This one is for the web developers. Ok, so if you have not yet seen the Ruby on Rails screencast then the next fifteen minutes may change a few perceptions regarding web development. Take a look. Go on, I’ll wait. That little video has done more to poke the fire of web controversy than any debate since the IE v Netscape browser wars. It made big waves with people looking for alternatives from Microsoft and Sun. From the other side of the yard, php and perl programmers were impressed by the full service nature of the framework. Testing, DB connectivity, MVC, AJAX, even web services were all rolled into the system in the beginning, not bolted on afterward. It hit a sweet spot in the community at just the right time.

The business world (thats you guys with your eyes closed) appreciated the quick application turnaround and the low low price. Suddenly simple applications could be modeled in hours and up and running in a day. The quality of those early apps were rough, but the quick turnaround gave the stakeholders something tangible to see and experience. I have used Rails in many applications in my day job and I have reaped the benefits both as a department head and as a programmer. We have been trusting Ruby on Rails more and more for critical applications both internally and out in the wild.

Here are some misconceptions about Rails

1. Ruby is too new to trust your applications to: Ruby is not a new language. Ruby is almost old as Perl, having started in Japan over 10 years ago. This means it is a well tested, fully proven language to develop in. The Rails hoopla has allowed for many authors to fully explore ruby and rails in book after book. The language is a very safe bet at the moment, possibly a better reputation at the moment than Java at least in the web community.
2. Hosting rails applications is impossible: I will say that hosting rails is tricky, but no more so than PHP, Python, Perl or Java. The hardest part is overcoming the knowledge gap between what is assumed by instruction writers and what you truly understand. That just takes a bit of time, a good book, or a good consultant. Since its true that difficulty breeds opportunity, the safest solution is to host with a pro. I will be interviewing the CEO of EngineYard in an up-coming segment.
3. Rails wont Scale: If someone tells you not to use Rails because you cannot scale up the site to large number of users, thank them for their assistance and walk away from the conversation. It’s a troll bait argument which has no defendable position either for or against. Sure, there are large apps that run rails. There are also large apps that run rails and have success issues. The real kernel of the argument is ‘Do you know enough to make a certifiably scalable application in language X instead?’ If not, then just don’t worry about it. For the non expert, rails has just as many pit falls as php, java, perl, python, asp, .net, etc. With the exception of Microsoft, Rails tries just about the hardest to avoid those pitfalls for new users. Arguments can be made that they succeed more often than Redmond, too. So if your site’s traffic is modest at best, don’t let scaling scare ya. When your site gets huge, you can still keep your site in ruby.
4. The Rails community has a Our Way is the Only Way attitude: Yep, can’t really argue with this one. The leadership of the Ruby on Rails group is tight knit and self facing. They are solving problems that they see in ways that they believe is best. Nothing wrong with this and actually it is a perfect model for highly focused software design. One of the traps of programming languages and applications is the human tendency to compromise. Compromise leads to more than one way to achieve a goal, which always leads to complexity, confusion and non conformity in implementation. Rails skirts this issue by just saying ‘Do it our way’. This isn’t a problem for 99.9% of the web community so it really is overplayed in the media. If you want Rails to do something it doesn’t do, you are free to fork the source code and make your own version.