How to deal with an incompetent department in a new firm

Question

Me and my team were hired to a new software organisation, "X". Top management is good and wants us to succeed. We agreed fairly tight timelines on my team's onboarding, in part because there is a team, "T", that provides a lot of services we would otherwise need to cover ourselves. As it turns out, however, "T" is incompetent, slowing us down and endangering our performance. How best to deal with this, given we're new, and sort-of rely on timelines for "T"? Top management doesn't seem to realise/acknowledge that "T" is incompetent. We're fully remote.

Incompetence is obvious when you're dealing with "T" directly, but perhaps less so from the bystander. They always have excuses and blame my team. A key report is wrong? Well they didn't know we wanted all the data in it. Crucial service stopped working without notice? Well they didn't know we want to use it now. Why don't you just tell us and we'll restart it. Another 10 things (serious issues by any other name) - innocent mistakes, can happen to anyone, next time we'll think about trying harder. It's F-up upon F-up, no committment to correctness or diligence.

Thing is, it doesn't seem too straightforward to go to management and say "these guys have no clue". It doesn't sound constructive, "T" would surely push back. Also their services are OK, say, 90% of the time - but due to the area, they should be correct more like 99.999% of the time. The issue we find each time seem to generate a flurry of activity, just not reliability going forwards. Their continued mess-ups slow us down no end. So far we took the line of "encountering many teething issues, but making slow progress". After the latest one, we're thinking of dropping all dependence on "T" and redoing all the work ourselves, that's how bad it is. This morning I'm clearing up another critical mess-up instead of doing what I was hired to do. We have a good written record of the issues, especially the more recent ones, but they require some energy to delve into, to fully understand the horror.

Any suggestions on how to handle this welcome.

---

EDIT

Just some common points:

• I wrote it at a low point; but in either case, I had no intention of going all-guns blazing letting rip of all my frustrations. Communication so far has been cordial, if anything it's "T" who are visibly annoyed with our team, and if anything.

• I mean "incompetent" in a factual and objective sense, I'm not looking for labels to pin. Also, there is an objective industry standard they are failing to. My post is understandably vague, but e.g. IT should be able to install a computer, which doesn't stop dead every other day for weeks and months on end. This is the scale of failures we're talking about, btw. What is causing these issues within "T" is a whole different question, it could be that it's not "T"s fault.

• We have been stuck on a loop of "here's another issue, pretty please can you fix, as we're all on the same team". We have bi-weekly calls with management, where we say with a smile that progress is made, blockages were encountered, here's tickets X, Y, Z". Management, notes, expressed hope surely now that it's the last of issues with "T" and we all go. It feels like this formula is exhausting itself.

Answer 1

Unfortunately without a clear view of the politics at hand you won't be able to do anything however should cover yourself and your team.

Start by doing all communication by writing if not already the case and be as precise as possible in your demands. Yes it takes some efforts you could direct somewhere else, but the situation is what it is.

Never blame, never assume, always observe. "X was asked but we got Y, please provide X", with your manager in copy if you have to.

Give it a bit of time, at some point you should be able to talk to your direct management and argue that your department could perform better if some thing went better with the T team.

Answer 2

