What is the one metric for sucess in your career?
Lately I’ve been thinking about what it means to grow in my career. Like, How do I know I am doing a good job? Is there a metric I can track? It turns out there’s people way smarter than me that have already thought about that and written about it.
Tanya Reilly wrote an excellent book on that subject The Staff Engineer’s Path which I reference a lot, specially when I try to figure out how I should approach my career path. I am clear in the fact that I want to stay technical, I don’t want to be a manager, not because there’s anything wrong with being a manager. The thing is: I don’t want to stop writing sofware. I want to design, implement, test, deploy, maintain and deprecate software systems. I don’t want to stop doing that, at least, not for now. So anyway, there’s a lot of good advice out there, there’s a lot of things you can optimize for. If you want to go from software engineer to senior you need to know things, you need to be responsible and reliable. If you want to grow in your career then you need to be a leader, a role model, you need to be the glue that facilitates collaboration. Since there’s so much to know, so many different ways to help a team. There are so many rabbit holes one can go down in depth: Business Domains, Customers, new fields developments. There’s so many good people to meet. So, you can’t know and do everyting. You have a limitied amount of time and everything counts. So then, how do you know you are doing a good job? What is the North Star?
There’s a quote in Reilly’s book that cleared it up for me (I think) and it’s attributed to John Allspaw’s On Bing a Senior Engineer
The degree to which other people want to work with you is a direct indication of how succesful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with
So the metric for sucess is whether other people want to work with you. If they don’t, reevaluate your approach.
It’s not like this is new to me, I’ve always had a similar mantra but worded slightly differnt. When I was an intern at IBM, One of the old-timers (COBOL programmer) gave me this advice:
The people who succeed in this business are the ones that know how to get along, not the ones that know the tech better.
I’ve had this with me. “Know how to get along” It has helped me. I remember my first job was writing low-level firmware for Motorola radios. Back then, the HW team and the SW team had to collaborate to design and build products on time. The hardware team and the software team hated each other, in principle and practice. Heated arguments and folk storming out of meetings was not unheard of. I got stories about that…but the COBOL programmer’s advice was still in my head so I would walk to the HW team area and talk to the engineers there. I built rapport with those guys and that helped me get stuff done. It was quid pro quo relationship. I’d give them special sidebuilds to let them test HW features in isolation and they’d give me early access to the HW’s schematics so that my team could start the implementation sooner. It was a wonderful underground railroad of productivity. While the managers were deadlocking plans, the engineers were making stuff happen. What a beautiful thing.
Then, when I moved to Seattle I joined a startup and I grew my internal mantra to something like this:
Be a good human being first.
This means, that no matter the stakes, pressure and situation, don’t be an asshole. The end does not justify the means. Success at any cost, (my marriage, my relatioship with my kids, team’s morale, ethical integrity) is not acceptable to me. I work in order to have a life, not the other way around.
This new mantra “Be the person that people want to work with” is better because it is more focused. Being a nice person that can get along is great, but will people want to work with you if your code doesn’t work? If you don’t know the domain? If you don’t have high standards? So I think I will take this with me.
JV