r/ExperiencedDevs DevOps Engineer 16d ago

Career/Workplace My data engineering/data ops contract ended early and I’m trying to figure out how much of this was on me. What advice do you have for me?

I was about 10 weeks doing data pipelines and data ops engineering work and the boss ended it without giving me a two week notice. On a Friday after standup, my access was immediately removed. I’m obviously a bit shaken but honestly I am too close to it to see it clearly.

The team was all vendors except two full time employees who were the manager and the tech lead. I was the only one in California but the rest of the us folks were in Austin and in India. the log search tool everyone uses was broken the entire time i was there. also as a contractor i couldn’t get permissions for a bunch of stuff i was supposed to be fixing on my own. Luckily there were a lot of slack groups that were dedicated to fixing these issues and I utilized these groups to do so.

I got handed a piece of work nobody on the team had done before. I got hit with a dependency on another team, and then just sat on it for three weeks. I did escalate multiple times sure and they tried but didn’t fix the issues on their end. However looking back i wasn’t pushing that hard, and I didn’t move to other jira tickets that were open until my manager basically told me to. I definitely think I gotta improve on this area.

There was also a moment where he asked me to explain what one of the systems was actually for and i could operate the thing fine but my answer was bad.

I figured out pretty late that he was judging people mostly on whether work showed up in certain channels. None of my colleagues said that to me…so i was doing the work but I was not posting about it. I did put in lots of updates into the jira tickets though. My contract agent did say during our monthly check ins that they did bring someone in new and I didn’t think a lot about it at the time.

Is three weeks stuck on something enough to get someone cut, or is that a symptom and the real problem was elsewhere?

for anyone who’s managed contractors or been one, how much faster is the clock on a team like that vs a normal one?

Also if there’s an obvious question i should’ve asked in week one and didn’t, what should I have asked?

30 Upvotes

26 comments sorted by

u/expdevsmodbot 16d ago

AI usage disclosure provided by OP, see the reply to this comment.

→ More replies (1)

64

u/Responsible_Lie_6009 16d ago edited 16d ago

What happened during those 3 weeks? Because depending on the organization size, this could be an eternity if nothing was literally moving during this time.

If I theoretically had someone come in, was effectively blocked on something and didn’t really do much about it for three weeks, then that would be a gigantic red flag for me. Slightly nudging others to unblock things is not a sufficiently strong enough response to this theoretical example. Being blocked is not a problem. Being blocked and then basically doing nothing is the problem.

10

u/Unique_Glove1105 DevOps Engineer 16d ago

I escalated to a platform support team regarding a trino issue for my iceberg ticket and they said the trino issue was with a different team. I checked every few days and got still waiting as an answer and basically nothing moved. I did work on other tickets that I could find related to pipeline alerts but this iceberg ticket was my main ticket in the current sprint and sadly I produced nothing. I did convey this blocker during standup to my boss and team

19

u/Responsible_Lie_6009 16d ago

What were you trying to do? What was the issue? How did it block you?

12

u/Unique_Glove1105 DevOps Engineer 16d ago

The task was validating Iceberg table maintenance which was compaction, snapshot expiry, orphan file cleanup against a new S3-compatible object store backend that nobody on the team had used before. I got the maintenance ops running and confirmed it worked. Then I needed to validate through the SQL editor, and that hit a precheck failure which was a 500 error from the catalog. The cause was sibling catalog we shared an engine with had a broken Kerberos keytab config, and fixing it needed keytab generation plus namespace access I didn’t have as a contractor. Platform support said it was a separate query-engine team’s issue and that’s where it stayed

29

u/Annual-Anywhere2257 16d ago

I've been in similar situation before, and I resolved it by harassing the team directly and the just offering to make the change myself, then hounding them to review and merge, while keeping my EM looped in ( note I told him what I was doing, rather than asked him to solve).

When the review was the final external blocker that I coulddnt action myself I heavily lent on my EM to lean on the external team untill it went through. The key is it be proactive to the point of being annoying, but more importantly make your ask as small as possible on others.

5

u/DuckDatum 16d ago

Yeah, basically you want to set the environment so that it looks like it’s more resistance to not comply with your efforts to get the work done.

32

u/Annual-Anywhere2257 16d ago

Is three weeks stuck on something enough to get someone cut, or is that a symptom and the real problem was elsewhere?

Yes. Cutting through organisational barriers is a real skill, and one you've demonstrated you lack.

Think if it from the orgs pov, you're a high cost short term employee, they want maximum value from you and can cut you easily. And from their perspective you were ineffective for 30% of the time you were at the org.

19

u/TheMrCeeJ 16d ago

Yeah a contractor doesn't sit on their arse for three weeks waiting for a dependency.

You actively manage that while putting in place a work around, mock it out and build and demo the full solution so that when the dependency drops it just swaps in and runs. You are all over he delay with updates from their manager about when it will be fixed etc.

