It's amusing how quickly programmers-turned-managers forget their roots. Look here:
I used to get a huge feeling of satisfaction from a weekend
spent working on a clever hack. I would spend serious
effort making something run twice as quickly, even when
there wasn't a problem with how quickly it was running in
the first place. Meeting those types of challenges was my
primary motivator.
This is how you were motivated before they gave you a manager hat. This is how the people you manage think. And I wager that this mindset isn't wrong by any stretch of the imagination - as a programmer, I love working around people who program for the sake of programming, who find fun and satisfaction in writing code.
I don't mean to suggest the perception of code as just one of many means to an end is wrong either; it actually makes perfect business sense. It's something managers need to understand. But in your "enlightenment" you've forgotten what made you tick in the first place - how do you translate your new business-value-driven mindset to something the people under you (who don't have that mindset) can appreciate? Hint: it's not by telling them their cool hacks are useless. And we wonder why programmers distrust management.
Actually, let me put this another way... back in the original dotcom era, I worked at a startup that decided to write a BIOS. With the amount of hardware we'd be selling, it'd save a million dollars! Well worth six man-months or so of work, right? WRONG. That was six man-months of critical programmer time when the time and money was running out, and all we learned was that we couldn't do it in a 512k PROM (not with our design anyway), and upgrading to a 1mb PROM would have cost more than a license from Phoenix for their BIOS.
That's what happens when you let the inmates run the asylum.
Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. We thought we were solving a cost-of-production problem for a fully scaled business. That wasn't the problem. The PROBLEM was NOT DYING. And that meant getting a working product out the door as quickly as possible, even if it cost more.
Programmers are fools, for the most part. They don't understand what problem they're really trying to solve.
That's a little harsh. I think it's fairer to say that they often don't have insight into the wider strategic objectives of the company, and that's as much a company failing as anything. I'm now a firm believer in sharing e.g. revenue numbers with everyone in the company and explaining why they're important - people are much more willing to accept things when they understand the wider picture.
It's not just managers vs. coders. It's also experienced coders vs. novices.
You get tired of writing a pile of code that solves the problem the wrong way, so after 10 or so iterations of un-appreciated or un-used code, you learn to try to look at the big picture instead of always trying to isolate the problem into a fun programming exercise.
There is a management lesson here in being sure the right people are working on the right stuff. If you may need process improvement to generate the nightly reports by the next morning, don't send someone who loves to re-implement scripts in C. Or, if you're the person who loves to re-implement scripts in C, realize that your prospects may be limited.
> Hint: it's not by telling them their cool hacks are useless.
No, of course not. It's by showing/encouraging more ways to hack a solution. Writing code is one of many tools that can be used, and as the adage goes: "if the only tool you have is a hammer, everything looks like a nail." You can't pick the best tool for the job if you only want to use one tool.
I don't mean to suggest the perception of code as just one of many means to an end is wrong either; it actually makes perfect business sense. It's something managers need to understand. But in your "enlightenment" you've forgotten what made you tick in the first place - how do you translate your new business-value-driven mindset to something the people under you (who don't have that mindset) can appreciate? Hint: it's not by telling them their cool hacks are useless. And we wonder why programmers distrust management.