Iyfjky

Question

I manage a small company and find most - if not all - employees keep repeating certain mistakes. This is a young team and in general we have a positive office ambiance going on. But I want to find a way to weed out unnecessary mistakes.

There are two main issues:

Not properly updating tickets. There is a clear policy that states that tickets should either be finished on time or deadlines should be changed. Also, after certain work tickets have to be updated. Too often this does not happen and results range from simple inconveniences of not having updated data to unsatisfied clients.

Repeating mistakes or forgetting tasks. These include repeating the same programming mistakes, making the same mistake in certain office procedures, or forgetting some office-related tasks repeatedly. Examples: not scheduling a meeting with a coworker to discuss a joint project, and then requiring last-minute, unplanned meetings that interrupt everybody's schedule, or not turning off the power outlets before leaving (sounds silly but we have had several equipment-damaging surges at night).

Please note that the required procedures, guidelines, and standards are all well-documented or clearly explained.

I have discussed the importance of these issues, and everybody pretty much agrees and understands this -- but that did not eliminate repeated mistakes. I tried introducing having to do uncool tasks when not complying, which worked for a little while but now we're back to where we started.

At this point I am considering providing a (monetary) incentive for those who achieve (near-) flawless results (note that this does not apply to overall work performance, it's just measuring whenever somebody breaks clearly-defined protocol, so flawless performance should be achievable).

Anyway, I'm wondering how others have dealt with this problem. Is such an incentive a good idea, or other there other methods that you have successfully employed?

"not turning off the power outlets before leaving (sounds silly but we have had several equipment-damaging surges at night). " sounds like time for management to buy an UPS. — Aug 17 '12 at 2:43
No matter how clearly-defined your protocol is, human beings are never going to follow it perfectly. If you want perfect adherence to a protocol, then replace the humans with computers. If that's not practical, then automate as much of the protocol as possible so that the humans aren't the ones responsible for remembering to follow it. — Aug 17 '12 at 5:07
If you haven't already, I would strongly suggest going out and buying Peopleware and The Mythical Man Month. Even if you have them already - re-read them, it will do your management abilities a world of good. Also, beware extrinsic motivators (monetary incentives) as they may not have the desired effect. — Aug 17 '12 at 14:10
it's quite a pity to see so little upvotes (and even downvote) to this question. If anything, it deserves a respect as a "prelude" to this wonderful answer — Aug 17 '12 at 14:14
BTW, "everyone agrees" doesn't necessarily mean that they actually agree. It could just mean that they have given up on really talking to you. How well do you handle disagreement? — Aug 29 '12 at 6:39

score 99 · Accepted Answer · 2012-08-17 04:18:18Z

Fix the process

If there is a problem with the majority of the employees, It's a management problem.

Either you are not paying enough to hire people capable of doing the work, or you are treating the workers badly and they just don't care, or your processes are poorly designed.

Not properly updating tickets...

Why isn't this happening? Is your ticketing system annoying to use? Are the workers so busy that mundane tasks are frequently omitted to deal with urgent tasks? Have you asked the workers for suggestions?

Repeating the same programming mistakes again...

What sort of mistakes? Do you have any code review process in place? Are you using any automated tools to prevent these mistakes? Is it easy to do the right thing, and hard to do the wrong thing? If not, why not? Why aren't these mistakes caught by unit tests?

making the same mistake in certain office procedures...

Why haven't you automated those procedures? You can't expect programmers to be good at executing repetitive procedures. They hate doing that, that's why they became programmers.

not turning off the power outlets before leaving

This is a hardware problem. Buy surge protectors.

"If there is a problem with the majority of the employees, it's a management problem" I would upvote this twice if I could. And your other points are very well taken — Aug 17 '12 at 10:20
You can't expect people to be good at executing repetitive procedures. - That is exactly why you have programmers — Aug 17 '12 at 10:41
People, even highly paid, highly trained and highly motivated people CAN NOT remember large numbers of things to do for particular tasks. Hence the evolution of checklists for the pilots of aircraft: atchistory.org/History/checklst.htm — Aug 17 '12 at 14:57
Checklists apply to medicine, as well as to other fields including software development. Atul Gawande wrote a book on checklists called The Checklist Manifesto. — Aug 17 '12 at 16:43
@Chad - If you're resorting to firing people over non-conformance like that, then you have bigger problems, and you're only getting conformance at all because of fear, and you've destroyed company morale. What's going to happen as the economy improves and your employees no longer fear losing their job? — Sep 4 '12 at 20:32

Communityâ™¦ 1 · Answer 2 · 2017-04-13 12:48:42Z

Kevin's answer is phenomenal, but I wanted to add some thoughts of my own.

My company has recently started using a ticket system company-wide. Prior to the company-wide implementation, we had a few people already using GitHub, and doing so with great success.

The manager in charge of getting a ticket system decided to go with what he knew, instead of seeing what we were familiar with. The result was a ticket system that was annoying as hell to use, overly complicated for users (there were like 20 fields to fill out or otherwise change for a ticket, finding the status update field was difficult, and it was all-around not a pleasant experience). The developers hardly touched it and it fell apart within a couple of weeks.

We then decided to switch to GitHub, since that's the platform all of the developers favored. It also offers more free-form fields (and fewer fields in general), and an API that we could use to build a more structured ticket entry portion for the non-developers (to help get the right information out of them). So far, it's been used quite a bit more extensively.

The moral of the story here is that developers will use something if they feel it adds value and doesn't waste their time (time better spent fixing the problems you hired them to fix), but if it doesn't, very few incentives with coerce them into using it. For developers, productivity is king. If it hinders productivity, then it will be abandoned if the developers have anything to say about it. Talk to them, see what they use naturally, or what format they're most productive with, and do what you can to accommodate their needs. The developers, after all, are the ones making your product work.

And I concur with the sentiment about the UPSes. You're a business. Your hardware is an investment. Why wouldn't you take the necessary steps to ensure that your investment is protected, especially if you know that your power is unstable?

Another thing to consider, too - are there actual reasons for these policies (ie - are they all like the power issue, or are there any arbitrary ones), have they been adequately explained to everyone, and are people satisfied with the explanations and solutions? (And, for that matter, have you listened when they suggest solutions?) Programmers are creatives. We're also problem-solvers, some of us compulsively so. We don't take well to top-down authoritative directions with no apparent reason for them. If you want compliance, you have to show that you're willing to consider our solutions when we propose them, and provide good reasons for making the decisions you make. You hired very smart and talented people, don't treat them like monkeys.

Just a quick ? about using GitHub for issue tracking. As I understand it, you can just do this for each repository, right? Or is there a way to use it as a standalone issue tracker? Or did you just create an empty repository for a project/workspace? — Aug 29 '12 at 23:05
The anecdote is still the primary part of the answer and really does not add anything. Anecdotes should support the answer not the answer supporting the anecdote. — Sep 5 '12 at 17:09
@Chad - Then I think we'll have to agree to disagree. The anecdote is intended for illustrative purposes not only for my own response, but for other responses (as I said, Kevin's answer is great, and I fully support that it got upvoted, marked as the answer, and given a bounty; I initially thought about making my response a comment, but it would have required several comments, which I thought was more inappropriate). — Sep 5 '12 at 17:19
@Chad - The comments aren't supposed to be "chatty" either, so just vote down the answer if you don't like it and be done with it. — Sep 6 '12 at 18:54

