Being Valuable

So, I said earlier that tech people shouldn’t have to negotiate for their salaries. Some of you took this the wrong way. It is not validation for you just sitting in your cube, doing your job, and not paying any attention to the company around you. That’s not good. You should not be completely ignorant of the business side of the house.

Let’s go through the basics here. You are working at a job. Your employers employ you. They pay you a salary. They pay you this salary because you do something that they consider useful. “Useful” generally means “makes money for them”. There may be a fairly indirect path to it, but what you do ultimately brings money in the door. Your usefulness to them is measured by how much money that is. Your perceived usefulness also depends on how visible the connection is between your work and money coming in.

This is why sales people make so much more than programmers. Their work is directly tied to money coming in. The sales guy can say, “I made X in sales this month.” You can argue that because you’re a really good programmer, it’s easy for the sales guys to sell your work. You can argue that the clever work you did six months ago has resulted in a better product, and increased sales now. But that’s very hand-wavey. It’s hard to put dollar figures on that.

There are two things you can do to increase your perceived usefulness. You can publicise your accomplishments, strengthening in the minds of your bosses the connection between your work and money coming in. You can also focus your work on things that make (or save) the company money. Both of these require understanding at least a bit about the business side of things.

Let’s say you’re a sysadmin (because if you aren’t, you probably know one), and you implemented an automated patch management system. Well, that sure made your life easier, and gave you more time for your other work (‘cuz there’s no end of that). And it’s a much more scalable solution, to boot. But how do you sell that to your boss?

Your boss thinks in terms of money. It’s not that he’s inhumane or clueless, it’s just that money is how you measure things. People and equipment are manifestations of money. You are a person, and your time costs them money. Therefore things that save you time save him money. Now the hard part, the maddeningly imprecise part, is figuring out how much.

In this example, you’ll have to have some idea how much time you used to spend patching machines. Guess - you can preface your report with, “According to our estimates…” Say you used to spend 3 hours a week patching machines, it took you a week (40 hours) to set up the system, and now you only have to spend 5 minutes a day on it. So your system “cut patch management staffing requirements by 85%” and will “earn back its initial investment” after about 4 months. Yes, that’s management-speak, but “automated a bunch of stuff” is meaningless to anyone outside of the tech staff. You have to translate it - you have to explain the business impact of what you’re doing.

Note that this cuts both ways. If you only used to spend half an hour a week patching boxes, and it took you a month to set up the system, you’ll have a hell of a time explaining that. Ultimately, you need to learn to do the math up front.

So now what do you do with your new-found spare time? Make yourself useful. First, start learning the bigger picture. Learn more about why you do what you do, and then why your group does what it does. Then start thinking about how that might change, or how they should change. Research new tools and techniques you could use - not just “cool” stuff, but things that will help you do your job better. Learn to apply that business logic.

You can also learn more about the other parts of your company, how and why they do what they do. First off, this is just interesting, like exploring a new world or some weird parallel universe. But there may also be things you can do to help them out. I’m not talking about doing their work for them; I’m talking about situations where you say, “Hey, we could write a tool to do that,” or “Don’t you have a database to track all that?” - situations where a little work by you could save them a lot of time and trouble. You’d be amazed at how much tedious, repetitive crap other people put up with in their work - things that programmers would find some way to automate.

At one job, we had a graphic artist who got stuck doing a monthly update of a web page from a PDF file. It was table after table of financial data. She opened up the PDF file in one window, the HTML in another, and copied it field by field, by hand. Click, drag, CTRL-C, click, CTRL-V. For every single number in every table. The first time she did it, it took her two full days. She griped about it to me, and I said, “that’s insane.” I spent the next day hacking together a couple of utilities and a perl script, and came up with something that parsed the PDF file and generated the web pages. It took about 5 seconds to run, and after that, she just had about 15 minutes of reviewing the pages and making special format tweaks. I made a new best friend that day.

You can earn a lot of good karma that way. It can also help break up the monotony of your regular work. You pick little projects and do them incrementally, on your own terms. You’ve got your “customer” right there, so you can try out all the XP and agile methodology stuff you’ve been reading about. And it can give you an arena for learning new skills or technology. A quick and simple web-based form entry application may be perfect for teaching yourself Ruby On Rails. A report generation tool may be a good way to brush up on your Perl.

When you’re done, make sure everyone knows. Tell your boss, and get him to talk to your new-found friends over in graphic design or accounting or wherever. It’s one thing to toot your own horn, but it another when people outside your department are singing your praises.