5 ms·

Ask HN: What can be done to fix a dev team that has become complacent?

15 points by sv_throwaway 13y ago

Our dev team is no longer producing quality work at a pace fast enough for the business. They're complacent. They give estimates of days versus hours for even the simplest of asks, and when outsiders hear how long it took for our team to fix a bug or add a new feature, they are shocked. Extremely competitive pay, free food at the office, catered meals daily, activities, video game areas, arcade, lounge areas, and work-from-home flexibility are used by all extensively... but none of those things actually motivate the 12+ men and women on this team to work to get the job done.

shellab 13y ago
It sounds like the code might be part of the issue. If code isn't developed in a way that makes refactoring easy then as time goes on the code becomes more complex and it's harder to add even simple features without breaking stuff. You may want to look for a developer who knows how to refactor legacy code. If someone recommends a rewrite it's almost always a bad idea.
DigitalSea 13y ago
Have any of the managers/developers been confronted on their complacency, and if not, why? Sadly, you can't just fire someone without first giving them a chance to turn things around. Nothing motivates better than fear, but it can also cause people to become resentful towards the company. You need to pull each employee aside, especially the manager(s) who should be ensuring efficiency is kept at acceptable levels. This sounds like a double-edged problem. Employees not realising they're dropping in efficiency and managers not noticing the drop in performance and also failing to do anything about it if they have noticed. Sounds very much like a safety in numbers scenario at the moment. All you need to say is, "Hey, we've noticed you're not performing as well as you have in the past. Is there a problem we are not aware about, is there anything preventing you from doing your job properly? Lack of resources, lack of proper tools, personal issues? Are you being asked to do too much, is the work too difficult and is there anything we can do better to make it easier for you to do your job?" but at no point should you start pointing fingers and placing blame upon people. Talk to your employees like you would your best friend, only more professionally. Free food and a great environment shouldn't be the only motivators the company offers by the way. It's like those code hackathons that offer free pizza, beer and cans of Red Bull, just because you're giving away free stuff, doesn't mean you are entitled to overwork or unreasonably expect more from your employees or those around you. If the work isn't stimulating or challenging people will grow bored as well, there is usually more than one answer to a problem. Are unreasonable time frames and expectations being placed upon your employees? If you're asking for things to be done within 2 weeks, but it should be a 3 week job, who is to blame? The business imposing unreasonable time frames or the employees who have to try and get the work done within said time frame? The fact you're saying it's a twelve person team and it's the whole team to me signals it is a management problem. Solve the problem at the top and you'll most likely notice the trickle down effects to the rest of the team.
- cjbprime 13y ago
  I agree with almost everything you said, but: > Nothing motivates better than fear Seriously?
  - DigitalSea 13y ago
    If you confront someone who is deliberately not doing their job correctly and it is their fault, the fear of losing your job is greater than all in my opinion. If you're knowingly slacking off, maybe fear is what you need. I don't agree that fear is an excellent motivator in all situations, but in some situations it is warranted. It is no different than receiving a legal letter asking for payment because it is 2 months overdue. The legal letter is a fearful reminder you need to pay and it's sad that some situations call for fear tactics, but sometimes you need to understand it is how things go.
    - lancewiggs 13y ago
      Fear can be a motivator, but it can also backfire. The motivation may be to wok harder, but also to leave, seek legal redress or become even more demotivated.
    - RollAHardSix 13y ago
      The problem is in the workplace environment, where one's own personal liability and livelihood is at stake, fear will only serve as a reason to find a new position. Personally if I was involved in any type of one on one like you mentioned, I would go home and start putting out resume's that day. You just can't take the chance of being fired later on, plenty of companies will use the 'you're not performing' bit to motivate employees to work themselves far beyond what they should be working even on a regular schedule.