maple_shaft 15.8k75296 · Answer 3 · 2012-08-17 13:45:35Z

A good general doesn't blame his soldiers when they lose a battle. Likewise a good manager takes responsibility and makes actions when the team is not performing its best. A good manager when faced with a problem removes obstacles for the team so that they are able to do their job.

When an employee screws up, a good manager tries to figure out how to fix the screw up, and then works with the employee to find out what happened so that similar problems can be avoided in the future. A bad manager looks to pin blame or find excuses and scapegoats.

I may be implying your attitude incorrectly but I feel as if you are convinced that the problem lies in your employees somewhere. You should be skeptical about this, because it is unlikely that nearly all of your employees are low quality. Sure it is possible, but even if that were the case then it was either your fault in picking the team, or if you had no say in the team then it is a blameless obstacle that you must lead your team through to success.

The very first step is that because it is ultimately your responsibility now that you need to assume these team failures are directly your fault. The next step is taking proactive steps to remedy the problem. Some of the solutions may not work, if this is the case try something different until you start seeing improvement.

Joshua Drake 22749 · Answer 4 · 2012-08-17 15:18:39Z

I concur with the majority of what has already been written.

It appears that you need to change the process around ticket updating, and you certainly need to purchase some surge suppressors, upgrade the office's power system or possibly relocate to better facilities. I also have seen in practice that code reviews significantly reduce the number and impact of mistakes made by developers.

However, I believe that

repeating the same programming mistakes again

is the developers' responsibility, and needs to be addressed by each developer individually.

One method I've successfully used to reduce my own mistakes is tracking them. Simply keeping a .txt file on my desktop and adding lines to it describing my mistake, e.g. Closed outlook when I intended to close a single message., has had a positive impact on my personal error rate.

Another tactic would be to share the techniques you use to avoid repeated mistakes in your own work. This may include having the better performing team members share their own practices.

Showing the team support by making the initial changes above, and sharing your personal struggle to meet the same standard that you hold them, while equipping them with best practices from yourself and their peers, should go a long way toward instilling the desired ethos.

bethlakshmi 70.4k4136277 · Answer 5 · 2012-08-31 13:42:32Z

Here would be my steps, based on successful cases of continuous improvement I've seen implemented in level 5 CMMI shops. I believe processes like Lean Six Sigma focus on a similar approach, although (based on casual observation) with a slightly different nuance.

Examine your current state

I bet that it's a no-brainer in the cases that you mention that harm is caused when people don't do the process properly. The big question is how much harm? How often does this happen? What is the magnitude of impact when it does happen? How does that impact affect the big bottom line? Everyone probably understands that these problems cause "some impact", but when you can put some hard numbers to it, you can see how big a problem you've got. Saying "we loose customer faith when we don't update change tickets" is one thing. Saying "we could have sold X many dollars more of our product/service" if customers had more faith in our process is a lot more urgent. It also tells you how much money/time you can spend trying fix the problem. No one wants to spend $100 worth of effort on a $20 problem.

