I'll let you into a secret: a lot of us are out of our depth at least some of the time. In many cases, that's how we learn and grow our skills. In other cases,

I'll let you into a secret: a lot of us are out of our depth at least some of the time. In many cases, that's how we learn and grow our skills. In other cases, that's how we get burnt out and/or really mess up by pretending we know what we're doing until we fail anyway. Do you really want to provide the best service you can provide? Then stick around, admit your limitations, tell the team you're struggling but ask them what you can do to help the team get closer to its goal. Maybe there's some small part of the technical challenge that you can get your head around in isolation and still make a contribution. Maybe you need to be the guy who helps out with QA, keeps the bug tracker in a prioritized order, sorts out deployment issues, reformats the documents for the higher-ups, or just brings pizza and caffeine to the others at appropriate moments. But if "losing a team member will result in a bit of chaos" then walking out on them isn't going to be providing the best service you can provide. I've managed teams where someone is in a similar situation, and they can react one of three ways: 1. Pretend everything's okay, and churn out shitty code that just about hangs together but causes serious problems now or later; 2. Throw in the towel and leave the team; 3. Be honest about where they are struggling, ask for help getting up to speed and/or ask where they can be of most help with the skills they do have. I would prefer the third option a thousand times over the other two. Assuming your resume is honest about your skills and experience, only the first option would have you marked down for "subpar performance". No good manager would expect everyone to be a rockstar ninja know-all genius at all times. If they do, then yeah, that would be the time to give the appropriate notice period and still do your honest best while you're waiting to leave.