I am recently hired (1-2 months) software development manager. Since I have arrived, I have found two problematic practices.

  1. Most developers start off on one year temporary contracts. Market rate pay, but no benefits and they need to re-apply for their jobs every year. The dev team is mostly either young or tied to our city for family reasons, so developer skill is still high. However, turnover is quite high as well because people start job searching at 8 months (as we don't allow them to try and renew until the 11th month). Most get renewed if they apply though.

  2. We use Scrum as a project management tool (It wasn't my choice for all you Scrum hating devs, so I can't change it), complete with using the points from the Scrum Master to estimate work. Problem is, developer performance reviews (apparently not done by me) are done by our Scrum Master using the points and bonuses are based off the reviews. It doesn't help that our Scrum Master is a Executive Vice President type as the project is considered extremely high stakes for our company.

What these two practices lead to is a cohort of developers mostly focused on churning out code with little regard for long term viability. Edge cases get ignored, the React.jsx files become massive to save the work of making new components, and anything not explicitly in the spec (from the non-technical product owner who basically forgets about anything they see on the frontend) is just not included.

An example is that they wanted an input field for phone number for some rare use case for our more expensive clients. The input will only be seen in a really bad business crippling scenario. The product owner didn't specify that the number should be saved and texted emergency instructions (that was the intent), so it was not.

How should I go about handling this? I feel like a taskmaster, not a manager.

I don't want to press on my devs as they might quit.The extra 5 points a sprint (high performance is considered more than 18) means a lot to them (bonus can be 20% of salary).

Management wants control as this is the top priority development project for us. My manager says his hands are tied by upper management. He said that he could probably get the permanent devs more money, but that was it.

HR has the authority to renew contracts earlier, but won't as "we still get applications for programmers when we post the jobs, so there is a large surplus."

Mr Scrum Master says that he already gives us more leeway to manage ourselves than Scrum allows (not terribly agile but ok).

I asked one of my star temp devs and his view was that I "should stay, get a nice project on your resume, and quit as soon as the end hits. Leave the flaming pile of s**t of maintenance to the next guy."

I am running out of ideas here to try and solve this.

What options might exist to fix or mitigate the short term outlook of the developers which is making its way into the code?

  • 4
    Why do you expect to solve what upper management can’t see?
    – Solar Mike
    Commented Nov 22, 2019 at 18:00
  • @SolarMike not sure I expect to any longer. More just hoping that there might be something I haven't tried. Commented Nov 22, 2019 at 18:02
  • @SolarMike some of it is ego. I'm the kind of person to fix problems long after others write them off as not worth fixing. Sometimes that stubbornness pays off nicely. At other times, I burn time and money in futility. So feel free to tell me if you think this is one of those times. Commented Nov 22, 2019 at 18:07
  • 1
    On a side-note, I think you should split this up into two different questions. Commented Nov 23, 2019 at 9:13
  • 2
    I disagree with closing this as too broad, as the real question has now been stated and looks to me like a perfectly answerable (albeit very susceptible to x/y problem type answers) question.
    – Magisch
    Commented Nov 25, 2019 at 13:17

5 Answers 5


In a comment, you clarified your question as,

what options might exist to fix the short term outlook of the developers which is making its way into the code?

Rather than directly address the specific challenges you're describing (i.e. how to deal with your frustrating Scrum Master), I think it's more valuable to step back, zoom out, and consider a framework for solving what you perceive as quality issues in the workplace, in general.

The problem with quality in the workplace is that, in many situations, it's arbitrary and highly personal. You have alluded to this yourself in another comment when you said,

I'm the kind of person to fix problems long after others write them off as not worth fixing

This tells me that you probably have a more rigorous evaluation of quality than some others you are working with. Differences in perception of quality or process will almost always lead to the kinds of conflicts you're having. It's easy for it to devolve into a spiral of arguments, with no focus on what you are actually trying to obtain.

So, before trying to solve any one of your specific problems, take a step back. Do the following:

  • Determine, at a high level, what your company's goals are.
  • Determine how or why those goals are relevant for your project.
  • Re-frame your issues through the lens of those goals, as they apply to your project
  • Consider if your issues actually still need solving, and if so, develop a solution that clearly links back to your identified goals.

Software development is (almost always) a means to an end. Software quality and/or the types of issues your short-term devs are introducing can be really frustrating for a perfectionist. It can seem like an insurmountable problem. But, by following the above steps, you can help yourself to see these issues from the company's viewpoint, instead of from your personal viewpoint.

This is important because it may result in one of two outcomes:

  • You may realize that the things you see as problems aren't really problems. This is a common moment of epiphany for software developers and software development managers who are used to pursuing a sense of perfection. Most formally-trained software devs have been trained on the idea that there is always a best answer, or a best solution, and that's the only one that matters. In the real world, good enough is good enough. If a software team generates output that satisfies the business's needs and fits the business's goals, that is all the matters.

If you can't find a way to make a "massive React.jsx file" relevant to the business's goals, then you need to stop worrying about it. But if you can show that turnover has some direct correlation to your company's ability to meet it's goals, then you may get some traction.

On the other hand, the fact that a phone number input field didn't have the desired functionality sounds like it is a serious problem, and easy to frame in a context the business will understand. But it sounds like it's more a problem of incorrect requirements rather than turnover among developers.

Ultimately, businesses don't hire software development teams because they want to make the best software in the world. They hire software development teams because they see custom software as a way to solve their business problems. As such, when you - as a leader of the team - encounter things that you think are issues, the best approach is to gut-check yourself against the company goals and those business problems.

And then if you are still sure it's a problem, make sure you frame it in the business's viewpoint instead of a pure software development viewpoint. A company that sees software development as a commodity - a means to an end - will not easily consider turnover a serious problem unless you help them understand why, in terms they will understand, and with a solution that makes sense within their framework.

  • 3
    Good analysis. Common problem in the software world.
    – AndreiROM
    Commented Nov 22, 2019 at 18:42

The behaviour of your colleagues is based on their incentives. Their incentives are set at a very high level.

I don't know what you're experience or place in the organisation is, but since you don't even have a say in the processed used for development, I dont think you occupy a place of significant organisational power. (And btw, you guys are doing the darkest form of Dark Scrum I've ever heard of). You're super new. You don't have any allies. Your manager is either fatalist about this or doesn't really care. Your organisation is so disfunctionally arranged that HR (ie admin staff) are the ones deciding how developers are treated.