Also - however - look for patterns in your failures and successes. I'm willing to bet that not EVERYONE does this wrong. Or, if everyone does it wrong, do they only do it in some circumstances? If you have problems with a specific group, or under specific conditions, see if there's something you can do to address that specific case, rather than trying to change situations that don't need changing.

Involve the People Who Need to Change

When you've got the data, get key people together - you may end up with a few meetings, if you have a big organization. One meeting is the people who need to change, who need the option to discuss this in a penalty-free way. In other words, they need the latitude to grime, complain and come up with wacky ideas without management freaking out at them. But they probably need a moderator to channel the discussion to productive ends instead of just complaining.

You may also end up with meeting with other key people - if it's the tool that it causing grief, you may meet with those who maintain it. If it's a two-group problem, you may end up meeting with both groups separately and then together. The big deal is to be cognizant of the fact that different groups come to different conclusions depending on who is in the groups. Use that to your advantage, not your disadvantage - the wrong people put together too early in the process will kill it flat out, but the right people will come up with some brilliant ideas that may even be cheap and easy to implement.

More important is giving people the chance to feel like they took a shot at solving it - most successful programs for change involve the people who need to change so that the effort becomes their effort and not something foisted on them from above.

Monitor and Give Feedback

Whatever metrics you used in the first step are ideal here - which means that although you may be monitoring the low level (# of status updates, etc) - what you REALLY want to pay attention to is that bottom line, as well. You may make the detailed change you want and still not get the payoff you are looking for - and it's important to know that. In my mind, this connection is what separates good managers from the pointy haired boss in Dilbert - that they are clever enough to look for the impact their people make and point it out to them. There is nothing headier than a victory in this area, and knowing you have failed helps you to figure out what you can discard as useless the next time you want to see change happen.

When giving feedback, consider that how you give feedback and to whom has a huge impact on the effect. Saying "this is urgent" when you body language says "I don't care" can be worse than saying nothing, and mailing the team when only one person is failing to comply reassures the one person that this is a group-wide problem when it really isn't.

Carrot or Stick

You'll see almost none of the work involves either an incentive (carrot) or punishment (stick). The modern management take on this is that how you lay out work, and how you get people involved in it is more motivating and effective than the carrot and/or stick approach. The general thought is that most people want to do their jobs, they just need guidance on what "doing the job right" means.

There's an exception for every case though, as you get into this approach, you'll see it takes a heck of a lot of time to get it done right... it's not a 20 minute task by any means, and some of this (like the metrics collection) is intense, data-driven work that most managers don't have time to complete on their own... so you're going to need help. In addition, you're probably going to hit the outliers on your bell curve, who really can't manage to do the thing you want them to do, even when the rest of your demographic has adequately turned the corner on making change a reality. That's where the carrot/stick strategy may work out:

Carrot - when someone goes above and beyond the call of duty. It is not above and beyond if you say "do this" and they do it adequately within their skill set. Incentivize "doing the job" and you'll be in a never ending, demotivating cycle. But if someone suggests and then seamlessly implements great new ideas, taking ownership and going above and beyond to nail down issues above their pay grade - make sure this gets rewarded come bonus time. And be specific in your praise, since you want to make sure that this excellence continues.

Stick - when you have ended up with an outlier that simply can't do the work that everyone else can do, it's time for the stick. To be effective, a stick has to be a real penalty. Doing the lame work that no one likes is not really the penalty you are looking for - it can easily be misinterpreted, and you can end up with an employee who never really does the job correctly. You're going to end up in the realm of docked pay, negative performance reviews and (if the issue is big enough) talk of termination. The things you mention are part of doing a good job, they are not "bonus work". They are having a negative impact on the business, and if this guy can't do what other people can do, chances are you can find someone else who can perform better on the open market.

I'm harsh on both the carrot and the stick here, because the two issues mentioned in the question are baseline for a good process. Both of these can have serious impacts for the company and it's in the mainstream expectation for the average worker to be able to both of these properly. If you were talking about a new "ideal practice" that was innovative and therefore had a higher chance of not paying off, my thoughts on what the bare minimum that the average person can do right off the bat may be more lenient. That said, when you've innovated and proved it's a huge value-add and you have people who can't come up to the new par... do you really want to pay them for sub-par work?

+1 for Carrot and Stick. A good process will drive itself once it is proven. You need the carrot and stick to get it started, and make sure that those tempted to slack off stay on track. — Sep 5 '12 at 13:52

Michael Durrant 9,68122856 · Answer 6 · 2012-09-06 03:27:38Z

Focus on Results.

Getting into personal issues, habits or even attendance at meetings is frequently counter-productive.

I recommend you focus on one thing - the product(s) and the users you serve. All of your policies should stem from that. If someone missed a meeting and then a deadline was missed you ask the person why it the deadline missed - was it related to the missed meeting? Why did they miss it? Did they speak to the other person or people separately? Do they have other issues not mentioned?

The hallmark of a great manager is one that listens.

The hallmark of a bad manager is one that dictates procedures.

When you speak about things to the whole company look to be talking about your products, the needs they are meeting, the features you're focusing on, the deadlines ahead. But stay away from attendance / ticket issues / documentation issues.

Remember the golden rules:

Nothing negative by email.

Nothing negative in public.

Focus on the end results.

Treat employees well.

Provide support and training

Provide snacks and treats.

Kate Gregory 105k40232334 · Answer 7 · 2012-09-06 13:15:53Z

As long as you frame your problems in terms of your employees being the problem, it's going to be difficult to address the problem. No amount of yelling "Change!" at a person is going to result in changed behavior.

As people above have stated, it is a management issue, but more importantly it's a system/process issue. I mean, you could be the most motivating manager ever but if you're using a flawed ticketing system then expired tickets are going to fall through the cracks.

In fact, realistically, the fact that this is happening is almost a good thing. Why? Going in to expired tickets and updating them with new expiration dates is time consuming and, to be fair, relatively trivial in terms of work skills. If your workers aren't doing this it suggests that they're probably busy spending their time on more productive work.

If you have any kind of control over the ticket system, I would amend it so that:

each morning it pulls up expired or near expired tickets

finds the worker assigned to that ticket

lets them know it's about to expire and invites the worker to push it forward, including offering a default extension date so the worker doesn't even have to calculate what the date would be next Friday or whatever

If this was a single e-mail each person received daily, and the process took under 5 minutes, you'd probably see people doing it regularly.

If it's still a problem, add a nag screen when they go to the ticket system, so if there are outstanding expired tickets a little alert pops down from the top of the screen.

Integrate using technology as much as possible. For example, let's say that the ticket is to alter a person's record. Before they go to the form, a small popup could ask them if it is related to a ticket, and if yes they just punch in the ticket number. Then, once the record is saved, the ticket is automatically updated to reflect the changes just completed. If it's code work, integrate the ticket system so that each time they check in code, or build, or whatever, a message is sent to the ticket system. So all they would have to do is indicate the ticket number when writing the commit message (there are many IDEs that will do this for you).

If co-workers are working on a joint project, they should be encouraged to be in more constant communication so that they don't have to schedule meetings last minute. Maybe even set up specific times each day devoted to collaboration (say 10:30-11:30, that gives people enough time to take care of initial business for that day and leads up to lunch so if the collaboration goes over they can even continue chatting over lunch and keep the ideas percolating). Send a quick alert via whatever instant message system you have (you do use some kind of IM system, right?!?) reminding people it's collaboration time. You might even remind people of the joint projects they're working on.

You're a manager. It's your job to be organized and to keep projects, schedules, tasks, etc. all in your head. So maybe you're expecting all of your workers to do the same. Realistically, not all of them will be as good at it as you are. So set up systems that offer constant reminders. The ones who remember well will probably not need them and can switch them off. The ones who don't remember will welcome them as effective ways to keep them on task.

JohnMcG 1,8561818 · Answer 8 · 2012-08-17 17:48:48Z

Assuming these are all legitimate mistakes that are the fault of the employees and not the process, a system of peer accountability seems be in order.

If you have a regular meeting with the employees to review tickets (e.g. projecting them on the whiteboard), and point out if they have not been updated in a regular enough time.

If you have regular stand-up meetings, where the root cause of a problem repeatedly comes down to a certain developer forgetting a semicolon, that should be embarrassing to the programmer and provide the incentive him to change.

I don't like meetings anymore than anyone else, but making the team members accountable to each other for results and their performance in following through with certain things will in most cases make them more likely to do it.

Meetings like this waste time, piss off the workers, and generally lower morale. Not a good idea. — Aug 29 '12 at 22:47

jayturley 1793 · Answer 9 · 2012-08-29 22:21:21Z

Being that there is a really good answer to the major issues already, I simply want to address the issue of motivation you bring up.

If you want your employees to do a task, and you feel it's critical that they do it regularly, use the Dangerous Minds technique: start them off with a 100% financial bonus, and penalize each time the task is neglected by removing a small amount from their known bonus as a penalty.

This is highly effective, but if you use the technique for small tasks like ensuring that your team turn off power supplies, you run the risk of thoroughly alienating them.

score -2 · Answer 10 · 2012-08-30 12:46:48Z

up vote
-2
down vote

I have to ask, being a manager what power do you actually have, are you an owner of the company or a manager?

To me it seems you are afraid to hurt people's feelings. My company has constituted a no cell phone policy. You get caught on the floor (manufacturing) you get 15 minutes taken off your pay. 2nd time an hour. Third time you are sent home for the day, no pay. Final, you are fired.

You may want to talk to the owners if you aren't one yourself, and see if this would be allowed, but in reality you need to be a manager, not the friends of the employees first, otherwise you are going to find yourself on the street for not doing your job...

Otherwise the employees are going to look at you and realize they can get away with some things, and you won't be respected. You'll be liked, but respect is harder to earn when lost.

edited Aug 30 '12 at 12:46

answered Aug 30 '12 at 11:45

Matt Ridge

1,99911221

1

answer mentions an example of "industrial manufacturing" - how is this relevant in question tagged software-industry?
â€“Â gnat
Aug 30 '12 at 11:49

Just because its a different industry, doesn't mean that employees compliance should be any different. I always give an example of why I say something, so to kill questions later on. Just because you can't see the correlation doesn't mean the answer is wrong. In our case cell phones cost our company in mistakes over 2 million dollars last year, since we implimented it, we cut that down to under 200k Sometimes you need to put your foot down to get results, if you can't understand why perhaps that is a problem?
â€“Â Matt Ridge
Aug 30 '12 at 11:56

I see. I've been confused by the fact that you refer to particular industry different from one asked. If you believe this applies to software industry, consider editing the answer to clarify that.
â€“Â gnat
Aug 30 '12 at 12:35

Well I figured industry manufacturing would underline the reasons for rules, because one slipup and you could find a 12" long by 1/2" thick drill into your arm if you don't follow safty guidlines. It may not be as dangerous in an software company, but the fact is one wrong move and you could loose all that day's data or fry a server, or something else that can set you back for months.
â€“Â Matt Ridge
Aug 30 '12 at 12:48

interesting. Did you consider possible differences in employees mobility? I don't know if this is the case for manufacturing but in software industry, most managers I used to work with would rather rephrase your statement into something like, "one wrong move and you could loose all your most productive developers that can set you back for months"
â€“Â gnat
Aug 30 '12 at 13:19

Â |Â
show 1 more comment

score 99 · Accepted Answer · 2012-08-17 04:18:18Z

Fix the process

If there is a problem with the majority of the employees, It's a management problem.

Either you are not paying enough to hire people capable of doing the work, or you are treating the workers badly and they just don't care, or your processes are poorly designed.

Not properly updating tickets...

Why isn't this happening? Is your ticketing system annoying to use? Are the workers so busy that mundane tasks are frequently omitted to deal with urgent tasks? Have you asked the workers for suggestions?

Repeating the same programming mistakes again...

What sort of mistakes? Do you have any code review process in place? Are you using any automated tools to prevent these mistakes? Is it easy to do the right thing, and hard to do the wrong thing? If not, why not? Why aren't these mistakes caught by unit tests?

making the same mistake in certain office procedures...

Why haven't you automated those procedures? You can't expect programmers to be good at executing repetitive procedures. They hate doing that, that's why they became programmers.

not turning off the power outlets before leaving

This is a hardware problem. Buy surge protectors.

"If there is a problem with the majority of the employees, it's a management problem" I would upvote this twice if I could. And your other points are very well taken — Aug 17 '12 at 10:20
You can't expect people to be good at executing repetitive procedures. - That is exactly why you have programmers — Aug 17 '12 at 10:41
People, even highly paid, highly trained and highly motivated people CAN NOT remember large numbers of things to do for particular tasks. Hence the evolution of checklists for the pilots of aircraft: atchistory.org/History/checklst.htm — Aug 17 '12 at 14:57
Checklists apply to medicine, as well as to other fields including software development. Atul Gawande wrote a book on checklists called The Checklist Manifesto. — Aug 17 '12 at 16:43
@Chad - If you're resorting to firing people over non-conformance like that, then you have bigger problems, and you're only getting conformance at all because of fear, and you've destroyed company morale. What's going to happen as the economy improves and your employees no longer fear losing their job? — Sep 4 '12 at 20:32

Communityâ™¦ 1 · Answer 12 · 2017-04-13 12:48:42Z

Kevin's answer is phenomenal, but I wanted to add some thoughts of my own.

My company has recently started using a ticket system company-wide. Prior to the company-wide implementation, we had a few people already using GitHub, and doing so with great success.

The manager in charge of getting a ticket system decided to go with what he knew, instead of seeing what we were familiar with. The result was a ticket system that was annoying as hell to use, overly complicated for users (there were like 20 fields to fill out or otherwise change for a ticket, finding the status update field was difficult, and it was all-around not a pleasant experience). The developers hardly touched it and it fell apart within a couple of weeks.

We then decided to switch to GitHub, since that's the platform all of the developers favored. It also offers more free-form fields (and fewer fields in general), and an API that we could use to build a more structured ticket entry portion for the non-developers (to help get the right information out of them). So far, it's been used quite a bit more extensively.

The moral of the story here is that developers will use something if they feel it adds value and doesn't waste their time (time better spent fixing the problems you hired them to fix), but if it doesn't, very few incentives with coerce them into using it. For developers, productivity is king. If it hinders productivity, then it will be abandoned if the developers have anything to say about it. Talk to them, see what they use naturally, or what format they're most productive with, and do what you can to accommodate their needs. The developers, after all, are the ones making your product work.

And I concur with the sentiment about the UPSes. You're a business. Your hardware is an investment. Why wouldn't you take the necessary steps to ensure that your investment is protected, especially if you know that your power is unstable?

Another thing to consider, too - are there actual reasons for these policies (ie - are they all like the power issue, or are there any arbitrary ones), have they been adequately explained to everyone, and are people satisfied with the explanations and solutions? (And, for that matter, have you listened when they suggest solutions?) Programmers are creatives. We're also problem-solvers, some of us compulsively so. We don't take well to top-down authoritative directions with no apparent reason for them. If you want compliance, you have to show that you're willing to consider our solutions when we propose them, and provide good reasons for making the decisions you make. You hired very smart and talented people, don't treat them like monkeys.

Just a quick ? about using GitHub for issue tracking. As I understand it, you can just do this for each repository, right? Or is there a way to use it as a standalone issue tracker? Or did you just create an empty repository for a project/workspace? — Aug 29 '12 at 23:05
The anecdote is still the primary part of the answer and really does not add anything. Anecdotes should support the answer not the answer supporting the anecdote. — Sep 5 '12 at 17:09
@Chad - Then I think we'll have to agree to disagree. The anecdote is intended for illustrative purposes not only for my own response, but for other responses (as I said, Kevin's answer is great, and I fully support that it got upvoted, marked as the answer, and given a bounty; I initially thought about making my response a comment, but it would have required several comments, which I thought was more inappropriate). — Sep 5 '12 at 17:19
@Chad - The comments aren't supposed to be "chatty" either, so just vote down the answer if you don't like it and be done with it. — Sep 6 '12 at 18:54

