Having been through a situation where I felt thoroughly out of my depth at work, when I saw this question on Quora, I just had to answer. I’ve put a version of it here, for people that are wondering about a way out of this horrible feeling.

Swallow your pride

First I’d say don’t be ashamed. There’s a lot to be said for recognising there might be a problem. Second, are you getting any feedback on why there is problem with your performance? Maybe there’s a co-worker you trust to give you honest feedback in confidence.

Wrt your manager I’d be ensuring they’re actually a competent judge. I had a boss who was supposed to be a tech lead but was clueless. I’d had some backstabbing co-workers complain and he just made assumptions. Fortunately there was another manager there who was receptive and I approached him instead.

Try and identify the problem yourself

It’s important to know what the problem is before you speak to your boss so you can at least go with proposed solutions. That would go a long way to showing willing and if they’re not going to meet you halfway, do you really want to hang around?

Some concrete strategies once you’ve identified a problem:

Delivering too slowly?

Are you delivering too slowly or just under-estimating? Perhaps you need to do more diligence in your estimates to understand what’s involved and speak out.

If your co-workers try and pressure you, it’s ok to stand your ground and admit something takes you longer to learn. Remember that story point estimates should be estimated on the basis that (within reason) any team member can pick them up, not a specific one.

I’ve written points about how we learn as to why something take us longer than others. (See Increasing overall learning speed with Chunking — tips for developers)

Things being re-worked a lot?

Are you finding your stuff being reworked a lot? Perhaps you’re not necessarily asking the right questions in advance, or maybe you’re just thinking about doing ‘your little bit’ when doing development?

In those instances, try and understand more about the business processes that create the input to your task, and how they outputs you created are used. If you try and understand the end to end process, the ‘edge cases’ the tester comes back at you with (or worse still production incidents) might be drastically reduced.

Struggling for clarity?

It’s hard sometimes to feel like you can ask. I find this happens to be even now, and the ‘second brain’ approach works every time. What I mean by this is offloading everything into a mind-map and try to make sense of what is is you have to do. You might find this article helpful in that sense.

Struggling to prioritise

Another example of where the ‘second brain’ comes into its own. If you can break down your work a bit better, you will find a natural order presents itself.

If you have the natural order of the tasks, you can start seeing the ‘cut-off’ for what might be the Minimum Viable Product (MVP). If you can’t prioritise, then that;s a good point for further discussion with your peers/tech lead.

Methodologies like GTD can be used to sort your work, but a list is sufficient to at least trace your steps “a to b to c” through a solution. That’s often enough to get you thinking about what’s really important.

It’s best improvement starts with you

These are just a couple of things that spring to mind, as I don’t know your exact situation. My point is that if you can pinpoint what the ‘complaint’ (I hate to use that term but it probably conveys my meaning for now) you can hopefully say to someone, ‘Hey I’ve noticed X, maybe I can do Y to improve it. What do you think?’. Hopefully then with showing willing you’re in a position to get people to meet you halfway.

It might not be you

Lastly, some co-workers are just unpleasant, and you may not be as bad as you think (Imposter Syndrome is a very real thing in our industry).

But I think it’s always better to assume you can learn something from the situation with an open mind. Hope that helps.

By James