Blog by Sumana Harihareswara, Changeset founder
Two Tips On Convincing Managers & Executives To Invest In Your Technology Projects
Hi, reader. I wrote this in 2010 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.
From a years-old job-advice email to a friend. The sort of knowledge that Rachel Chalmers or Karl Fogel finds obvious but that some of us still haven't quite integrated into our day-to-day communications and long-term strategies:
You need to be able to express your suggestions to your boss in terms of financial incentives and losses.
A few things I've picked up during a recent class in "Technology in the Business Environment" (when I was doing the master's in tech management at Columbia):
I) Management focuses on the things that drive the organization (directly making money), and tends to ignore things that support the organization's drivers. If you're directly making money, lowering the cost of producing the product/service, increasing management's control, increasing product quality, increasing the knowledge available to an important decisonmaker, or improving customer service, you can describe your work as a driver. Can you find a way to describe your high-level TODOs in one of those ways?
II) Here's a model of management's priorities for technology investment. The higher up this list you can get, the more attention you can grab from management.
- Revenue. Guaranteeing a financial return. Not just cutting costs, but actually MAKING money from customers.
- Increasing scarce productivity. If the demand for a product exceeds the supply, then this is attractive. [1 and 2 indicate that the company is growing, and interested in the future. A good sign!]
- Cutting costs. More popular in a struggling company.
- Competitive advantage -- this means the company is already behind its competitors and has lost first-mover advantage.
- Tech for the sake of tech -- pizzazz and leadership.
So can you explain "creating system-monitoring scripts, streamlining processes, and installing and configuring new programs on the server" so that they're way up on that list?
Let's say a system-monitoring script would take your service from 95% uptime to 99.9% uptime. That's #2. Maybe one of the high-level tasks you do will make it possible for your company to serve twenty units instead of fifteen (#2) or even start a whole new line of products (#1). But "It's more elegant/technically correct" is #5.
I welcome comments, tips, examples, disagreement, and cake.
Comments
zanko
http://daemontux.org
24 Aug 2010, 6:27 a.m.
Dan Percival
http://www.kith.org/poi/journal
25 Aug 2010, 16:51 p.m.
So freaking depressing: basic best practices -- security, backup, not sharing your password with your underlings as a way of delegating work -- can't be spun to be better than #3, and even then, it's an invisible "what if" cost. Heck, they don't even make #5: nothing snazzy or forward-thinking about them.
And yet, I don't disagree.
Sumana
27 Aug 2010, 7:38 a.m.
zanko: From an engineer's perspective, yes, it would be nice if the managers of a company pandered more to the engineers' preferences regarding technical purity and progress. But it is nearly tautological to say that if a profit-seeking corporation does not make money, it goes out of business, so that has to be the top priority. Nonprofits and government agencies have other missions but in those cases those missions are the drivers and technology is just a supporter.
There are organizations where it's engineers all the way down (and up). And in those organizations you'll see more alignment between the developers' priorities and preferences and management's. But, arguably, the reason some engineers work for other people instead of being independent service providers is that those other people provide an interface to the marketplace, translating customer requirements into technical specs and helping potential users understand what's awesome about what you just built, and take a cut of the proceeds. The honest middleman in a competitive market always has to care more about what customers need/want than about what the vendor thinks would be neat.
Dan: It's tough to hear, and I'm glad you find the taxonomy useful. I believe it's descriptive rather than immediately prescriptive, a model to explain what the suits care about.
This is a huge topic, but I think that you can phrase risk mitigation in terms of "increasing scarce productivity," and that part of one's job is to make invisible costs and benefits visible so others know about them and can act appropriately. This sometimes means we need to make really rough statistical estimates so we can throw some diagrams and charts on a board, or explain the narrative of risk mitigation like we're singing "Amazing Grace." This translation from engineering parlance into the language of money and organizational resources is not just about words, but about priorities, strategic long-term thinking, empathy, and -- it sounds so banal -- a change in perspective.
Dan Percival
http://www.kith.org/poi/journal
27 Aug 2010, 12:58 p.m.
Huh. I have to think hard about this, since I'm going to have a few critical "selling something to the money people" moments in the not-too-distant future.
I think I'm getting tripped up on understanding "increasing scarce productivity" means. Could you expand on that, particularly in terms of risk mitigation or collaborative work?
Dan Percival
http://www.kith.org/poi/journal
27 Aug 2010, 13:00 p.m.
(ps - still suppressing chuckles in my cubicle over "explain the narrative of risk mitigation like we're singing 'Amazing Grace.'")
Elisa
la_luna_llena.livejournal.com
27 Aug 2010, 18:55 p.m.
Hey, do you have tips on being female in IT?
I have had the experience of walking into a room for an interview and having the hiring manager frown immediately when he saw who I was: a woman in a sea of men.
I have also been at tech conferences where some people are cool, but others look right through me as they hand out their cards to Barbie lookalikes and other men.
I know that I'm as skilled and knowledgeable as many of these men, but they dismiss me or assume I'm a girlfriend who's been brought along for the ride.
Sumana
28 Aug 2010, 10:31 a.m.
Dan, Elisa, you're both asking interesting questions that I wish I had time to answer; in a few hours I get on a plane.
Elisa, my hasty reply is that you should check out the Geek Feminism wiki and Systers. There is discrimination against women in IT and these communities are among the several working to fight it and help you deal with it.
Dan, I figure that any time you can say "it would be good if we had more $foo and my proposed step would help us increase it," that's increasing scarce productivity. So decreasing downtime and increasing service to internal users would count. Try to think from the manager's perspective -- what are her pain points? What are the bottlenecks in your organization? What's directly costing them opportunities or productivity?
Too bad managers care so few of #5...
I personnaly have worked in a company where developpers where telling management they were working on #1/#4 (adding features) when in fact this was finished, so they had time to work on #5 ^^.