update: after reading the answers and comments below, I realized I started off with the wrong question, and actually just needed a change in perspective. The answers in this question are now much more relevant to me.

The team I currently work in follows bad software development practices. The team is part of a big international company, but it is not primarily a software company.

The (bad) practices include:

  • no version control. (infrastructure is in place, but my team does not wish to use it)
  • no centralized issue tracker. (we do send spreadsheets to each other however, so this might just be a matter of preference)
  • no clear development process. (at least, not clear to me).

I have been pointing this out for the past 6 months. My team's manager has left the company after a 3 month absence, and there is no replacement for him at the moment.

I have spoken to several people in management positions and they all agree that this should be solved. Some action has been taken to eventually solve this. But I am not certain resolving this will eventually happen.

I am not very experienced yet, and not in a position to structurally change this myself. I do try however, to set the best example wherever possible.

Should I let management know that I consider leaving the company due to these practices? Or at least let them know that I am growing quite frustrated?


10 Answers 10


You actually ARE in a position to change this. You lead by example.

You can start using version control locally for your changes. You can simply 'commit' everyone else change at the same time. You will always be able to recover previous versions and compare things to prior versions.

You can also offer to do this for the company. Setting up version control (on a smaller level) is fairly easy to do and manage. This may set you up for a promotion in the near future if it is seen as valuable.

You can do something similar for the issue tracker.

Don't let an "opportunity" to excel be a reason for leaving. Expecting a 'senior' person to do the work guarantees you will always be the 'junior'. Once the company sees you as an authority for solving systemic problems - you will have a lot more power to implement changes in the future. That is how you become the 'senior' leader. You have to demonstrate the competency.

  • 63
    Leading by example means that in your subsequent interviews you can talk about how you single-handedly implemented source control and did whatever you could to improve the company's culture. Apr 2, 2019 at 16:26
  • 8
    The only problem is that if the team steadfastly refuses to use either system, then OP will always be the one making all commits and entering all tickets. May not be an issue, but worth considering that this might result in unintended consequences down the line (e.g. being scapegoated if something goes wrong with either). However it's also possible that they'll start using a VCS if you do this. I would highly recommend making it easy for them: SVN + TortoiseSVN. Not saying this is the best solution, but WAY easier to go from nothing to this than to say a full Git implementation.
    – bob
    Apr 2, 2019 at 21:16
  • 6
    If you go this route, make sure to keep notes about things that you were only able to do because you were keeping things in version control. Non-technical management doesn't respond well to technical explanations. However, if you're able to show that you saved a half-million dollar customer account because you were using version control, then you can expect a much stronger management buy-in.
    – bta
    Apr 2, 2019 at 22:50
  • 8
    @bob I recommend against SVN. Its overuse of folders and poor support for branching leads to all sorts of anti-patterns and bad practices in organizing repositories. These practices would have to be unlearned. If you're starting from scratch, you may as well just go with git. It's not as hard as people make it out to be if you stick to the basics and don't worry too much about the main branch being a little messy at first.
    – jpmc26
    Apr 3, 2019 at 3:47
  • 3
    @bob I'd actually argue that it's easier to go to git without first going for SVN and learning them the old way first. They'll feel weird about it at first anyway and git seems far easier to just run locally and gradually pull in other team members to use it, in particular if you have no senior/company support to provide resources like a server. Apr 4, 2019 at 0:11

Should I let management know that I consider leaving the company due to these practices?

Never say directly that you are thinking of leaving - as soon as management know that you're not committed to the company, that always puts you at risk of being out of a job without a new one to go to.

Or at least let them know that I am growing quite frustrated?

This is a much better idea - and an ideal topic to bring up in any regular 1-to-1s or similar that you may have with your manager. I'm suspecting that you may not have regular 1-to-1s (which is a different issue), but you can always schedule a meeting with your manager, or whoever is at least sort of acting as your manager, to let them know that your concerns.

  • 10
    'I have been pointing this out for the past 6 months.' 'I have spoken to several people in management positions and they all agree that this should be solved.' Sounds like @OP has done what's available to do to raise these concerns. The only thing left to do is stay or leave.
    – Alex M
    Apr 2, 2019 at 17:56
  • 11
    i think general advice here is "Never say directly that you are thinking of leaving if you don't have other job offer" Apr 2, 2019 at 19:42
  • 6
    @aaaaaa More than just a job offer, a signed and dated contract. See so many questions here about resigning from job A only to find verbal job offer B vanishes into a plume of smoke. Apr 2, 2019 at 19:56

