How do you turn pro?

“I love deadlines. I like the whooshing sound they make as they fly by.” — Douglas Adams

While figuring out what I like doing and what I’m good at, I’ve also tried to learn and build things on my own. By “work” I mean both the day job and learning in general, and what I’ve realised is that I don’t work consistently.

In college I knowingly worked in endsem mode for the most part: attending lectures but not putting enough effort into the material, tackling assignments by their deadlines and, most tellingly, studying only when the endsems were around the corner. This usually got the job done and left me time in the semester for other stuff, like playing and research. In a lot of cases I found the material itself pretty interesting, but I couldn’t afford to spend time on it because I had exams in the next couple of days.

This led to okay academic results (though when I studied regularly for courses I found interesting, I usually scored better), and the habit carried over to work. Most tasks in junior engineering have clearly defined outcomes: implement this algorithm, run these regressions, debug this piece of code, review failing PRs. So for most of my first year out of college, I was driven by tasks and their deadlines. That meant hectic weeks followed by peaceful weeks.

When I got more autonomy in my current job, I quickly realised that there were no clearly defined outcomes, so I couldn’t go into endsem mode on anything: there was no skeleton to work against. What do you do when there’s a 6-hour window where you’re waiting to hear back from the client on whose iPad your change is live, but you’re not sure they’ve even looked at it? And you’re out of ideas for the next couple of days? (This usually leads to crunch time later, when you have to rewrite something from last week because you just had to get it done.)

Some days I whiled away blocks of time reading; other days I tried to brainstorm what to do next. Eventually I realised I needed some kind of system for myself, though I had no idea what it should look like. Separating myself from my work was also something I struggled with, so feedback on my work made me question my self-worth. One bad round of feedback or one bad meeting would set me off (it still does, actually), and I’d start thinking about how unfair it was, and how I could possibly have made a mistake.

One colleague whom I respect immensely told me to stop playing like a striker: I’m not the only one scoring goals, so I should start playing like a midfielder. I realised I had to cultivate that: caring about the team’s outcome, and not letting my inner technical builder develop an ego about, or an attachment to, the things I put forward.

That’s when I realised I needed to work on being a professional, which is completely separate from being a good engineer, and something I had no experience in.

In their conversation on the Huberman Lab podcast, Steven Pressfield and Andrew Huberman talk about the idea of a professional: no matter what you do, you do it like Michael Jordan would. That doesn’t mean you need to be a prodigy; it’s about showing up, doing the work, and leaving it all out on the mat. Pressfield offered an interesting way to do this: think of yourself as a two-person team. One is the manager (the CEO), and the other is the operator. Feedback is read by the CEO and filtered down to the operator. Work is assigned by the CEO and done by the operator; the when and where are set by the CEO, and the how is executed by the operator. The why (which I struggled with) is handled only by the CEO.

Sow enough seeds of effort and you might get a good crop back. The Sower, Vincent van Gogh, 1888. Image: Wikimedia Commons, public domain.

So when the CEO hears “your work is shoddy”, the reaction is: okay, I didn’t do the work, my operator did. I’ll tell him to do better, but since I know my operator isn’t emotionally intelligent, I’ll put it as “the work needs more attention to detail in these areas: (a), (b), (c)”. Essentially, I need to be a manager for myself. That turns feedback into to-dos for my operator instead of a verdict on me.

When I have a free 6-hour block, the CEO can think without worrying about execution or effort, and set an ambitious goal: look at the changes we made last week. Are they hotfixes? Can we rework them into something that handles more edge cases? That sends the operator off to do at least something productive, instead of brainstorming endlessly.

What if all that’s left is small, annoying work I don’t enjoy? Then I try to think like the operator: this is a widget on the assembly line, and I just have to get it done. The CEO is in charge of incentives too: get these three items out and you can take the rest of the block off.

Meeting deadlines is at the base of the pyramid of being a pro, I suppose. I’d like to believe a true pro doesn’t wait around for things, like deadlines, to happen to them. Feelings don’t come into it: you do it scared, you do it hurt. Deadlines should whoosh by without incident, because you’re sure your system can get into the mud and get it done.

What I’m trying now: separating my work self (the operator) from myself, and being a CEO who can drive that operator.

Turning pro is something I need to learn more about, and I’ve only just realised that I’d been ignoring this side of work. Future me will hopefully read this and give a professional thumbs-up.