How do you diplomatically call a situation 'very bad' in a resume-like document?

Question

I need to list in a resume-like document how a system I've worked on was so misconfigured as to be ludicrous (like I cannot describe the level of incompetence that led it its state when I found it), but it needs to be in a business-appropriate way and concise enough to fit in a bullet point, preferably a word or two.

I've tried searching around for things like "business terms for 'terrible'" and "diplomatic ways to say something is incredibly bad" but the problem is that I can't abstract the language enough to figure out an actual business-positive way to call out how awful a thing is. I want to be able to succinctly highlight an enormous challenge without simply asserting personal opinion. For example:

• "The environment I took over was so poorly-assembled and mis-managed that I was left with no option but to restructure the entire business' processes around it and build a new environment from scratch. I've never seen something so laughably bad in my life." This not only feels unprofessional, but it takes a lot of space.
• "I took over an environment with nothing but room for improvement." Doesn't have the impact, also feels mostly subjective, and falls far short of describing how actually bad it was and what a challenge I had ahead of me.
• "Took over a critically mis-configured environment." This one sounds the most succinct but still lacks a description of how it was also mis-managed due to lack of expertise, it only addresses one slice of the pie. It also feels a bit off-the-cuff, while I'm looking for a very professional way to describe the situation.

Is there a word or phrase, or even a short sentence, that would convey what I'm trying to illustrate without sounding petty or offensive?

Answer 1

The key thing is that your statement needs to be factual, rather than opinionated, and you need to be able to back up any statements that you're making - because you're likely to be challenged on them by whoever was responsible for this mess.

A useful term for this type of situation is technical debt, because it's not blaming anyone, and it's an easy concept for non-technical management to understand. You're making it clear that the system implemented by cutting corners (for whatever reason), and that the price needs to be paid for those shortcuts. Something like:

There is a high level of technical debt, and it will require a significant investment of time and resources to bring the system up to a state where it is reliable and maintainable going forward.