From the sounds of the (bad) practices, this seems like a small company. I would say voice your frustration in a way that improves the company. Saying something like "Hey, Mr. Manager - I notice that we aren't following some best practices. This can effect my efficiency and others on my team. I was wondering if we could have a discussion, maybe with the team, about putting some best practices in place?" If at this point your ideas are falling on deaf ears and you plan to leave, do so quietly while searching for other jobs and give your proper notice (usually 2 weeks in the U.S)

You also mention the manager has been out and no replacement. what if you could be the replacement? I know you say I am not very experienced yet. But showing your company that you are passionate about leading the team to better practices goes a long way - especially in smaller companies. If you are worried about lack of experience, you can ask for training. At the very least you can have a discussion about the path of your career to move into a management role. Of course, only pursue this option if it is something you want.

  • 6
    Actually, it as a big multinational company. Just not big on the software development part. I will update the question to reflect that.
    – gorgabal
    Apr 2, 2019 at 12:46
  • 1
    @gorgabal just pointing out given your current stackoverflow profile it's extremely easy to pinpoint what said big multinational company is. There are articles on SO on how to deal with anonymity / protecting a question etc if this is a problem for you. Apr 2, 2019 at 20:53
  • 1
    Small company wouldn’t be any excuse. I have an app that I develop on the side privately. It is completely under source control.
    – gnasher729
    Apr 2, 2019 at 21:26

One thing I noticed in my career is that if you expect a manager to manage anything useful, you're going to be disappointed :-)

What does work, particularly, in small teams is proactive improvement. You say there's no version control. So put some in. Get something simple and easy to maintain and free (whether its VisualSVN on Windows or git on Linux) just install it, show your colleagues how to use it, and hopefully you will all use it without problem. You won't be able to force its use, but really, if you can show a benefit without much cost (in terms of effort or time for the devs) then they'll use it. Chances are they already know its needed but don't have time or inclination to make the effort to put it in.

An issue tracker can be done the same way - if your VCS comes with one, use that, otherwise install a web tracker thing and show people how to use it.

The trouble comes with overcoming inertia from the others, but that's what interpersonal skills are for - explain, encourage, get them excited about going for it.

You don't need a manager for any of this. And you don't need to leave because your team has no devops environment. So improve things, don't just run away, and don't make assumptions that you can't change it yourself - you can, pick that ball up and run with it.

  • "that's what interpersonal skills are for" - Don't tell them why you are interested in/excited about it - show them the benefit to them. It's the difference between "I want to play ping pong, come play with me" and "you look frustrated, some ping pong will help work that out, let's go!" - both get you a ping pong match, but the other guy believes you're looking out for him. NB: make sure you really are looking out for the team - if you're fake, they'll see through it pretty quickly.
    – FreeMan
    Apr 2, 2019 at 12:46
  • Comments are not for extended discussion; this conversation about the merits of SVN vs git has been moved to chat. Continue it there, not here. Apr 7, 2019 at 19:45

Your question is actually two-fold:

  1. Should you tell management you're considering leaving the company.
  2. How to improve/enforce best practices.

