Skip to main content

Command Palette

Search for a command to run...

The audacity to do whatever I want

The best thing my tech lead ever did for my career was absolutely nothing at all

Updated
7 min read
The audacity to do whatever I want

Starting at my current company, I imagined I’d follow the path defined by the degree I had studied. My mind was closed to the possibility of stepping outside of my comfort zone. Naively, I imagined I’d forever be a Python programmer who only ever used the language for light data processing. Included in my 10-year plan was a career of manipulating pivot tables from messy Excel spreadsheets.

As a junior, I didn’t expect to be given opportunities. You expect to take on grunt work. Tasks labelled ‘tech debt’ that everyone else is smart enough to identify but doesn’t have the time to get around to doing themselves.

After wriggling my way into a backend engineering team working on personal banking features (released and unreleased!) that I wanted to use in my day-to-day, I had reached a significant checkpoint. I landed in a place I thought was only reachable through years of experience, plus a lateral movement.

My tech lead was a Staff Engineer, not a manager, and yet I’d hear stories of juniors before me flocking to his team to learn from him. “How does this guy manage to advise teams on how they can best manage their services, and yet have the capacity to mentor juniors year after year?”

This tech lead had worked with a few brilliant engineers (juniors and graduates) who had ended up moving on to bigger, more “glamorous” companies. I remember thinking at the time, “This guy must run a STRICT schedule.”

Imagine my surprise when I landed on the team that nobody told me what to do. I sat in on standup meetings, mentioning I was still completing A Tour of Go. Maybe a couple of weeks after joining the team, I asked, “Can I pick up a ticket now?”

“Yep, go ahead,” was the response I received.

“Why are they letting me pick up real work? Don’t they think I’ll mess things up?” I’d ask myself.

The next day, I selected an item to complete from our GitHub project board and updated the team on my latest task. No objections. I would spend weeks on each ticket I picked up, often ending up having to rely on my tech lead and teammates to spoon-feed me through the tasks.

“Surely this isn’t how the other juniors grew?” I thought to myself.

Months passed, and I asked lots of questions. There was never any conflated praise, which I at the time heavily relied on as if it were the air I breathed. I’m sure there were more than just a few “good job” comments thrown in there, but my tech lead was not the type to applaud and sing to the heavens every time I pushed a commit that appeased the GitHub Action gods. (Crazy, if you ask me).

I mainly stuck to tickets related to GitHub Actions because that’s what I was most familiar with. As a test to see if my tech lead actually cared about our team’s output (considering I was taking weeks to complete my tasks), I selected a ticket I thought was way too complex for me, one that another teammate had even mentioned I may be better off avoiding.

“I want to pick this up,” I bravely announced to my team in standup. Blank stares, as if nobody cared, and no objections followed. It was almost as if it were BAU. Did they care about the work? It felt crazy that they’d let me take on what felt like a Herculean task; I had intentionally chosen a task that sounded like total gibberish to me. What I thought would be a harsh experience with rejection therapy was met with total acceptance.

I pushed through more tickets, constantly battling the fear of looking stupid. I leaned into my TL’s grace, learning to ask questions that focused on the problem rather than my own inadequacy.

Throughout my time with this team, my old colleagues would ask me what I was up to. They would hear things from me like, “I don’t know, but I updated something to do with our API!” I couldn’t explain the importance of the work I did. All I could do was point to files in our codebase and say, “I touched some lines of code in that file.”

It wasn't until I moved to a new project under a new tech lead (TL2) that I realised those 'random lines of code' had actually built a foundation I didn't know I had. Another greenfield project, except that with this one, I was afforded the privilege of joining earlier than the previous one I was on. I was creating new services from scratch, participating in API design discussions, and guiding my very new team on what areas of our codebase to work on.

TL2 took a different approach to work allocation; he proactively voiced what work should be taken on by whom, which made sense because we hired contractors for their subject matter expertise. As a permanent employee and proud non-expert of anything, I was able to more freely switch between different tasks.

TL2 picked up on my habit of switching tasks. I never stayed in an area of the codebase long enough to become an expert–our team had to move fast to meet our release date for our MLP.

TL1 and TL2 were well acquainted with one another and naturally had different working styles. The high agency and sense of trust I’d been given, not earned, by TL1 had TL2 raising his eyebrows. Because nobody really stopped me before. How could they? Safety guards like established standards for unit and integration tests were in place for my last project, so I couldn’t really break anything. I was impatient. I’d raise fixes for problems without thinking them through properly and would volume-shoot decision suggestions without giving others time to process them.

“Did TL1 let you do this?” TL2 would ask. I was mortified. Did TL1 let me act this recklessly?

Stubborn and allergic to being wrong, I would present TL2 with a counter-argument-turned-inside-joke: that maybe I wasn’t “not thinking enough,” maybe he just wouldn’t let me learn (fail) as fast. “You’re the problem, not me 😁” vibes.

It took TL2’s raised eyebrows for me to finally realise what TL1 had been doing all along. He wasn’t “leaving me to my own devices”; he actually just never put me in a position where I had to earn his trust. He never stopped me when I said, “I want to do this,” but he didn't offer any “I believe in you” cheerleader speeches either. There was just a total, unsurprised acceptance of my agency.

I thank God for TL2 being able to take a joke and for being the person who held a mirror up to TL1’s impact on me. Had I never worked with him, I’d never have had the opportunity to question my own recklessness.

Looking back, I don’t think the blank stares from my team meant “we don’t care” (I’ve since become closer with these engineers and found out they were actually just zoning out). My tech lead had built a team environment where it wasn’t absurd for a junior to take on complex tasks. It was normal. If I wanted to fail, nobody was going to get in my way.

On my last day with TL1’s team, my teammate shared that “no feedback means good feedback”—a common yet controversial take. I later realised that when I was forced to stop chasing praise to feed my ego, I focused purely on objective data points that could help make me a better engineer.

I guess the other engineers that TL1 had built up weren't taught how to follow instructions. He probably just let them own the problems that they chose to own. I used to project my own fears of being 'called out' onto my peers, telling them to over-document and over-communicate. I see now that while it felt like TL1 was too busy to manage me, he was actually too intentional to micromanage me.

Clearly, I was oblivious to both subtle and blatant signs that I had my team’s trust, because our manager at the time used to remind me, “You can do whatever you want!” Not in a “the world is your oyster” way, but as a “stop asking for permission and do the thing” kind of nudge. The signs were all there; I was just too distracted by what I thought progress validation should look like.

Thanks, TL1, for never forcing me to earn your trust. I now have the audacity to:

  1. Move faster than I can be granted permission for,

  2. Speak up when I’m overlooked; and

  3. Build a career founded on agency rather than instructions.

I’m proud to say the junior who asked for permission is gone, because I’m too busy building to wait for it!