When I first started tech leading, kicking off a project felt intimidating, especially if the requirements were vague, not well-defined, or even non-existent - which is more typical than you may think. Turning something so abstract into a distinct set of tasks didn't feel possible. I didn't know where to start. There was a lot more that I didn't know, compared to what I did know.

After some thumb-twiddling and minor anxiety (✨this is fine✨), I asked for some advice from a peer on my team who was experienced in tech leading. She suggested that if it's not clear where to start, start asking questions until it starts making sense. I couldn't believe it could be that simple - I was a little skeptical. Despite my hesitance, I decided to give it a try. The results were surprising.

As a new tech lead, you may wonder to yourself how you might know what exactly the “right” questions are. It turns out that there isn’t a secret formula or a prescribed set of questions that fit every scenario. We should begin by asking simple questions that unravel assumptions about how we think things may work. The old adage is true - "there are no stupid questions".

Identifying familiar scenarios

We can begin by trying to pinpoint various scenarios. Let's say we are adding a new feature to a familiar platform. That familiarity can guide us by framing the constraints we need to work within or the implementation details required to integrate successfully with the platform.

The scenarios we consider shouldn't be based solely on the product itself; we also have user scenarios. We should ask how a feature may behave for different user archetypes.

Additionally, we have to consider scenarios where our proposed plans may impact existing implementations. Equipped with this knowledge, we can then raise questions to determine the key points we care about in a project.

Nonetheless, we aren't always blessed with a clear path. As a tech lead, we often have to dive headfirst into the unfamiliar, which can cause discomfort. The best way to get comfortable with the uncomfortable is to ask questions until we recognize our surroundings.

Identifying the unknown?

If you are working on a completely new surface or platform, your existing familiarity can still guide you more than you might initially think. Ask similar questions as you would for a platform you are already familiar with. Let that line of questioning guide the discussion, challenging assumptions along the way. This can help steer you in the right direction or quickly identify if you are off base. You are starting somewhere and making progress, which will clarify the path forward and maybe help define the timeline you are working with.

For example, if my team was tasked with integrating with a new API on the client side, I'd ask questions such as this:

• Are other teams using this service?
• Is it production-ready?
• If we are able to use it, how straightforward will it be to integrate in our service?
• Does it require authentication?
• Do we need tokens?
• What is the expected response?
• What is the performance and impact?

...and more!

You might think these are questions one might ask themselves as they dig into a ticket, but asking up front will help better define our work and determine early on if we have a viable path towards solutions. The earlier we illuminate the unknown, the better.

Be shameless

I used to think that asking a lot of questions came off like I wasn’t paying attention, or that I didn’t retain knowledge I had learned previously. That really isn’t the case.

What we once knew may have changed shape over time; or maybe, because of the given scenarios of our project, our assumptions won’t hold weight. We should be shameless in our question asking. We ask from the perspective of our own understanding of the problem at hand, as well as illuminating and providing clarification for others in the room.

Being shamelessly inquisitive is a crucial skillset for tech leading. Ultimately, it helps us produce more well-defined projects, leading us to be more successful in the work that we do.