How to deal with inter-team work in a toxic team? [closed]

Question

I work for a company where the manager always justifies the shortcomings as "we are a company that happens to develop software, we're not a software development company".

There is the development team, the support team, the implementations team, and the reports team.

• Development develops what they feel is necessary, and rarely what the clients (corporate or other teams) actually need.

• Support doesn't know the product and sends tickets to development for things that were already explained, and doesn't "support" on their own.

• Implementations doesn't know how to implement and asks for help from development or reports.

• Reports has a boss that feels personally that everything should be addresses by her and exceeds her job description in order to please any whim the client may have.

• The boss refuses any change and only works so that "teams don't have issues with each other", and we use outdated technology that gets in the way of any change. Mostly any proposal not coming from a "higher up" is dismissed.

• The product is getting outdated and we're losing customers because of this.

Is there hope for this company? Can I propose anything in a way that would be listened, and not shot down by lack of rank?

Answer 1

If you are in the position to suggest the ITIL or any other process improvement methodologies, I would suggest you do this immediately.

Your company seems to be suffering from what is known as the SILO MENTALITY The linked article addresses it.

The problem is that everyone is concerned with their group, and nobody else's. I had a manager once who said "Don't just throw stuff over the wall", and that's exactly what is happening in your company.

Even if you are not personally in the position to affect change, you may want to read up on the subject and bring your educated opinion to someone who can.

Answer 2

Sounds like the company is in a late stage of silo failure. Where leadership knows everything is failing, and spend most of their time trying to cover their own butts from the inevitable fallout.

"we are a company that happens to develop software, we're not a software development company".

This is frequently the sort of thing used to justify a freeze in spending. A sure sign of current problems. Often this is preceded by a change in ownership of the company and the new owners not understanding what they acquired.

Imagine if you will, 2 car dealership.

The first sells SUVs exclusively and makes huge money on very little effort.

The second sells compact cars, light trucks, and other niche markets. They do this by designing software the allows these cars to be self driving. This software is their selling strategy and is given away to anyone that purchases the vehicle.

Now some rich investment company buys both dealerships. Then looks at both. Both make the same profit, but company 2 has huge expenses. It makes no sense, they both sell vehicles, so why does company 2 cost so much more?

Soon a decision is made, company 2 leadership is instructed to cut expenses. The leadership does their best to explain the different business model but it just doesn't get through. The investment company sees a dealership, not a software company.

Pressure from above trickles down until:

Development develops what they feel is necessary, and rarely what the clients (corporate or other teams) actually need.

Developing exactly what was asked, without checking anything because no time can be wasted. Speed, quality, cost. You can't have all 3, quality usually plummets.

Support doesn't know the product and sends tickets to development for things that were already explained, and doesn't "support" on their own.

Support is a revolving door by this point. All tribal knowledge has been lost.

Implementations doesn't know how to implement and asks for help from development or reports.

Same reason, tribal knowledge was lost and nothing was documented.

Reports has a boss that feels personally that everything should be addresses by her and exceeds her job description in order to please any whim the client may have.

This is a prime butt covering example. This boss is making sure they and their team aren't blamed for the inevitable failure.

The boss refuses any change and only works so that "teams don't have issues with each other", and we use outdated technology that gets in the way of any change. Mostly any proposal not coming from a "higher up" is dismissed.

Time costs money, and expenses have been cut. This is maintenance mode now. This one point is why you should leave that place immediately. You are out-dating yourself and will make it much harder to find another job. It's worth losing your severance to avoid spending a year or more in school to catch up.

The product is getting outdated and we're losing customers because of this.

This won't bite the company until there is a solid competitor, by then it will be too late.

The short answer, there is no hope for the company. Culture gone this far can't be fixed without a complete change of everyone higher than middle management. It's very unlikely that will ever happen, and you shouldn't pigeon hole yourself while waiting for it.

Answer 3

Have you considered that you misunderstand your position in the company?

You seem to be hired as a fairly junior code monkey (no offense) without any lead or design responsibilities.

Now it is good and usually welcome to offer suggestions and improvements but once they were rejected you should leave it at that.

Furthermore, suggesting changes to the work of another department is way overstepping your responsibilities, unless you made out a clear error or have a sensational improvement on offer.

We all have to accept that we would run our company, even department very differently but can't change how others run theirs.

Just do the tasks you're assigned, voice concerns and make suggestions where you think in the grander scheme it would be an improvement and accept your superiors decisions even if you don't agree.

Don't try to fix everything you see is not working to its optimum.

Pick your battles and keep your position and experience in mind, others certainly will when considering your proposals.

Oh and yes, please shorten your TL;DR question.

Answer 4

I lived a version of this. Business thought IT did nothing. IT couldn’t get an answer from business. Software vendor was suing the support vendor. Thanks heavily to my manager, we went from finger pointing to partnering. In our scenario the mechanics were as much about laying out boundaries—not to silo but to allow teams to do their own roles—and communication.

Whatever your dynamics, change is usually tough. How you present suggestions is often going to have more impact than their actual content. Put yourself in the audience’s position. Developers do a poor job of passing information to support. Reporting is the only group who face the customer. Customers have no idea how the system really should work. Whatever the reality, if these kinds of perceptions are what each person thinks, that’s a bigger battle than anything else.

I’d suggest quietly documenting scenarios—not to throw in faces, but to build a story. Rehearse it as a case study, not a complaint. When the opportunity comes to talk with your boss or whomever, be passionate about the good you want it to do and dispassionate about the individual scenarios. Use them only as a tool from which to learn.

When you’re personally involved in an issue, go out of your way to make sure the ongoing issue is also addressed. Meet “this doesn’t work” with “Let’s take a look.” Instead of throwing an email over the wall with the steps, engage the support person to work through it with you or maybe work through the later parts. Get them involved in understanding why X fixes Y, not just what the steps are. More than any specific solution or new methodology, buy in will make or break the outcome.