I've been in my first professional position for about six months now, and so I am hitting what I suppose is the pretty typical moment:

Naievely perhaps, I think there's a lot of cultural baggage on the team that holds it back (A lack of respect for documentation work, hugely scattered documentation, infrequent code review, a disconnect between development and test etc.)

I've started trying to make my mark; setting up tooling for documentation, static analysis, etc.

Where I am lost however is in the questions of buy in: While I can try to lead by example in some areas, I do need to get the team on board. I also have to consider that my priorities don't match those of the rest of the team.

How do I get buy in, and get a good feeling for what people value? Ideas I've considered:

  1. Team survey -- Ask about what's important to drive future efforts
  2. Skunkworks teams: Try to recruit small groups to work on driving forward pieces they care about in their 'free' time?
  3. Try to convince management that we need to make these kinds of changes, and try to get them part of the review process?

Or maybe I need to STFU and keep my head down and do my work.

The team is about 50 people spread across multiple teams working on a shared C++ codebase.

closed as too broad by Robert Harvey, GlenH7, Telastyn, Jim G., gnat Feb 8 '15 at 20:41

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Ok, first step for me is to find out why/who else understands that this is an important issue. For example, if some manager halfway up your "chain of command" is hiding the fact that development work isn't done "to reliable standard", you could be in trouble if you expose this (obviously not in a GOOD company where managers listen to staff, but some companies are not good).

Second step is to find arguments for your project. Can you show that the code in the current project is suffering from bad discipline? For example, how many bugs are caused by lack of code-review.

(Of course, code review is not perfect either, I recently introduced a bug by moving a variable out from a loop [because I needed it in the context after the loop too], which led to the value not being set in an unusual condition -> bug detected in nightly testing.The code had been reviewed by two or three experienced engineers that didn't spot this...)

Third, can you show that the work will actually be more efficient "after these changes"?

If you can show these things, most managers will agree to introduce changes, because it improves productivity. But if you simply go into a manager and say "The work isn't very good here...", you may not get quite so far... :)


In my professional experience (a combined 26 years in three very different workplaces, not counting grad school), there are times when a team does better with documentation, review, testing, and the like, and other times when it does worse. It can be influenced by external deadlines or a number of other factors. The "bad time" can last a lot more than 6 months, and people are less willing than usual to humor the new hire's ideas on best practices when they feel required to forgo some of their own.

Or it may be that it's always been like this in that group as long as anyone remembers. In that case, it's going to take a while to change old habits; conversely, if the whole house of cards isn't already tumbling down at this point, it can probably be propped up for enough time to implement changes gradually.


How big is the department you work in?

I recently implemented a set of standards for working with source control where I work since we used to have things like (a) cryptic messages which only the author and (maybe) the code reviewer understood, (b) monolithic commits which should be split into separate commits (e.g. 'changed comment', 'fixed bug', 'renamed method', etc.).

The way I did it was by:

  • Bringing it up with my managers in my annual review (your point 3).
  • Sending an email to the developers in my department saying I was writing a standard and asking to see if they had any suggestions/thoughts (your point 1).
  • After finishing the final draft, sending it out to ask the developers then asking for feedback.
  • Arranging a meeting for people to discuss openly any changes they thought might be beneficial (I bought a small box of chocolates to the meeting in order to sweeten the deal).

While it's not been a complete success, the way the department uses source control has definitely gotten better as a result (I think).

If I were you (and depending on how many people you have to influence), I'd talk to as many people as possible, let others know you're doing it (it might earn you brownie points with management for showing the initiative), and thoroughly research any changes you want to make: that way you can make others see why they should follow your suggestions.

edit: I should point out that there are about 15 developers in the department I work in.

  • Bring it up in an annual review is the first step? Doesn't that imply a maximum possible delay of one year? – Robert Harvey Feb 8 '15 at 16:47
  • It was about a week before the review that I decided to make the change. In @HamsHroon's case (depending on his circumstances) perhaps he could bring it up with his managers in an informal way? – Wai Ha Lee Feb 8 '15 at 16:57
  • Just updated the answer with the team size- About 50 people spread across multiple teams. – HamsHroon Feb 8 '15 at 17:46

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