I'd like to apologize in advance for a lengthy problem description, however I am interested in the community's opinion and I'm asking this from the employer perspective.

My company deals primarily with software products aimed at insurance market which has secured us stable financial future for the upcoming 5 or more years, and since there were only 3 of us working at the start - we decided to expand our small IT company and area we work in and we began hiring about 1.5 year ago - and that's when the problems started. We are between 27 and 30 years of age, me being the oldest at 30 years.

The problem we're facing is lack of motivation and interest in our developers. People hired are offered excellent work conditions (in my opinion):

  • high and competitive salary (2x the country's standard, one's able to get a car, a 2 bedroom apartment and sufficient leisure money and even save up)
  • no education requirements except years of experience (we hired people with min. 5 years of exp.)
  • there's no classic boss who yells at people, nor are there any repercussions and developers are welcome to dispute ideas and propose their own at any time
  • We are not tied to a particular technology nor do we suffer from "older version" syndrome, we tend to adopt newer version of the software stack we work with, therefore new ideas, new methods are always welcome and encouraged
  • We expect developers to work in teams promoting redundancy, we strive to have no "bus people" (people of importance who, if hit by bus, no one can resume their work)

The issue we're faced with is that trough award program we have (bonuses for successful project completion), we're not getting the results we need from our developers. Even though we have reading material bought and ready, there seems that no one cares to educate themselves and up their knowledge. The code produced is faulty, it's not even testable, and our latest project was almost cancelled due to sub-par production. None of the developers have any sort of personal satisfaction of completing the projects. The usual tasks we're involved with is UX, UI design (JavaScript), performance problems, parallel processing etc. which in my opinion is rather interesting but still there's underlying problem which people seem to "avoid" and that's that everyone have to write the actual code after they lay foundations to solve the problem, no matter how boring that might be.

Question is - how do other managers in IT companies deal with this kind of problem? We tried motivating people trough awards (more money essentially) but I'm slowly favoring the method of punishment and letting people go and hiring new ones. It seems overly aggressive and I'm afraid it might cloud the atmosphere we're trying to build. If anyone can shed some light or an advice, no matter how small, I'd be grateful. We're obviously young and would like to expand, however there's this barrier we're faced with and before expanding we have to come to terms with a team of this size before creating a bigger one.

  • 1
    2x the country standard for similar positions? Or 2x the country standard? There is a big difference between the two :) – Rob P. Jul 23 '13 at 11:20
  • @RobP. 2x the country standard for similar position, my bad :) – user2601913 Jul 23 '13 at 11:26
  • 1
    Well...for two times the country standard, you got any position available ;) – Michael Grubey Jul 23 '13 at 12:07
  • 2
    I think the issue is with the hiring process. You only require 5 years experience i can sit around from job to job doing nothing for 5 years. doesn't mean im good at what i do, it just means i have had a job for 5 years. are their any entry tests? to check their ability to code? If you hire people with bad coding abilities, youll get bad code, regardless how long they have been in the field for 5 years or 500 – Rhys Jul 23 '13 at 13:26
  • 1
    If you aren't satisfied with code quality, working with the new hires on programming methodology may actually improve morale. it would not surprise me if the newer people feel like they have been 'processed' from one role to another their entire life, and no one has taken much interest in what they actually do. The point is not to impose 'standards', it's to show the programmers problems the coding examples create and bring them up to speed on better ways. Some might take this personally, others might latch on to the improvements. – Meredith Poor Jul 23 '13 at 20:42

How can you make this statement

there's no classic boss who yells at people, nor are there any repercussions

and expect people to perform? There's no need to yell, but there have to be consequences for not getting projects completed. If you offer what you claim to be very good salaries, the bonus is not going to be as important.

If you honestly believe you have created an environment for developers to succeed, but they fail on projects, they have to go. Of course we would like to hire the best people who do great things all on their own, but that's not always easy.

Start setting standards. Code quality, testing, customer approval, learning new technologies are required to not only get a bonus, but to keep your job. You're offering a great opportunity for a programmer, but they're taking advantage of you.

| improve this answer | |
  • 1
    A million times yes! Managers who have no repercussions for substandard work only get substandard work. And trhey are not doing their job as managers. It is nice to have this fantasy that people don't need to be managed, but it is a fantasy. – HLGEM Jul 23 '13 at 13:48
  • Note that this doesn't have to start out confrontationally. First port of call should be a company meetings to say "we're not hitting standards and will be watching more closely in future", after which you can move on to assessments for those who still don't perform. One thing I've noticed in startups is that performance reviews are often skipped. This is generally a bad thing, as not only does it let the employer assess the employee, it gives the employee a forum to air any issues. There may be problems you're just not aware of... – Basic Nov 15 '15 at 17:03

I'm afraid I'm not a manager so can't answer from a managers perspective, but here are some thoughts for you:

  • Have you asked the team what the problem is? If you get them down at the pub or somewhere informal and have a proper open discussion often you can learn a lot.
  • Ensure that your team aren't overworked, if people are under a constant pressure to deliver then you'll find that corners often get cut, quality goes down and professional development/education - well there just isn't time in the day for it. Poor code quality can be a result of poor estimates, with fixed deadlines. It's very hard to make accurate estimates (especially if you've still stuff to learn in that particular domain). If those deadlines are fixed once estimated however then again this can lead to poor quality e.t.c.
  • Consider some training courses and taking time out from the day job if peoples skills need updating, or have someone do a presentation on Test Driven Development as a new way of working to try and improve quality.

Honestly, I don't take satisfaction from completing projects if I feel the code is to a sub-standard quality but I can't fix them for some reason or another.

You also mentioned rewards through money. Money serves as a great incentive up to a point, once people have enough (ask your team) then it no longer motivates people. Instead take a look at this blog on codinghorror.

| improve this answer | |
  • 1
    >"have someone do a presentation on Test Driven Development" - Usually that's useless. Pretty often the developers are actively discouraged from spending time on tests, maintenance or technical debt. Presentations won't help here. My previous employer had plastered the whole office with "growth mindset" stickers. That does not help a single bit is the management is against that. – Ark-kun Dec 28 '18 at 2:30

Not the answer you're looking for? Browse other questions tagged .