Desired Traits for a Software Executive
After working with a few technology executives, I've formed a few opinions about what traits are desired.
An Understanding of Software
I've built software at a lot of companies. When the executive level of the company is dominated by executives who don't understand software, the net result is that the company doesn't understand how to build software.
This has a number of potential side effects:
- Unable to Make Tradeoffs: The business is unable to make appropriate decisions in the tradeoffs that are a daily part of building software. Is this release date more important than minor quality issues? Is this blocking defect more important than your scheduled release? Is fixing this issue you've discovered a higher priority than feature X?
- Management by Star Trek: Management decisions are made by people who think that Star Trek is a good model for technology management. "The features you've asked for will take thirty days to build." "Well, you've got ten days!"
- Software is Predictable: The business believes that developing software is a mechanistic, predictable task, and does not react well to the inevitable, that requirements are not clear, that implementation sometimes brings up issues that weren't clear in advance, that we mave to make the kinds of tradeoffs described above.
- Emphasis on the Visible: The business puts more emphasis on the visible aspects of software than the invisible ones. "You're not done? But I was playing with the prototype a month ago! What's taking so long?"
A Hands-Off Approach
Of course, having development-savvy executives has its own set of concerns. An executive who has been involved in software development can have trouble keeping his or her hands off the process now that they've moved on up.
This can lead to:
- Micromanagement: Having been involved in the detailed decisions of building software in the past, an executive may want to continue that involvement, even though he or she doesn't have the time to be involved day by day and stay in touch with all the information that leads to those decisions. This can result in what feels like arbitary decisions being made seemingly at random.
- Technology Zealotry: Technologists often have favorite technologies. Some have difficulty separating their preferences from merit. When those technologists join the executive, they may try and influence or override technology decisions arbitrarily.
- Leading by Design: It's not uncommon for more senior members of a development team to be more involved in the architecture and design of a software platform than junior members. This means that someone who has moved up through software development to executive may be used to leading software teams through architecture and design metaphors. Unfortunately, like micromanagement, this may be done without the time and detailed understanding that project team members have to dedicate to this task, resulting in poor design decisions.
So, in a technology executive, I'm looking for someone who knows how to code, but is willing not to code.
Do your company's executive team understand software? What traits have you found desirable?
Labels:
business,
development,
leadership,
management,
software
5 comments:
*wince*
Well, at least I know what category I belonged to at the time :)
Well, if if makes you feel any better, I wasn't using you as the template for either side here; I hadn't even pushed you into either slot.
Looking back on Medium One, I'm not sure how strongly this advice applies to a company of that size, at least in the early years.
I suspect that in those years, you would have had the time to stay involved if you were involved. So even if you chose to be directly involved in project decisions, you wouldn't fly in, make a decision, then not be around for the impact.
You were certainly interested in specific technologies, but I don't recall you ignoring arguments of merit. You tended to persuade, rather than issue an edict, IIRC.
And finally, you tended to be pretty hands-off on detailed design, so of these three areas, I think you did pretty well. Which isn't to say that you're perfect, I'm sure you had your own set of flaws, but I'm not sure if these were them.
As far as Medium One goes, I might argue that we had more troubles with a lack of understanding of software at the top. And my first instinct would be that that wasn't your doing either.
I'd say I didn't know enough real software development at the time, and didn't nurture those in a position to carry that torch well enough. Hiring could have been better in a couple of areas.
At the top, I think there was just a bit of Canadian timidity; we needed a smidge more aggressiveness and willingness to toot our own horn. That would be disputed I'm sure.
At any rate, we were good, and I'm still really proud of some of our projects. And the team. We all had a fair bit to learn still, but what a group of people.
The fact is, I've seen multiples of both those examples and I'd have to say the ones that don't know anything are far more damaging than the ones that are savvy.
Many times, I've been on a team where the executive knew quite a bit (even one place where the CEO did the 'prototype' that went to production, which we finally phased out in parts) but even when they have been at their worst, it was no match for the times that the executive in charge of technology didn't know enough.
The times it's been close is when the savvy executives knew what something would take, but ignored it for business reasons. *waves to BB and MR*
Matty
The damage-level in my past experience has seemed close to equal (although I admit, I probably still prefer having someone in the executive team who understands software well).
It's a very different feel, but the end results haven't been radically different for me so far.
Post a Comment