I recently returned to work after taking three months off to welcome a baby boy into my family. During that time, I tried to disconnect from work as much as possible and focus solely on my wife and two (then three!) children. I didn't find that difficult, and so as I returned to work - having thought about software only fleetingly for three months - let's just say I felt a little rusty. And since I've only been developing software professionally for two years, I wasn't terribly practiced to begin with.
If it had been up to me, I probably would have started my new assignment with someone who had far more experience, so I could let them take the reins while I got up to speed. However, my assignment was to be the sole Red Squirrel engineer on a small team at a very large and fast-growing company. The stakes were high. My team was responsible for a critical component of the product, and we had a tight and absolute deadline to complete our work. Failure to roll out the changes we needed to make would be a major setback to the client's ability to serve their users, which simply was not an option.
What that meant for me was that I needed to get up to speed very quickly. Since I was the sole representative of my company on a small team, it was also top priority for me to provide a high level of service to the client, which meant I could not remain a muted face in Zoom meetings. In the past, because of my level of seniority, I would typically be paired with a more senior engineer who I could defer to if I made a mistake or said something stupid. If I wasn't sure about something, I could remain quiet and ask them about it later, and no one had to know.
But with my most recent assignment, that would not be an option. It was just me. My knowledge, experience, and skills were about to be exposed for what they were, and all I could do was prepare as best I could, and hope it would be enough to deliver great results for the client. And because first impressions count, it needed to start on day one (earlier if possible).
Where did I start? Well, if there's one thing I've noticed about software engineers, it's that the best ones are always asking questions. Well before my start date, I asked for information on specific technologies the team would be using, so I could get somewhat of a head start on ramping up.
While I on-boarded, I made a conscious effort to ask as many questions as I could as early as possible. If I needed access to something, I asked for it right away. If something was unclear, I asked for clarification. I asked about expectations (do they see my role as staff augmentation, or are they looking for feedback on technology and process?). Once the engagement was underway, I frequently asked for feedback on my work.
The scary moments came in sprint planning meetings and pairing sessions with other engineers. That's when a question would surface in my mind, and I would hear that familiar inner voice say "Don't ask that. That's a dumb question. You'll look ridiculous." But those sprint planning meetings and pairing sessions are at the heart of the Agile process. Those meetings are where everyone's voice really needs to be heard. Those meetings offer me my best chances at gaining clarity and understanding on requirements. And those were the moments I knew I needed to un-mute my microphone.
So I did.
Here are two things I learned from navigating that experience:
Most likely, the only person who thinks your question is stupid is you
I want to make it clear that I'm not basing that assertion on my experience with just one team. Having worked on quite a few (wildly) different teams over the past two years, what I have come to find is that much of the time, the questions we're afraid to ask are the ones that need to be asked the most. If something doesn't make sense to you, it could be because you don't understand it, in which case finding the strength to expose your ignorance and ask the question can only benefit you and the team as a whole. But it could also be that there is an aspect of the problem that the team hasn't thought out yet, and the reason why you feel like you don't get it isn't because your question is stupid, but because the problem needs more discussion.
Just one example that comes to mind: on my most recent project, I was tasked with writing some raw SQL queries for a database backfill process we were implementing. What I didn't know was where I was supposed to write them. Did a file exist already? Was I supposed to create one? Should the queries go in the code base at all, or are they meant to be run by someone locally at some point in the process? I searched documentation and couldn't find an answer, so I asked. It turned out that no one had thought of that up to that point, and those questions prompted an exchange of knowledge across teams, and resulted in our team having more clarity on the database backfill process we were working on.
You never know unless you ask.
You really do know more than you think you do
What surprised me more than the fact that no one laughed me out of the Zoom when I asked questions was how much I could actually do. It turns out, there is magic in being courageously vulnerable. When you find the strength to put yourself out there, it opens the way for you to showcase your knowledge and skills, and you just might even surprise yourself with how good you really are.
What I found was that when I started talking in my meetings, concepts and ideas would come to my mind that wouldn't have if I had sat silently. (By the way, if you have something to say, but you feel afraid that it might be wrong, I find it helpful to lead with, "I'm just thinking out loud here, but …"). You keep the knowledge that you use most often, and when it comes out of your brain, through your mouth, and out into the world, you almost invariably gain new and greater knowledge, especially in a collaborative environment like an engineering team.
There are, of course, exceptions. Some teams are not healthy or particularly collaborative. Some people will go out of their way to make you feel stupid. Sometimes people feel genuinely unsafe with speaking up and making themselves vulnerable in the environment they work in. If that sounds like the team you work on, may I suggest considering making a change, if only for your own health and well-being. If that sounds like the team you lead, consider getting in touch with us.
I am for sure not advocating talking just for the sake of talking. What I am advocating for is you. On a team, your voice should matter. So don't be afraid to speak up and ask stupid questions. You might regret it sometimes, but what feels worse than feeling dumb, is having a question and staying quiet, only for someone else to ask the very question you had and watching it bring about great discussion or results in a meeting.
Give it a try. I bet you'll be surprised.
Top comments (6)
Regardless of the task at hand, the more confident you are, the better the outcome. Confidence is a side effect of being comfortable with what needs to be done, and knowing as much as you can about the task. Asking questions and getting appropriate answers will build confidence. Our well-being and the quality of our work is tied to our level of comfort and happiness. Being hard on ourselves and having negative emotional feelings is detrimental to happiness, comfort, and confidence.
Love this! Absolutely
Bravo Jeremy, nailed it
Thank you!
Amen! I think asking questions and asking for help is a skill that is really worth working on.
Agreed!