Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A lot of bad practices were being committed at the beginning of a project, and I recognized them and fought against all of them. Since I didn't pick and choose my battles, my boss now assumes anything out of my mouth is an over complicated response, and spends a lot of time defending himself personally, instead of looking out for the best interest of the project.

How do I push the team in the right direction, without waiting four months for everyone to come to the consensus I was trying to get in place all along, or scarring my reputation on the team as a difficult know-it-all?

share|improve this question
49  
Keep an eye out for a post from your boss wondering how to avoid "Smart Ass" syndrome - the one guy who thinks he knows it all even though he's new and never worked on any real world projects. –  Paul Tomblin Dec 18 '11 at 16:57
3  
@Droogans, please do not assume that I have read other questions by you. If you expand the body of your question, then we can mutually withdraw the comments (which are meant for clarifications, right). –  Job Dec 18 '11 at 16:57
9  
@Droogans: Building the UI first (prototyping) and no up-front design can be considered Agile, if done right. Don't assume that you know it all and you won't be known as the guy who assumes he knows it all. That said, a development team without a bug database is probably not doing it right. –  pdr Dec 18 '11 at 17:05
3  
As an additional note, not having formal specifications of the entire project is something that is quite common. Learn to adapt with your project owner. I (and many others I know) quite often work with only user stories, no specification as such. –  jer Dec 18 '11 at 17:47
14  
How can you be so certain that you are right and they are wrong? Please backup with facts. –  user1249 Dec 18 '11 at 23:17

8 Answers 8

up vote 38 down vote accepted

Change takes time. Udi Dahan has an excellent article that touches on what you are asking, and I think he does a better job with the answer than I would.

Be enthusiastic, not bitter. Be prepared to carefully, cheerfully explain your position far more often than you'd like. Count your wins, and be prepared for others resisting your ideas. Always keep in mind, that other people's view points, while not your own, may in fact still be right. In time, you can achieve your goals if you are prepared to work with people.

I wonder if you had a little bit of a twinge when you wrote "since I don't pick and choose my battles" ... it seems like a bit of a red flag to me. Getting a few early, easy wins can set you up not as "that jerk that thinks he's smarter than everyone else" but "that guy that had that great idea last month".

share|improve this answer
1  
Getting early victories is hard when your solution is hinging on "what could happen in the future". Now, when I identify these things, I keep notes on what I should expect, and just wait for it to break. Give myself a head start. –  Droogans Dec 19 '11 at 1:31
    
If it's as bad as you say it is, its unusually bad and you should seek a graceful exit. Either way patience is your friend. Hopefully your career will be long... Don't stress out so much about the short term. Things usually work out. –  Kyle Hodgson Dec 19 '11 at 2:05
    
I like to think I'm learning as much, if not more, in the interpersonal side of software engineering. Regardless, I'll be satisfied knowing I made a difference someplace that needed it, plus...it's good practice. –  Droogans Dec 19 '11 at 2:09

I love the way this was flagged "teamwork", when the question seems to be "how do I make everybody do everything my way and like it?". If that's not really the question you're asking, the answer is very simple. Pick and choose your battles. Compromise. Use actual teamwork to get the team to agree on something, even if they all agree on something you personally feel is a bad practice. Being stubborn and insisting any way other than your way is "bad practice" is just going to get you exactly the reputation you're trying to avoid.

share|improve this answer
    
I upvoted this (because I think this is the actual situation), but being too passive on a team full of bullying, politically entrenched and insecure people whose skills are at least ten levels below your own backfires too. You get them used to getting their way over yours every time, and they will fire you the minute something comes up that you find important enough to fight for. –  user16764 Feb 24 '13 at 0:25

Trying to go against the team's current decisions on a continuous basis is harming the viability of your ideas, regardless of their value.

You have to realize you're struggling with the Overton window, and this is essentially a political battle, not a rational debate. If it were rational, you would have agreed long ago with the team on a good practice.

