If you’re here because you read my provocative title and thought to yourself, “Well, that’s just objectively false, I know lots of people who don’t know what they’re doing, and they’re wrong all the time … often confidently so” — haha, you’ve activated my trap card.
I don’t, in fact, mean that the act of being wrong is harder to achieve when you don’t know what you’re doing. What I instead mean is that it’s more emotionally difficult. Get polysemy-ed, punk.
You’re here now, though, so you might as well keep reading.
There are no stupid questions
One of PortSwigger’s mantras is ‘there are no stupid questions’. It’s always been a bit of a no-brainer to me, to the point where, if someone starts a conversation with “Can I ask a stupid question?”, I’ll quickly cut them off with “There’s no such thing!”. I’m that guy.
The thing is, as much as it’s something I preach, it’s not something I’ve really had to practice. Not properly, anyway. Oh, I ask stupid questions all the time, but until recently, I’ve never had to go outside of my comfort zone to do it.
I’ve been a software engineer for ten years now. Just about long enough to get away with phrases like “I remember when …”, but not quite long enough for “Back in my day” … yet. As a result, not to tug my own trumpet or anything, I think I’m pretty good at what I do. This means that, when I ask a stupid question, I’m not worried about how I’ll be perceived if I make an incorrect assumption, or more generally, if I get something wrong. I’m confident enough in my own ability on the whole to shrug off mistakes without spiralling.
It’s easy to be wrong when I have confidence in myself that, on the whole, I know what I’m doing.
I don’t know what I’m doing
I’ve been a product ___ for ten months now. Just about brief enough to still get away with phrases like “Ahhhhhhh oh god what’s happening, I don’t know what I’m doing”.
By ‘product ___’, I mean some sort of role where I’m embracing a proper product mindset, and taking on a lot more product-y tasks: discovery, research, opportunity space mapping, etc. Not a product manager, though. The benefit of being friends with an actual product manager is that I can listen to the insane amount they do and take solace in the fact that I’m currently only ankle-deep.
In recent weeks, however, I’ve been putting a lot more deliberate effort into wading out further into the ‘product pool’. My professional development goal is to be more proactive instead of reactive — seeking out the product work that needs to be done, rather than just taking on what comes my way. This means seeking out the product people who know what needs to be done, rather than just taking the advice that accompanies what comes my way.
I have to ask the stupid questions; I have to risk being wrong … and it’s really hard.
We have plenty of product people at PortSwigger (try saying that ten times quickly), and all of them are perfectly pleasant and perpetually patient when pondering pertinent probes (right, I’ll stop). That is to say, I’ve been reassured by them several times that I should just come and talk to them, come and ask them questions, come and learn from them. Without that safety net of experience, though, the trips and falls hit a lot harder.
Why do we fall?
So how do things get better?
Well, they already have to some degree. Earlier on in this journey, I noticed a behaviour in myself that was even worse than not asking for help: actively rejecting the help I was offered. I was so desperate to prove I was capable that I got defensive when someone tried to give me a steer. A concrete example of this is when I was asked whether we wanted to benefit from the design partner initiative PortSwigger was undertaking, and I said no because that’s not exactly what Inspired said to do at that moment in our project’s lifecycle. That was daft. Don’t turn your nose up at the hand that feeds you design partners … or something.
To go the rest of the way will just take emotional intelligence (bah, my nemesis). I need to remember that the people telling me that there are no stupid questions do so with the same mindset I have when I say it to less experienced developers. They’re not trying to trip me up. There doesn’t need to be a safety net, because the fall isn’t that far and the landing isn’t that hard. You just get right back up and continue, having learned something.
It sounds so easy when mangled into a metaphor like that, and perhaps it will be. The purpose of this blog post has been as much about writing my own thought process down so that I have to come to terms with it as it is about sharing the experience.
Fingers crossed.