So, really, you have one option:

Continue to work here until you have the skills and experience to work somewhere better, then do that. And maybe screen companies better.

Which is exactly what your "star temp dev" said, because that's a smart reaction to the environment they're in.

  • 5
    I can't remember where in the Scrum Guide it says that team autonomy is a bad thing and that the purpose of estimating stories for the iteration is so that the SM can do staff performance reviews. Is your SM an actual SM, or did his qualified come free in his cereal?
    – Nathan
    Commented Nov 23, 2019 at 2:01
  • We need to start saying, frequently and loudly, that any company using story points for performance tracking is doing Waterfall in Agile's clothing.
    – EvilSnack
    Commented Aug 21, 2023 at 12:49

I feel like most (if not all) devs are temp workers, that should've been a red flag since before you even joined.

As @AndreiROM (I'm not used to StackOverflow tagging etiquette) suggested, the best alternative would be to 'leave these people to run their circus any way they'd like'.

The problem seems to be the company culture. If there is not a strong, defined group of developers that can force standard practices and defined coding expectations, it means the boat is not correctly anchored and it's a matter of time until it drifts ashore.


Get a good project to add to your portfolio, and get out of there in the short term


Try to make substantial, company-wide changes

Option A is probably the best option overall, and it would free you to look for other options easily.

Option B, on the other hand, will mean you're willing and able to push against the current and try to get permanent devs, and get rid of your already-existing tech debt. This option can make a good hero story to try and climb up the ladder, if that's what you're after. But I would advice against.

  • 1
    "I feel like most (if not all) devs are temp workers, that should've been a red flag since before you even joined." It would have been. Some of the newer devs didn't know they were temps until I found out. We only know because we tried to apply for some training money and found out that 2/3 of devs aren't eligible because of the temp status. The current job postings for devs don't mention the temp nature either. It is just kind of hidden into the offer letter. Commented Nov 22, 2019 at 18:56
  • 1
    What is the locale here? And is that legal? I'm pretty sure that most civilised countries don't let you treat permanent staff as non-permanent in this way.
    – MikeB
    Commented Aug 21, 2023 at 15:58

It seems to me like you're playing a losing hand:

  • your manager doesn't feel he has the political capital to push for change (which right off the bat is a red flag that he's there to simply enforce the status quo)
  • the higher-ups don't understand that their ship is headed toward disaster (another red flag)
  • the scrum master has no idea that the work he is pushing to be completed is useless, or worse, damaging your code-base (yet another red flag)
  • the employees are gaming the system to get bonuses (no company ever succeeded by encouraging lack of engagement with the needs and goals of the business)
  • although you see the impending disaster, your own hands are tied

The easiest thing to do, would be to start looking for a new job, and leave these people (lunatics?) to run their circus any way they'd like.

If, however, you're looking to stick around for a while, you may want to set some long-term goals on what you want to improve, and start pushing small, incremental changes.

For example, fight to have a couple of technical people on staff (full-time), and send them to the requirements gathering meetings, such that the temp devs get better specs. Or review the requirements yourself before the work gets done (this could be a good stop-gap solution).

Slowly push for more full-time devs, or get the ones you have to focus on reviewing the temp's code quality. Get whom-ever performs the reviews to start including at code quality in their criteria, etc.

One critical item is that you should establish very strong lines of communication with whomever the scrum master is, and get him to realize that you need to be involved in what gets done (discuss reviewing the requirements before sprints, etc.). The two of you need to be allies, making sure that the work that gets done is relevant, and future-proof, not simply that a dev meets his or her ill-defined objective.

In time, you may establish a "good-enough" situation that allows you to tackle the technical debt you've built up.


There’s no upside for the developers to do things right. There however is an upside to do things fast - the bonus. I didn’t see any penalties for substandard work and add the fact that their contract might or might not be renewed in x months and you’ve basically taken away the incentive for developers to do things right.

Determine what’s important to you/company and structure your reward system accordingly. Your current reward system values speed of delivery, not its quality.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .