How can I manage my team to maintain a reasonable productivity when my employer doesn't treat employees well?

Question

My employer doesn't treat employees too well, for example we often work overtime without pay (for details you may check my other question How can I argue against the idea of working overtime to fix bugs (constantly)?)

But the situation is out of my control and I still have a team to manage. So how do I manage my team to maintain a reasonable productivity when I know they have their reasons to work slowly?

For example, sometimes I observe that my team-members don't work as focused as they should because we all know we need to work overtime again. I just run out of ideas how to tell them to be focused.

----- update -----

When I said they did not work as focused as they should, one typical example is I see they use social media from time to time. I am totally ok if they just have a social media "break" (like a coffee break). But if they spend too much time on it that is definitely a problem. On the other hand if it is Sunday but we are at office work overtime, how much time is acceptable to use social media?

My other question's title may be a little big misleading. Feature creep is one of the main reasons we have some many bugs to fix. We develop new features in the name of fixing bug!

Answer 1

A wiser man than me said “You can make people stay in the office for 80 hours a week, but you can’t make them work more than 40 hours a week.”

That’s the problem you are running into, and there’s nothing you can do.

People come to the office because you pay them. They work because they want to. And you know why these people have no motivation to work.

Answer 2

The way your employer treats people benefits nobody. They might get unpaid overtime from their staff but that is likely to result in poor morale, low quality work and a high turnover of staff (along with the cost/time required to train replacements).