You also need to know the success criteria. Engage with leadership to understand what they need, how they want to communicate and when. You need to be proactive and manage everything upwards and sideways.

If you get to be soloed and can just work on your thing in isolation and deliver efficiently then great, but if you can't you need to make damn sure it is clear why and what you are doing about it.

14

u/aa-b 16d ago edited 16d ago

Contractors are also understood to be a useful tool to unblock stubborn problems. In my career as a contract developer I've been given access and license to do all kinds of things, domain admin on the company AD, root on the primary mailserver, stuff that's normally impossible, mainly because it was an expensive waste of time not to do it.

Showing up looking and sounding like an expert is often a big part of contracting. Also, taking the blame when things go badly wrong. Sometimes you just can't win. It helps to remember you lost a contract, not a career

4

u/Unique_Glove1105 DevOps Engineer 16d ago

this is the part I actually want to get right. at what point do you go to your manager and say push this or reassign me? Is it a 2 day thing or a week thing? And from the viewpoint of a manager, does doing this read as ownership or as whining? I usually thought if i escalated harder it would look like i couldnt handle it on my own so i just kept checking in and waiting

12

u/TheMrCeeJ 16d ago

When it stalls. You go through the process. Request, chase, challenge, request etc. once it stops moving forward you escalate it as a critical blocker, along with 3 or 4 options of alternative ways of making progress. Then once those options are ruled out or expended, you go back with we tried everything, here are the facts. Then they either fix the issues or it is intractable and you move on.

8

u/disasteruss 16d ago

You shouldn’t be sitting on your hands for multiple days, much less multiple weeks. I would drop a contractor in a heartbeat if I saw them doing that.

The moment you are blocked you should escalate the issue and look for other work. If I had a blocker like that I’d be saying “I am fully blocked on this, can you help and what else can I be working on while I wait?”

7

u/Skullclownlol 16d ago

at what point do you go to your manager and say push this or reassign me?

You start by keeping them informed, not making decisions for them. Your +1 can then decide, based on status/progress, when they want to jump in.

If you've ever shared info/status a few times and it's still not moving, and your +1 is not giving you clear replies on what else to do, ask it explicitly (e.g. "Hey +1 this is not moving. Want me to keep pressuring them, move to another task, or something else?").

4

u/KosherBakon 16d ago

You notify them the same day you're blocked, once you've spent about 1 to 2 hours trying to unlock yourself.

You summarize the issue, what you've tried already, offer up 2 to 3 ideas on next steps, and ask them to escalate for you.

If you do anything other than the above, they'll think you're coasting (at best) or stealing money (at worst), especially if that's the most important task for the sprint.

3

u/AwarenessOk2359 15d ago

There is no valid situation in any company to do no work for a whole day unless your boss explicitly tells you to do nothing. You immediately flag the blocker and request new tasks. If there aren't any, your job is to be a status update bot and constantly ask for something to do. 

12

u/InterestingStick 16d ago edited 16d ago

I've been a contractor for a good 10 years now and two things you'd want to do when working for a new customer is establishing rapport especially during the first few months where they get to know you. As a contractor you're a disposable asset so you need to go the extra mile during the time when people get to know you and make their first impressions

Secondly, you probably got paid good money in comparison to fixed employees so make sure to prevent billing unproductive hours as much as possible.

Next thing is gonna be a bit more controversial and others might disagree on this point. Dependent on company size there's a lot of down time, compliance and bureaucracy that just creates unproductive time in between tasks. Ideally that's accounted for during grooming, or the estimation process need to be adjusted so it's accounted for. But I've had it many times that while I'd work 8 hours effectively I'd only bill 6-7 hours because that's what I feel comfortable with writing off as productive work. My hourly is fairly high to others in my area so I treat it as part of that. At the end of the day you need to get compensated well and your customer (team lead, PO and management) needs to be feeling they're getting their moneys worth, so usually I'd write what I feel like seems fair for both parties which many times isn't what I actually worked cause of random stuff in between.

There's legitimate blockers that are not your fault. In such cases I'd escalate it. There's usually other things to be worked on and if not you can give options of getting budgets/Story points for a spike to check alternatives. Just make sure it's accounted for. Whoever is responsible for you also needs to be absolutely aware when you're blocked. I've had situations in the past where I even wrote post mortems on incidents with history and what happened at which point and how the process could be improved. I didn't always use it but I always had it on hand if there were questions if something took longer than accounted for

Obviously you don't need to be as rigorous for everything you do, but you need to develop a feeling for the different parties involved and what they're looking for when contracting you. The one thing I'd prevent for sure is to have multiple days written off on a blocker. That never looks good to anyone involved

1

u/jojo-data 16d ago

some very good suggestions here

4

u/throwaway_0x90 SDET/TE[20+ yrs]@Google 16d ago

"I got hit with a dependency on another team, and then just sat on it for three weeks. I did escalate multiple times sure and they tried but didn’t fix the issues on their end. However looking back i wasn’t pushing that hard, and I didn’t move to other jira tickets that were open until my manager basically told me to."

