I have a sticky note that I keep on my computer. It looks like this:

it's not really even sticky anymore

I put it on the top of my computer and every time I see it before starting work, it reminds me to take a deep breath. Leading a team of developers, especially as a new manager, can be incredibly fulfilling and immensely stress inducing. It can feel like there are a million questions to answer in the span of a single morning, ranging the gamut from technical problems to personnel issues. And it doesn’t help that alongside the responsibilities, there’s a strong dollop of impostor syndrome to top off my anxiety sundae.

So while it might seem silly, having this raggedy post-it note is a gift to myself. I feel an immense pressure to have the answers. Whether in response to a particularly thorny code-related issue on a pull request, guidance on a refactoring process in an old base, or just answers about what priorities the team should have in the coming year. For me, the pressure can often feel insurmountable, and it stems from a desire to demonstrate my competence and to prove that I am, indeed, capable of being a Technical Leader (capital T capital L).

Certainly any job that involves collaboration and mentorship requires a degree of shot-calling. I think we’ve all been in meetings where everyone goes around in a concentric circle of indecision. But I’ve noticed that in my desire to posture as a leader, I’ve been leaping to answers without asking questions. Providing answers without creating room for questions is a means to cover up my own insecurities, even if I’m fairly certain the answers I’m providing are right.

Take for example a question about refactoring a legacy code base. Developer A calls a meeting to discuss the refactor, and lays out the reasoning behind the refactor, and how the code base needs a face lift. After the team at large gets a chance to weigh in, my creeping tendency is to provide a detailed game plan on how to conduct the refactor, and to start assigning out the work. I’ve done refactors like this before, I know where the codebase needs some TLC, bing bang boom, let’s move on to the next topic.

Not so fast, Ev. By jumping into answer-mode, I’m robbing the developers who work with me a chance to take ownership of the problem, to extend their troubleshooting tool kit, and to demonstrate their own technical expertise. And what’s more – I’m not really hearing them because I’m in an echo chamber. My thoughts revolve around wanting to showcase my knowledge, rather than to bolster others.

When I heed the call of my little sticky note, and take a breath to consider, it would behoove me to start off with some pertinent questions designed to guide the conversation. Why do we need to do this refactoring? What areas are most problematic, and how do we break the problem down? Who might be interested in doing this work? Rather than feeling an onus to solve the problem in order to demonstrate technical leadership, I can create an atmosphere that allows others to take center stage – while still using what wisdom I’ve gleaned in a more healthy, and sustainable manner.

And I use the term “sustainable” quite deliberately here. Feeling a constant pressure to know, and to have the answers on hand, is not sustainable. At least, it isn’t for me, and I suspect others feel similarly. It’s not a matter of abrogating all responsibilities for making decisions, but rather introducing an internal vocabulary that pauses an implicit drive towards answers, and instead orients it in the direction of asking insightful questions.

So next time you are in an environment where you feel some anxiety over having to know the answer, take a moment, take a breath, think about my stupid little post-it note if you want, and ask a question instead.