This explains the issue (without pointing fingers at anyone), and provides a way forward (rather than just saying that it's all crap).

And then you can drill down into the details of the actual issues (missing documentation, best practices not followed, legacy and outdated components, etc).

Answer 2

A useful approach in situations like you describe is to focus on what you did (i.e. how you made the system work), not on what others did (i.e. how bad it was before you started). This way, you're painting a good picture of yourself (which is what you're supposed to be doing anyway) and not a bad picture of others (which, as you've noticed, tends to come off badly).

So, concretely, I might rephrase your example statements as something like:

"I was hired to manage and modernize a business-critical legacy Foo environment that had grown unmaintainable. After a four-week evaluation and consultation with the previous maintainers I developed a roadmap for gradually replacing the legacy system with a modern and properly configured Bar installation while maintaining continuity of critical business processes depending on it, and over the following six months oversaw the successful replacement of the system."

This could probably be even shorter and more succint, but it communicates in a positive manner the parts that you really want to communicate in a resumé:

• You were given a difficult task, and you succeeded in it.
• You brought in expertise and organizational skills that no-one else in the company had (or they would've fixed the system already).
• You managed to fully replace a business-critical system with no (or minimal) costly downtime.

Also, besides these general indications of your competence and initiative, the description above is detailed enough that someone reading it could recognize parallels with current problems in their own company. This could be a good thing or a bad thing (do you really want to end up being tasked with cleaning up another similar legacy mess in your new job?), but at least it's another reason why someone might want to hire you.

(Of course you'll obviously need to tweak this statement to fit your actual circumstances. For example, if you weren't hired or assigned to fix the messy legacy system, but just took it up as a task on your own accord, say so — and try to emphasize your initiative and willingness to step up to new challenges. This can be tricky to phrase, though, since you do not want to come across as someone who disregards their assigned tasks and priorities and just decides to embark on a costly and risky replacement project just because they don't like the existing system they're supposed to work with. Something like "developed a roadmap which was approved by the department lead / CTO / CEO" could be a useful phrase to include — if true! — just to make it clear that you in fact had proper senior management buy-in for your project.)

Answer 3

Simple. "Fixed broken xyz system". No blame at all. No mention of incompetence. Things can get broken because you upgrade to a new OS version, which was unavoidable because other systems needed it, and therefore nobody's fault, or because the original developer was beyond incompetent.

You just fixed it. Didn't work before you joined the scene, works now. You make things work without being distracted by blaming people. We like people who make things work. We are not so keen on people assigning blame, especially from a very limited point of view.

Answer 4

Why do you need to say how bad it was at all? You say a "resume like document", so you need to say what you did rather than giving your opinions on other people's work.

So instead of

The environment I took over was so poorly-assembled and mis-managed that I was left with no option but to restructure the entire business' processes around it and build a new environment from scratch. I've never seen something so laughably bad in my life.

Simply say

I restructured the entire business' processes and built a new environment from scratch.

(with maybe a few more descriptive / clarifying words if required)

Answer 5

Lots of other great answers here. But I want to focus on how someone might read your three examples, that wouldn't match what you're trying to tell them:

1. "... I was left with no option but to restructure the entire business' processes..." I would assume this was a working system, and be very skeptical that this amount of work was necessary, opening up questions on whether you can remain focused on what is needed, not what your idealism wants to pursue.

2. "I took over an environment with nothing but room for improvement." This could mean that anyone could have done almost anything to make this system better, and doesn't highlight your contributions.

3. "Took over a critically mis-configured environment." Again, this doesn't highlight your successes.

As others have said, show quantifiable success, like 'enhanced system to allow 25% growth' or 'delivered $2 billion in increased revenue' or 'reduced time-to-pay by 18 days per month', etc.

Answer 6

"Managed and made improvements to a legacy system which was not fit for purpose."

The word "Managed" suggests you took charge & coped well. "Made improvements" suggests you left things in a better place than when you found them. This gives the sentence a positive spin right from the start.

"Legacy" suggests it was old / clunky / already there when you found it - i.e. not your fault! (Maybe use "pre-existing" if you don't like the word legacy.) And "not fit for purpose" is professional way of describing your nightmare without sounding too opinionated.

Overall, this phrase is concise enough to be a bullet-point on a resume; which can be embellished in person if questioned about it.

Answer 7

I say tell your story.

It flies against some of the other advice here and against advice you might get from an employability expert on the subject of CVs/Resumes but it's what I'd do.

I see no harm in bigging yourself up by saying that you worked on a particularly difficult project BUT any language that you use to do so shouldn't just be derogatory. It should serve a narative purpose. Avoid words like bad and variations that aren't descriptive beyond indicating negativity. Instead use terms like convoluted, overengineered, not fit for purpose, etc. But even then, context is important.

I've spend a lot of time working on a less-than-optimal application at the core of a large chunk of a large, multi-national company. It should be strategically thrown away and replaced with a custom solution instead. But, having said my piece, my mandate is nevertheless to polish the turd and make it useable. But that's not what I'd stick on a CV.

And maybe you'll feel you can't go into too many specifics because word count and confidentiality. That's fine. But you might be doing yourself an injustice.

Something like:

"I have extensive experience taking existing applications with many faults and improving them. One such application, deeply rooted in my client's organisation had a hastily designed UX that proved difficult and time-consuming to navigate; it was prone to crashes and resource hungry; it had a database schema that made report creation very difficult; and while the application had an API and could be configured to call custom executables triggered by certain events, what the client company was making do with when I was brought in was not fit for purpose.

By the time I left the project, I had increased the speed of the average user's end to end work process by reducing load times by over 80%. By refactoring and debugging the custom executables, crashes too were reduced from around 80-100 reported incidents per week to 0-2. The UX was unchanged in the core product, but I was able to build a separate, custom interface hosted on the client’s intranet that boasted a clean interface, designed in partnership with key users, that better met user needs and, because I acquired such a wholesome understanding of their business logic, even automated some of the core application’s biggest pain-points. And, finally, after studying the database schema I was able to create a number of custom views that better fit the needs of the client's data analysts."

This is wordy. It's less than perfect in other ways too. But I'd want to meet anyone who submitted a resume with something of a project history like this on it.