6 ms·
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 fe
by jwheeler79 12y 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 12y agoThere 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.
- cpncrunch 12y agoDo they actually manage to get all the bugs fixed in a reasonable time? There is nothing wrong with working an 8 hr day with breaks in the middle, if they get all their work done. Question: what type of job do you do, and what hours do you work? (To be honest I'm wondering if you are a bit of a PHB, although I'm giving you the benefit of the doubt :)
- duochrome 12y agoFire the team manager. Promote a new one within the team.
- sheepmullet 12y agoWorking 10:00am - 6:30pm or 10:30am - 7pm is an 8.5 hour day. Lets say they have a 30min lunch break and stuff around at the arcade/gaming area for an hour. That is still a solid 7 hours worth of work each day! So 12 developers each working a solid 7 hours each day but unable to produce quality work within a reasonable time frame. That says one of a few things: 1) The team is working hard but you have a lot of crap code (aka technical debt) and so it takes a long time to make even simple changes. 2) The team has implemented more thorough processes. E.g. Previously they might have went straight from coding a fix to putting it into production but now they have proper QA and Testing phases. So now it looks to outsiders that they are "complacent" when they have really just improved processes. I would never give a business person an estimate of anything less than a day. 3) Politics/dynamics between the dev team and the rest of the office have changed. For example if management had a serious go at the developers for a defect in production or business users have been passing the blame onto developers, or everyone got pay rises/bonuses but the devs, etc then it is likely they are operating in an extreme risk averse, document everything manner. I know entire dev teams who have stopped being productive because business stopped listening to them. 4) Team politics. Are one or two of the developers/managers doing something that is really throwing the other developers out of joint? 5) The team is productive and business expects too much or is only looking at superficial indicators. For example you keep mentioning standard working hours as though working 8 hours is being lazy. The devs having fun at the arcade/gaming area. The rest of the company "grinding" etc. It almost looks like you care more about shared misery than results. If you bring in a new developer and they are significantly more productive than the existing team then you could rule out 1&2&5.
- jwheeler79 12y agoman, it sounds like they got you by the balls then. if theyre playing video games all day you should say, "hey guys, stop playing fucking video games all day" or something like that.