How should I approach a boss that keeps hiring temporary workers, only to have me finish something?

Question

Long story short, we've recently had a lot of work to do at my job and in order to fill that vacuum my boss has been hiring temporary workers. At first he hired three which stayed for about two months, but after the client moved up a deadline he hired one back recently.

I've been very cautious about delegating work to them as they've been making a huge mess of the code base and then when a push to production approaches I'm approached about making it workable. My boss is getting a little picky about this and made a comment to me about them being here to help, and I need to give them something to do. The problem is he's not a developer, so he doesn't have the perspective of what it can take to fix or patch together bad code; he only has the perspective that he's paying for them.

I wouldn't have a problem giving them things to do if I didn't know (as it's happened numerous times now) that in a few weeks they'll leave and when something breaks I'll be the one who's tasked to fix it in record time. The last time this happened a temporary spent almost two weeks writing out code that I was then expected to fix in one days time.

How do I convey this without seeming like a perfectionist who just wants to do it all himself?

Answer 1

You might want to take some arguments from the book The Mythical Man-Month by Frederick Brooks. Although it was originally written back in 1975 (overhauled in 1995), it is still one of the most important works regarding management of software development teams.

It is most known for codifying Brooks's Law:

adding human resources to a late software project makes it later

The reasons are:

• New developers must be taught about the existing architecture of the project before they can do something useful. This takes time away from the existing development team.
• There is an upper bound to how many people will be able to make useful contributions to a software development project at the same time. It is often not possible to find reasonable sub-tasks to assign to new people.

Good software development requires a stable core team which works together from start to finish.

Your manager might not be aware of this rule. So he tries to help you in the only way he can think of: Add more people to your project.

Answer 2

The issue with temps and contractors (disclosure, I am one) is that there is often no comeback if the delivery is awful.

It may be worth having a chat with your boss about the quality of the temps. Hiring cheap means moving the costs further down the road, but eventually he'll be paying to fix the code.

You might also ask to be involved in the hiring process by providing a small coding test to make sure the temps are actually worth hiring. Nothing too dramatic, less than an hour of work to get an idea of ability.

Answer 3

What you wrote actually raises a number of red flags suggesting the only viable solution is changing your job. You wrote your manager ignores the importance and value of unit tests, I assume it's the same with the analysis and design as those misconceptions usually come in bundles. You also say that he thinks adding a temp dev for a month will bring anything else than a further delay. Apparently your manager has little idea how the software development project should be run and there are little to no chances that he's going to change his mind

Yet, you can try.

While a 9 women to deliver in a month is a popular way of "proving" that adding people doesn't necessarily expedite work it usually doesn't work on someone who is not into real understanding the problem but knows better instead. Rather than that use the example of digging a well.

Let's say you need to dig a well that is 1m in diameter and 15m deep. One man needs 15 hours to dig it. How many men will it take to do the task in 1h?

The answer most managers (and most people in general) will give you will be that it'll be 15 men but that's not true and it's simple to show to anyone who has no idea about the coding well digging at all. Just like in coding you can replace one digging person with another one. You can (to some level) share your work. But only one man fits in a hole 1m wide to work at all. If you add second person inside, the first one will be obstructed by them and won't be able to do their work.

You can expedite work a bit swapping an exhausted person with a fresh one so a second person will help a bit. It'll not be 1/2 of the time, a save will be probably no more than 1/3. But adding a third man most probably won't help a bit. The two will be exchanging every hour or so, having time to regain their stamina. So if you insist on using the third worker inside the hole, the only effect will be that you lose more time when they swap or simply more men are waiting for their turn, being paid but not bringing any extra value. No gain at best, a loss at worst.

So, you can use the third person on some auxiliary tasks, like removing the excess of dirt from the well neighbourhood. Fine, it adds maybe 5% time save for the cost of a full worker.

But how can you utilise a fourth man, not to mention another 11? If you really insist on using all of them, you'll start having additional costs like communication, time for swapping etc. So starting with the fourth man you're going to add only delays with no benefit at all and additional extensive cost of people.

And that's assuming all workers are skilled. What if digging a well requires an extra precision and you hire an untrained temp for that? You need to teach them so you'll spend the first hour on showing how to properly make well walls so that they do not fall apart and how to achieve that perfectly round shape. Then they'll be working at 50% of the trained man speed and their work will still not be perfect so the perm guy will have to do the fixes, losing some time of his work. In reality before the new person can bring anything but delays the well will be ready. And it will take longer than if the skilled worker digs alone. You can still use a temp for those auxiliary tasks or the simple ones (while I'm having a break dig in the middle, leave the walls untouched) but that's still 5, maybe 10% gain at best. And if the temp hits the wall the trained worker have to fix all that and it is no longer a gain at all.

And it's something as simple as swinging a spade. Coding is way more complex.

Summarise it with something like that:

It's obvious that you need to train a dev and 1 month is a minimum to make them run at the basic productivity level if they are skilled. During the training you need to invest time of one regular dev into the training and the work of temps has to be reviewed anyway so adding anyone to the team for less than 4-6 months is nothing but waste.

The other idea suggested you could be involved in the hiring process. That's a good advice to reduce the time of introducing a new person into the team and limiting number of errors in their code but it'll still require training (a lead in). So a temp, even a skilled one, for one month is a waste. At best, you can use them to write auxiliary things. Like unit tests ;-)

If your manager can't comprehend such comparison, your last option is to hit the job market again.

Answer 4

This ventures into general software development advice....

1. If the code anyone writes breaks something add an automated test so that you can see it earlier next time.

