I come with a clear agenda on how to code correctly. I used to be a team leader, and I managed using significant amount of mentoring to create a team that creates high quality code.

Now I have 3 teams under me, each one has its own team leader. My time is mostly spent on strategic meetings and I can't devote enough of it to mentor my teams.

Once I do get to see code or design, I usually finds flaws in it, but I get to see little of that and I am afraid that all the code I can not see is designed or written poorly.

How can I make sure my teams produce great code?

Note: I am not in the position to fire anyone.

  • 1
    one option is another team that does nothing but QA, (or have teams do each others QA) – ratchet freak Feb 6 '13 at 23:26
  • You're not in a position to fire anyone, for financial reasons, or you just don't have that authority? And are the three team leaders from your previous team or not? – pdr Feb 7 '13 at 0:08
  • 1
    for more comprehensive info read the books 'code complete', 'project survival guide' and 'peopleware' – Imran Omar Bukhsh Feb 7 '13 at 0:43
  • 1
    Honestly - just let it go. Concentrate on your new job and let the team leaders worry about code quality. – James Anderson Feb 7 '13 at 2:04
  • 1
    You should only mentor your team leaders, so they can do a better job of mentoring their teams. Teach the teacher! If there isn't enough time to do so, cut back on the strategic meetings. Many of them are ineffective brain storm sessions that could be a lot more effective if everybody came well prepared and each meeting had a very focused question to answer. – Marjan Venema Feb 7 '13 at 7:45

People often confuse quality control (testing) with its sibling quality assurance. (See QaIsNotQc) The latter is about the processes that assure that the product (in this case code) is of a high quality.

Accepting and understanding quality assurance processes is key. This often has the scary (at least to developers) concepts of governance, ISO, CMM, and the like.

Use tools (sonar, pmd, findbugs, checkstyle and the like) that help identify problems with code. Sonar in particular has a technical debt plugin. Use it, keep that number low. Sonar has a nice dashboard that managers can look at and go "oh, that's ugly."

Remember also from your days as a developer the negative impacts on code quality. Shortened time lines, poor estimates, over commitments. Strive to make sure these things don't happen. Schedule time for cleanup of code.

  • 2
    +1: I highly recommend a CI platform (e.g. Jenkins) with Sonar. It gives nice management-type overviews as well as allows developers to target specific parts (hotspots) that need improvements – Deco Feb 6 '13 at 23:59
  • 3
    +1: "Schedule time for cleanup of code". If only more managers would do this :-) – Amadeus Hein Feb 7 '13 at 7:37

You know the answer. You've used mentoring in the past, mentoring has worked well. Strategic meetings are preventing you from doing mentoring. Cut down on the strategic meetings to do mentoring well. If you can't cut them, or delay them, or delegate them then you need to decide how to balance your time. What matters more?


Can you trust your team leader on each team? Are they good enough so you could trust to look after the codebase? If so, I guess you could have each of your team leaders to pair with the developers to kind of control the quality of the code. After pairing for a while your whole team should be familiar the coding style or standard of the code you're looking for. This will help you delegate your work to your team leaders as well. And if you have some time then come and pair with the developer or organise some code review session. This will help spreading out the standard you're looking for faster than pair with each one of them.

Or you could mix people who you can trust that they are strong and have them paired with the other junior developers.

Or one thing that I find the most interesting is coding-dojo session.


The best way to improve quality is to offer incentive. The carrot always works better than the stick for motivation. Give the programmers an incentive to improve their quality, find their own bugs, produce elegant code. You have 3 teams, make it a competition. Get them to code swap and debug each others code, then have some sort of awards for most bugs squashed, least bugs produced, etc. Make it something they want to do.

  • 1
    I agree incentive is often better than the stick, but sometimes if you go down this route the Carrot just has to get bigger and bigger and bigger and bigger..... – dreza Feb 7 '13 at 1:57
  • A good point. That is why the holy grail is the self regulating carrot. If you can get healthy competition between teams, they can continue to strive to be better than one another. But this has its own problems. Basically there is no catch all, and sometimes you need stick to remind people how much they shouldn't take their carrot for granted. – Bergasms Feb 7 '13 at 1:59
  • See badges for project team members for motivation at PM.SE and The Econ 101 Management Method from Joel on Software. – user40980 Feb 7 '13 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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