maple_shaft 15.8k75296 · Answer 13 · 2012-08-17 13:45:35Z

A good general doesn't blame his soldiers when they lose a battle. Likewise a good manager takes responsibility and makes actions when the team is not performing its best. A good manager when faced with a problem removes obstacles for the team so that they are able to do their job.

When an employee screws up, a good manager tries to figure out how to fix the screw up, and then works with the employee to find out what happened so that similar problems can be avoided in the future. A bad manager looks to pin blame or find excuses and scapegoats.

I may be implying your attitude incorrectly but I feel as if you are convinced that the problem lies in your employees somewhere. You should be skeptical about this, because it is unlikely that nearly all of your employees are low quality. Sure it is possible, but even if that were the case then it was either your fault in picking the team, or if you had no say in the team then it is a blameless obstacle that you must lead your team through to success.

The very first step is that because it is ultimately your responsibility now that you need to assume these team failures are directly your fault. The next step is taking proactive steps to remedy the problem. Some of the solutions may not work, if this is the case try something different until you start seeing improvement.

Joshua Drake 22749 · Answer 14 · 2012-08-17 15:18:39Z

I concur with the majority of what has already been written.

It appears that you need to change the process around ticket updating, and you certainly need to purchase some surge suppressors, upgrade the office's power system or possibly relocate to better facilities. I also have seen in practice that code reviews significantly reduce the number and impact of mistakes made by developers.

