Technical Writing, Leadership, and the Power of Saying "I Don't Know"
Recently, I have started recognizing the power of technical writing and the importance of being comfortable saying, "I don't know," as a software engineer.
I had a task recently where I needed to create a job that stores permissions. Once those permissions are stored, we use them to map against the appropriate rules. When a rule matches, we apply the corresponding permissions to the appropriate resources.
On the surface, it sounds like a straightforward engineering task. But while working through it, I realized how many questions naturally come up when you slow down and think through the system properly.
How should we store the permissions in Cosmos DB? How should we send and retrieve that information? How should permissions be associated with agents? What happens as the number of agents and permissions grows? Will the design scale? What are our dependencies? What happens when something fails?
These questions are exactly why I have started appreciating technical writing.
Thinking and Writing Go Hand in Hand
I used to think of writing as something you do after you have figured something out.
I am beginning to think about it differently.
Writing can actually be a way of figuring things out.
When I write down how a system is supposed to work, gaps in my understanding become visible. I start asking questions that I may not have thought about otherwise. Writing forces me to slow down enough to understand the problem instead of immediately jumping into implementation.
In that sense, technical writing is not just documentation. It is a thinking tool.
And the more I write, the more I realize that good engineering is often about making our thinking visible.
The Power of Saying "I Don't Know"
One of the biggest lessons I am taking away is that saying "I don't know" is not a weakness.
In fact, it can be the beginning of better engineering.
Our rules engine, for example, became slower than we expected. Looking back, part of the problem was that we didn't know what we didn't know. We had assumptions about how things would behave, but we hadn't investigated all of them deeply enough.
There is a difference between:
"I know."
"I know that I don't know."
And:
"I don't even know what I need to ask yet."
That third category is where many engineering surprises come from.
The willingness to say "I don't know" gives us permission to investigate, ask questions, experiment, and learn before making decisions.
Leadership Is About Context and Trust
I also think this connects directly to leadership.
As a leader, I don't need to have every answer.
I need to be able to explain the problem, the context, the constraints, and the desired outcome. Then I need to trust my teammates to figure out the best way to get there.
That requires trust.
If I tell someone exactly how to implement every detail, I may get the outcome I want, but I am also taking away their opportunity to think and own the solution.
Good leadership is not about having all the answers.
It is about creating enough clarity that other people can make good decisions.
That also means trusting people's capabilities and resisting the urge to micromanage.
Work With Intensity, But Also With Consistency
There are moments when we need intensity.
A difficult production issue, a design decision, a critical deadline, or a complicated technical problem may require deep focus and sustained effort.
But we cannot operate at maximum intensity all the time.
Consistency matters just as much.
Writing regularly. Learning regularly. Reflecting on our mistakes. Giving ourselves feedback. Understanding our dependencies. Sharing what we learn. Taking on increasingly difficult problems.
These small actions compound.
I am starting to care less about having a perfect outcome every time and more about building a process that keeps making me better.
Losing the Ego
Losing the ego does not mean thinking less of yourself.
It means being less attached to being right.
It means being able to say:
"I don't know."
"I was wrong."
"Someone else has a better idea."
"Let's try it and see what happens."
It means responding thoughtfully instead of responding quickly just to prove that you have an answer.
It also means letting other people do their work.
If I trust my teammates, I have to trust their ability to make decisions. I cannot say that I trust someone and then constantly second-guess everything they do.
The same applies to myself.
I don't need to know everything before I start exploring.
Sometimes the answer comes from experimenting, playing with an idea, getting feedback, and learning along the way.
Trust Allows Us to Scale
There are only so many things one person can do.
If I try to own every task, every decision, and every detail, eventually I become the bottleneck.
The more senior I become, the more important it is to learn how to let go.
Not because the work doesn't matter, but because other people are capable of doing meaningful work too.
My responsibility is increasingly becoming about creating clarity, removing obstacles, sharing knowledge, and helping others succeed.
That is how individual contribution starts turning into leadership.
Apologize When You Make a Mistake
We are not robots.
We are going to make mistakes.
The important question is not whether we make mistakes. It is how we respond when we do.
Someone who refuses to acknowledge mistakes becomes difficult to trust.
Someone who can say,
"I made a mistake."
"Here's what happened."
"Here's what I learned."
"Here's what I'm going to change."
is much easier to trust.
Failure is an option, especially when we are trying something new.
If we never fail, we may simply be staying within what we already know.
Innovation requires experimentation, and experimentation inevitably comes with mistakes.
The goal is not to avoid every failure.
The goal is to learn from failure quickly enough that it makes us better.
Slow but Steady
Ultimately, I am realizing that growth is less about constantly trying to achieve some impressive outcome and more about consistently improving the process.
Write.
Think.
Ask questions.
Admit what I don't know.
Learn.
Experiment.
Share.
Trust others.
Reflect.
Try again.
I don't need to have all the answers today.
I just need to keep becoming better at finding them.
And perhaps that is one of the biggest lessons I am learning about engineering and leadership: the goal isn't to be the person who always has the answer. It is to become the person who helps the team find better answers.
Top comments (0)