This question may be considered subjective (I got a warning) and be closed, but I will risk it, as I need some good advice/experience on this.
I read the following at the ‘About’ page of Fog Creek Software, the company that Joel Spolsky founded and is CEO of:
Back in the year 2000, the founders of Fog Creek, Joel Spolsky and
Michael Pryor, were having trouble finding a place to work where
programmers had decent working conditions and got an opportunity to do
great work, without bumbling, non-technical managers getting in the
way. Every high tech company claimed they wanted great programmers,
but they wouldn’t put their money where their mouth was.It started with the physical environment (with dozens of cubicles
jammed into a noisy, dark room, where the salespeople shouting on the
phone make it impossible for developers to concentrate). But it went
much deeper than that. Managers, terrified of change, treated any new
idea as a bizarre virus to be quarantined. Napoleon-complex junior
managers insisted that things be done exactly their way or you’re
fired. Corporate Furniture Police writhed in agony when anyone taped
up a movie poster in their cubicle. Disorganization was so rampant
that even if the ideas were good, it would have been impossible to
make a product out of them. Inexperienced managers practiced
hit-and-run management, issuing stern orders on exactly how to do
things without sticking around to see the farcical results of their
fiats.And worst of all, the MBA-types in charge thought that coding was a
support function, basically a fancy form of typing.
A blunt truth about most of today’s big software companies! Unfortunately not every developer is as gutsy (or lucky, may I say?) as Joel Spolsky! So my question is:
How best to work with such managers, keep them at bay and still deliver great work?
8
While developers are perceived to be ignorant of the business problems, less technical managers will look down on developers. Developers need to learn the business cases and start driving or suggesting improvements in business terms. Once developers and managers are speaking the same language, things get easier.
This is as much about an attitude change. Yes, there will always be ahem stubborn individuals in management. However, creating an “us and them” attitude reinforces this from both sides.
3
Option 1 : Become manager yourself and show everyone how to do things right. You will probably find out it is not as easy as many programmers think.
Option 2 : Leave and find better place to work. I believe there are many big and small companies that at least know of this problem and try to solve it. With varying degrees of success.
9
Your job is to deliver great work. Managing is a support function, its purpose is to enable you to deliver great work – act as a buffer between you and the clients & stakeholders & politics & sales etc, remove obstacles, abstract away everyday crap that prevents you from achieving your best.
Think of the memory manager. It’s not the boss that commands you and your programs, rather, it frees you from considering everything else that’s going on in the computer, letting you to concentrate on what’s essential for your program. That’s what Joel is writing about, that’s how managers ideally should work.
Not all managers are perfect, but nor are you. Nothing is. Unless things are totally crazy, then just suck it up and do the best you can, ignore what annoys you, and concentrate on your work. If you deliver great work, the managers will eventually respect and trust you more and let you work more in your way, once you’ve shown that you can deliver great work.
It’s okay to work in a 70 % perfect organization. If your situation is really bad, then switch your employer. But don’t give up too soon; the process of earning trust – convincing your managers and the organization of your abilities – can take years.
keep them at bay and still deliver great work
Good luck with that. I started my own company and that’s really all I can suggest.
Hopefully in situations like this, the engineers band together and if theres a real issue, either a technical project manager, a technical product manager, an architect or your own dev manager can understand the scope of your work, and keep nontechnical people out of your way.
But it doesnt always work that way. I worked for a huge tech company once where the manager WAS supposedly technical and when the devs complained about non stop meetings with 4 different project managers day in and day out his response was – OK so you want MORE meetings with project managers.
I feel that over the last 10 years technical “talent” as in actual talent has been incredibly marginalized by the business side of software organizations and this is a problem for us careerwise.
Managing high paid developers with low paid business people is like sending your kid sister to lion taming school, it just doesnt work.
But one solution I will definitely side against, is lying. I have seen really good developers try and ward off managers by filling them with stories that have no basis technically to get them to go away. Dont do this, if you do, you have sold your soul, and thats worse than having a crappy job.