How To Be A Horrible Boss
diegobasch.com
diegobasch.com
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.]
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?
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.
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.
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.
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.)
So you were at my last company? ;)
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.
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.
"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".
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.
If these articles don't give a bit more context, then they are easy to misinterpret.
Edit: So, it is the results that speak for you.
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'.
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.
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.
And how many people have been poisoned in a bad office atmosphere spending their career there thinking that's just the way it is.
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.
So how am I going to learn about management? What are good classes? What are good websites to ask these questions?
A good dollop of common sense never goes amiss.
I wonder what that says about the daily Agile stand-up-s.
-- 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.
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.
My experience: the better the programmer, the more willing to ask/involve other people.
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.
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.
[1] http://www.amazon.com/Corps-Business-Management-Principles-M...
http://en.wikipedia.org/wiki/Strategic_Corporal#Strategic_Co...
even better: maneuvers. exactly which companies 'train' things? a roll out? a disaster recovery? you fight as you train.
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.
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.
I don't want to into a political discussion so, it really is just an example.
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.
see this pdf for details: http://www.au.af.mil/au/awc/awcgate/army/tc_25-20/tc25-20.pd...
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.
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.
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.
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?
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.
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.
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.
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.)
Disclaimer: Not at all serious, except the first sentence.
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.