Now, these two have been answered plentiful on this site, but here are the basics.

  1. Never tell management you're considering leaving the company before having a signed contract from your new employer. And when you do, don't accept counter-offers.

  2. Be the change. Set up version control, use software patterns wherever useful, set up linters etc yourself. You will notice that this is as much fun as having your team do it or more.

  • Why would state don't accept counter-offers as a general rule?
    – JeffC
    Apr 2, 2019 at 17:00
  • 2
    @JeffC Because it doesn't usually work out. Apr 2, 2019 at 17:28
  • 4
    @Jeffc It's not necessary for the outcome to be absolute to justify an absolute rule. My advice to you is to NEVER drive while drunk. Not carefully consider whether or not to drive drunk, just never do it. Am I wrong because sometimes people drive drunk and they don't get in a wreck?
    – barbecue
    Apr 2, 2019 at 19:57
  • 2
    All analogies are flawed, or they wouldn't be analogies. Since you don't like the high stakes one, instead consider buying a lottery ticket. If I have a rule that I never buy lottery tickets, that doesn't mean I think nobody ever wins the lottery, I just don't think it's worth doing.
    – barbecue
    Apr 2, 2019 at 21:24
  • 2
    Apply the same reasoning to any rule that says "Never do X." Having a rule that you never do X does not mean you reject the possibility of X being beneficial, it just means you've made a rule. Absolute rules exist because they're easy to follow.
    – barbecue
    Apr 2, 2019 at 21:26

I am in a similar position (and I was actually considering posting this for suggestions) except the fact I am actually having problems convincing MY OWN TEAM & MANAGERS to use version control and project management tools. And while this might not be exactly what you are looking for (I answered at the end of the post), maybe it can help you understand why some companies are like this.

I've been in this company for 5+ years and before I became the Team Lead, I watched the previous Team Lead trying to do the same with almost no result.

In my case the situation is frustrating since:

a) most of my team members try to avoid taking responsibility every time they are given the change

b) every time someone blows it (and it happens), I am the one taking the blame because the manager (who is a non technical person) believes that one's success belongs to all (him included) and one's error (his included) is the leads fault, thus leading to a)

c) the manager often sets up meetings with individual members of my team to assign new tasks (change functionality and design) on a projects where the entire team works or to take them off the project for undefined period of time and fails to notify the rest of the team (or me, in this case) and to fill in the changes in Trello / Freedcamp

I tried everything I could think of:

  • Set up BitBucket teams yet we ended up messing things up because some refuse to commit & push their code
  • I tried setting up project management tools (Trello / Freedcamp) but as I mentioned above (c) they seem useless
  • Members of the team forget or refuse to change the status of their tasks or fill in new tasks if necessary (bugs, possible issues, etc.) because they think it's a waste of time (after all, if they can keep their notes in a Sublime Text or Notepad, it's OK) therefore leaving the entire team unaware of these things (and this caused a lot of problems in the past). Not to mention no one in UI/UX design filled in anything EVER (artists don't have time for this, they say), resulting in devs working on UI features that were about to be removed or changed anyway. Occasionally, the manager sends some spreadsheets or emails to certain members of the team, leaving the rest out of loop.
  • We set up Facebook Workplace to enhance the communication and created groups for all projects, teams, departments, etc. Yet the only group used is the roast one.
  • For a while I actually had to manually get archives of the apps on my workstation and manually check every line of code to merge changes. Also, I tried talking to my managers every morning and after every meeting he had with my team members to get all the tasks in order to fill them in myself. All these resulted in me spending half of my time checking other people's work instead of doing mine, thus b) above.
  • I ended up setting up meetings with all management staff and explained the situation and as a result, we decided to have stand-up meetings everyday and one meeting at the end of the week, in order to make everyone do their job but in the end, it didn't work.
  • I even wrote a common sense practice guide that even included How to on BitBucket, Trello and other tools we are using but people simply ignored it.

After all this time and all the hassle, I came to one simple conclusion - it takes a lot to convince people to play nice and follow some simple guidelines and if they don't really want to, you cannot change this. Leading by example works on people that are ready to accept changes and in this case, when you're backed by the management team or anyone who can actually enforce the rules (although I do consider that it's better to explain your point of view and why do you think things should be like that, even if you are right, enforcing is sometimes necessary albeit unpleasant).

Now to answer your questions:

1) Should I let management know that I consider leaving the company due to these practices?

NO. Never let them know you plan on leaving untill you are certain you have a new job. It's risky for you since the management will assume you are no longer committed and you are only trying to find some excuses no to do your job. And if you really want to tell them the reason you are leaving, do it after you secure yourself a new job. And make sure you are not doing it by throwing the blame on the management or your colleagues. If you start blaming others, it can bite you back in the future. Be polite.

2) Or at least let them know that I am growing quite frustrated?

