Trjtdtk

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.

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.

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.

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.

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.

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 .