Evolving through blunders

Sometimes, the path to growth is paved with missteps. Recently, I faced one such bend in the road - an opportunity to lead a major feature, something I’d been eyeing for a while. In my eagerness to shine, to be seen as ‘promotion-worthy’ and ‘intelligent,’ I stumbled.
This post goes beyond just telling the story of my stumble; it’s about digging into the lessons that came out of it.

I find immense value, especially as the writer, in sharing these experiences. Writing about them not only cements my learnings but also, I hope, encourages you to reflect on and share your own mistakes and lessons learned.

Heavy-weight feature

As a software engineer eagerly awaiting a promotion, I’ve felt ready to step up for some time. However, management needed more evidence of my leadership capabilities, particularly in steering a larger-scale feature than I had previously managed.

Note - leading a feature in this specific company was pretty broad. you get some raw product requirements, design the architecture for the solution, >iterate with the product on the specs, and break down the feature into small tasks for multiple teams to handle, while implementing the core parts and syncing with everyone involved on a weekly/bi-weekly basis to verify everyone’s on track.

TLDR; It is a pretty demanding task.

The scope of the feature I got was the biggest I ever got, and it was even more important since it was linked to my promotion - doing well leading that feature meant getting promoted in the next cycle.

Blunder

Since the feature was so important to me, I mistakingly tried to do everything on my own without consulting with other engineers, thinking that it would make me stand out.
I came to the design review meeting, fully prepared, ready to shower everyone with my great solution - eager for them to just say “Awesome, let’s do that”.
I didn’t even come up with an alternative. I was so laser-focused on my design, that I was blinded by it.

10 minutes into the meeting, one of the principal engineers asked a question that I didn’t consider. In the following 10 minutes, everyone in the meeting (including me) decides that the design could and should be improved.

Handling disappointment

I prepared for that design review meeting for a week. I thought I did good enough research. and then within 10 minutes of the meeting, most of my design went to trash.

It was a shock to me since I never failed so publicly, I just grabbed some water and left the office. It was a bad day.

It was also hard since I felt my perceived intelligence took a blow that day. I was never pushed back like that and felt pretty confused as to how I missed all of it while I was planning and designing for a week.

Instead of dwelling in disappointment, the day after the design review meeting I started jotting down the new design, this time having separate calls with multiple engineers brainstorming for potential flaws and overall correctness of the new approach.

A week later, I presented my revised design. The second review meeting was a stark contrast to the first. Not only was my design well-received, but I also felt a renewed sense of confidence. This wasn’t just about the approval of the design; it was a testament to my ability to learn, adapt, and grow from my experiences.

What I learned

• I will fail more often than I want - that’s a good thing, I want to be challenged as much as possible! I felt I had grown a lot from this particular failure.
• Asking for advice and brainstorming sessions while designing a feature doesn’t mean you take less credit for it.
• Deadlines vs Feelings - even though I felt really bad after that first design review meeting, I didn’t let that affect the day after and I started working on the new design immediately. This was key to recovering mentally, and to also showcase that failures don’t get me too rattled.

In my quest to stand out, I initially believed that going solo was the key to earning full credit and proving my worth. I thought that handling everything independently would showcase my capabilities most convincingly. However, this experience taught me that this mindset was far from the truth.

Observing engineers whom I admire, those several levels above with decades more experience, I noticed something crucial: they didn’t shy away from collaboration, even on high-stakes projects. They regularly sought input and brainstormed with others, including those less experienced, like myself. This was an eye-opener.

I realized that it’s not about taking all the credit; it’s about creating the best outcome through shared efforts and diverse perspectives.