Sure. In fact, I believe this is a good idea. You can also ask them to explain why do they think those practices are a good idea. Maybe they actually have a reason for going on like this and you are missing it. But in the end, don't expect too many changes and certainly, not over night.

  • "because they think it's a waste of time" - this is crucial. You need to demonstrate that doing it your way will save them time and effort. The sooner they save the better. Apr 4, 2019 at 8:00
  • I did. We had a situation where the person in charge with implementing some new features took a few days off without letting anyone know what tasks he completed and that he had new tasks. Some of us checked the Trello boards and start implementing stuff and when we pushed everything on git, things got messed up. And what's worse is that he made the unannounced changes directly on the production VM, on the production branch. No new branch, no commit, no push. His final conclusion - Git sux, it messed up his work. We lost 4 days trying to fix this and rewrite his work.
    – daydr3am3r
    Apr 4, 2019 at 8:09
  • Why didn't he understand that his changes would be overwritten at the next deployment? (Also sounds like a good time to decide that only git can touch the production server) Apr 4, 2019 at 8:56
  • He was expecting everyone to check the production server first. But we all pushed to git, merged and pulled from there. As for the git only part, it's a bit complicated. Since it's a production machine, behind the client's VPN, we can only access some internal services / apis from there. And we weren't provided with a dev clone so... This was the reason I insisted so much to use git and Trello (besides the other common sense reasons) in the first place. Knowing we will have to do some work directly on the production machine should've put everyone on guard.
    – daydr3am3r
    Apr 4, 2019 at 13:35
  • Sounds like there is a lot to chat about on the retrospective. "How can we avoid this in the future?" Apr 4, 2019 at 15:18

Don't underestimate your ability to make a positive impact on your team. It doesn't matter how much or how little experience you have, everyone has a different set of knowledge and skills and can use those to improve things.

When I first started working after college, I worked on the codebase for a product that was originally developed in the 1980's. The coding style, development processes, etc hadn't changed a whole lot in the quarter-century since. We didn't have real version control, documentation was non-existent, and many development processes were far more complicated and time-consuming than they needed to be. Management was far-enough removed from the technical aspects of things that they agreed things could improve, but weren't too driven to do anything about it. Overcoming this inertia and making meaningful changes required understanding the motivations of stakeholders and learning how to communicate in ways that spoke most strongly to each of them.

Most people are like cats. You can ask them to do something, but they'll largely ignore you. They'll happily do something if it was their idea, but they'll protest and refuse to do the exact same thing if it was an instruction coming from you. The key to convincing others to change a deeply-ingrained process is to make them want to change, which involves them truly understanding how it will benefit them personally.

For example, one of my big pain points was our build system. It was a cobbled-together mess that was extremely error-prone and slow. A full build could take 35-45 minutes, and dev/test iterations were slow. I re-wrote the build system using Makefiles, but nobody was interested in learning a new tool. At least, they weren't until I was working with a senior dev on a bugfix. We made a change and kicked off a build so that we could test it. The senior suggested we go grab lunch while we were waiting on the build. I asked him to wait and when my build completed in around 90 seconds, he was visibly confused. I told him "that's the new build system I was telling you about earlier, you should really try it out, it saves so much time". In the time he was expecting to take to do one single build, we did a half-dozen edit/compile/test cycles. We were able to resolve the issue and deliver a fix to the customer several whole days earlier than promised. After clearly seeing how much time and frustration he would save on a daily basis, he switched over to the new system.

As another example, I noticed that a lot of our bug reports boiled down to us making preventable mistakes. I set up static analysis software to check our code base and found an incredible number of problems. After a bit of research, I met with my manager, explained what the static analyzer did, and showed him a list of bug reports from the last couple of months that were caused by problems that the static analyzer could have found. I then showed him the list of outstanding issues found by the analyzer. He was quite concerned about the number of bugs that could be waiting to surface. I pitched the idea that if we switched to a real version control system, we could set up a CI server to do automatic nightly builds, run static analysis, and email out reports showing any new problems found. Once he understood how changing the process would reduce the bug count (making our product more reliable and causing him to have to attend fewer meetings with test teams), he also started pushing for the change.

