How To Be A Horrible Boss(diegobasch.com)
diegobasch.com
How To Be A Horrible Boss
http://diegobasch.com/how-to-be-a-horrible-boss
24 comments
A little compassion on both sides would go a long way towards making 'horrible' bosses better and employees function better as a team. I find a lot of employees these days, especially younger ones are too entitled and self important to appreciate the more subtle sides of compromise. Especially if you're not constantly telling them how wonderful they are (when they barely understand their own job) and expect the same trophies for participation that they've received all their privileged, sheltered lives. Nor do they understand how a manager, especially a new, perhaps inexperienced manager might not have the bureaucratic pull to obtain the best tools for everyone and must operate within certain budgets. Trust me, your boss, no matter how horrible, wants you to succeed. They might not always take the best approach, but they went from being great at a task to being in charge of seeing to it the task they love gets done better than they could do it by others who don't necessarily know how, or want to put in the time it takes to make it great. This article is typical of the whining and entitled little d-bags around the entire working world who think they could manage better than their current boss, often having no idea what that takes, or simply believing in their heart of naive hearts that if they are simply everyone's buddy their team will succeed beyond all their wildest dreams. Ha. Good luck! I hope they get promoted soon. Then revisit this ridiculous article and see how many of the things 'horrible bosses' do are symptoms of a larger machine at work than just their function and their subordinates role within it. And don't even get me started on micromanaging. Most employees I know can barely organize their own projects, believing it their god given liberal arts education to 'think in piles rather than folders.' but what they fail to understand is that their manager is responsible for picking up all their shitty, entitled little pieces and presenting them cohesively to THEIR superiors. So, yeah, fuckhead...they do need to know what you're doing.
I really like that 'back to HN' link. I wouldn't vote for the article if you didn't make it easy for me, thanks :)
Every manager should also watch Office Space :)
and The Corporation
One thing that I've found extremely demotivating is when a manager tells me what NOT to work on. I'd have a side project that I'd start on my own time, and I'd tell my manager "I've got this prototype of X working, and I'd like to spend more time on it / test it out." He'd say "I don't want you to spend any time on that". Instant loss of motivation. And this wasn't my first month on the job, it was after maybe 3-4 years on the job, already having proved myself, etc.
This is really tricky. Often the person telling you not to put more time into something is trying to protect you from later disappointment or waste effort. Sometimes you need time to look at a prototype and figure out how it fits into your broader strategy.
The danger is that you keep working on it, and develop it in a certain direction. Then we often end up in one of two failure modes:
1. We need something different from what you built. You have to throw your (perfectly good) work away. This is even more demotivational!
2. We need something different from what you built. But you've already built this thing that sort of does what we need . . . so we keep it anyway. This is bad for the organization.
I'm seeing negatives on all sides. Suggestions on how to deal with these situations?
The danger is that you keep working on it, and develop it in a certain direction. Then we often end up in one of two failure modes:
1. We need something different from what you built. You have to throw your (perfectly good) work away. This is even more demotivational!
2. We need something different from what you built. But you've already built this thing that sort of does what we need . . . so we keep it anyway. This is bad for the organization.
I'm seeing negatives on all sides. Suggestions on how to deal with these situations?
I've been on the receiving end of what this, more than I care to remember and usually it spells the beginning of the end at that place of work for me. Here's what I've gathered from having it happen to me so many times.
If someone brings something like that to you as a manager, you have to realize that they are highly motivated about what they're doing and that you shouldn't get in the way of that unless its affecting other things that are a priority for you.
Its a very rare case where there is a valid reason to tell someone to completely stop working on something that they're doing, if there is, then outline it in simple terms and have a good discussion about it and how they feel about it, instead of just commanding them to stop.
The only valid reason these side projects are a problem is that they become a distraction for the employee. A skillful manager will know how to use this project as a carrot to let the employee perform better on the major projects that you want them to do. "If you can get me x by the 12th instead of the 15th then I'll give you 2 days to work on your side project on company time".
Its also the case that as a manager, you're overconfident about your abilities to foretell the usefulness of an idea to the firm. Only 1 out of about 5 side projects I've ever done for companies , I worked for, turned out to be total busts, all the others were pretty popular when I put them out but if I bet if I had asked my managers before I did them, they would have told me they wanted me to work on something else.
Overall, show interest in what they're trying to do ... talk through it with them, you'll learn a lot more about your employees by seeing what genuinely excites them than the stuff you just assign to them.
If someone brings something like that to you as a manager, you have to realize that they are highly motivated about what they're doing and that you shouldn't get in the way of that unless its affecting other things that are a priority for you.
Its a very rare case where there is a valid reason to tell someone to completely stop working on something that they're doing, if there is, then outline it in simple terms and have a good discussion about it and how they feel about it, instead of just commanding them to stop.
The only valid reason these side projects are a problem is that they become a distraction for the employee. A skillful manager will know how to use this project as a carrot to let the employee perform better on the major projects that you want them to do. "If you can get me x by the 12th instead of the 15th then I'll give you 2 days to work on your side project on company time".
Its also the case that as a manager, you're overconfident about your abilities to foretell the usefulness of an idea to the firm. Only 1 out of about 5 side projects I've ever done for companies , I worked for, turned out to be total busts, all the others were pretty popular when I put them out but if I bet if I had asked my managers before I did them, they would have told me they wanted me to work on something else.
Overall, show interest in what they're trying to do ... talk through it with them, you'll learn a lot more about your employees by seeing what genuinely excites them than the stuff you just assign to them.
The few times I've gone "off the reservation" to work on something important to the organization, but I know I would have been told to not work on it, I usually:
1. Don't tell the boss about it until is partially functional. They can't forbid you to work on something that they do not know exists.
2. Work 1-2 hours a day on it. When they ask you what you are working on today, you can honestly talk about the main stuff you are doing for 6-7 hours of the day, without mentioning the side project.
Instead of commanding to stop working on the project say what needs to be changed to make the project useful for the organization.
Or maybe figure out why this particular side project by your employee is important. It seems like a lot of these "side project to fix problem" situations come from a manager not knowing / not caring about the true barriers their employees are encountering or what is really costing the company time and money.
How about assuming your employee isn't a child (trying to protect someone from disappointment or wasted effort is what parents do to their 3 year old)?
Give the people a reason (a real reason, not a bullshit one). If you don't believe it will be useful say so, if you need to be different in some way say so.
Give the people a reason (a real reason, not a bullshit one). If you don't believe it will be useful say so, if you need to be different in some way say so.
I see the risk. However, after 4 years at the company, I felt I should have been trusted. Here's the rest of this particular story:
A year later, I said screw it and worked on it anyway, for 2 weeks (manager was out of town). It was an internal tool. It became the most popular internal tool in the office (95% of people have it open in a browser tab all day). At one point, the founder checked it out and said "I love [name of tool]!". Vindication. I left the company after that, and they use the tool to this day.
A year later, I said screw it and worked on it anyway, for 2 weeks (manager was out of town). It was an internal tool. It became the most popular internal tool in the office (95% of people have it open in a browser tab all day). At one point, the founder checked it out and said "I love [name of tool]!". Vindication. I left the company after that, and they use the tool to this day.
I've had a similar experience several times as well.
There's a real disconnect when you are chewed out for having wasted company time on improving a process and it is still used years after you have quit the company. (I actually managed to replace about 20 hours of my work week with several scripts that took two or three minutes to run. The best part is that I also did the same for a project manager - and he would regularly get bored web surfing and come and ask if I ever needed any help.)
There's a real disconnect when you are chewed out for having wasted company time on improving a process and it is still used years after you have quit the company. (I actually managed to replace about 20 hours of my work week with several scripts that took two or three minutes to run. The best part is that I also did the same for a project manager - and he would regularly get bored web surfing and come and ask if I ever needed any help.)
That's what project management is there for, at least I was told that. You can't replace simple routines by a script, you know you made this guy out of work? ;-)
Disclaimer: Not at all serious, except the first sentence.
Disclaimer: Not at all serious, except the first sentence.
My last company was so dysfunctional, that this would happen on a weekly basis. I would get an assignment for some new feature the boss wanted. Within a week or two, there would be some kind of managers meeting and the new feature would be cancelled. In the beginning, I would get pissed and feel like my work was wasted, but then I turned it around and used it to my advantage.
It got to the point where I would only actually do enough to show the boss that I was working on it. I only stayed there because it gave me the opportunity to get paid and work on my own projects/business ideas.
This lasted around 3 years. The company eventually ran out of money because the boss couldn't ever decide on anything and would change his business strategy on a daily (and sometimes hourly) basis. I think he was bi-polar, but I'm not 100% sure. To think, he was making 10 million/year at one point..
I actually wish I could find another company that is like this, so I can fund my next startup.
It got to the point where I would only actually do enough to show the boss that I was working on it. I only stayed there because it gave me the opportunity to get paid and work on my own projects/business ideas.
This lasted around 3 years. The company eventually ran out of money because the boss couldn't ever decide on anything and would change his business strategy on a daily (and sometimes hourly) basis. I think he was bi-polar, but I'm not 100% sure. To think, he was making 10 million/year at one point..
I actually wish I could find another company that is like this, so I can fund my next startup.
Nice points.
I do see problem with trust, not many would do that unless you are already proven before you join a work place. Moreover if you are a talented programmer, some see you as a threat.
I do see problem with trust, not many would do that unless you are already proven before you join a work place. Moreover if you are a talented programmer, some see you as a threat.
I was once told that trust is not something one earns from you - it's something you chose to invest in others. I think that's quite right.
As someone who's never had one, what is the general role of a manager of programmers?
When my wife was at a very large company, her good managers [0] did these things:
-- make sure the programming team understands the customer's priorities, goals, timelines, etc.
-- pay attention to the task breakdown, making sure that all of the programmers know what pieces to work on, and making sure that important pieces don't get overlooked
-- make sure the programming team has the resources they need. Fight with upper management, procurement, HR, or whoever else in order to get the necessary equipment and personnel.
[0] This is not always a single person with the "manager" title. Sometimes it's a "team lead", or multiple people with multiple titles.
-- make sure the programming team understands the customer's priorities, goals, timelines, etc.
-- pay attention to the task breakdown, making sure that all of the programmers know what pieces to work on, and making sure that important pieces don't get overlooked
-- make sure the programming team has the resources they need. Fight with upper management, procurement, HR, or whoever else in order to get the necessary equipment and personnel.
[0] This is not always a single person with the "manager" title. Sometimes it's a "team lead", or multiple people with multiple titles.
Remove obstacles and organize resources so programmers can create good software for the right purpose while being happy.
I know most people would know a boss was bad but I wonder if most could say why other than the obvious such as yelling.
And how many people have been poisoned in a bad office atmosphere spending their career there thinking that's just the way it is.
And how many people have been poisoned in a bad office atmosphere spending their career there thinking that's just the way it is.
He calls out 'weekly status meetings' as one of the things a manager should not do, but depending on how they are handled I think it could be a good thing.
A place I worked at used to do a '5 minute meeting', every day, right after lunch. Of course, it ended up being longer than 15 minutes, but in a varied team where many times other people have no idea what you are working on, it can actually be somewhat 'motivational'.
A place I worked at used to do a '5 minute meeting', every day, right after lunch. Of course, it ended up being longer than 15 minutes, but in a varied team where many times other people have no idea what you are working on, it can actually be somewhat 'motivational'.
Agreed. My (small) team does a 15-ish minute standup every morning where everyone gives a status on what they're working on. I think it's nice to be able to see the status of how everything is going instead of just sitting down in front of my computer in the morning and leaving, never knowing what several other guys are doing.
My job as a technical manager is to serve the people I am responsible for. Simple as that. Transparency, direct feedback and appreciation are some of the tools. In the end, my job is to make sure everyone on the team has what they need to meet our goals.
The interesting thing is determining where, and successfully managing, the point in one's career where the "people you're responsible" for inflects to become closer to shareholders than employees.
On a tangent, I've noticed an interesting correlation between a high number of bad bosses and a companies policy of frequently moving managers into new positions to give them experience with all parts of the company. I think it has something to do with reducing people to cogs.
Be patronizing I left a high-paying job after upper management installed a smug, platitudinous director over my group. I disagree that people become what you expect of them. I would not become an imbecile because my boss believed that everyone else was an imbecile. There's no reason to lose one's dignity.
Worth pointing out that even if you personally did not become what the director expected of you, by leaving you likel brought the remaining team's average closer to the expectation.
I'm not certain they could be manipulated that easily. But that was out of my hands. I couldn't stand attending mind-numbing meetings by a self-styled expert on matters of common knowledge. I had to leave.
Best bosses: Usually self-describe themselves as "meat shields" for their troops. Ask "How can I help you do your job?" instead of "Why isn't that done yet?" Understands the creative process.
Worst bosses: Ditherers, or opaque and random ciphers. Never present. Jerk you from one task to another. Surprise you with bad reviews. Unwilling to pay for good tools ("What's wrong with Notepad?") Sees you as a fungible cog or chess piece to be moved around. Often non-technical, or "used to be technical" in an ossified region of the industry (e.g., large aerospace firm). Uses Scrum as a platform for micromanaging.
[I made a decision 25 years ago never to be a manager. I recently had the opportunity to try it out again for a summer, and it sucked just as hard as I remembered. I am an engineer, and I work with people in a far different way than good managers do.]
Worst bosses: Ditherers, or opaque and random ciphers. Never present. Jerk you from one task to another. Surprise you with bad reviews. Unwilling to pay for good tools ("What's wrong with Notepad?") Sees you as a fungible cog or chess piece to be moved around. Often non-technical, or "used to be technical" in an ossified region of the industry (e.g., large aerospace firm). Uses Scrum as a platform for micromanaging.
[I made a decision 25 years ago never to be a manager. I recently had the opportunity to try it out again for a summer, and it sucked just as hard as I remembered. I am an engineer, and I work with people in a far different way than good managers do.]
"Unwilling to pay for (good) tools."
A manager where I once worked demanded that we continue to use (the unpaid for shareware version of) WinZip on one computer that was dedicated to sending data off to clients. After WinZip added the 1 second wait for every file ever processed, he implemented a 'wait and come back rule'.
The count reached over 3000 at one point!
I would just use 7-zip or zip it in Cygwin. But it became so that when I wasn't around clients would have to wait an extra hour to get their files. He sometimes would just sit there and wait for the count to complete. A single license was maybe $25 at the time?
A manager where I once worked demanded that we continue to use (the unpaid for shareware version of) WinZip on one computer that was dedicated to sending data off to clients. After WinZip added the 1 second wait for every file ever processed, he implemented a 'wait and come back rule'.
The count reached over 3000 at one point!
I would just use 7-zip or zip it in Cygwin. But it became so that when I wasn't around clients would have to wait an extra hour to get their files. He sometimes would just sit there and wait for the count to complete. A single license was maybe $25 at the time?
How about when the good tools are free (as far as money), but your boss doesn't want to use them because that would require him (as well as co-workers) to learn something new?
My current employer still uses CVS. No one really uses it properly. I see output files committed to repositories and I think I'm the only one who writes commit messages since I haven't seen anyone else's when I look through the history. I haven't seen anyone else create a branch.
I've mentioned Git both in private and in group meetings, but it always falls on deaf ears. So I use Git via Cygwin and always keep it local on my machine. I have Git ignoring the CVS directories and CVS ignoring the .git directory. The master branch is for things that I check-in to/update from CVS. All my real work is done in Git feature branches.
My current employer still uses CVS. No one really uses it properly. I see output files committed to repositories and I think I'm the only one who writes commit messages since I haven't seen anyone else's when I look through the history. I haven't seen anyone else create a branch.
I've mentioned Git both in private and in group meetings, but it always falls on deaf ears. So I use Git via Cygwin and always keep it local on my machine. I have Git ignoring the CVS directories and CVS ignoring the .git directory. The master branch is for things that I check-in to/update from CVS. All my real work is done in Git feature branches.
I see your CVS and raise you having to support Word Perfect 5.1 for DOS (from 1989) in 2008 because the President's right-hand woman didn't want to have to learn to use a text editor like SciTE. (And by 'use' I mean open a file, hit a key, and press save.) To top it off, when the pre-millenium desktop exploded, she came down to my office and started screaming at me that I had destroyed the computer.
She also refused to upgrade from Office XP or give up another expired shareware program from the Windows 95 era.
I totally agree with you. Some people will expend a monumental effort to avoid learning anything.
She also refused to upgrade from Office XP or give up another expired shareware program from the Windows 95 era.
I totally agree with you. Some people will expend a monumental effort to avoid learning anything.
Got that beat. One of the previous places I was working was still on RCS (this is in 2010). CVS is what I was able to get them to upgrade to. And it was like showing fire to the natives once they realized they no longer had to "take turns" when it came to editing the same file.
[deleted]
To be fair, if they can't use CVS right they're not going to use anything else right, either.
No one's born knowing how to properly use a version control system, but that doesn't mean you can't learn.
I totally hear you. Back when I was in the IT division of a major (really big!) automobile firm, I asked my manager for the approval to install SVN, since I didn't see anybody using any version control system. I was told that the department doesn't approve of anything "open source" and I was asked to build a version control system so that everybody could use!
> pay for good tools
You don't even need to pay for good tools, but that doesn't mean the bad boss will allow you to use them.
There's a point at which idiocy turns into a personality disorder all its own.
You don't even need to pay for good tools, but that doesn't mean the bad boss will allow you to use them.
There's a point at which idiocy turns into a personality disorder all its own.
I've been at more than my fair share of establishments. The boss that stands out as the worst, hands down, had two traits that stood out:
1. An alpha personality that could admit no wrong. 2. A failure to leverage his senior people for their abilities, everyone was treated as a contractor and told what/how to do it.
This was a startup and the behavior basically resulted in a couple of us leaving. There were other bits of the startup that were chaotic (and could be attributed to a fast/changing environment), but this individuals behavior sealed the deal for a couple of us.
Personally, I've had to manage a bit here and there. When it is a small company/team, I really prefer to understand everyone's strengths and weaknesses. Cater to the strengths, learn where I can, and try and fill in the weaknesses with other's strengths. Even with many years of experience, there is still something I can learn from most people (rockstar, average, etc.)
1. An alpha personality that could admit no wrong. 2. A failure to leverage his senior people for their abilities, everyone was treated as a contractor and told what/how to do it.
This was a startup and the behavior basically resulted in a couple of us leaving. There were other bits of the startup that were chaotic (and could be attributed to a fast/changing environment), but this individuals behavior sealed the deal for a couple of us.
Personally, I've had to manage a bit here and there. When it is a small company/team, I really prefer to understand everyone's strengths and weaknesses. Cater to the strengths, learn where I can, and try and fill in the weaknesses with other's strengths. Even with many years of experience, there is still something I can learn from most people (rockstar, average, etc.)
>This was a startup and the behavior basically resulted in a couple of us leaving.
So you were at my last company? ;)
So you were at my last company? ;)
Although i agree with most points made in this article, I think, having been a manager/teamlead of many programming teams, i think i might write an article on "how to be a horrible employee"...
I've had a number of horrible bosses over the years (if you are reading this and we still talk, i'm not referring to you!) and for me it falls into two categories: trust and authoritarianism.
Trust is critical. If you hire an engineer you should trust that they can do their job. If you don't think you can ever do that, don't hire them! It is incredibly demoralising, and a sure sign you should plan an exit when your boss tells you that he doesn't trust your code, especially when they write poorly thought out, untested, spaghetti...
Authoritarianism is also a deal breaker, especially when it is applied simply to assert dominance. A new alpha male manager coming in and declaring a new company order without even trying to get to know the strengths and weaknesses of his team is fatal. I've seen teams fall apart because of this.
I would probably suck at both of these things. I probably shouldn't be a manager.
Trust is critical. If you hire an engineer you should trust that they can do their job. If you don't think you can ever do that, don't hire them! It is incredibly demoralising, and a sure sign you should plan an exit when your boss tells you that he doesn't trust your code, especially when they write poorly thought out, untested, spaghetti...
Authoritarianism is also a deal breaker, especially when it is applied simply to assert dominance. A new alpha male manager coming in and declaring a new company order without even trying to get to know the strengths and weaknesses of his team is fatal. I've seen teams fall apart because of this.
I would probably suck at both of these things. I probably shouldn't be a manager.
For these articles, it would be good to consider the other side:
Talk a lot, do not listen much - people need to know what's going on. A good boss has to keep everyone informed of the stuff that matters.
Be patronizing - you need to ensure all the right checklists are followed (security, stability, etc).
Be as cryptic as possible, never direct - don't micromanage.
Encourage bureaucracy, and demand visibility into everything - documentation and process is really important.
Show them who's boss - you have to make sure everyone is co-operating, and that silos are broken down.
These "problems" can be strengths, or necessary evils. It's more a question of when the behavior is a problem, rather than which behavior is always best.
Talk a lot, do not listen much - people need to know what's going on. A good boss has to keep everyone informed of the stuff that matters.
Be patronizing - you need to ensure all the right checklists are followed (security, stability, etc).
Be as cryptic as possible, never direct - don't micromanage.
Encourage bureaucracy, and demand visibility into everything - documentation and process is really important.
Show them who's boss - you have to make sure everyone is co-operating, and that silos are broken down.
These "problems" can be strengths, or necessary evils. It's more a question of when the behavior is a problem, rather than which behavior is always best.
I'm having trouble seeing "don't listen too much, be patronizing and show who's boss" as something positive.
It depends on how you frame it.
"Don't listen too much" could be framed as "Keep your team informed".
"Be patronizing" could mean "Make sure the little things get done".
"Show who's boss" could be "Be a leader", "Be responsible", or "Don't be afraid to delegate".
"Don't listen too much" could be framed as "Keep your team informed".
"Be patronizing" could mean "Make sure the little things get done".
"Show who's boss" could be "Be a leader", "Be responsible", or "Don't be afraid to delegate".
What you see as re-framing, I'm seeing as distorting, and they work better as separate examples of good management.
For example:
Ensuring correct procedure is followed doesn't mean you have to be patronising.
Keeping your team informed doesn't mean you don't have to listen, or you have to talk too much.
Being a leader, responsible, or not afraid to delegate doesn't mean you have to "show who's boss".
And I don't say this with any intention to cause offense, nor is it directed at you specifically, but I think if, for each point, you think the inverse is true, then you may have more in common with 'bad manager' than you think.
For example:
Ensuring correct procedure is followed doesn't mean you have to be patronising.
Keeping your team informed doesn't mean you don't have to listen, or you have to talk too much.
Being a leader, responsible, or not afraid to delegate doesn't mean you have to "show who's boss".
And I don't say this with any intention to cause offense, nor is it directed at you specifically, but I think if, for each point, you think the inverse is true, then you may have more in common with 'bad manager' than you think.
Yes, my problem is that a lot of these "5 things managers should do" lists describe a particular kind of bad manager (the article seems to be talking about an egotist).
If these articles don't give a bit more context, then they are easy to misinterpret.
If these articles don't give a bit more context, then they are easy to misinterpret.
This. It's never a matter of "what" but "when" and "how".
How to be a "good" boss very much depends on the people and the circumstances. There's really only one constant: clarity.
Even if the boss's style is authoritarian micromanagement, which most people on HN won't feel comfortable with, if said boss provides clarity and consistency certain types of people will be happy to work for them.
Knowing what is expected of you is the most important part of being comfortable in the role of employee. The rest is more a matter of personal preference.
Even if the boss's style is authoritarian micromanagement, which most people on HN won't feel comfortable with, if said boss provides clarity and consistency certain types of people will be happy to work for them.
Knowing what is expected of you is the most important part of being comfortable in the role of employee. The rest is more a matter of personal preference.
He suggests "managing humans" as a good book for managers to read. Just started reading it, and it seems decent. Anybody have other good resources?
'First, Break All the Rules' is a great read. For new managers, I highly reccomend 'The First 90 Days'
Remember not to just accept everything in these books. They should be read with the expectation that you will have to pull out the useful pieces that are relevant to you.
Remember not to just accept everything in these books. They should be read with the expectation that you will have to pull out the useful pieces that are relevant to you.
Peopleware and Slack by Tom DeMarco are must-reads. I re-read Peopleware once every few years. I also liked Delivering Happiness (by @zappos) and Tribal Leadership, although they are more about organizations than management per se.
while these horrible boss threads are always enjoyable (hey, scott adams' career is built on it), how about switching perspective for a moment.
the majority of programmers are employees.
what makes a horrible employee?
- disregard of communication etiquette. you're running late on something, a meeting, a task, anything - say it, write it, text it early, and loud enough for your boss to hear. a manager needs that info to counter-steer.
- in the same vein, the non-ability of constructive criticism. don't just think 'this won't work' but continue to work on it anyhow. communicate it, in plain language, with reasons. want to be excellent? provide an alternative.
- play politics. try to brown-nose. etc. hint: your manager likely became one because he/she is good at politics. can see through your attempts and gets easily annoyed by it.
as a manager you need to protect your team from bad apples. the no-assholes rule applies, but as programmers tend to have anti-social behaviors it is harder to apply. is the behavior of the employee destroying the productivity of others? is his/her productivity high enough to compensate? a rockstar programmer might be worth putting up with.
managing people is hard. and you can't learn it like you can with programming. no theoretical studies help, no tutorials, no forums. no stackexchange to quickly solve a problem. that's why a lot of managers suck - cause they are on their own. or as Peter Drucker put it, there are only a few possibilities to learn true management skills out there - the army being the biggest of them, followed by the boy scouts. think about that and what it means for modern organizations.
the majority of programmers are employees.
what makes a horrible employee?
- disregard of communication etiquette. you're running late on something, a meeting, a task, anything - say it, write it, text it early, and loud enough for your boss to hear. a manager needs that info to counter-steer.
- in the same vein, the non-ability of constructive criticism. don't just think 'this won't work' but continue to work on it anyhow. communicate it, in plain language, with reasons. want to be excellent? provide an alternative.
- play politics. try to brown-nose. etc. hint: your manager likely became one because he/she is good at politics. can see through your attempts and gets easily annoyed by it.
as a manager you need to protect your team from bad apples. the no-assholes rule applies, but as programmers tend to have anti-social behaviors it is harder to apply. is the behavior of the employee destroying the productivity of others? is his/her productivity high enough to compensate? a rockstar programmer might be worth putting up with.
managing people is hard. and you can't learn it like you can with programming. no theoretical studies help, no tutorials, no forums. no stackexchange to quickly solve a problem. that's why a lot of managers suck - cause they are on their own. or as Peter Drucker put it, there are only a few possibilities to learn true management skills out there - the army being the biggest of them, followed by the boy scouts. think about that and what it means for modern organizations.
As a fellow programmer: the worst programmer is the guy who doesn't want to consult other programmers and who doesn't think other programmers might have important insight into datastructures etc.
My experience: the better the programmer, the more willing to ask/involve other people.
My experience: the better the programmer, the more willing to ask/involve other people.
This is an important thing to realize.
For most teams, the differences in backgrounds and experience provide different perspectives that are key to a good design or decision.
More importantly, any meaningful system/product is large and complex enough one person can't know everything or have considered all of the implications.
For most teams, the differences in backgrounds and experience provide different perspectives that are key to a good design or decision.
More importantly, any meaningful system/product is large and complex enough one person can't know everything or have considered all of the implications.
Do you really see the army as a reference in management? Focus on discipline, strict hierarchies and codes doesn't do much good for most software businesses.
And yes, you can learn it. Every profession that involves people has it's dose of "magic" that you must grasp - project management isn't special. Ask a teacher.
And yes, you can learn it. Every profession that involves people has it's dose of "magic" that you must grasp - project management isn't special. Ask a teacher.
There's a book on how the marines does management called Corps Business [1], it makes a pretty decent argument for implementing some stuff from the armed forces, eg. adaption, steering by objective, breeding culture etc. It was a while since I read it, but I remember that I thought it was a decent book sans some needless glorification of the marine corps.
[1] http://www.amazon.com/Corps-Business-Management-Principles-M...
[1] http://www.amazon.com/Corps-Business-Management-Principles-M...
The military doesn't work like you think it does
http://en.wikipedia.org/wiki/Strategic_Corporal#Strategic_Co...
http://en.wikipedia.org/wiki/Strategic_Corporal#Strategic_Co...
yes. the army of today has progressed a lot. lead by objective, after action reviews - most companies do not implement these techniques as they are too disruptive.
even better: maneuvers. exactly which companies 'train' things? a roll out? a disaster recovery? you fight as you train.
even better: maneuvers. exactly which companies 'train' things? a roll out? a disaster recovery? you fight as you train.
When I was working as a technology manager for the Winter Olympics in Vancouver, we had what were called technical rehearsals. These were simulations of Games-time trouble scenarios to test and improve our systems and processes. It was one of the most nerve-wracking/stressful experiences I've ever had. You could essentially liken them to maneuvers the military uses to train for real battle. The result was that I was much more prepared for the real Olympics, and felt confident to handle almost any disaster situation within my area of responsibility. The same for almost everyone else in the technology department.
I do realize this type of thing is rare though in most settings. For the Olympics (and I think most big events), technical rehearsal is a staple exercise because you get only one chance to make it right and the world is watching.
I do realize this type of thing is rare though in most settings. For the Olympics (and I think most big events), technical rehearsal is a staple exercise because you get only one chance to make it right and the world is watching.
Not even inn leadership one my think (the army as an example, I mean), but in terms of management of large organisations, yes armed forces (as long as they are used from time to time, so NOT the germen ones) or the roman catholic church are pretty good examples. For leadership, you rather go look somewhere else for examples.
particularly in leadership, why would you single that one out?
squad leaders, platoon leaders, up to officers - they all lead people. all they rely on is their people. if you are out there in afghanistan all that can save your life is your people.
the days of WWI style large-scale battles are long over. ever talked to veterans? most i talked to confessed that it is pretty likely that more officers died by 'friendly fire' than enemy contact. if you suck as a leader in war, feedback is pretty direct.
the modern army is the outcome of a lot of field testing. it is a learning organization, they employ their own historians to assess past activities and learn from them.
leaders are actually being trained in leadership. practical training, you get your own team in a controlled environment and then exercise with them. which organization has such a process?
i particularly like the AAR. not even SCRUM has such a feedback loop, nothing is learned.
squad leaders, platoon leaders, up to officers - they all lead people. all they rely on is their people. if you are out there in afghanistan all that can save your life is your people.
the days of WWI style large-scale battles are long over. ever talked to veterans? most i talked to confessed that it is pretty likely that more officers died by 'friendly fire' than enemy contact. if you suck as a leader in war, feedback is pretty direct.
the modern army is the outcome of a lot of field testing. it is a learning organization, they employ their own historians to assess past activities and learn from them.
leaders are actually being trained in leadership. practical training, you get your own team in a controlled environment and then exercise with them. which organization has such a process?
i particularly like the AAR. not even SCRUM has such a feedback loop, nothing is learned.
Maybe I should have been clearer on that point. Yes, the leadership you mention certainly is there and hopefully good (I'm not american and didn't serve). What I meant was more the fact there arose quite some incidents where the leadership aparently failed. Not in a combat situation, mind that, but rather in a global scope, allowing the burning of korans for example isn't best pratice.
I don't want to into a political discussion so, it really is just an example.
I don't want to into a political discussion so, it really is just an example.
A good sprint retrospective in Scrum should be similar to what I've read about After Action Reviews (AAR).
One the dust settles, spend time to figure out what went well, what can be improved, and what the on-going issues are. They both seem like decent continuous improvement vehicles to me.
One the dust settles, spend time to figure out what went well, what can be improved, and what the on-going issues are. They both seem like decent continuous improvement vehicles to me.
what's really great about the AAR process in the military is that it is set up as an open forum, where rank does not apply. it is time-limited, to be done right after the exercise. it is highly focused, not a bitching session.
see this pdf for details: http://www.au.af.mil/au/awc/awcgate/army/tc_25-20/tc25-20.pd...
see this pdf for details: http://www.au.af.mil/au/awc/awcgate/army/tc_25-20/tc25-20.pd...
That's the description of an ideal sprint review.
The army, the Catholic church and a successful software company have very different jobs to do, under very different circumstances. It's no surprise that they are organized very differently. Trying to model any of them on the organization of either of the other two will not produce good results.
In th end, yes. But all three face the common task of organizing trully global organizations with thousands of peoples spread all over the place. It doesn't matter if you programming software, preaching to the world of fighting wars. AFAIK there were even books written about the lessons one take from the organization of the church.
The point I wanted to make is, that you can learn from everyone even if it's from a different sector. As far as the church goes, you clearly see the old roman heritage.
The point I wanted to make is, that you can learn from everyone even if it's from a different sector. As far as the church goes, you clearly see the old roman heritage.
no stackexchange to quickly solve a problem. that's why a lot of managers suck - cause they are on their own.
Well said. Someone once told me the real reason being a CEO is a such a tough job: "The work is easy, and you have people who can answer any question you might have, but everyone is lying to you."
the army being the biggest of them, followed by the boy scouts. think about that and what it means for modern organizations.
The military is different. People will die for their country, and will subordinate in ways that they would in no other context because of this impulse. No one is actually willing to subordinate his own interests for the sake of Initech's bottom line. The "eager foot soldier" act that office politicians play when they're young and at the bottom is paper-thin.
Well said. Someone once told me the real reason being a CEO is a such a tough job: "The work is easy, and you have people who can answer any question you might have, but everyone is lying to you."
the army being the biggest of them, followed by the boy scouts. think about that and what it means for modern organizations.
The military is different. People will die for their country, and will subordinate in ways that they would in no other context because of this impulse. No one is actually willing to subordinate his own interests for the sake of Initech's bottom line. The "eager foot soldier" act that office politicians play when they're young and at the bottom is paper-thin.
The military is different. People will die for their country, and will subordinate in ways that they would in no other context because of this impulse.
This isn't a natural instinct though, on top of that, I would only say that a small percentage of recruits are willing to die for their country. I remember hearing from a recruiter awhile back (2008 era) that the number one segment of recruits are males from farm towns because it is one of the few "reputable" ways out of the farm life. For people who want out of where they are and want a better life, death sure isn't the answer.
It takes management skills to make people fight their urge to self sustain and dig in and fight 'til the possibility of death. It takes management skills to keep morale up when people are in some foreign land for years at a time.
This isn't a natural instinct though, on top of that, I would only say that a small percentage of recruits are willing to die for their country. I remember hearing from a recruiter awhile back (2008 era) that the number one segment of recruits are males from farm towns because it is one of the few "reputable" ways out of the farm life. For people who want out of where they are and want a better life, death sure isn't the answer.
It takes management skills to make people fight their urge to self sustain and dig in and fight 'til the possibility of death. It takes management skills to keep morale up when people are in some foreign land for years at a time.
My most recent problem : think you are like Steve Jobs. Seriously, this disease seems rampant amongst manager recently. Is it anecdotal evidence or has someone else observed that too ?
"Don't learn about management."
So how am I going to learn about management? What are good classes? What are good websites to ask these questions?
So how am I going to learn about management? What are good classes? What are good websites to ask these questions?
I'm found the manager tools podcast (at manager-tools.com) to be valuable.
Read a critical mass of business books - and then make your own mind up. Their advice is somewhat confused and conflicted, but in the middle of it all are the basics.
A good dollop of common sense never goes amiss.
A good dollop of common sense never goes amiss.
According to HN posts, Steve Jobs seems to have posed these characteristics. But I'm sure he is not a horrible Boss.
Edit: So, it is the results that speak for you.
Edit: So, it is the results that speak for you.
Being a horrible boss and being a successful executive are different things. Steve Jobs was a horrible boss by all accounts. The first chapter of Managing Humans addresses exactly this point.
> Have weekly status meetings even if there is nothing new to say,
I wonder what that says about the daily Agile stand-up-s.
I wonder what that says about the daily Agile stand-up-s.