However, I believe that

repeating the same programming mistakes again

is the developers' responsibility, and needs to be addressed by each developer individually.

One method I've successfully used to reduce my own mistakes is tracking them. Simply keeping a .txt file on my desktop and adding lines to it describing my mistake, e.g. Closed outlook when I intended to close a single message., has had a positive impact on my personal error rate.

Another tactic would be to share the techniques you use to avoid repeated mistakes in your own work. This may include having the better performing team members share their own practices.

Showing the team support by making the initial changes above, and sharing your personal struggle to meet the same standard that you hold them, while equipping them with best practices from yourself and their peers, should go a long way toward instilling the desired ethos.

bethlakshmi 70.4k4136277 · Answer 15 · 2012-08-31 13:42:32Z

Here would be my steps, based on successful cases of continuous improvement I've seen implemented in level 5 CMMI shops. I believe processes like Lean Six Sigma focus on a similar approach, although (based on casual observation) with a slightly different nuance.

Examine your current state

I bet that it's a no-brainer in the cases that you mention that harm is caused when people don't do the process properly. The big question is how much harm? How often does this happen? What is the magnitude of impact when it does happen? How does that impact affect the big bottom line? Everyone probably understands that these problems cause "some impact", but when you can put some hard numbers to it, you can see how big a problem you've got. Saying "we loose customer faith when we don't update change tickets" is one thing. Saying "we could have sold X many dollars more of our product/service" if customers had more faith in our process is a lot more urgent. It also tells you how much money/time you can spend trying fix the problem. No one wants to spend $100 worth of effort on a $20 problem.