Even the new guy with no experience can make meaningful improvements in your team. To get there, though, you have to use those "soft skills". Think of it more like you're building an advertising campaign and less like a technical discussion.

  1. If you are not 100% sure you want to leave, then you can try to solve the problems as already suggested. If the company is otherwise healthy, this could be an important opportunity for you to grow professionally. You may be in the fast track for (big?) promotions too.

  2. If you are determined to leave, here are some discussions worth reading, just to be sure you do not shoot yourself in the foot:

What to tell when leaving

When to tell about leaving

Note: you added to the question that we talk about a big international company. It means that there is a big inertia for implementing changes. It combines with "team manager left" and with "bad practices". Therefore I would (kind of) forget option one.


The accepted answer is a good one and many of the rest make good points, but they don't address the worst case scenario.

I owe a lot to my first big-deal-to-me-at-the-time job as a front end developer at a recognizable century-old US brand name company. Recruiters haven't stopped bugging me since I got it on my resume. It also happens to be the stupidest, most ridiculous job I've ever had and the worst company I've ever worked for. By comparison it has made every situation that was bad in the workplace nowhere near as bad since.

How bad was it? (note: this was over 10 years ago)

  • It took two weeks to get a computer and what I got was garbage. There were PMs and interns with better laptops than mine. IIRC my earliest work was me doing trivial things on my own laptop and emailing files to people.

  • Network access was wi-fi only and over max capacity by about 200 people. I picked up a crimper and some cat-5 and caps at a Radio Shack (RIP) so I could make a 30 foot ethernet cord in order to reach an ethernet port from my spot on the cafeteria-style long table I worked at. I'd already learned from the first week waiting for the laptop to hope for help from something resembling dedicated IT. In the near-year I was there, this situation never got fixed. It actually got worse.

  • There was actual willful championing of mediocrity. Nobody cared if a completed project was reduced to a burning piece of molten slag by foolishness when it was declared finished. All you had to do was declare it was done a day or two early and they would celebrate, never making note of the fact that the follow-up projects were always massive sets of repairs and bugfixes on previous projects that were actually nowhere near complete on cursory examination.

  • I was on a team that had an hour-long meeting every day to prepare for the follow-up hour-long meeting which was mandated by the buddy of the guy who had purchased the company. Unsurprisingly, he wanted to circumvent some 18 layers of middle management to get directly to the developers, burning about 30% of our work days, ultimately self-sabotaging his own goals. This particular team, ironically enough, was doing performance work.

  • The greatest factor in our site's poor performance? Our requests were being choked to death by something like a dozen plus redundant analytics platforms that were being used to see how we were doing (I could have told them: not well). In my 11-month tenure there, we were never able to get somebody to let go of a single one of the silly things because somehow there was no gatekeeper. Think about that. They were choking performance, and as a result sales, so they could keep tabs on how good they couldn't possibly do because nobody wanted to learn an analytics platform other than the first one they'd ever been exposed to. We instead focused the bulk of our non-meeting time on much higher hanging fruit for very modest performance gains. I received an award for the laughable non-successes I was able to eek out on this team. It came with a 10 dollar gift certificate at the company cafeteria which was a lot like a public high school cafeteria, only without all of the giving a !@#$. To receive the award, it took about 4 hours of commute time to get out to the corporate HQ, which was long ago moved out of the city, probably because somebody high up wanted it closer to their house at some point. Hint: it used to be in a rather tall building of the same brand name.

  • The performance initiative itself was a deflection from another very real problem, which was that after a customer decided they wanted to purchase a product, they would, depending on who in a position to get changes made got their way that week, go through no-joke, 5-11 screens of upsells, address verifications, chances to make changes to their purchases, etc. If the browser made it to the final step, there was a good chance it would go to pieces when you tried to finally buy the silly thing you were after in the first place. On my home machine I would often see load-times of 30 seconds for each screen.

  • The back end development was outsourced to the largest offshore outsourcing firm on the planet (that company's founder was college buddies with the right person, apparently). The skill-level of employees from this firm ranged from actually-code-illiterate to entry-level and completely and hopelessly not in a position to change anything, as the code-illiterate types tended to drift up to the top. They did not use version control. They had a massive shared network directory. Their 200 or so (not counting offshore) devs would regularly copy over entire directories causing parts of the site nobody was actively working on to revert, mutate and go to pieces. Much of our job was to bend fold and mutilate the front end back in to place with limited control over the HTML so nobody on their end had to accept responsibility for their incompetence. I've since compared stories with other people who've had experience with this firm at other companies. While their stories certainly weren't positive they weren't nearly as bad and I'm now convinced they were using us as a testing ground for devs they couldn't be bothered to vet so they could promote out to more discriminating assignments at other companies while hiding their useless employees behind the blame game which was an easy game at our company.

  • We were once stopped at the finish-line on an already-overdue-due-to-severe-design-churn project to go back and change some logos the lawyers didn't like. We asked what the legal issue was and were told there wasn't one. They simply didn't like the look of the logos. There were no lawyers in our building or at any meeting I ever attended.

  • Graphic designer attrition, mostly due to frustration with way too many cooks in every kitchen causing constant post-deadline changes to their work, was so bad, we actually ran out at one point. Thirty front end developers. 0 designers. A more typical ratio would be around 1:4 designer to developer. Nothing but bugfixes for weeks. Sometimes the same bugs repeatedly (see folder overwrite situation above).

Believe me. I tried to be positive. I tried reason. I tried to reveal a better way. I tried to frame my requests for sanity in terms of success for the company over abstract notions like "widely accepted best practices practiced by everyone." What I finally realized was that I had just spent the last 11 months going through the 5 stages of grief as in:

  • Denial
  • Anger
  • Bargaining
  • Depression
  • Acceptance

Only it never ended because I would realize things were even worse than they seemed at the acceptance phase via some new revelation and then the whole thing would start over again. That realization that I was actually grieving over my ridiculous job situation was when I gave my 2-weeks notice without having found another job yet. Just 4 weeks shy of the 12-month goal I'd set for myself when I realized what an absurd situation it was panning out to be.

So before you give it your all and decide to be positive and lead by example, ask yourself. How are they getting away with it? Does it actually serve somebody for them to continue to get away with it? Are the powers that be too afraid of the political cost of acknowledging a problem in order to fix it? Is the overall experience a lot like discovering some institution or person you cared about, died every single day? Is it worth continuing to expose yourself to such a sham if it might leave you an angrier person for like nine months after you finally leave the job?

For me it was. Barely. But I should have just learned to laugh at it, abandon all pride in my own work (which would get trashed by the breakage on the back end, regardless of how hard I tried) and CYA until my year was up. Because sometimes there is simply nothing you can do about these situations. Incompetence and willful mediocrity may not be anything to be proud of but that doesn't mean they can't be forces to be reckoned with. Too big to not rebuff any attempt at change from a developer, a manager, or even a dedicated team with the best of intentions and an ally or two in upper management.

When it's finally over, take what you can from it. I learned a lot about writing UI that kept trying in totally unreasonable circumstances like the HTML and base CSS all around it mutating randomly. And no matter how silly it gets, I've both seen and can tolerate worse and I understand a lot more about why those best practices that got ignored are there in the first place. Most importantly, I've learned when to quit. You quit when they don't actually want your help or you realize that the only way to "succeed" is to become a lot more like them.


Run away and never look back , for many reasons . Lead by example ... Mm nah thing like setting up a source control and basically trying to force other to use it will cause a fire back as other will see you Trying to become the alpha and then you will have a trust issues and bad blood

Inform the upper management about the current bad work practices, will force you to set up examples of someone is doing something and following bad practice and your teamember will know you rat them to the upper management and you will be a backstabber in the eyes of every one , and then even other teams will avoid you .

You must log in to answer this question.

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