Wow, it’s been three years since my last post!! Also, a lifetime.
I spent about half the time working at Twitter, the other half at AOL and Facebook. I moved from NYC back to our house in the Bay Area, CA.
Last year I was privileged1 to participate in a layoff, which was presented to me as a termination for lack of performance, along with, unbeknownst to me until later, half the office. At first I took it really hard, but then I decided to see what I could learn from the experience.
First of all, I realized that my performance was just fine – in fact, while I was being told how bad I was doing, I was also dealing with a severity 0 failure, starting with finding the root cause, contacting the appropriate developers, and keeping management aware of progress. During one of these management calls, I had forgotten to ask some specific question (I don’t remember; it doesn’t matter) and got screamed at by the manager for two minutes about how sloppy my work was. Meantime the sev0 was fixed over a weekend, and a hotfix saved a lot of people trouble.
But the main learning here is that as a senior engineer and beyond, the primary skillset isn’t how well you program, it’s how well you navigate the work social graph. At the end of Thinking Physics, Lewis Carrol Epstein has an appendix on the growth of business organizations that was really enlightening. A small startup will have one manager, the CEO, and say 3-8 engineers. Everyone will be producing and working hard, and the CEO will have the additional task of securing funding and marketing the product.
Eventually, if lucky, the CEO will need to hire an office manager, an accountant, and more engineers. At this point, she or he will probably have to hire an additional manager or two. Epstein estimates it to one manager per 10 employees, whose job it is to coordinate resources, and goals for those employees, and communication with other managers and the CEO.
If the startup makes it to mid-level, around 100 employees, an amazing thing happens. We now have 10 managers, which means we need to hire a middle manager, whose sole job is to coordinate the 10 managers, and is removed from the ‘front lines’ by a full level.
This is used as an argument that smaller companies can move faster and work more efficiently, by minimizing the number of communication lines that have to be maintained. But the reality is, companies grow. Sometimes they’ll split off smaller companies, but often they just get bigger, and hence further removed from their original mission, toward maintaining their own size and maximizing profit and shareholder value.
What this means is that you will likely work in large companies, and have to take on a good portion of this communication yourself. Senior and Staff engineers have to coordinate with engineers in other groups, because the managers may not have the bandwidth to fully immerse themselves in the technical details, all they can do is provide the introductions and step back.
If you want to accomplish your cross-team goals, it’s critical therefore that the engineers you need to work with want to work with you. Going to social events, taking people out for drinks, remembering their kids’ names, now are part of your way of life. You want them to hear your voice, or see your Instant Message, and think happy thoughts. Otherwise they’ll put you off and delay you, and your project will fall behind, and you get “(barely) meets expectations” at your next review instead of “exceeds.” Even if you’re a topnotch programmer!
And this is what happened to me way back when – I failed to understand the importance of the social graph. I would let my moods and my paranoia influence my interactions with peers in other offices to the point where I couldn’t get my code reviewed and kept missing deadlines. Which of course led to my mood getting even worse.
But in truth, a failure is only a failure if you don’t learn from it. Learn from my failure, and don’t fail yourself!
1 That’s sarcasm, just in case you couldn’t tell