It's 100% denial/ego. I've been a contractor longer than I'd like and it's the exact same response I see when I join a new team. The team complains they have too much work and can't get anything done, so their manager pulls me in. Suddenly, they don't want to give anything up. I'm actually in the middle of this right now. The team "is swamped" yet somehow, they are able to argue that almost everything I can handle is best handled by them and they don't need help. Fine by me, I'll sit around and get paid. But it smells exactly the same. They don't want to admit that A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.
The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions.
Thus:
Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottleneck. But being the bottleneck is not the root problem, but rather a consequence of not being allowed to improve things.
Concerning (A): It is indeed often the case that if you simply let someone else do the work, the code quality decreases a lot and in subtle ways. Good programmers are very sensitive (and sometimes vocal) with respect to that - in opposite to managers.
And I totally respect that, I get it, I really do. But it's really obvious when people are being territorial and any contractor will tell you this happens every time. I suspect that a lot of the times, I'm hired to "teach them a lesson" in that "Hey, velocity sucks and I'm hearing a lot of whining, so if you don't like doing it, this guy will" and people snap into shape.
Unless the team are seriously bad developers, many times, it’s the manager fault. As a hired consultant, you often benefit many freedom that team is lacking. As someone that has been hired as a consultant, one of those are meetings and not having to worry about office politics.
I love how everyone is blaming management and if they only listened to the programmer(s) everything would be fixed.
I’ve been on all sides of this coin, and there is plenty of blame, misunderstanding, and bad ideas to go around.
Additionally on A: the people who will be stuck maintaining this contribution for years and years have a different view of the pain.
Pushing a 90% solution through is a ‘win’ for the coder who is leaving, and hurts everyone on a continuing basis. It’s bad accounting, and lets the consultant look good for making the team perform worse (and look bad later).
And, IME, if that 90% solution needs a 100% rewrite after 40-80% burn in bugs and error chasing? What once was a bit behind is now way behind with staffing issues. Sunk costs don’t create extra budget.
Do It Right The First Time doesn’t always apply, only mostly always. Some people are insecure and territorial, yeah, but some know what their job is.
No matter what you do, entrenched engineers will make SURE they will be the only ones maintaining everything until their retirement, because they will make life impossible for everybody else until they leave.
Entrenched engineers don’t want to you to alleviate or god forbid share the pain. Pain is good for employment security. And if the ship goes down, they’ll make sure they’re the last one to get fired, because there’s nothing the entrenched engineer fears more than having to job hunt.
Well who are you? Why should they trust you to actually complete a task and not dump unfinished work on them when your contract is up?
The manager didn't do the work to figure out what a contractor should do before hiring one. Why would they expect that org to plan the exit if they didn't plan the entrance?
Behavior shouldn't be surprising, no?
I mean, they hire me for a reason, whatever that may be. I want to do a good job and carry out the task because I want to get hired again by them or whatever agency is pimping me out. I've seen a lot of shit and that's my value. Whether or not the team wants to help me succeed is their political thing. And that's not invisible to management either.
You're not looking at it very empathetically. You're disregarding the concerns I floated, you expect the team that feels underwater to now stop everything to reshuffle the work scheduling to fit in a wild card all while you're calling them bad and replaceable.
I mean it really sounds like you're not on their side at all. It's their job to help you succeed, apparently. From what you've said already, you don't care about the project either. You're happy to waste time and money. It sounds like they're right not to trust you.
If he was hired to do a job, its not on the team to "trust" him. Its to incorporate him as a resource. I'm sorry but speaking strictly from a productivity standpoint, we're not here to be empathetic, we're here to deliver value to the organization.
If I'm a manager of a team thats struggling and now also sabotaging additional resources, because they havent got the right warm and fuzzies, I'm going to be looking to have some difficult conversations. I'm also going to be very critical of anyone who floats a lack of "trust" as the blocker without some concrete evidence to justify it.
Whatever concerns they might have is not for the contractor to address. They are between them and their own management who deemed them unable to deliver sufficiently.
Well this is all highly hypothetical but my point is that there are valid reasons to not entrust a contractor, who is only around temporarily, with long standing features. Not because they are nefarious but because they, by definition, will not own the feature ultimately.
Resistance is also not the same as sabotage. My assumption is that everyone is acting in good faith from their own perspective. An immediate issue I see that the contractor was brought in because folks were looking at the calendar and not the tasks. Now the team is being pushed to carve out tasks. If shovel ready tasks are identified first, almost certainly, things go smoother. You're not context switching everyone. Its far less chaotic.
What you seem to not understand is empathy is going to move the team forward and deliver. Jumping to bad faith immediately is likely not the fastest way to a solution. If someone is struggling, its useful to understand why and address those problems. Its often not because they're bad.
That's not at all what I'm saying and I don't know where you're getting that from. I'm not trying to stop anyone. I'm trying to be an extra paddle. I'm happy to do nothing iff I try to help but get boxed out. I have no problem just riding in the boat and saying "hey, there's rocks up there" or "This seam looks leaky, maybe patch it". I'm not here to fight people or egos.
This sounds like my ideal job. How do you land such gigs?
Recruiters.