The trick with getting your ideas accepted is to take a long game approach to move the Overton window:

  1. Initially, you must label yourself "reasonable" in the minds of others. This means adopting current team practice and generally being a "reasonable person". You may offer doubts about these practices, but you cannot refuse them if the team currently feels they are reasonable.
  2. Once you're reasonable in the minds of others, you can start offering your ideas to the team. They will gain credibility because you have gained credibility (it shouldn't work this way, but it does). Gradually you will broaden the window of acceptable ideas to include your own. In this phase you still do not try to force a change in practice, merely make such a change seem like a "reasonable" idea. Repetition of ideas is key here, because each repetition makes the idea seem slightly more reasonable.
  3. In the last phase, you abuse people's inability to pay attention in a balanced way. You have to put negative consequences of current practice front and center of their attention plane, while putting risks of your approach far outside of it (do this by changing the subject of conversation to what you need it to be). Eventually, the team will itself decide that your idea is far better than the current approach. It will become democratically adopted without you having to force your will on anyone, and without ever needing to rationally demonstrate superiority of the idea.

This is how politicians and lobbyists operate. Make no mistake; office politics are just like regular politics. Think like a lobbyist and you can force the hand of those in power without ever confronting them.

Ofcourse, all of this only applies to dysfunctional teams. If you're in a cohesive team run by a good manager (who knows his job is not to tell people what to do, but to allow them to do it), then none of the above applies. If you're not in such a team, consider switching jobs.

share|improve this answer

I recommend reading http://www.jamesshore.com/Change-Diary/ It has a lot of incredible remarks about managing change in a company. Also this book might be helpful: http://www.amazon.com/Agile-Coaching-Rachel-Davies/dp/1934356433 . Not because you should go Agile but because it has lot of remarks about providing change to a team and dealing with feedback and response. From my own experience: You will not be able to change anything if people are not with you on it. If they do not already want such change. If that is the case, you can just leave it. You probably expect something different from your work or you outgrow your coworkers.

The best approach IMHO is to be the change. Doing things the right way yourself as you see them. Others will follow you if they found value in your approach. And they will be grateful for you for introducing this change. However first people need to see the good side of the change. Then they want it. It is very hard to do it the other way (introduce change, wait for good results of it).

Wish you best luck.

share|improve this answer

be sure not to confuse being recognized as being right and getting result according to what you think is right. Those two goals are both valid and legitimate but they are not the same and it's very hard to get them together especially if you dont have a clear view on which one you are working for.

share|improve this answer

With some bosses, you have to somehow trick them into believing that it was their idea all along to fix some practice, not yours.

Choose which battles you want to win, and which ones you just want credit for.

share|improve this answer
3  
its isn't "trick", its called "manage" –  Josh Petitt Feb 23 '13 at 17:02

I think that you've answered your own question somewhat. The only suggestion I have is to learn to pick your battles, and learn to be patient. Inject a few ideas every now and then, then let those ideas percolate until you get "buy in" from others in your team.

The main problem isn't about who is right or wrong. It all comes down to both individual and group psychology. People tend to wrongly feel a sense of inferiority when their values and ideals are challenged, and people can be very resistant to change. They can become argumentative and will seek others to validate their position and be comforted as a group so that they do not have to challenge their own values, and so that they do not have to face changes that might make them feel that they had certain concepts wrong. On the flip-side, software developers in particular can be very sensitive people, and yet can often be insensitive (particularly when younger) in terms of how they might approach challenging the values of others. The result is that you will often find teams where one individual is very unhappy and feels that everyone else seems to refuse to understand, and treats that individual like the proverbial tall poppy. Often this results in a group culture that is poisonous to all, where blame and defensiveness become the norm.

