On my way up through the ranks, one thing never changed – I always thought I knew more than my immediate bosses did.
Often over beer, and always around performance review/salary adjustment time, I’d grouch about how out of touch the old guys were (at that time, middle managers in their mid-thirties), and how much better things would be if I, who didn’t yet have any management experience, were running the show.
Better that is, until someone pointed out that those old guy managers could have been thinking the same thing when they were my age. Damn.
And then that someone made it worse by pointing out that, generally speaking, management doesn’t get to become management by accident, that the reason these people got to be where they are is because they’re able to do certain things, see certain things, that others, including me, couldn’t.
As the years passed, the “my management doesn’t understand me” rant lost all its steam. Especially when I became one of ’em.
With a tip of the hat to all my old managers (I’d like to go on record as saying that I respected all of you…there: that should keep my phone from ringing), I go to a font of great wisdom on this stuff, otherwise known as my good friend Darcy Vaughan. Vaughan runs a substantial software development shop out of Denver, and unlike me, he continues to work with technical people every day.
Vaughan and I got to talking recently about the things we wished the technical people who worked with us understood, things that could really help make them better managers when they eventually make the leap.
“Vaughan” I said, “I need inspiration – give me three things you wish technical people understood better.” He said he’d think about it for a while (you get that thoughtful thing going on with good senior managers), and when he got back to me, here’s what he had to say:
First, as self-evident as it might seem, developers really need to know the business they’re in. It’s not good enough for them to just know how to program, even if they’re really good at it. There are lots of programmers out there with good technical skills. The solutions we’re after always involve tradeoffs – scope versus speed, functional richness versus cost – and a programmer can’t possibly understand how to make those tradeoffs if they don’t know what’s driving our business. We’ll never ask a developer to lead a team unless they understand the bigger business picture. A good technical programmer may be able to help another programmer with their code, but they can’t help us make decisions on what is really important to the commercial success of the product.
They get to know this stuff by getting to know our clients better, so any time they have an opportunity to listen to clients, I encourage them to take it, knowing they’ll learn more about keeping management happy in 60 minutes spent that way than they will in a month of internal company or technical meetings.
Second, developers should understand the value in being the “open source movement” within their company, the value in being the leader in sharing information. They need to recognize that knowledge is not something to be hoarded – that they’re not more valuable when they’re the only one who knows how to do something, that they’re more valuable when they can leverage what they know and help others to do the same.
Finally, developers should understand the benefits in being curious and proactive – curious about the trade, curious about the business they’re in, curious about new technologies and proactive about bringing anything they learn to our attention. They need to keep in mind that we’re most interested in how that learning can be used to make things better for our customers. Being curious should mean a willingness to learn independently. There’s a wealth of information out there that doesn’t involve sitting in a classroom. If a developer really needs to attend a course, I suggest they learn something about the subject on their own before they go, and then show us how what they propose to learn might solve a business problem we’re wrestling with. Better yet, play with the technology first and build us a prototype – show the initiative that gives us the confidence to invest in your training, and then ask to take the course.
A few words from a wise man who doesn’t even have any grey hair yet.
If I haven’t already wished you the best for 2003, Happy New Year.
Hanley is an IS professional in Calgary. He can be reached firstname.lastname@example.org.