0:00
/
0:00
Transcript

Ramping up is hard to do

But a good plan helps…

(Like this article? Read more Wednesday Wisdom! No time to read? No worries! This article is also available as a podcast).

I am a terrible ramper upper. That sits as follows (Dutchism): As a senior engineer, your effectiveness is dependent on three things: Your detailed knowledge of the technical architecture (with all of its quirks and history), your extensive hands-on experience with the infrastructure, and your deep network of key people in the company. As a new senior engineer you don’t have any of these things. But here is what you do have: Lots of expectations loaded upon you. The mismatch between these expectations and your ability to deliver can get you into trouble.

For most of my career, ramping up was not much of a problem because architectures and infrastructures were much simpler than they are today. Typically, a basic knowledge of the operating system, TCP/IP, the programming language, and maybe some database stuff, was more than enough to get you going pretty much everywhere. That all changed when big tech came along and the size and complexity of systems exploded. When I started at Google, this was not just the biggest and most complicated infrastructure I had ever worked with, it was easily 100x bigger and 10x more complicated than anything I knew about.

Fortunately, expectations were low and it was made clear to me that Google did not expect anything useful out of me for the first three months or so. That took the pressure off as I tried to wrap my head around Google Maps (the first team I joined at Google), GFS, Bigtable, Borg, gRPC, and Google’s C++ coding standards. It helped that I was part of a new team in a relatively new office and nobody really knew what they were doing; we were all just making it up as we went along.

I always thought this was a special and magical time to join Google. Sure, I was the dumbest guy in the building, but I was also among the first of a large wave of new hires so I didn’t immediately stand out as a clueless n00b. I didn’t know a lot, but people around me also didn’t know a lot, and that gave considerable comfort. I often reflected on how different things must be (have been) for people who joined many years after this very delicate time. By that time, everyone around them had been there for years already and must have seemed like total gurus. No surprise then that imposter syndrome was (and probably still is) rife among new Google engineers.

When I left Google and joined Facebook, I didn’t give much thought to ramping up. Big mistake, as I suddenly found myself without the knowledge, experience, and network that I alluded to in the opening paragraph of this article. I struggled quite a bit, which translated to my manager starting my first performance review with the remark that it hadn’t “really clicked yet” for me at Facebook. Fortunately, this was in the years before the current lay-off fests, because I am quite certain that, were this to happen today, I would be let go. I eventually found my groove though and when I announced my resignation, at least some people professed they were sad to see me go.

In my next job, I approached things differently. Realizing the deficit in knowledge, experience, and network, I negotiated that I would start my new gig with a hands-on project to deliver a piece of software. For these first few months, I was in essence operating as a high powered L5 or L6 engineer. This approach allowed me to right-size expectations (at least, initially) and to get my hands dirty while learning about the architecture and the infrastructure through hands-on experience. The other advantage of this approach is that it showed the junior engineers that I was (and am) not above hands-on work and that I am actually somewhat decent at it. This builds street cred, which is a very valuable currency in our profession.

The other advantage of this approach is that it allowed me to have my first conversations with other people in the company about some tangible project. I have done a lot of introductory 1:1s with people and I always find them a bit awkward because there is not always a lot to talk about. People who worked with me might know that I tend to start most work conversations with the phrase “what can I do for you?” which almost immediately gets us into some meaty topic. I find most “getting to know each other” conversations useless because, just like most first dates, there is often not a lot to talk about and the only thing you see is how people prepared and act. I’d much rather see how people react, because then you have a higher probability of seeing who they really are.

Here is a cool first date story. In the early 2000s, I took a young lady out on a first date to an improv comedy show in Amsterdam. We had a nice booth to ourselves at stage left. Halfway through the show, one of the actors walked up to us, followed by a camera and did a little interview with us, which was projected onto the big screen on stage. Kinda awkward, but okay. The next thing that happened is that it turned out that they had filmed us all along and in the next improvised skit they showed footage from earlier that evening with the improv actors playing out a made-up and hilarious conversation between me and my date based on the information we had just given them. Awkward to the max. Plus, during the break and on our way out, the entire audience congratulated us on our first date and inquired if we had really met “on the Internet”, which was quite novel at the time. After that auspicious start it is probably no surprise that my date and I were an item for many years and we are still very good friends today. It also shows this: Never a dull moment if you hang out with me… 🙂

Back to business: For my introductory conversations with new colleagues I would rather have a conversation about a project or problem, instead of just engaging in bloodless rehearsed niceties. Ramping up with an actual project, even if it’s technically below your level, gives that opportunity.

High expectations are a very specific ramp-up problem that I haven’t quite figured out how to deal with yet. Due to my many years of experience and sage look and feel (complete with grey beard and all), expectations can be sky high when I join a new company. Not seldom is there the unrealistic expectation that, by virtue of many years of FAANG experience, I will be able to quickly turn around some sclerotic team, organization, or project. I can do that, and I have done that, but I find that hard to do unless I have a deep understanding of all the aspects of the problems at hand. In the past, I have compared this expectation with hiring a general and then after a month asking why we haven’t invaded <insert neighboring country here> yet and replaced their government with one ruled by our puppets. The answer is of course that a military campaign of any consequence requires time, careful planning, and a capable army. There is literally no military genius who can pull this off all by themselves. If you hire me, you are hiring a general (or, probably more accurately: A major or lieutenant colonel); and you need to give me not just a problem, but also some time to plan and people and resources to fight the battles with.

The way to deal with this situation is by carefully managing expectations before you join. What does your new employer expect you to do, in what time, and with what resources and which people? And if you think your new employers have unrealistic expectations and you can’t talk them out of these: Don’t join! This sounds terrible, but you should obviously not set yourself up for failure. Another advantage of this approach is that it immediately sets you on a mission and as I described above, that makes ramping up easier. I have seen very senior engineers joining new organizations and spending months figuring out what they were going to do while the more junior engineers and managers were anxiously waiting for some magic to happen.

Getting back to me being a terrible ramper upper. This probably has to do with the way I learn, which is slowly, thoroughly, and by hands-on experience while solving real problems. People who know me somewhat superficially might be surprised by this analysis because I often seem to be a very fast learner, but that is not entirely true. Sure, I can go from 0 to 75% very fast and appear to be useful very quickly. But the real magic happens in the top 5% of the curve and it just takes me some time to get there.

Superficial and shallow knowledge leads to superficial and shallow solutions. You should give yourself time to really reach the summit of any mountain you are going to climb, but you need to attack that mountain with a plan, and not just start ambling up the incline, which I am sad to report, I have done way too often.

Here is a very easy summit to climb: Subscribing to Wednesday Wisdom. It requires no planning and no forethought;

Discussion about this video