2. Review pull requests, don't merge anything until you're sure nothing else breaks.

3. Tests make a good spec. TDD is a good way to ensure that what you're getting is what you want. Give someone a task to write the code you need (as exemplified by the tests you already wrote).

4. Peer programming might be an option. You can correct things immediately and answer questions as things go on.

Answer 5

How to approach boss that keeps hiring temp workers only to have me finish something?

You already have. All you can do is persevere with telling the boss.

Meanwhile there is a solution, the reason you're having to redo work is because you found out it was rubbish too late. You have an opportunity to practice some skills and take on more responsibility, but you're not doing it. It's not an esoteric problem, it's just a way of looking at a problem and resolution methodology. Well worth learning.

This is one of those times that micromanaging is critical. Assess the situation as a whole (including the people, they're a resource) and make a plan of resolution, use the manpower efficiently on those terms. This is the ONLY way to do it, you don't let even experienced people deviate from your plan, they don't have the full picture, you give them small tasks and check everything they do, they report to you at every step.

The most important bit is to understand the problem wholly and have a solid plan. Then break it up into simpler tasks wherever possible and don't rely on anyone to do their bit unsupervised.

Answer 6

If you can get away with logic arguments like the 9 months to make a baby analogy, that's great but, in my experience, this argument only works with people who already get it. And even when they do, it will often be followed with questions about what the optimal number of team members will be.

What might help if logic fails is to put together some data showing how work is actually getting done and focus on which people's work needs remediation. If you pull this together, you can show a pretty dramatic graph of who is actually adding to the output and who is detracting from it.

Part of the problem is that managers are under pressure to deliver and they need to show that they are doing something to make it happen. Doing nothing could make them look ineffectual and irrelevant. You can help with this by offering up some changes that your manager can make that will help (better machines, laptops, whiteboards, a build server, different hours, isolated work space, etc.)

Answer 7

The skill level of the temps is likely dependent upon the amount of money your manager is investing into them. As they are only temps he obviously doesn't want to be wasting too much funding. As you say your boss is not a developer and likely just assumes that a coder can code.

However, if it's increasing your work load in the long term and it's affecting your current work. You need to pull him for a 1x1 and just convey your issues and the reason that you are not delegating as much work down to them and your worries for the future if you do delegate work to them

You want to make sure you don't come across as if you're having a go at your boss but at the same time you need to get the message across as he doesn't understand what happens within development. If you simply mention that you would be happy to delegate the work but only when you feel safe to do so.

Answer 8

I find it useful to discuss a specific example. Take one case of something a temp did that took fixing by you. Describe the issue being worked on. Make a careful timeline of the events, showing when the temp got asked to work on it, how long the temp worked on it, when the problems were discovered, how the problems were fixed, and when the code was ready or at least back to usable. Compare with an estimate of how it would have worked with a stable development team. You can admit that you cherry-picked the example, but also have a list of many issues where this has transpired.

Now discuss your solution, which seems to be hiring a permanent addition to the staff. How long will it take to train this person (but you only do it once, not once per temp), how do the costs compare (as best you know), etc.

It sounds like your boss/company is not understanding that there is too much work for you to do. Hiring temps makes sense when the overload is temporary, but is a very costly solution when the overload is permanent. You need to make this case.

Answer 9

The other answers are all very good. However, I would suggest another tack. If this is a recurring problem, then perhaps it is, as your manager seems to think, an indication that your workload is too high for his expectations to be met by you alone.

You're pointing out that his solution to this doesn't work, and you may very well need to explain to him why. The other answers cover most of the possible arguments you could make in this regard. But if you want to see a change, the best way to accomplish that is generally to suggest your own alternative solution.

Maybe instead of continuing to hire temp workers, he might consider a permanent addition to the team. If you are actually willing to delegate tasks, but can't because the code quality isn't up to par, then that's the part you need to fix. However, if you want someone to invest in learning your architecture and coding style, they need to have some expectation that investment will pay off. A permanent addition to the team does come with additional costs, but the improved quality of their contribution and the reduced need for supervision/rework can easily pay for itself in the long-term.

Answer 10

Unit tests

This answer suggests that you should write unit tests and have them code to the tests. That's one approach, but it leaves your job as writing unit tests. That may not be what you want. And to get best results, you have to write great, comprehensive tests and have good developers. Because tests control the outcome rather than the process. It's entirely possible to write lousy (hard to maintain and modify) code that passes tests.

Another approach is to switch things around. Instead of you writing tests, have the other developers write the tests. You continue writing the code that you were going to write anyway. If it passes the tests, great. If it doesn't, you can then consider why. If the reason is that the test sucks (meaning that it doesn't match the actual requirements), delete the test. Anytime that you do that, record that decision.

You can also review the passing tests for usefulness as well. Again, if they aren't useful in codifying the requirements, delete them. Record the decision.

This relies on it being easier to review tests than code. So it is much easier to see if a developer can graduate from writing tests to code than to determine if the developer's code is good enough on its own.

At the end of the temporary developer's tenure, write up statistics on how many tests were useful versus deleted. That is then the information that you present to your boss when arguing against hiring more temps. Include how much time it took to review the tests versus how much time it would have taken to write the final test suite. If that number is net negative, then the company paid money for a "developer" to make your software worse. Even if it is net positive, compare the cost of the temp to what your cost would have been.

In my experience, bosses respond best to financial arguments with evidence. Without the evidence, they can reject the argument. With technical but not financial evidence, they won't necessarily understand the evidence (some may but many won't). So express any technical evidence in financial terms.