In the long term, I think you need to push to change your employer's mindset. They are unlikely to experience sudden enlightenment so you'll need to chip away at it. Keep knocking on the door, pointing out the risks and problems with their approach and eventually you might get somewhere. Be careful though - you'll have to tackle this with subtlety because you don't want to be seen as an irritant. (Also - I don't know the company size or structure - you may need to go through your line manager and ask them to carry it up the ladder for you).

(If the company is in a tight position financially then you need to adjust your requests accordingly. There are more things than money - perhaps extra annual leave, time-in-lieu, the ability to knock off early on a Friday, free fruit/soft drinks could make all the difference)

In the short term there is a lot you can try to improve the team's performance.

• The company might not appreciate their efforts - but there is nothing stopping you from doing so. Saying "thank you" for a job well done, praising good work and really showing appreciation when somebody goes above and beyond will show you recognise their hard work. (Also bringing in a box of donuts now and then will do wonders!)
• Be flexible. Again, I don't know the type of work you do, but if it's possible try to make life easier for people. Let them slip out early if they have an appointment or need to collect their kids. I find that if you give some slack in situations like that you will get it back twofold when the deadlines are tight or backs are against the wall. It's all about give and take.
• Career Help. Chat to your team members. Find out where they want to be in 5 years. Try (it might not always be possible) to get them exposure to that kind of work. Maybe it's learning a new skill or technology, maybe it's taking on different type of work (sales, support, project management). If people are learning and feel challenged by their work they are likely to work harder at it.
• Be an advocate. All the previous points fall into this category a little. You need them to know (or at least feel) that, while the company wants you to manage them, you are also fighting in their corner. Tell then you appreciate the position they are in - but also tell them that you are trying to change it. Tell them what you've tried and the progress you're making.
• Communicate. Continuing on from the above, communicate the progress you're making. If you hear something from management, decide what if anything, you can share with the team. If they feel involved they will feel invested and therefore more committed.
• Monitor more closely. The above won't work for everybody. In those cases you need to monitor them more closely. Know what they are working on. Have them commit to a time for delivery (you need to know if this is reasonable or being padded) and then check in regularly to make sure they hit that deadline. If they don't, find out why. You're not aiming for conflict, it should be a "well how can I help you to meet the deadline next time" type discussion - maybe the process needs to be improved, maybe they were interrupted or re-assigned, maybe something went wrong. If deadlines are missed continually then you probably need to go down the disciplinary route.

Answer 3

Your job as a team lead / manager is to shield those in your team from the rubbish that comes from above so that they're productive.

You need to find out WHY they're having to work overtime. Are they being generally unproductive, or are the timelines unrealistic? If they're unrealistic, then you need to take steps to make them realistic... Get the team involved in making the estimates for time scales; and if management push for unrealistic time scales then you need to push for more resources.

Management won't like you saying it... no one likes it when people push back; but in the end they might prefer it when the productivity goes up, people are happier and deadlines are hit.

Answer 4

Culture Problem

I think Karl Bielefeldt's answer is the best one, but I would like to state it even more forcefully: you have a culture problem, and it has nothing to do with China. Your boss wants bugs in your software fixed? Awesome!!! There are countless times in my career when I wanted to prioritize bug fixing, but management wanted more feature delivery.

The real problem you have is your team's attitude towards code quality. Ultimately, this is a maturity problem. Most teams end up with buggy, broken code for a few common, recurring reasons:

• Not enough time/resources spent testing
• Not enough time spent documenting + reviewing code
• Too much focus on delivery
• Willingness to accrue unlimited technical debt

It is not your boss' job to fix these problems. These are not organizational or corporate problems. These are developer problems, and developers must acquire the proper attitude and strategy to deal with them.

Cold Read

Without knowing anything further about your company or team or business practices, I'm going to make a few predictions:

• Your codebase has few to no unit tests (code coverage < 20%)
• Your team engages in manual testing (few to no automated integration/functional/acceptance tests)
• Your team puts little effort into code review (either treats it as rubber-stamp, opportunity for gratuitous nitpicking, or skips entirely)
• Your team rarely documents code, or adds trivial comments (// next line prints a message to the log file)
• Your team does not engage in regular refactoring, or only has 1 or 2 engineers that believe refactoring is even a useful thing to do
• Your team loves to write new, green-field code, and tries to avoid maintaining existing code like the plague
• Your system lacks automated metrics of success (number of successful transactions/requests vs. attempts, number of errors per transaction, counts of timeouts, user-facing errors, etc.)

Climbing Out of the Hole

Even if I'm only right about half the predictions, that's enough to explain your predicament. The solution is not more overtime, nor trying to convince your boss to back down. Part of the problem is that you lack strong technical leadership on your team. Your team really needs a senior engineer or five that can promote mature software development practices that reduce defects as early in the pipeline as possible.

As you can imagine, the prescribed fixes will directly address the defects I predicted above, along with a short blurb on why you should invest in the activity:

• Unit Tests--I think 80% is the absolute bare minimum for a long-term maintainable codebase. I strive for 98%+, and that is almost always achievable. This isn't about checking off some box in a masochistic SDLC checklist. First, not all code is easy to unit test. Writing tests against such code forces the developer to rethink the design and organization of the code. Making code unit testable makes it better. I say this as an absolute truth, because I believe it is, and have never seen a counter-example. Furthermore, unit testing uncovers a lot of bugs that eventually manifest in production, and often in an insidious, hard-to-reproduce way. Finally, unit tests serve as a kind of documentation of developer intentions when the original coder has moved onto another project, and the maintainer is trying to infer what they were trying to accomplish. I claim that unit tests always save more time than they cost, which is why mature developers will invest the time to write them. Unfortunately, I would wager that less than 20% of developers worldwide count as "mature" by this metric. :/ You can't tell how well you are doing on unit testing until you implement a code coverage analyzer in your build process, and put the results on a "radiator panel" that the whole team can see 24/7.
• Acceptance Tests--your team has lots of bugs to fix because you have outsourced proper testing to your users, and this makes your boss quite understandably angry. Your developers are lazy, believe that someone else should do the testing (like, dedicated testers), and are clearly not maintaining a suite of automated tests. You need tests which run on every merge, on every production build, on every deployment to every test environment, and on every production deployment. You want broad coverage via randomized test generation and extensive data validation within your code. This is a whole topic by itself, but is also core to your problem. You don't need to write thousands of test cases to have a useful acceptance test suite. But you do need to find a good testing framework, get very comfortable with it, and make it your new best friend.
• Code Review--many developers don't get the value from code review which is readily available. First, code review should help maintain a consistent style and approach across the team. I don't think developers need to write code as if they were all clones, a la XP style. But it does help to enforce some common standards, without devolving into formatting wars. This extends to design patterns and coding idioms which occur frequently in your problem space. Second, code review is an opportunity for learning, for both the author and the reviewers. It's an especially good way for junior developers to learn good practices from more senior ones (assuming the seniors are actually good coders). Reviewers should ask lots of questions whenever code isn't clear, and the process should be collaborative rather than confrontational. Third, good reviewers can often spot bugs just by reading the code. This won't happen all the time, and is no replacement for testing. But it is a nice bonus, and one which you get "for free" just because you bothered to ask 2 other people to read your code. Every merge should have a code review.
• Writing good documentation is overlooked by about 95% of all developers, given my highly unscientific judgment. You don't need NASA-level documentation to improve your codebase, nor does all code require the same level of documentation. In general, the more code is re-used, the more documentation it should have. Therefore, any kind of shared libraries/classes/modules should get extra documentation, especially for things like thread safety, exception safety, intended usage, detailed function APIs, null handling, etc. Bespoke app code should tend more towards being clear and self-documenting. Again, you can't tell how good your documentation is until you generate it as part of the build process and publish it to a local web server. A lot of bugs occur because there are mismatched assumptions and expectations between engineers (about valid values for fields, where validation occurs, etc.). Documentation helps mitigate this failure mode.
• Refactoring--this is one of the most valuable things you can do for crufty codebases which have acquired a lot of technical debt. It is perhaps the second thing you should do (after writing unit tests, of course!). For a small company or a startup, there are times when moving fast and breaking things is the correct course of action. But that cannot be sustained indefinitely. If you do not push hard for refactoring pauses, then your team will eventually fall off a cliff of technical debt (sounds like it's holding on by a tiny little branch as we speak). Good engineers should push for refactoring anyway. The fact that you have not mentioned any developer-advocated remedies tells me that you lack such engineers. Code does not have to be perfect the first time you write it (and almost never will be). But you should be able to improve it every time you touch it. Refactoring should be second nature for your whole team, and everyone should feel empowered to do it, when the changes are clearly beneficial to the whole team. Obviously, you want to avoid gratuitous refactoring. But I doubt this is even a risk for your team.
• Ops/Metrics--Not only do you need tests at the code level and external to your product, you also need operational metrics to see how your product is performing. And these metrics should include quality parameters (transaction count, speed, error counts/rates, etc.). Your boss shouldn't be the one demanding that you fix bugs. You should have your own team-defined quality targets that force you to go into cleanup mode when you stray outside of them.

Next Steps

Curiously, the one thing you have not mentioned is your boss demanding that you deliver 20 new features by next week, in addition to fixing all the bugs. I assume there is some such pressure, but your failure to highlight it gives me hope. It suggests that you have space to ask for a feature delivery pause while your team pays down the massive technical debt it has accrued. If you put together a detailed plan for your boss on how you are going to systematically improve the quality of your product, and maintain a high quality level going forward, then perhaps you will find support for such a plan.

Of course, you need to work with your team on the plan, and get buy-in as to which steps will be most appropriate and effective. And surely there will be compromises that will need to be made on all sides. You may need to amortize refactoring across a few product cycles, while your boss may recognize the urgency of building out a decent test suite right away, even at the cost of feature freeze.

In summary, I think your situation is totally salvageable. However, I think it requires a big change in thinking and attitude for your whole team. Instead of seeing your boss as the enemy, you should start thinking of the boss as an ally in a new era of software quality. And be sure to use the focus on quality as your ammunition when you sell your remediation plan: "Well, you did tell us you want all the bugs fixed. We have a plan to do that, but it will require you to meet us halfway. Here is what we propose..."

Good luck!

Answer 5

There are other ways to increase productivity on bug fixes than just working longer. I would solicit ideas from your team about that and give them time to implement their ideas. Empowerment goes a long way toward morale. For some ideas:

• Improve testing and get tests to run before every merge.
• Refactoring of problematic code.
• Prioritize your bugs so the important ones get worked first.
• Figure out which code causes the most bugs and allocate time to improve its general quality.
• Use linting or static analysis tools.
• Fix the warnings and turn on -Wall -Werror or your language's equivalent.

Answer 6

Focus on the employees. Make sure that you hold (best practice) weekly one-on-ones to talk about larger goals, big ideas, professional development. Here's a great resource, with a mix of paid and free offerings -- there's real value in the free stuff: https://www.manager-tools.com/

Specifically, seek out information on the "one-on-one" meetings.

I had a situation years ago where my boss informed one of my guys that his contract would not be renewed -- a year out. Can you imagine? Here's what I did. I focused on working with the guy to buff his resume. What do you want your resume to say? Let's make some of that reality. Where do you want to go from here? How can I help you get there? This worked very well, until the guy found another opportunity, at which point it was pretty much on rails. But it helped immensely.

The one-on-one meetings are the key to engaging with your people -- as people. BTW, these are not project or update meetings. This is you as a manager doing one aspect of leadership one person at a time.

There's an old saying that usually people don't quit jobs -- they quit managers.

Since your people are "merely" mistreated, rather than already fired, you have more options than I did. Make sure that your people know that you are doing what you can for their benefit, whether in this job or the next.

Answer 7

Are you using a formal process? I'm guessing from the contextual clues and your other question that you are a) building software and b) in China. 'a' is relevant, 'b' may not be, but keep in mind I'm coming from a United States/Canada perspective and there may be cultural/learned behaviors that affect the viability of my suggestions or require adapting them. These suggestions are based on 20+ years developing software professionally and having worked in companies ranging from tiny start-ups to massive global enterprises and having everything from extremely supportive management to rule-by-fear despots running things.

1. If you are not already doing so, start doing test-driven development, or a similar fast-feedback solution to immediately let you know if new commits break anything (assuming step 0 is done and you are using source control -- if you aren't, implement it immediately). Testing needs to be automatic and performed on every commit.
2. Adopt a process to take in, perform, and deliver new work. Scrum is very popular one. They key here is to be extremely transparent about how you estimate and deliver, and provide continuous feedback about the progress. Hold the line on what you can realistically deliver: fast, inexpensive, good -- pick 2. As part of this, create a backlog of known bugs and work on reducing it.
3. Prioritize not introducing new bugs. If #1 shows anything broken, fix it before heaping on even more changes. If you keep adding new bugs you will never catch up and productivity will never improve. And a constant cycle of never-ending bugs is a sure way to drain productivity and motivation.
4. Track your progress: time to deliver, bug creation rate, bug backlog count, etc. Demonstrate via data that when the team is pressured to deliver more than they say they can comfortably deliver, the quality of the product declines. Celebrate incremental improvements and treat setbacks as learning opportunities, not an excuse to dole out punishment.
5. Help team members recognize that management's treatment of an employee is not a reflection of that person's worth. This is something that each person on your team needs to understand. They are working in a toxic environment and that takes a huge toll on your mental health. They may not even realize how it is affecting them until somebody points it out.

The last item is probably the most important, but the first 4 are what will help get your team there. You can't force people to "focus", at least not effectively.

An observation I've made over the years is that companies run by owners who consistently interfere with the professionals doing the work and try to squeeze productivity through threats of punishment have also tended to be the least successful ones.

Answer 8

Answering this bit specifically:

sometimes I observe that my team-members don't work as focused as they should because we all know we need to work overtime again

What's probably happening here is that they've realised that they're not just in the office until a few bugs are fixed, but that they're stuck there for however many hours senior management has chosen, and the amount of work they do is irrelevant.

Fix it by setting the goal for the day that the team can work towards: "3 more bugs and we can all go home. X, if you've finished your bug, can you pair up with Y so we can all go home faster?"

But really, as everyone else has said, your job is to fight for your team, not to exploit them. Feature creep should be pushed back to the next iteration.

Answer 9

Bad working conditions will take a toll on your employees - it doesn't matter who is to blame for them.

The best you can do is convince management that unpaid overtime is counter-productive and the rate of which they're pulling the 'occasional bit of overtime' as per what is likely in your employees' contracts might be illegal (jurisdiction dependant).

EDIT: As per virolino's comment, this needs to be done carefully. We can't tell you which approach will work best with your management because we don't know them. If you can't answer this yourself, it may be best to steer clear of this option.

Answer 10

Responding to your first update:

On the other hand if it is Sunday but we are at office work overtime, how much time is acceptable to use social media?

On a Sunday? I would say at least eight hours is acceptable. Though I would hope that they would get bored sooner than that!

To begin with, why don't you make weekend work more fun?

You all have to come into the office at weekends while there are still bugs to be fixed, that's the unfortunate reality of your situation.

But you already know that no one's going to be able to fix any bugs on Saturday and Sunday having already worked Monday to Friday.

So accept that no one's going to get anything done anyway, surely you can think of something better to do than browsing social media?

You could start off with playing programming games like TIS-100 and Shenzhen I/O, compete with each other for high scores.

Once everyone's relaxed a little bit and is having fun, maybe you could think of a programming project that the ten of you could work on together? Maybe some of you already have some ideas?

It's the weekend! You're not getting paid. So do what you want.

Then, maybe, if you feel like it, for the last hour of each Saturday and Sunday, you can say "OK guys! Let's each of us take a bug and spend the last hour of today fixing it!"

An energised and motivated team will fix more in one hour than a demotivated team will in one weekend.

My other question's title may be a little big misleading. Feature creep is one of the main reasons we have some many bugs to fix. We develop new features in the name of fixing bug!

How are you working? It sounds like you have new feature list that keeps getting added to, which is what you work on during the week; and a bug list which also keeps growing, which is what you work on during the weekends.

If you can fix the bug list, then you won't need to come in at the weekends any more (however much you might want to after implementing the last bit ;-) )

Break your work down into sprints. Plan each one with your team. Prioritise fixing bugs over developing new features. Do retrospectives. All the good stuff in Lawnmower Man's answer, basically.

But fix the morale problem first to build the team back up to speed.

Answer 11

I think no one has addressed the below so far: people focus on "don't" (which I fully support) or focus on some coding practices.

If you cannot fully abolish unpaid overtime (as it comes from above), what can you do?

• Can you provide flexible working hours? "Guys and gals, I know, we need to clock 80 hours a week, but in my team you can come and go when you want, you just need to clock that hours, because I cannot change this yet."
• Do you have funds to compensate? Some financial voodoo might be in your grip. "I know, the overtime is actually unpaid by the company, but each employee in my team gets a 1k$ bonus if we quench 100 bugs by the end of the year."
• Get a non-monetary compensation, a la Google did it to keep folks in the office for longer. "Folks doing overtime get three meals served for free, get an in-house gym pass and can visit a therapist for free in the seldom non-working hours." I exaggerate, of course.
• Things I did not come up with, but support your team in all possible ways. Get them fancier computers. Move them to a better office. Cut the upper manager's throat and abolish unpaid overtime. Such things.
• If everything fails: quit with the whole team and find a new job / launch a startup.

Answer 12

How can I manage my members to maintain a reasonable productivity when my employer doesn't treat employees well?

The last half of the question is irrelevant. If employees are not being productive, discipline them since other approaches have not worked out. If you aren't prepared to discipline then you're failing in your role.

Take a guess at who is the worst and discipline them first pour encourager les autres.

You may have to repeat this a few times. Meanwhile see what you can do with the boss in terms of making some concessions to staff morale, keep repeating that as well. Don't undermine your boss to the workers, but do your best for both them and your responsibilities.