31–40 of 58 posts
We usually refer ours to a Dilbert strip that defines the exact problem. Fortunately he has a sense of humor :)
A comment on the first comment of the article: "This last part reminds me of something recently. Because management needs to feel like they have control over what's going on, as a technical person, you should do the right thing, but only 90% when you show it to them and make the 10% that is miss quite obvious. The reason is so that when you present it to them, they can point out the missing piece of the project and f…
These are no more 'games and tricks' than having to expend more energy walking uphill than downhill is a game or trick. I am horrible at inter-office politics. I want so badly for things to be "efficient" - but it is always efficient for me. My boss has me print hard copies of email and put them in a physical folder AND has me copy the email as a PDF and sstore it in a sub folder of the project folder. Mind-blowingly…
Accommodation is a good idea, game-playing may work in the short run, but it does not build long-term trust.
Good article. The part about figuring out your boss' motivations is the best part. This is really the key to any interaction with another human being whether we're talking about speaking to an overseas technical support person, your boss, your mom, or your partner. 0. Realize your non-technical boss isn't some cartoonish, mustache-twirling villian with a fetish for poor technical solutions. He or she is picking them…
A comment on the first comment of the article: "This last part reminds me of something recently. Because management needs to feel like they have control over what's going on, as a technical person, you should do the right thing, but only 90% when you show it to them and make the 10% that is miss quite obvious. The reason is so that when you present it to them, they can point out the missing piece of the project and f…
These are no more 'games and tricks' than having to expend more energy walking uphill than downhill is a game or trick. I am horrible at inter-office politics. I want so badly for things to be "efficient" - but it is always efficient for me. My boss has me print hard copies of email and put them in a physical folder AND has me copy the email as a PDF and sstore it in a sub folder of the project folder. Mind-blowingly…
And in future you have to remember the real battle is external, not internal.
One of the most common mistakes most people make when they're evaluating someone else's actions is to refuse to give them the benefit of the doubt and to overly assign negative drivers.
Assuming that managers are power hungry and desperate to be in control is the equivalent of assuming that the only reason a programmer would select a particular technology is that it would look good on their resume. Both of those can be true, but far more commonly they're not.
Neither managers nor programmers are generally stupid and they're not generally malicious. Most managers aren't even power hungry. Like most people they want to do a decent job they can be proud of, be surrounded by decent, contented people and customers, and be reasonably rewarded for what they do. If you assume any of these things to be false you're going to be wrong considerably more often that you're right.
What is also common between programmers and managers is that they are constrained by a range of factors and often have very limited control over the constraints placed upon them. Managers have managers. They're answerable to directors, to customers, to shareholders and to suppliers. As a rule the larger the organisation the more complex the web of constraints and constrainers becomes (hence why large organisations tend to react so slowly).
The thing to understand is what these constraints are. They're rarely technical, they're far more commonly budgetary or time based. When your boss says no he almost certainly isn't saying "no, it's a bad idea, I know better", he's saying "no, I can't do this without damaging / risking something else".
So work out what the limiting factors are and try and work with him within those. Often that will mean taking a longer term view - getting something changed within a period of weeks or months is often massively more difficult than if you set yourself a longer time frame. Short term commitments (deliveries, revenue over the next couple of months) are often close to immovable, things over a longer time scale are often more flexible.
One of the things bosses are often bad at is talking about the business to programmers. Partly this is because programmers aren't always interested, but a lot of it is habit. If everyone knows what the targets, deadlines and schedules are, then they're in a better position to work within them.
The good advice is to repeat the manager's argument, the way you understood it. However, if you do it to "loosen them up" and make them "more willing to work with you", then you're doing it for the wrong reason.
The right reason is to verify whether you understood them correctly. Maybe they meant to say something else. Maybe the did something else and you misunderstood. Maybe they said exactly what they meant and you understood it perfectly, but there's more to it. For example, they might have a perfectly practical non-technical reason for their argument.
Here's an example from my own experience: at one point, a manager argued that we should do something that would risk defeating the very purpose of a rather big and complex software we've developed, by allowing a group of future users to circumvent certain of its restrictions that are meant to make sure their stuff can be used on more than one target platform. I pointed out this risk and argued vehemently against it. The manager explained that the cost of migrating their existing work to our software, while maintaining those restrictions, would drive the cost of the whole project to 150% (or higher) of what the project would cost if we allowed users to do what he proposed. That certainly complicated the whole equation, even though his argument was still "technologically horrible".
TL;DR: When non-technical managers disagree with you, it might be because they have a need to assert their power and be respected by their subordinates, but that's a conclusion you should draw only if you've made a reasonable attempt to discard the alternatives. If you do happen to have a manager that behaves that way consistently, then maybe you should consider changing the manager and/or the company, instead of wasting your time and energy by trying to manipulate them.
Regardless of the technological background of your manager this type of conflict arises when there is power struggle. Good managers will take advice and evaluate it giving their opinions/knowledge to arrive at the best decision available. Bad managers will seek opportunity to step over you to either appear bigger/better or to push you down. I've seen cases of both and am glad I'm now working under the former but as f…
A good boss will bring his concerns forward and give you the opportunity to address them, and if you tell him this is a better solution for the X issue, then he'll trust you to do it and give you approval.
If it turns out that your solution was worse for X, then when he has to be more careful in the future, he can remind you that X didn't get met last time and that is why he's not sure about this time. You then have to prove it or shape up.
It's all about building trust-- with GOOD bosses.
The problem is, good bosses are maybe %30. To many of them are simply people who were promoted to management because they are ambitious and good at playing politics and in a lot of companies their incompetence (eg: knowing nothing about software despite managing programmers) is seen as an advantage (that was the case at Amazon where my boss had trouble operating excel and his background was in criminal justice.)
Hell, I once worked for an educational software company that higher ex-kindergarten teachers to manage programmers. They knew nothing, but they had been trained that "young ones" (eg us 20-30 year old artists and programmers) were not to be trusted.... we even got scolded once for stepping out of the office to have a conversation! It was a company run like a kindergarten class!
Trying to explain technology in both of these examples to profoundly technology illiterate people was taken as "back talking". What they heard from some cousin (or once, I kid you not "bill gate's investment group might make an investment, so we need to get rid of our linux mail and file server and replace it with windows") .... was always more compelling than what their employees, who actually knew the situation, would tell them.
I think their incompetence fed a need to put their foot down.
In both cases the team collapsed as all the talent walked out the door.
I couldn't shake my knee-jerk response to this title: "Get a technical boss"
There are a hundred technical decisions that need to be made. A non-technical boss who trusts his best experts can farm that out to the entire team. A technical boss will often try to use their own judgement... but there is too much for one person to micromanage, so they end up failing.
get rid of managers - see Fred George and Programmer Anarchy http://www.youtube.com/watch?v=uk-CF7klLdA
There definitely is some stigma about these sorts of tactics being manipulative or political, but I would compare it to learning how to write effectively - it's an optimization that improves clarity and is really a lifelong skill.