49

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?

2
  • 1
    Comments are not for extended discussion, they're also not a substitute for the answer space so this conversation has been moved to chat.
    – motosubatsu
    Jun 21 at 9:56
  • 41
    "I need to list in a resume-like document how a system I've worked on was so misconfigured as to be ludicrous" — do you? It might help to know what this document is meant to achieve. For an actual resume, this level of detail about the deficiencies of the old system wouldn't be relevant. Are you trying to sell yourself for a promotion at the organisation where you worked on this old system? Jun 21 at 10:35

7 Answers 7

145

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).

11
  • 96
    Particularly wise to avoid pointing fingers if one wasn't around for the system's previous history. Without that background it can be very hard to distinguish between "previous manager was incompetent" and "previous manager was doing the best they could in circumstances that didn't leave room to do it right". Jun 20 at 23:41
  • 4
    This is very good advice, I'm having trouble sticking with facts because I'm professionally so distraught by the level of incompetence. I think "technical debt" is the right term to use, thank you!
    – thanby
    Jun 21 at 0:37
  • 15
    @thanby be aware of Not invented here syndrome. People will always say code made by others is worse, even when its not. Jun 21 at 8:23
  • 16
    "Technical debt" is correct if it is working, but is for example very hard to maintain, a future maintenance nightmare and so on. If it works today but you know it will break in the future, that's "technical debt". Tomorrow when its broken, its not technical debt, it is "broken".
    – gnasher729
    Jun 21 at 8:52
  • 19
    +1 for @SirDuckduck Having worked around a lot of old code, it gets very hard to tell apart the "at the time, was a genius fix that saved the project" code from the "developer got fired for incompetence shortly after writing this" code, after enough years and secondary fixes. Accept that we're all writing stuff that the next people along will sneer at, and concentrate on how to make it better.
    – lupe
    Jun 21 at 16:59
59

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.)

2
  • 6
    This is gold. Concise, constructive, casts nothing but a good light on the writer. Jun 21 at 16:33
  • 4
    I look at it as separating the "what" from the "why". Resumes are concise so they list what you did. Why you did it is something you'd discuss in an interview setting. Not only is it more space-efficient, but it makes it easier to tailor the way you tell the story to that particular company's needs.
    – bta
    Jun 21 at 17:17
14

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.

2
  • Although "works now" is important, OP might also want to mention other contributions, like proper documentation to facilitate future maintenance and upgrades. Jun 22 at 2:25
  • 3
    I'm on the fence about "fixed broken"; I'm more a fan of, e.g. "modernized and documented a difficult-to-maintain legacy system" or "optimized[/simplified] a complex system" or something more neutral, even if it's more verbose.
    – Jason C
    Jun 22 at 15:19
12

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)

1
  • 1
    Not forgetting to mention benefits accrued by doing so, e.g. 'thereby reducing customer response time from 3 months to 3 days' or whatever was actually accomplished by making the changes.
    – traktor
    Jun 23 at 14:16
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.

2
  • Hmmm. Yeah. I read those quotes and they do nothing for me.
    – DKNguyen
    Jun 21 at 20:45
  • +1 "mis-configured" could mean you set foobar to 1 instead of 0, not really the story you are trying to tell!!
    – deep64blue
    Jun 21 at 21:30
4

"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.

2

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.

2
  • 2
    I like this answer the best, because instead of qualifying the system with unsupported like "misconfigured," "mismanaged", or "poorly assembled," it describes the impact or limitations of the system objectively. It crashed, it was resource-constrained, sales were lost because it didn't meet customer needs, or whatever. Without objective descriptions like these, I could wonder if the candidate just invented an excuse to fix an ain't-broke system to suit their personal aesthetic.
    – erickson
    Jun 22 at 16:14
  • This is far too wordy for a resume. It might fit in a cover letter, though.
    – nick012000
    Jun 24 at 2:14

You must log in to answer this question.

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