Also - however - look for patterns in your failures and successes. I'm willing to bet that not EVERYONE does this wrong. Or, if everyone does it wrong, do they only do it in some circumstances? If you have problems with a specific group, or under specific conditions, see if there's something you can do to address that specific case, rather than trying to change situations that don't need changing.

Involve the People Who Need to Change

When you've got the data, get key people together - you may end up with a few meetings, if you have a big organization. One meeting is the people who need to change, who need the option to discuss this in a penalty-free way. In other words, they need the latitude to grime, complain and come up with wacky ideas without management freaking out at them. But they probably need a moderator to channel the discussion to productive ends instead of just complaining.

You may also end up with meeting with other key people - if it's the tool that it causing grief, you may meet with those who maintain it. If it's a two-group problem, you may end up meeting with both groups separately and then together. The big deal is to be cognizant of the fact that different groups come to different conclusions depending on who is in the groups. Use that to your advantage, not your disadvantage - the wrong people put together too early in the process will kill it flat out, but the right people will come up with some brilliant ideas that may even be cheap and easy to implement.

More important is giving people the chance to feel like they took a shot at solving it - most successful programs for change involve the people who need to change so that the effort becomes their effort and not something foisted on them from above.

Monitor and Give Feedback

Whatever metrics you used in the first step are ideal here - which means that although you may be monitoring the low level (# of status updates, etc) - what you REALLY want to pay attention to is that bottom line, as well. You may make the detailed change you want and still not get the payoff you are looking for - and it's important to know that. In my mind, this connection is what separates good managers from the pointy haired boss in Dilbert - that they are clever enough to look for the impact their people make and point it out to them. There is nothing headier than a victory in this area, and knowing you have failed helps you to figure out what you can discard as useless the next time you want to see change happen.

When giving feedback, consider that how you give feedback and to whom has a huge impact on the effect. Saying "this is urgent" when you body language says "I don't care" can be worse than saying nothing, and mailing the team when only one person is failing to comply reassures the one person that this is a group-wide problem when it really isn't.

Carrot or Stick

You'll see almost none of the work involves either an incentive (carrot) or punishment (stick). The modern management take on this is that how you lay out work, and how you get people involved in it is more motivating and effective than the carrot and/or stick approach. The general thought is that most people want to do their jobs, they just need guidance on what "doing the job right" means.

There's an exception for every case though, as you get into this approach, you'll see it takes a heck of a lot of time to get it done right... it's not a 20 minute task by any means, and some of this (like the metrics collection) is intense, data-driven work that most managers don't have time to complete on their own... so you're going to need help. In addition, you're probably going to hit the outliers on your bell curve, who really can't manage to do the thing you want them to do, even when the rest of your demographic has adequately turned the corner on making change a reality. That's where the carrot/stick strategy may work out:

Carrot - when someone goes above and beyond the call of duty. It is not above and beyond if you say "do this" and they do it adequately within their skill set. Incentivize "doing the job" and you'll be in a never ending, demotivating cycle. But if someone suggests and then seamlessly implements great new ideas, taking ownership and going above and beyond to nail down issues above their pay grade - make sure this gets rewarded come bonus time. And be specific in your praise, since you want to make sure that this excellence continues.

Stick - when you have ended up with an outlier that simply can't do the work that everyone else can do, it's time for the stick. To be effective, a stick has to be a real penalty. Doing the lame work that no one likes is not really the penalty you are looking for - it can easily be misinterpreted, and you can end up with an employee who never really does the job correctly. You're going to end up in the realm of docked pay, negative performance reviews and (if the issue is big enough) talk of termination. The things you mention are part of doing a good job, they are not "bonus work". They are having a negative impact on the business, and if this guy can't do what other people can do, chances are you can find someone else who can perform better on the open market.

I'm harsh on both the carrot and the stick here, because the two issues mentioned in the question are baseline for a good process. Both of these can have serious impacts for the company and it's in the mainstream expectation for the average worker to be able to both of these properly. If you were talking about a new "ideal practice" that was innovative and therefore had a higher chance of not paying off, my thoughts on what the bare minimum that the average person can do right off the bat may be more lenient. That said, when you've innovated and proved it's a huge value-add and you have people who can't come up to the new par... do you really want to pay them for sub-par work?

+1 for Carrot and Stick. A good process will drive itself once it is proven. You need the carrot and stick to get it started, and make sure that those tempted to slack off stay on track. — Sep 5 '12 at 13:52

Michael Durrant 9,68122856 · Answer 16 · 2012-09-06 03:27:38Z

Focus on Results.

Getting into personal issues, habits or even attendance at meetings is frequently counter-productive.

I recommend you focus on one thing - the product(s) and the users you serve. All of your policies should stem from that. If someone missed a meeting and then a deadline was missed you ask the person why it the deadline missed - was it related to the missed meeting? Why did they miss it? Did they speak to the other person or people separately? Do they have other issues not mentioned?

The hallmark of a great manager is one that listens.

The hallmark of a bad manager is one that dictates procedures.

When you speak about things to the whole company look to be talking about your products, the needs they are meeting, the features you're focusing on, the deadlines ahead. But stay away from attendance / ticket issues / documentation issues.

Remember the golden rules:

Nothing negative by email.

Nothing negative in public.

Focus on the end results.

Treat employees well.

Provide support and training

Provide snacks and treats.

Kate Gregory 105k40232334 · Answer 17 · 2012-09-06 13:15:53Z

As long as you frame your problems in terms of your employees being the problem, it's going to be difficult to address the problem. No amount of yelling "Change!" at a person is going to result in changed behavior.

As people above have stated, it is a management issue, but more importantly it's a system/process issue. I mean, you could be the most motivating manager ever but if you're using a flawed ticketing system then expired tickets are going to fall through the cracks.

In fact, realistically, the fact that this is happening is almost a good thing. Why? Going in to expired tickets and updating them with new expiration dates is time consuming and, to be fair, relatively trivial in terms of work skills. If your workers aren't doing this it suggests that they're probably busy spending their time on more productive work.

If you have any kind of control over the ticket system, I would amend it so that:

each morning it pulls up expired or near expired tickets

finds the worker assigned to that ticket

lets them know it's about to expire and invites the worker to push it forward, including offering a default extension date so the worker doesn't even have to calculate what the date would be next Friday or whatever

If this was a single e-mail each person received daily, and the process took under 5 minutes, you'd probably see people doing it regularly.

If it's still a problem, add a nag screen when they go to the ticket system, so if there are outstanding expired tickets a little alert pops down from the top of the screen.

Integrate using technology as much as possible. For example, let's say that the ticket is to alter a person's record. Before they go to the form, a small popup could ask them if it is related to a ticket, and if yes they just punch in the ticket number. Then, once the record is saved, the ticket is automatically updated to reflect the changes just completed. If it's code work, integrate the ticket system so that each time they check in code, or build, or whatever, a message is sent to the ticket system. So all they would have to do is indicate the ticket number when writing the commit message (there are many IDEs that will do this for you).

If co-workers are working on a joint project, they should be encouraged to be in more constant communication so that they don't have to schedule meetings last minute. Maybe even set up specific times each day devoted to collaboration (say 10:30-11:30, that gives people enough time to take care of initial business for that day and leads up to lunch so if the collaboration goes over they can even continue chatting over lunch and keep the ideas percolating). Send a quick alert via whatever instant message system you have (you do use some kind of IM system, right?!?) reminding people it's collaboration time. You might even remind people of the joint projects they're working on.

You're a manager. It's your job to be organized and to keep projects, schedules, tasks, etc. all in your head. So maybe you're expecting all of your workers to do the same. Realistically, not all of them will be as good at it as you are. So set up systems that offer constant reminders. The ones who remember well will probably not need them and can switch them off. The ones who don't remember will welcome them as effective ways to keep them on task.

JohnMcG 1,8561818 · Answer 18 · 2012-08-17 17:48:48Z

Assuming these are all legitimate mistakes that are the fault of the employees and not the process, a system of peer accountability seems be in order.

If you have a regular meeting with the employees to review tickets (e.g. projecting them on the whiteboard), and point out if they have not been updated in a regular enough time.

If you have regular stand-up meetings, where the root cause of a problem repeatedly comes down to a certain developer forgetting a semicolon, that should be embarrassing to the programmer and provide the incentive him to change.

I don't like meetings anymore than anyone else, but making the team members accountable to each other for results and their performance in following through with certain things will in most cases make them more likely to do it.

Meetings like this waste time, piss off the workers, and generally lower morale. Not a good idea. — Aug 29 '12 at 22:47

jayturley 1793 · Answer 19 · 2012-08-29 22:21:21Z

Being that there is a really good answer to the major issues already, I simply want to address the issue of motivation you bring up.

If you want your employees to do a task, and you feel it's critical that they do it regularly, use the Dangerous Minds technique: start them off with a 100% financial bonus, and penalize each time the task is neglected by removing a small amount from their known bonus as a penalty.

This is highly effective, but if you use the technique for small tasks like ensuring that your team turn off power supplies, you run the risk of thoroughly alienating them.

score -2 · Answer 20 · 2012-08-30 12:46:48Z

up vote
-2
down vote

I have to ask, being a manager what power do you actually have, are you an owner of the company or a manager?

To me it seems you are afraid to hurt people's feelings. My company has constituted a no cell phone policy. You get caught on the floor (manufacturing) you get 15 minutes taken off your pay. 2nd time an hour. Third time you are sent home for the day, no pay. Final, you are fired.

You may want to talk to the owners if you aren't one yourself, and see if this would be allowed, but in reality you need to be a manager, not the friends of the employees first, otherwise you are going to find yourself on the street for not doing your job...

Otherwise the employees are going to look at you and realize they can get away with some things, and you won't be respected. You'll be liked, but respect is harder to earn when lost.

edited Aug 30 '12 at 12:46

answered Aug 30 '12 at 11:45

Matt Ridge

1,99911221

1

answer mentions an example of "industrial manufacturing" - how is this relevant in question tagged software-industry?
â€“Â gnat
Aug 30 '12 at 11:49

Just because its a different industry, doesn't mean that employees compliance should be any different. I always give an example of why I say something, so to kill questions later on. Just because you can't see the correlation doesn't mean the answer is wrong. In our case cell phones cost our company in mistakes over 2 million dollars last year, since we implimented it, we cut that down to under 200k Sometimes you need to put your foot down to get results, if you can't understand why perhaps that is a problem?
â€“Â Matt Ridge
Aug 30 '12 at 11:56

I see. I've been confused by the fact that you refer to particular industry different from one asked. If you believe this applies to software industry, consider editing the answer to clarify that.
â€“Â gnat
Aug 30 '12 at 12:35

Well I figured industry manufacturing would underline the reasons for rules, because one slipup and you could find a 12" long by 1/2" thick drill into your arm if you don't follow safty guidlines. It may not be as dangerous in an software company, but the fact is one wrong move and you could loose all that day's data or fry a server, or something else that can set you back for months.
â€“Â Matt Ridge
Aug 30 '12 at 12:48

interesting. Did you consider possible differences in employees mobility? I don't know if this is the case for manufacturing but in software industry, most managers I used to work with would rather rephrase your statement into something like, "one wrong move and you could loose all your most productive developers that can set you back for months"
â€“Â gnat
Aug 30 '12 at 13:19

Â |Â
show 1 more comment

Search This Blog

Iyfjky

How can I get employees to conform to office policies?

10 Answers
10

Your Answer

Post as a guest

10 Answers
10

10 Answers
10

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

How can I get employees to conform to office policies?

10 Answers 10

Your Answer

Sign up or log in

Post as a guest

Post as a guest

10 Answers 10

10 Answers 10

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

10 Answers
10

10 Answers
10

10 Answers
10