I found Tanya Reilly’s book validating. I came into Software Engineering as a career switcher from a completely unrelated field, but I spent years in operations management. Most likely due to my ADHD, I thrived in high-stakes, chaotic environments that required a lot of coordination and “synergy” (a word I think sucks, but for lack of a better term it’s good enough) between people to be successful. You could try to do it alone, but you’d most likely fail. Coordinating group effort is hard. Really hard. Sometimes it feels like baby sitting, sometimes it feels like you’re fighting each other even though you’re on the same side. And sometimes it felt like you were walking through your own Dante’s Inferno. Throughout that journey I learned a lot of soft skills around people management, leadership, and communication (it was exhausting). When I took a leap of faith in software engineering, I threw those soft skills in the trunk and focused on gaining technical skills to prove that I was worth keeping. This world was new to me, and I was surrounded by people who honestly lacked a lot of social skills, so I didn’t feel the need to whip out all of my tools I gained from previous experience. Since I came from a non-traditional background, I felt I didn’t belong. So I put my head down and pushed myself to improve technically to feel less like an imposter.

This worked out pretty well; I was gaining more notoriety as someone dependable and reliable. I was brought to the table on a lot of conversations that I wouldn’t have been privy to before. It was exciting. But as I grew more technical and my prefrontal cortex had room to breathe, I was starting to see the cracks that my previous soft skills could fill. I started to notice the breakdown in communication between teams, the misunderstandings, politics, etc. But these thoughts were unconscious. It had been 3 or 4 years since I was a manager, and I was burnt out from that life, so I did my best to ignore anything that caught my “manager” eye.

Until I couldn’t.

Tanya’s book put into formalized words everything my gut was saying. I found myself nodding along to the book almost 100% of the time. Some of it felt like common sense to me, but for those who have only worked in tech and haven’t had any people management experience could see it as enlightening. In the end I came away feeling validated, like I’ve been able to find the path clearly on my own, and Tanya’s book took a look and said “yep, keep going.”

I pretty much liked everything about the book. If there are any cons, it’s not really that there are any to me, but I could have skipped around due to already feeling like I knew the content of certain chapters.

The following are my thoughts and words, not a reflection of the book’s message. More so my outlook after reading the book:

  • Once you upgrade from being a “grunt”, you gain a new problem. People.
  • People are blockers. People are also remedies.
  • Do not avoid political capital. This applies to juniors (if there are any left in today’s misguided AI-bubble technofeudalism world), newcomers, and senior+ engineers. Without it, your job will only be harder. Sometime you won’t be able to DO your job without it.
  • Learn to negotiate (and influence). You have to do this with Product, other engineering teams, and stakeholders of your project(s). Without this, you’ll be pulled so thin and expectations will be so high, you’re only set up to fail. Entropy wins every time when you don’t negotiate.
  • Your ability to deliver value increases exponentially when you have people skills. Projects cannot be delivered by one engineer. If you’re working on one that can, then you’re working on the wrong thing and that problem is below you. Your problems should be measured by the number of poeple you need to coordinate with to solve that problem. This is the problem you should be solving because this is a class of problems only a select few can solve (and the business value more).

There are many gems in this book. I need to go through the sticky notes I made and update this article. But even more so, I’d suggest you read the book. While not everyone is a staff (I don’t have that title), staff engineer is a mindset as much as it is a position. And it helps to dress for the job you want, not the job you have.