Be very careful about calling someone "incompetent". Those who you think are "incompetent" may have totally different priorities than you would like (for example a manager who won't let them do the right thing, or business deadlines where they are forced to work long hours on unimportant things while having no time for anything important). State the facts. "We asked team T to deliver X to us, and they didn't".

Ask for your team to be reviewers for changes for your requests, so you can verify things are fixed before they are marked as fixed. Accept being blamed yourself and getting major pushback when the changes did what you asked for, but didn't fix your problem because you didn't ask for the right thing. And make sure that everyone agrees on priorities.

Answer 3

As pointed out implicitly by another answer, I would strongly discourage "thinking of dropping all dependence on "T" and redoing all the work ourselves".

This could backfire badly. Be aware of politics first. Also, do you really want that? I would argue what you want is your dependencies taken care of, surely, you'd rather not do this yourself?

In the end (without knowing exactly what team "T" is supposed to do), this is a learning opportunity. Team "T" needs to learn to be accountable. Holding them accountable (by testing their deliverables regularly and flagging up when they don't work, and by being precise in what's needed of them) should teach them that. Whether the individuals in team "T" learn or not, that's what team "T" has to deliver in the organization.

Keep pointing out issues with the team deliverables, and management will likely start recognizing the problem themselves: team "T" is not delivering. You could make this more obvious / try to attach a cost by doing some ticketing maths etc. to guesstimate lost time, if they don't take the hint, simply point to this whenever your team isn't delivering on time.

This should then be handled by management. It could do so in many ways, which you're not concerned about. Or it's not improved, in which case management (and you, unfortunately) have to live with the consequences.

Just as an aside: You make team "T" out to be incompetent. From your post, I could see other problems as candidates. For example, they might be extremely busy delivering things to many other teams, so they take short cuts that then don't pay off. Or maybe it's a communication issue: They're not always sure exactly what you need, but have been told to give you what you want, so they try something. Etc. Don't assume they're incompetent until you know.

Answer 4

Let's boil the question down to: are you more effective building a dependency yourself, or using something built by another team?

There's a classic Joel Spolsky blog post on this dilemma called In Defense of Not-Invented-Here Syndrome. Though technology has moved on in twenty years, the dilemma still exists. Software engineering surfaces the dilemma at a team level because software developers can have cross-competencies at lower cost than many other types of product development; the whole problem is arguably a special case of Roland Coase's 1937 article The Nature of the Firm.

To your credit, you're not pretending this is an obvious question. There are trade-offs involved. Let's try to make them explicit through some questions.

• How important to your management is timely delivery of your team's feature or service versus building architectural coherence and strong internal services? You've identified a pretty clear risk of slippage if you carry this dependency. Are those growing pains something they need service T to go through, at the cost of slippage? Or is timely delivery of this specific feature more crucial?
• What are the cultural expectations in the firm? Is careful design review by other teams expected, or do people expect you to JFDI?
• Who can make priority calls? Are you and team T under the same technical management or product management? At some point, you and team T all roll up to the one person on the org chart somewhere. Is that the CEO? The CTO? Or are you both reporting to the same manager directly? If there is a product organization, are both of these components considered part of the same product, and can a single product manager make a decision on priorities? The more distant the common decision point, the more reliable and low-touch a service needs to be to be worth reusing.
• Could you contribute patches to team T's service? This one requires some trust between teams, but it avoids an internal fork, too. Since you have the skills, and the motivation, could you jump development prioritization queues by adding needed changes to the code yourselves?
• Is partial reuse possible? Maybe some of the service or library is solid, and some of it is flaky. You could depend on the solid parts and roll your own for the flaky parts. You could get basic data and put a cleaner interface on it. Can also be useful as political cover in some cases. "We weren't able to onboard to T's SuperImportantService, as we found it needed to mature, but we are fully integrated with T's SmallReferenceDataService".
• What would be needed to integrate later? Write down in clear, engineering terms, in numbers where possible, what is needed from the service. Estimate the effort required to throw away your custom component and integrate with T, per the original plan.
• How unique is the service to the business? If it's a core function of the business, it will keep being reinvented over and again. You might need to work out how to make it succeed.
• Do other teams have problems with this service? Scout out other users of T's service and find out the lay of the land. Maybe everyone knows its a dog already. This will help with backroom political discussion and lobbying.

A company, especially a big one, isn't a blob, it's an archipelago of teams, some more closely connected than others. Tying your team to a dependency that won't ever do what you need it to is not going to help customers, or your own work. On the other hand, if all the shared service needs is some thoughtful engineering collaboration, it's a good way for the firm to standardize and save money, and can show good technical leadership.

Lay out the trade-offs involved in a clear, concise technical report. You can then use the report to justify the decision if you roll your own, or to push for the changes you need if you stick with Team T's work. You may need to revisit the decision in a few months or a year's time, and it will help then too.

Answer 5

Firstly, be very careful how you phrase things.

Calling someone incompetent is going to immediately shut down the possibility of actually investigating the root source of the issue. This seem to be built on some unfounded assumption that Management will blindly believe you over T when a conflict becomes apparent.

It is better to assume the exact opposite - you will not be believed until you have concrete evidence to the contrary. Ringing the bell before then is not going to look good on you.

Secondly, treat T and Management as a single entity, because they are both representing the same company.

You have no way of knowing what resource T has, whether the wrong people were hired for this job, whether they are buckling under an excessive workload, or whether they're meeting Management's overall expectation. Don't involve yourself in this.

You've been hired by a company. For all intents and purposes, the company acts as a single blob. This may be a multi-faced blob when you have several points of contact, but you have to treat them as multiple faces of what is essentially a single entity.

The first order of business is agreeing with management who your team depends on, i.e. establish your points of contact, points of escalation, and exactly who is authorized to decide/alter your workload. If someone is not on any of these lists, they don't matter to you and you should not cater to them either.

The rest of this answer assumes you know your proper points of contact.

Formally speaking, there is no purpose to distinguishing that T is not holding up their end of the bargain. T represents the company, and therefore the company is the one not holding up their end. Whether T is the sub-delegate that is supposed to provide the company's end here is up to the company to decide, not you.

Instead, you should communicate with your point of contact, and eventually your point of escalation when the situation does not get resolved. From that point on, it is on the company to fix its own internal issues, you should not meddle in this (unless you are both willing and explicitly asked to).

Is T not providing something they should? Talk to your point of escalation about being blocked because you do not have access to the [agreed upon thing]. Let Management sort out who should be providing [thing] and why they're not doing so. Not your circus, not your monkeys.

Thirdly, stop doing work you were not hired to do.

Failure to provide things you need can shift your deadline and is provably not your fault (make sure to document it to make sure). However, you deciding to work on something that you weren't hired to do, in a way that it impacts your own deadline, is very easily construed to be your fault for choosing to do so after making the agreements. This will bite you in the end if you hit a point of friction with Management about non-delivery.

Instead, alert your point of escalation that you cannot perform the tasks you were hired for. Wait for them to respond to this situation. It may still end up that you need to assist in resolving the issue, but wait for the company to explicitly ask you to do so. At that point, remind them that doing so will impact your deadline as you have now been sidetracked into work that was not originally planned.

If they disagree, do not let yourself get sidetracked, and repeat that the issue needs to be resolved as soon as possible for you to continue working.

If they agree to shift the deadline, that essentially solves the issue that the blocking issue created for you.

Fourthly, you should have factored in these kinds of delays.

You can't account for every possible scenario, but you do mention that you agreed to a tight timeline. That was a mistake on your part.

You effectively agreed to get a handle on a company's internal system, sight unseen, and made promises as to how quickly this could be delivered. You should either have investigated what you were agreeing to, or you should now have agreed to such a strict timeline.

Always pad your estimates with your expected delay times. The amount of padding can vary based on prior experiences with the company (there have been clients where I padded 150% simply because they continually changed their mind and had no concept of locking anything in).

Lastly, document everything.

Every time you are blocked, track the amount of time you are blocked. Back this up with evidence, such as the timestamps on when you sent an email and when you received a reply, or how long it took to resolve an outage, or how much work had to be redone because of someone changing their mind. Use manhours as your unit of measurement. If your entire team is blocked due to an outage, the effective cost is outage duration * team members.

Don't immediately start blaming the company for the first few delays that happen. However, as you get closer to your deadline or as the delays keep happening frequently, it becomes necessary to alert your point of contact that the deadline is in danger of no longer being reached. At this point, the company will respond about you not reaching the deadline.

That is the point where you bring forth your evidence, and a summarized report of exactly how many manhours have been lost due to blocking issues on the company's part.

Obviously don't just keep the blocking issues a top secret until the last day before the deadline either. Kindly alert people of the blocking issues, but don't immediately start ringing the alarm bell or suggest that this requires a contractual renegotiation, because you will be perceived as hypersensitive and will eventually be thought of as the boy who cried wolf.

---

To summarize

• Assume that the company knows precisely what it is doing, and that it has accounted for its own workings.
• Document any and all impact that the company's issues have on your workload. Be precise and provide specific evidence.
• Never butt into the company's private business. You do not have any standing to slander T to another part of the same company.
• Do not waste your time on work that you're not being paid for.
• Always include sufficient padding in your estimates for delays. Never try to undercut your own estimate for the sake of pleasing the client, unless you are making a conscious decision to roll the dice on such an outcome.
• Always make sure the company explicitly agrees to change your focus - and make sure to always mention the impact on your original agreement. This ensures that the company consented to these delays, and you cannot be blamed for going rogue or failing to deliver by mistakes on your own part.

Answer 6

Never start by flinging allegations of incompetence at colleagues. It immediately sets up the atmosphere in the company as one of antagonism, which will only harm your company. It also gets you and your department the reputation of being antagonistic, which will only harm you.

Also you don't know what the situation is in that department. You are a new organization. Maybe they are still working out how to make things work. Maybe they have some inexperienced people (that happens with new organizations). Maybe they are dependent on someone else who also isn't delivering like they should.

The way to deal with this is to do all the things you would normally do when you are not getting the support you need.

1. Talk with team T. Explain to them what level of service you need, why you need it, and how the company suffers when you don't get it. Be very careful here not to start out being accusatory or antagonistic. Make sure you start in the spirit of mutual problem solving. Find out if there is a reason for the issues.
2. Get together with team T and find out if there is something that could be done to improve things. Maybe some change in management that you could lobby for together. Maybe there is something you could help them with temporarily while they are sorting their stuff out. Maybe a small change in the way you work could help them a lot. Make your goal to improve overall productivity for the company, not just for your team. If someone on your team spent a bit of time helping this team, that would be better for the company than having them sit around waiting for some service to be available.
3. If for some reason the above doesn't work (and you will need to give it time) then start talking to management about the problem. When you do this don't say "T is incompetent". Explain again how the current issues are impacting company productivity, and give specific examples. Make sure your goal is to improve company productivity, not just make your own team look good.

Answer 7

I'm not sure why this is your problem. You said that you have a dependency on T, T is messing up, you report this to your manager, your manager says "that sucks, but there's nothing we can do about it", you move on. That's all you need to do. Your manager is not saying anything like "well, you should have pushed T harder" or "you should have done XYZ and not asked T to do it" or whatever, i.e. being upset with you for the delays.

For the moment, just continue doing what you're doing. Your manager knows what the problem with T is, if they are afraid of it delaying your project and missing your deadline, they will do something about it, e.g. contact the manager of T and have them shape up, or raise the issue with management. It's not your problem until your manager makes it your problem, which it seems is not happening.