sharemywin 13y ago
why not ask instead of second guessing them. could be other priorities. could be testing to make sure things aren't going to break. the code could be unorganized. if everyone one for several years has been slapping code in might be hard to work with like the other comment mentioned.
j4ck4l 13y ago
looks like there's waste happening in that team... sounds like they're taking an extreme attitude... this usually happens when they experience the opposite extreme of being pressured with unrealistic deadlines and work... so the team finds estimates the only hope of protection from "outsiders"... Need to build trust that the management is not out to screw devs and that devs are not there to waste time but can get job done... a suggestion would be to get priority on all items and realistic estimates and have daily/weekly cadences to track/plan for them... Below are some relevant principles of the agile manifesto: -Business people and developers must work together daily throughout the project. -Build projects around motivated individuals. (Give them the environment and support they need, and trust them to get the job done.) -The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
alexnking 13y ago
"Our dev team is no longer producing quality work at a pace fast enough for the business. They're complacent." B does not follow from A. Just because your team is not producing "fast enough for the business" does not mean they are complacent. It may simply mean the business has unreasonable expectations. Outsiders (especially non-developer outsiders) cannot really give you any insight on this, as all codebases are different, and the time it takes to fix a bug or add a feature will vary depending on the amount of technical debt and complexity that have accumulated. Your team however, is in tune with your codebase, and appear to be able to tell how long things will take (you don't mention that their estimates are inaccurate, just that you dislike the estimates). If you would like the amount of time it takes to be different, perhaps instead of assuming they are complacent, it would help to ask what needs to be done to make changes to the codebase faster. The answers you get (such as a higher level of test coverage to increase change confidence) might surprise you.
sv_throw2 13y ago
Have you tried blocking the internet access to HackerNews from the office?
bnolsen 13y ago
it may be collective burnout as well. Can you shuffle their responsibilities? Try to get them out of the office sometimes instead of keeping them there?
jwheeler79 13y ago
have you ever considered the problem might be you? i mean, just your attitude that 12+ people have something intrinsically wrong with them seems a little far fetched, doesnt it? maybe you have a stupid idea, and youre developers are happy taking the money but cant stand your ideas or you. sorry to be blunt but if you think the problem is 12 other people, you probably need a reality check, fast.
- sv_throwaway 13y ago
  There are 68 people total in this profitable multi-tens-MM/year net revenue company and everyone outside of the dev team is frustrated. When the arcade/gaming area is packed for several hours a day while everyone else in the company is grinding on their respective jobs and we are filing urgent, revenue jeopardizing bugs, complacency is the only logical conclusion. The dev team is the only team that comes in at 10 or maybe 11 or sometimes 1130 then have "hard stops" at 630 or 7. In the org chart, I'm unrelated to the dev team, but have visibility into that side of the org.
dmourati 13y ago
Start over.
cynthiakellogg 13y ago
Sounds like a management issue. Make sure whoever leads them is making clear requests (who is responsible for the task, what is the task, how is completion of the task measured, when should the task be finished) and that will give you a framework for communicating expectations and you can measure performance on it. The developers can negotiate the timing of it - but always make sure they give you specifics, "I can have that done by Friday at 5pm". It's a simple thing to do, but leads to powerful results.
aytekin 13y ago
In real world, if a worker sits all day and reads newspaper or chats with friends you can easily see and prevent it. In dev work, you don't see it. One of the commenters at HN was proud of how smart he is that he can work half an hour a day and coast the remaining time. So, the best solution is to make things visible. Make everyone's work visible to everyone else. Daily agile meetings/reports are one way.
mh370survivor 13y ago
May I humbly suggest a productivity app built on nudge theory? http://belimitless.co/ http://belimitless.co/ The ~ 25K users of the app seem to be happy and claim that their productivity has increased a little bit.
esw 13y ago
>They give estimates of days versus hours for even the simplest of asks, and when outsiders hear how long it took for our team to fix a bug or add a new feature, they are shocked. Unless you're a developer who is familiar with the codebase, then you literally have no idea how long it should take to implement these changes.
jmspring 13y ago
This feels like one of those cases of second guessing the development team or having pushed them to get the first iteration of something out there and then expect the same super human effort every time. It doesn't scale. Teams can certainly ramp up for short bursts, but more often than not there are PMs and other managers that think that should be the norm rather than the exception.
qpeoii 13y ago
First, have you communicated your concerns with the dev team or dev team leads? They might not even have the same perception of their productivity as you.
sixQuarks 13y ago
Dude, you're asking this question to the wrong crowd (as can be seen from the backlash). My advice would be to pay to talk to a mentor who has been through this problem - use http://www.clarity.fm http://www.clarity.fm (I have no connection to this site). They have some of tech's most prominent business guys willing to talk to you for an hour, at between $1 to $5 per minute. I've used it and it's worth it.