What's considered good support when you're assigned to work on a new domain
Posted by Alarmed-Hair3777@reddit | ExperiencedDevs | View on Reddit | 25 comments
I've tried to condense this the most I could, but it's still fairly lengthy. tl;dr at the bottom.
I work for a fairly large tech company and I've been here ~4 years now. My roles always revolved around frontend or JS/Node, even before working here. A few months ago I was unwillingly moved to a different 'squad', despite my objections.
This meant that my role changed from being JS-focused to, among other things, Jenkins, release automation, Android containers (java/kotlin) and an emphasis on error reporting and KPI monitoring (Conviva/New Relic). This is very different from anything I've ever worked with on my career.
I tried to come to terms with it and frame it as a chance to expand my skill set. But after a few months, there's a clear lack of support to ramp-up.
I've raised it to my line manager, twice now, explaining that this is all completely new to me, and there is absolutely no documentation on any process or workflow. His reply is invariably along the lines of "We're a nice and friendly team and you can, and should, just ask anyone for help!".
Is that really sufficient? I'm able to work on tickets, and work things out when I need to, but that takes time, obviously. Even when I ask anyone for help, first I need to figure out what exactly I need to ask help with, rather than a generic "Hey I have no idea what any of this means". More than a few times now, I only learned about some tool of process that I should've used after working on a ticket that required it. Generally, knowledge is assumed.
I should be ( and tried ) aiming for a senior title on this company, but on this team I feel like a junior dev new hire and I'm still learning the ropes - And that feels borderline humiliating, if I'm being honest.
So my question here is:
Is it reasonable for a developer to work on a whole new domain of knowledge and expected to ramp-up simply by asking his team for help? Or if I am being overly dramatic about this whole situation?
I can't shake the thought that if I was applying for jobs right now and saw this job description, I would absolutely not apply.
An easy suggestion would be to start looking at other jobs, but I also just moved into my newly bought flat and appreciate having some job security.
This is all in England, if that matters.
tl;dr: Worked for the same company for 4 years, recently moved onto a new team with a new domain knowledge, against my will. I'm expected to ramp-up by asking others for help, with no supporting documentation or training.
titpetric@reddit
Ask if they have onboarding docs, may be just a lapse due to the internal transfer. Responsibilities and process shouldn't take that long to derive from observation, as far as a skill gap is concerned, it's encouraged to have trainings if needed. In my circles 2-5K budgets are given yearly for education (courses, cloud resources) or health/lifestyle (office, home gym, coworking office cost, internet cost...). The vast majority of companies out there, to my experince, have chosen very individual approaches, some good, some bad, with the general expectation that you get experience through your work. Read a lot of docs and catch up is probablly on the 80% side of Paretto.
Alarmed-Hair3777@reddit (OP)
I did and there aren't. As for training budget, we have access to an internal e-learning platform ( in collaboration with someone else, can't recall cause they're always changing ). The first problem there is that there really isn't that much free time to be able to participate in those. There's always something to do, and that something will take precedence over 'online courses'. But more than that, my knowledge gaps on this team are not solvable through online courses - It's a lot of internal processes and tooling, workflows, etc. Not so much "how to configure Jenkins" but more "How to trigger a manual build for the container xyz which needs a certain configuration and certificates, which in turn live on two different internal portals and no documentation points to them".
chikamakaleyley@reddit
Generally speaking, there's nothing unreasonable about this and in fact. I've been the same as you before, and when I think about that version of me now, IMO it comes off as "did you even look read this/that?"
from the POV of someone who is now asked for help, i'm trying to gauge where the disconnect is. The generic "hey i have no idea what this means" is still vague even if were sitting next to each other looking at a block of code.
For me, it helps if you can sorta give the context of how you got there. I don't actually assume or expect you to have the knowledge, because you came to me for help, but painting the picture of how YOU understand something helps me pinpoint where the problem might actually be.
Yes, if you want to work towards a Sr role
Alarmed-Hair3777@reddit (OP)
I'm happy to give that context, but there's also a disconnect from the manager's side, in the sense that he tells me to ask for help with things, while raising concerns about how long some tickets take. For me, they take longer because there's a lot of context investigation, but that doesn't seem to register.
chikamakaleyley@reddit
yeah i mean... i understand that thought process but in a generally speaking - this is the manager saying to you, without actually saying to you, that they need the devs to be able to manage/unblock themselves - from personal experience this is kinda the ideal situation because you want your manager to handle 'managing the team/devs'.
Ultimately, i wouldn't expect it to register because the manager's concern isn't the implementation details. It's only of concern to them if there's technical, like something about the architecture, that blocks the project.
I've been in your shoes before, and its overwhelming at first, but that expectation fr your manager is likely the same they would expect of any of their devs. It's the norm
In my experience my 'buddy' period was no more than one official 30 min walk thru and then ad hoc 'i need your help with this' until i felt up to speed. This is in a big tech, fast pace situation, all high skilled devs, all empowered to manage ourselves
chikamakaleyley@reddit
basically you have to make the decision now to change how you work and it has to be a lot more proactive and it prob requires a bit more effort til you start feeling like you've caught up. It's just the way the team operates and this 'mode' is prob what makes the team function, makes them successful. I'd be inclined to match that
NUTTA_BUSTAH@reddit
Reasonable? IDK. Quite par for the case? Absolutely. "DevOps" roles can be very sink or swim. It is difficult and you gotta know what you don't know and be honest about it (to yourself too). Just being honest "IDK anything about nginx or proxies but I'll look into it and get back to you with my findings by EOD, let's figure out next steps from there".
It can easily take an intense year to get comfortable. Even two, depending on the company/role. All while you don't tend to have unit or integration tests to turn into but the business is actively bleeding $$$, do you pull the magic switch to save it or cause even more, potentially extremely expensive harm, whether in infra or integration costs or simply lost person-hours of your colleagues?
Now is a good time to start documenting all the processes. And keep very meticulous notes. Or swap jobs if it's not for you. The pay has definitely gone down from the boom, but likely hold better pay than developer roles that are more targeted by AI. These are also extremely useful skills. Making the app is just half of the work. Deploying it, securing it, fixing it or any issues the world throws at you and keeping it like that for years to come is the other half and in some nightmarish environments, it's the 95%.
Why were you switched?
Alarmed-Hair3777@reddit (OP)
Team reshuffle. tl;dr is that we ( as a department ) absorbed another department, and some people had to be moved around for whatever reason. I honestly never knew, since it wasn't even discussed with me beforehand and I learned about it on a general department email listing all people being moved. I've gotta say that felt like shit.
Regarding this team, it's not quite dev-ops, but it's adjacent. I'm not really touching infra, but work closely with setting up Jenkins ( for internal use, manual builds, etc ), and android container code. We sit somewhere between the client app and the pure devops teams.
NUTTA_BUSTAH@reddit
"DevOps" has become an extremely broad term, I'd still consider classifying yourself as that, it might help reframe your problem solving patterns too. But I get what you mean.
Your situation sounds like very clueless and borderline destructive management to be frank. Good luck!
Alarmed-Hair3777@reddit (OP)
Thanks, I'll need it
LovelyEntrep@reddit
Figuring out with limited resources is the main differentiator between senior versus junior. Who you want to be?
Alarmed-Hair3777@reddit (OP)
I understand that. And even if I am aiming for a senior title, I don't hold it yet. The question here is how much support is actually adequate, considering I'm also being evaluated directly against my other team mates ( and the company has just switched to a stack-ranking performance evaluating model ).
My question stands: Is "ask for help" a sufficient ramp-up support model, even if we're talking about senior devs?
thehuffomatic@reddit
I get your frustration. A senior developer will ask for help to know where to look for documentation, if any, and actually read it. Then if it is lacking, then start documenting a guide for the next developer added to the team. If you have your own quick start guide, then it shows management you took an ambiguous task and created tangible artifacts out of it. You created a direction when there wasn’t any.
Now this is where it gets tricky. You have to ramp up and depending on how much it’ll take in time, you might have to do it outside of working hours. This is where good management will tell you it’s not required. I personally do not take on new roles with unknown tech stacks as I burnt myself out trying to do everything. 60 hour weeks with a long commute each way wrecked me. If your stack ranking system is new, then it tells me your company put you in a very tough situation as a mid-level developer. I cannot answer whether or not this is something they will look past during review season.
Alarmed-Hair3777@reddit (OP)
Working overtime is a line I'm not willing to cross. I highly value my personal time and to me, there's nothing that justifies taking away from it to give it for free to a company. I do plan to start writing some quick-start guides or lay out a documentation base, but it's an ongoing process.
thehuffomatic@reddit
I’m glad you know your boundaries. It took me several years to learn not to give the company more than 40 hours each week. It’s them giving out more work than one person can reasonably handle, not me underperforming.
juusorneim@reddit
LovelyEntrep has the right idea, but focusing on "junior" and "senior" and making this situation a question of titles or character is not helpful.
No matter the title, environment contributes to success or failure.
Is "ask for help" a good model? It depends on you and the environment, but in general, no.
You asked for help from your manager, and they vaguely redirected you elsewhere. Also, stack ranking is stressful and unproductive, and your manager appears to be ignorant of the effects of stack ranking. The environment doesn't appear to be productively welcoming right now, but maybe it can be.
A good model consists of introductions (onboarding, sharing context, showing you ways of working, documentation, revealing unknowns to you), ongoing knowledge sharing (members actively sharing their findings, regular training sessions, demos), and a collaborative environment overall (no siloing, free to ask questions in chat groups or calls, noticing when someone needs help).
If you are motivated and able to, I suggest you start setting these things up. Try to explictly say what you need from others.
For example, you could ask one of your team members to casually explain to you how they're doing, what they know, how they work, etc. You'll get to know them and their work better. Another example, if you're beginning work on a new task, you could ask one of your team members to take 5 minutes to explain how they would approach it.
Of course, you will need to do some learning and digging on your own as well. Go through any existing docs, codebases, tools and try to build a mental map of everything, taking notes and coming up with additional questions as you go.
Your work is to build relationships, learn and understand, come up with questions, and take notes that you can later turn into documentation. You'll be the one to help yourself and set up the additional resources that you and the team might need.
Alarmed-Hair3777@reddit (OP)
That's an insightful reply, thank you. I do feel that "ask for help" in generally insuficient, but I haven't been able to put into words what I actually need to support me, given the context and available resources.
You laid things out a bit more clearly for me, which is helpful. I'll try to start setting those things up, a bit at a time. It'll still require a lot of "asking around" and being social in some way, which admittedly doesn't come easy to me. One factor that is holding me back, imo, is that I am working fully remotely ( medical reasons ) while the company mandates a 2 office days/week. But even if I went there, this team is 90% from another country. They share the knowledge in-person and it gets silo'ed between them, while I'm more positioned as an outsider.
Et_Sky@reddit
Really? "main differentiator"? Oh man..
OP, ask about the expectations. I assume that if the manager is sane, there will be a decent period to ramp up. Offer to start documenting things. Don't overdo it with "just ask questions whenever you have one" - people will get annoyed; instead, book a few KT sessions with teammates and bring a bunch of questions to ask at the session. Try to ask more fundamental questions - i.e., why things were built this way; I assume you can figure out the 'how'.
Alarmed-Hair3777@reddit (OP)
I'm starting to question that assumption. Without going extensively into it, we need to do something close to "active monitoring" of dashboards and KPIs, on a rotation. When it was my turn ( for the first time ), I was given a handover and quick overview of tasks by whoever was finishing their rotation then. Then, during my rotation, I get a message from the manager saying that I'm missing a few things or not completing tasks correctly/on time - which is information I didn't even have. As I mentioned on the post, it largely feels that "knowledge is assumed".
I have offered to start documenting things, but it's quite the task and so far it's mostly loose notes that don't have much structure.. but it's a start.
LineageBJJ_Athlete@reddit
You win the day with this comment. Well said.
Et_Sky@reddit
Really? "main differentiator"? Oh man..
OP, ask about the expectations. I assume that if the manager is sane, there will be a decent period to ramp up. Offer to start documenting things. Don't overdo it with "just ask questions whenever you have one" - people will get annoyed; instead, book a few KT sessions with teammates and bring a bunch of questions to ask at the session. Try to ask more fundamental questions - i.e., why things were built this way; I assume you can figure out the 'how'.
tinycockatoo@reddit
From someone who was always complimented for "ramping up fast", "hitting the ground running" and "being proactive": people are just lazy. They don't want to take their time to make an onboarding document for new team members because it's a boring task that usually isn't recognized by anyone except for the new team member.
A great manager should be able to put someone aside and assign them to be your onboarding buddy, and this person would be responsible for showing you the ropes. How many times people flounder in a task due to lack of domain knowledge that would literally take thirty minutes for someone else to teach them? And then people will preach "autonomy" lol. People should receive enough info to start their tasks, not having to wander in the wilderness to prove their capacity to obtain information. It's a job, not a great adventure to get the rings of power.
Sorry, I get a little mad about this
Alarmed-Hair3777@reddit (OP)
I fully understand and I'm on the same boat. I've been criticised by this new manager for 'lack of proactivity', but it's difficult to be proactive when you don't even know where or how to be 'active'.
I haven't had a buddy or anything like that assigned to me. It's always "Just ask the team" or at the most "Guy A has good knowledge on this topic". But then I just feel that my work consists of going around asking people "wth is this about" and basically looking massively inexperienced in the process. Good old impostor syndrome.
BrownBearPDX@reddit
Would the intense video based training at one of the training sites for the main tools that you use help? Spending an hour or two extra every day after work just to get super familiar with the basics of each tool might be very helpful. Asking an LLM at the beginning of each ticket might also help.
As to your main question, I think it’s bonkers that they did that to you. I mean, if they were gonna hire somebody, they wouldn’t hire you just as you said you wouldn’t apply for the job. It is a big company and I guess they do stupid shit like that and it is good that you have a job in this market, but still it’s really weird. I’ve always worked for medium and small companies and formal training is always on tap if there’s a big product or tool or anything that we needed to use and we didn’t know. I guess that kind of support is out of the question for a big company where they don’t give a damn about you and it’s sink or swim.
Well, if you do make it through a year, I bet you you’ll be a lot more confident and competent and you’ll have gone through that really weird stressful high growth period. That’s always crappy to go through, but you always look back and go wow I really made it through that and now I know my shit. But it’s no fun when you’re in the middle of it.
Good luck.
Alarmed-Hair3777@reddit (OP)
That's a positive way to look at things, and thanks, I think I need a bit of that right now.
As for the video training, I don't think that even exists. The things I don't know about are very "internal workflow" related. Things like how to locally launch a certain internally developed app/container, what's the workflow and tools required for tasks x y z, what needs to happen on a release cut or when another internal team updates one of our dependencies. None of these are things I can just search online or find a video course to.
And yes, it's absolutely bonkers. As I've mentioned on another comment, I wasn't even informed of this move beforehand and learned about it on a general department email listing all people being moved. Or rather, a teammate suddenly asking me via chat "Hey, are you moving to team X?!? When did this happen?" and me having no clue what he was on about. I could put on a bit of a tinfoil hat about why it was handled this way, but that's a big rabbit hole and not for now :)