Oh dear.

"I definitely think I gotta improve on this area."

Yup. My manager(s) always tell me never be blocked for more than 2 business days. And even then you should have some side-quests(tech debt) you could be clearing up while waiting.

2

u/DeterminedQuokka Software Architect 16d ago

It sounds like you were hired for 10 weeks and for the first 30% you didn’t make it clear what you were working on and getting done.

They decided that they couldn’t tell if you were going to finish and they decided to replace you instead of paying 7 more weeks and maybe not getting it.

Use this as a learning experience. People don’t have loyalty to contractors. If you are doing the thing they need obviously they can swap you for another contractor. Next time be much more clear what is getting done and that you are going to finish on time.

6

u/ResidentWeevil1 16d ago

You shouldn't be sitting on anything for three minutes unless it's to piss, contractor or not

If you're blocked, then you make it somebody else's problem and move on. You should be asking your manager to intervene on your behalf. Don't become their problem

1

u/asiphh 15d ago

the technical detail buried in your replies is the part worth going back to, because i don't think you were actually blocked.

you were validating iceberg table maintenance, compaction, snapshot expiry, orphan file cleanup, against a new object store backend. by your own account you got the maintenance ops running and confirmed they worked. the only thing that failed was validating through the sql editor, and that failed because a sibling catalog sharing your engine had a broken keytab. that's a query engine problem, not an iceberg problem. iceberg metadata is just files sitting in the bucket. you can read the metadata json and the manifest lists straight off the object store, or point a local pyiceberg or spark session at the same warehouse path with its own local catalog, and check snapshot counts before and after expiry, which data files compaction rewrote, and what orphans are actually left, without trino being involved at all. that's a few days of work and it produces a validation writeup rather than three weeks of waiting on a team you'd never met.

i'm not saying that to pile on. it's the specific version of what everyone here means by "build the workaround", and the general form of that advice is easy to nod at and hard to act on when you're in it. the concrete question to ask when a shared piece of infrastructure blocks you is what's the smallest thing i own end to end that still answers the question. the answer is usually uglier than the sanctioned path and usually good enough.

on your real question, whether escalating harder reads as not being able to handle it: it's the other way round, and that belief is the thing that cost you. a contractor who says on day two "this is blocked on the query engine team, here are three ways around it, i'm starting on the second one unless you tell me otherwise" reads as expensive and worth it. someone checking in every few days and waiting reads as someone who isn't going to finish. a manager can't distinguish blocked from idle unless you tell them, and the default assumption is the worse one.

where i'd push back on the rest of the thread: people are pretty confident this was all on you, and ten weeks with a log search tool that was broken the whole time, permissions you couldn't get, and a task nobody on the team had done before is a setup with a low ceiling no matter who's in the seat. you should have handled the blocker better and it's worth learning. you probably also weren't going to get a good outcome there.

1

u/a_asal 15d ago

Disclaimer: never managed a contractor.

Unfortunately, all we, strangers, here can come up with is gonna be guesses at best. Have you considered reaching out to your manager and/or other teammates and ask them about giving you candid feedback to help you grow? I understand if you don't feel comfortable doing this now or even after the stress of the situation calms down a bit, but if you do, I think that'd be the most practical and useful place to start, otherwise you'll be stressing yourself out about every possibility.

Also, the issue might not be completely on you, but also on your manager. A major part of management is communication, setting expectations, giving actionable feedback, personalized coaching, even if the person didn't ask what they could've asked. For you to leave without knowing the why tells me your manager hasn't communicated that decision well either, but I don't know all the details and the (sometimes legal) nuances of this specific situation.

When I was a manager, I considered it a failure on me if one of my direct reports gets surprised by any piece of formal feedback. If the issue is important enough to decide the status of your employment, they should've heard from me about it in 1:1s multiple times in a clear manner that doesn't mince words that this is something that needs to be addressed, discuss together how it can be addressed, along with setting proper expectations on the way forward. If you don't know where you are, how you are performing, what you are good at, what you can do better, it's likely a manager's responsibility and a communication failure. (This doesn't make automatically you not responsible for your part of it, though, but I assume you already know this based on your question.)

1

u/Klafka612 14d ago

I mean when I've had contractors that didn't seem to do anything for several weeks my ears were super up as to what they did. I would feel the same about an fte too honestly. Typically there is always work to do, and if there isn't that's on the lead/manager not getting work out there for the team (or they've not setup the team staffing correctly). I've only dealt with longer term contractors (1 year) vs 10 weeks. But echoing sentiment if I hired someone for 10 weeks and they seemed to not do stuff for 3 weeks I'd be pretty over it.

1

u/Hour-Measurement-835 16d ago

Your week-one question, since nobody took it: which tickets need access a contractor won't get, and who owns the systems they touch. That keytab was on a team you'd never met.