That's kind of the point. You don't want to be working with someone who can't work with other people. If you're a "troublemaker" and refuse to change and adapt to the way the company you work for does things, go ahead and found your own and do it your way, and see if others are willing to work for you in the long term, or find another company with the culture you're after. When it comes to tech there's plenty of companies out there who hire for different personalities and abilities.
I actually have a post about this: http://blog.alexrohde.com/archives/473
The whole "everyone must be a team player" thing is such crap. I will gladly take a one man army with the resolve to deliver above all else over a team of mediocre players who take 4 times as long and waste more time arguing in meetings than it would take to just bust the thing out twice.
Effective teams are great too, but if you can't figure out how to use the other type, it really is your loss.
That describes me pretty well, and those with whom I work love me. They just keep me in my little box, leave me alone and let me do my work. But they are also a grown-up company that doesn't make people wear 27 hats. PMs do their job, Infrastructure does theirs, Client Support does theirs, etc. Not every job has the same requirements as every other job.
That's corporate life in America. No room for individualism. But I've heard it's even worse in Japan, so there's that...
And she lists several "harmful" practices like this.
In short, taking initiative? Nope, we don't like that here in corporate America. Doing what you're told and minimize risk. Don't actually try to make us money or anything.
Software is a little special, because you can still kinda get away with that.
Currently dealing with a fellow that exhibits all four of the documented traits plus a general unwillingness to document anything. Kind of unsalvageable at this point... =(
1. Bake rules into your workflow. For instance, enforce daily or semi-daily standups. Make git commits a portion of things in those - so everybody has to say what they've done in git commits (obviously, this isn't 100% of things). Other coders on the team will be annoyed by the person who isn't committing code daily, so this will mean that coder is admitting not to you, but to them, they're playing by different rules.
2. Force them to write design docs for implementing new technologies, before they're implemented. Then write a retrospective about how things went over, a week or two after the project is launched (things that were unexpected?). This can serve as documentation, but adds a bit more clarity to the overhead that comes with these changes, which is easy to miss when you're in the thick of things. Perhaps it's all they need to understand what kind of complexity they're adding (or what kind of simplicity you're not giving them credit for).
Agreed. My style is to contribute to creating the goals of the team in addition to the projects. She'd probably call me a trouble maker haha! And I'd be proud to be one. Aren't computer programmers supposed to be troublemakers? We're hacking the system ... ;-)
Working effectively with other people is definitely a skill. Some people have it from birth and some have to learn it. One blog post isn't going to solve everyone's problems but it is interesting to hear her experience.
No, we're not, and no, we're usually not.
I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.
While that may be the reason in that particular case, it seems to me the more common problem for micromanagement isn't a desire to relive one's days in a position lower on the org chart, its simply lacking the skills to operate at one's new level. Or, I guess, a corollary to the Peter Principle: people tend to work at their level of competence, despite being promoted to their level of incompetence.
So yeah, the technical problems should be open to solve for me as I and my team think. But there are a lot of things my manager should define for me and care about even if I don't. That's why he's part of my team.
My favorite managers are coordinators and facilitators. They listen to everyone's input, above and below them, and stear the ship towards success. They gauge input commensurate with the experience and knowledge of each person from whom it came. They make decisions with special sauce that can't really be boiled down to words. They're transparent, communicative, thoughtful, available and appreciative.
If the manager has heavy experience and success, it may sound like he's saying "do this my way or get out". For example, Steve Jobs felt he had great taste, and many people felt he was a jerk.
He obviously received input from a huge number of people and couldn't have made Apple successful alone. He discusses how Apple recovered in the late 90s at D5 in 2007 [0]. The NeXT brainstorms are also interesting to watch [1]
I wonder if she realizes she's doing the same when working with people's problems? Almost all of those solutions end with, "do it my way or get out."
Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.
For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.