You also need to consider your own position in all of this. It isn't likely that the blame for a poisonous culture lies entirely with your colleagues, even if it may have started there. It is more likely that their reactions to you and your reactions to them all feeds back on itself over time, and left unchecked becomes a very difficult to manage problem. A good manager spots these sorts of problems early and fixes them, but the reality is that most managers in IT come from IT backgrounds first, and are promoted without the additional training needed to actually manage people effectively, so that by the time they realize there is a problem, it has grown very large, and has become a part of the team culture.

So what can you do about this?

One option is to simply leave, but to do so in a way that allows you to leave with your reputation intact, and with a good referral from your employer. You don't want to have your "Jerry McGuire" moment and burn all your bridges, and at your interviews you'll need to be careful about how you phrase your reasons for leaving, and to avoid coming across as arrogant or bitter at how you felt you were treated.

If you wish to stay, then you'll need to do the hardest thing of all. Swallow your pride, and over time show others that from their perspective you have "changed". You need to stop and listen to the others, and to avoid the temptation to take rejected ideas personally. Time, patience, and learning not to invest yourself too emotionally in the work that you are doing. Even more importantly, you need to learn how to phrase things so that you are showing others that you are sensitive to their point of view, while still getting your own across.

Your question echoes some of the experiences that I have had over the last 10 or so years, and while I'm not a psychologist, I am a keen observer of how people interact with each other, and I have myself needed to work at changing myself before I could effect cultural change in my team. In some cases I have changed jobs, and in others, I have stayed and done everything I could to really make a difference to my workplace. I've walked away with the greatest satisfaction from those places where I overcame being the tall poppy, and left an improved work culture and with great references. See this as opportunity to really rise to a challenge. It can be hard, but very rewarding in the end.

share|improve this answer
    
I have been mentioning things in passing since summer, and letting mistakes go if they're not in my direct area of concentration in the design of the system (even if it means working a few late nights). I also think really, really hard about giving my solution a sexy, buzzword-centric name, and not describing it. Sadly, this works better than trying to flesh out the source of the problem, or the solution I'm offering. –  Droogans Dec 19 '11 at 1:28
    
LOLz re: buzzwords. Even I've been known to explain to managers the need to "synergize" :-P In the end, these are just tools to use to meet the objective of making improvements. Managers however need to justify expending resources, and that requires making a sound business case for any improvement you wish to make. Hard data in terms of profit and expenditure speaks much louder than simply saying "because Fowler/Gof/etc says it's so". I guess that the gist of what I wrote comes down to engaging with people instead of fighting against ideals, and you get further with a carrot than the stick. –  S.Robins Dec 19 '11 at 2:19

You need to provide explicit, irrefutable, compilable, proof that you are correct, or reduce the problem to something trivially true, e.g., something that must be safe like RAII is by definition safer than something that can be safe, e.g. malloc/free.

share|improve this answer
37  
And consider the possibility that you're wrong, and the other 3 guys are right, and you just don't see it. –  Yam Marcovic Dec 18 '11 at 16:39
    
@Yam In that case, we'd have used a file-based data model. The examples here are not frilly details; these were fundamental, irreversible flaws that 90% of all software-centric books and courses warn about. Sounds pretty grim, right? Try and not be threatened when the figures are presented to you, the boss, in that manner. –  Droogans Dec 18 '11 at 16:52
10  
@Droogans I didn't say you're wrong, I said consider the possibility that you're wrong every time you get into an argument, just as you expect the other people to do. –  Yam Marcovic Dec 18 '11 at 16:56
    
@Yam: If you provide explicit, irrefutable proof, then you've just proved that the other guys are wrong. They can always try to pick it apart if they want. –  DeadMG Dec 18 '11 at 19:03
4  
@DeadMG Programming "best practices" don't really get to ever be objectively better, and hence you can't really prove that they're "better", only that they meet your standards of what you think is good. There's always going to be pluses and minuses, and sometimes the other guys will consider what you consider to be good, to be bad. –  Yam Marcovic Dec 18 '11 at 20:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.