What are some of the biggest lessons you’ve learnt as a professional Software Engineer?” Marcus asked shyly.
“And here I was, thinking that I’m the one asking the tough questions” I replied, smiling at him encouragingly.
I was taking a sabbatical from Software Engineering at Google and spending the Fall teaching at the University of Puerto Rico.
Marcus was one of the quietest students in my class and he’d never volunteered to ask a question before. Sometimes, after I’d cracked a joke in class, my eyes would meet his, and he would smile fleetingly before looking away shyly, as if embarrassed that I’d caught him smiling. So I was both surprised and pleased when he walked over after class, patiently waited for me to gather my notes and markers and asked me this question.
I wasn’t a stranger to having students walk up to me to ask questions about being a professional Software Engineer, or about working at Google, or both. Often I’d never even met the students before, but I enjoyed these interactions. I appreciated the warm candor of these questions- the raw inquisitiveness. They likely didn’t have many opportunities to interact with Software Engineers, and were curious about the career they themselves might embark on one day.
Their questions ranged from the frivolous: “Does Google really have a rule about food being within 200 feet from employees at all times?” (no), “Can you really have someone do your laundry at work?” (yes) to the more pragmatic- “Should I join the industry or stay in Academia?” (it depends).
I’d been asked the same questions so many times that I always had an answer or quip ready. But this wasn’t a question I’d been asked before. I paused, contemplating how I could condense my decade long experience into a few pearls of wisdom.
“How about we set up some time to chat about that?” I offered, and Marcus nodded.
Later that night, I opened my laptop and tried to put down my thoughts into words. Not only do I find writing to be cathartic, but anchoring my thoughts into words usually help me build clarity.
Marcus’s question prompted a lot of reflection on my life as a Software Engineer. I’ve worked at a Technology Incubator in Ghana, as a Software Engineer at Microsoft & Google and as an ad hoc Professor at the University of Puerto Rico. I’ve flip-flopped between optimism and pessimism. I’ve been an anti-establishment couch potato and a social justice warrior. I have both hated the man and embraced him.
I decided that I wanted to give Marcus an answer that would be useful to him. I wanted these “lessons’’ to be practical- something that he could be mindful of and get better at as he forayed into the industry. Many of these lessons were learnt from costly mistakes, and I hoped that he could avoid making the same mistakes I did. This blog post stems from my reflections from that night. I hope that you’ll find it useful.
Lesson#1: Reputation compounds
I worked at Microsoft from 2012 to 2016 and at Google from 2016 to 2020.
When I announced my departure from Microsoft in 2016, my boss smiled, thanked me for my work and wished me luck. That was it. There was no counter-offer, no attempt to keep me at the company. There wasn’t even a farewell dinner. Walking away from Microsoft was the easiest professional decision I’ve had to make.
I remember sulking about it to a dear friend and colleague over coffee. “Sounds like Microsoft gave you an Irish good-bye”, he said, winking.
I’ve had plenty of time to think about my mediocre 4 year stint with Microsoft. I can’t honestly say that I accumulated 4 years’ worth of knowledge. Initially, I blamed everyone but myself. I blamed the company (“Microsoft’s a dinosaur!”), my team (“It’s because of the constant re-orgs!”), my management (“It’s because I was punted from manager to manager!”) and the projects (“I was given low impact/uninteresting projects!”).
Since then, I’ve come to realize that reorgs, restructuring and changes in management are inevitable in companies at the Microsoft/Google scale. I’ve also improved at self reflection. “My experience sucked because I wasn’t given good projects” is a bit like saying “I got a speeding ticket because there were a lot of cops patrolling”. Factually correct, but obfuscates the underlying issue. What’s the first principle here? Why wasn’t I given good projects in the first place?
In the fall of 2020, when I told my manager that I intended to move on from Google, he was visibly upset. Both my manager & my director tried their hardest to keep me at the company. They offered me more money and juicier projects. Former colleagues and managers messaged me about my departure, often with offers to join their teams. Walking away from Google was one of the hardest professional decisions I’ve had to make.
The main difference between my tenure at Google and Microsoft was the reputation I had for my craft. And my attitude fed my reputation.
I joined Microsoft in my early 20s and at a stage of my life where my career just wasn’t my priority. I don’t necessarily judge myself for it — I was young, single, hedonistic, living in a new city and making decent money. But I developed a reputation for someone who needed constant guidance- someone who “wanted it easy”. And this reputation was hard to shake off long after my attitude towards my job changed.
In 2014, Satya Nadella took over the reigns of Microsoft and orchestrated a shake-up of the prevailing software development process at Microsoft by ruthlessly reducing certain roles. Prior to 2014, most teams at Microsoft were staffed with one quality engineer (called Software Development Engineer in Test or SDET) for every developer. SDETs were responsible for testing the code that developers wrote. In contrast, typical companies in Silicon Valley today have 1 quality engineer per team of 12–20 developers.
As a consequence of the restructuring, majority of the SDETs on my team resigned (or were fired) and the team shrank down to 6 people who were responsible for overall quality. I was the only developer included in this team of former SDETs. I learnt from a mentor that management thought that this team would be a better fit for me since it wasn’t a critical/core team.
It didn’t matter that I had put my act together in the several months leading to this reshuffle & was producing high quality work. The reputation I’d developed overrode what I was actually delivering. Once I’d been assigned to a low impact team, I ended up working on low impact projects and delivering low value to the company. This culminated into what I call the cycle of dispensability, which can be quite detrimental to career growth.
First impressions matter. Once you develop a poor reputation, it takes a disproportionate amount of effort to reverse that. Your first 6 months at a new company will be your most important. The reputation you develop will determine the kind of projects you get to work on, which will further feed into your reputation. Reputation compounds.
By the time I joined Google, I was determined not to make the same mistakes again. I hit the ground running, and those first 6 months were probably the hardest I’ve worked. I taught myself mobile and backend development, learnt about java services and Spanner.
Pretty soon, I developed a solid reputation. Within a year, I was getting the pick of the projects and within a couple more, I was leading the highest impact projects for my team. Yes, there were re-orgs and manager changes but the reputation I’d developed stuck to me, and was almost magically transferred from manager to manager. My reputation gave me leverage to craft the life I wanted. Almost every year, I took a month off to travel. I often worked remotely, from different countries, and got to work on super fun projects.
Work on building a cycle of indispensability. You’ll reap the benefits of it for many years.
This is the first part of a multi-part series where I will discuss the biggest lessons I’ve learnt as a professional Software Engineer. Follow me to be notified whenever I publish a follow-up to this article.