I had a similar experience last year applying for a major technology company. Although I still lightly code in the devops sense (process automation) and to do typical management data analysis my day job is managing people, processes and crises.
If you have billion dollar trading systems and need a cool-headed guy who can talk to VPs or directors in one breath and SAs, DBAs, SAN, Network, etc guys in the next I'm your man.
I applied to head a global support organization, with teams in (from memory) North America, India and Asia Pacific. I'm pretty sure day-to-day would be a mix of employee career management, forward planning with my application development partners to make sure we were prepared capacity and training-wise to take on whatever's next, and crisis management of production issues and the like. Business as usual as they say.
Yet I found myself answering computational complexity questions about hash map insertions. To be fair, before I became quite so management-centric I've found plenty of badly performing code via the usual tools (dtrace, strace, thread dumps), and sql queries using analogous database tools, but at some point you have to rely on technical people to do their jobs.
Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?
> Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer?
An organization that does this is hiring stupidly. They have clearly demonstrated via interview that they don't understand the job to be done and/or how to determine that a candidate can do that job. Asking low-level technical questions is a terrible way to answer what I'll guess was the intended "question", something like:
Does this candidate understand the technology and work well enough to make executive decisions grounded in our organization's reality?
> at some point you have to rely on technical people to do their jobs.
On one hand, I totally agree that technical tasks should be left to the technical people, preferably those who are actually working on the system. There's almost nothing worse than a manager trying to take technical decisions out of people's hands.
> Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?
On the other, I think people want to work for people they respect and to the extent that people respect technical chops that might be what they are screening for. Though the hash map question sounds like a soft ball, so it might be screening for a baseline of software competence.
I hear you about having enough technical ability to understand what's going on and make sensible decisions. Certainly in a role like that and the one I have now a mix of technical and positional authority are required.
But at what point does it become ludicrous? When your CIO is yelling "No, No! You have to enable the EPEL repo or you'll patch to the wrong version!"?
If you have billion dollar trading systems and need a cool-headed guy who can talk to VPs or directors in one breath and SAs, DBAs, SAN, Network, etc guys in the next I'm your man.
I applied to head a global support organization, with teams in (from memory) North America, India and Asia Pacific. I'm pretty sure day-to-day would be a mix of employee career management, forward planning with my application development partners to make sure we were prepared capacity and training-wise to take on whatever's next, and crisis management of production issues and the like. Business as usual as they say.
Yet I found myself answering computational complexity questions about hash map insertions. To be fair, before I became quite so management-centric I've found plenty of badly performing code via the usual tools (dtrace, strace, thread dumps), and sql queries using analogous database tools, but at some point you have to rely on technical people to do their jobs.
Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I don't really need to be under the hood in the code any longer? Or am I clueless?