Discover more from Meditations on Life, Technology, Leadership, and Everything
A toolbox I carry around with me
Anybody that has done some kind of craft job long enough will tell you that they have their favorite tool, I have friends that are mechanics and I can assure you that they have a favorite power tool and would be lost without it.
Knowledge workers are no exception, we also have our craft and tools and, once you have done your job long enough, you get tired of doing the same things over and over from scratch, in my job that translates to having several document templates or online resources that I can use when I start in a new job. Those are not “ready to use”, I am not bringing a show around the country, just simple templates I can personalize and use as the base to modernize or introduce some practices.
I know those documents would be useful to a lot more people, I have spent enough time googling for sources before having those documents to understand the pain, and I think more people would love to see how “other managers do it”.
Everything is a remix
Before I share anything, I think is important to point out that those documents are a patchwork of multiple sources, the feedback of multiple people, and my own experience. And I offer them not to be used verbatim but rather as a starting point to develop your own.
Management is situational, and nothing works out of the box.
Engineering progression framework
In my time at Booking.com and Aidence, I had to rewrite the engineering progression framework twice. It seems to also be the most common question I get from other engineering leaders. There aren’t too many resources out there, although there seems to be a small trend of open-sourcing career frameworks, companies just don’t care enough to go through the hassle of polishing it for the general public.
That is why I am a big fan of Dropbox’s career framework, it’s clean and written in plain English. The downside is that is difficult to apply generally to other companies since it’s very tied to Dropbox’s culture.
Gitlab, being open by design, has also open-sourced all their career frameworks and expectations but, not to pick on them, I always find their stuff super confusing.
So here’s my template, it’s divided into two ladders: Individual Contributor and Management.
If you happen to use it, personalize the framework to make sure it fits with your company and, more importantly, use it as the "80%" of individual expectations for performance evaluations or promotions. Bound the other 20% to achieve company/team objectives. More in general, never make the mistake of rewarding people for checking boxes, make sure to always reward business contributions first.
For the individual contributor, you can observe how the first 3 levels are progressing toward a very technical individual that has lots of depth and is very comfortable in their team/area of expertise.
Then at level 4/5, it takes a U-turn and now communication and leadership skills are more important. This is a common way of looking at the role, once your technical skills are really good, the next challenge is to convince the business to do the right thing. And this is for me the secret superpower of any excellent staff engineer. And something I have touched upon before.
The manager ladder is pretty shoer, the idea is that an Engineering Manager is equivalent to a Senior Engineer, seniority-wise. What is maybe unusual is the level of technical skills required by a manager here. This is my view of the role, one I care deeply about, but I understand it might not be your case. I still invite you to read through it and challenge your assumptions.
More in general, this framework is very opinionated, you might feel the need to have some levels in between to make the transition more smooth, in short YMMV.
More and more companies have an internal architecture “Request for Comment”, enough that the Pragmatic Engineer has a full list of them. I never found one that struck the right balance between technical and business, so ended up writing a template.
The basic idea of this template is to ensure that the author would think very hard and do their research upfront, to avoid getting the annoying barrage of “did you think about X” by their peers or manager. The other aspect I deeply care about is making sure all bases are covered, especially the ones that are usually forgotten: cost, customer service, and migration.
I wrote a comprehensive guide to “how to hire” in which I touch briefly on a potential template but didn’t include one in the post.
Here you go, you can find the template here.
I like to write memos, and while I don’t have a specific template, I wrote about the simple structure I have used in the past here.
Incident Response practices and training. In the past, I have trained a lot of people on how to deal with production incidents. Those procedures are very company-specific, but one great resource that helped me a lot is Pagerduty’s incident response documentation. And don’t forget to play a good game of “Keep talking and nobody explodes”.