Of course I told you. I didn’t tell you? Are you sure? Well, maybe I told your brother twice.
– my mom

I wish I could say that I’ve always set expectations consistently across my teams. That I’ve sat down with each of my direct reports and, based on their level, given well-defined explanations of requirements for job success. This is not to say that I didn’t try – I have some well-rehearsed speeches that I’ve been giving for years, which I’ve used to communicate specific expectations and anti-patterns. But these focus on quantifiable performance criteria, and I’ve typically only discussed more subjective expectations when they weren’t being met.

So to one, I talked about leadership. And to the next I discussed ownership. The next person got the impact speech, or maybe the one on personal development. I tried to match the message to the specific individual’s needs, but this just meant that everyone only got a piece of the whole.

Managers are told that it’s necessary to set expectations clearly with their teams, but are typically left to their own devices in defining those criteria. This results in uneven, shifting messages, and variable communication of expectations across an organization.

Blumenthal’s Law: an organization with N managers and M employees will have at least N sets of communicated expectations. This number will approach M over time.

This has always been a frustrating situation. People want to understand their success criteria, and to have a holistic view of the skills they need to develop. Managers want to set their teams up for success by communicating consistent level-specific expectations. And companies want consistency across their engineering organizations to aid in hiring, performance evaluation, training, and promotions.

And so, last year a friend and I spent a significant amount of time working out a formulation that broke down expectations by level. It focuses on behavioral competencies, not specific technologies, and tries to get at the heart of what senior engineers do differently from junior engineers. I won’t claim that it’s perfect, and it won’t meet the needs of an organization looking for a skills-based competency matrix, but it’s a start, and something I’m using at M.Gemi to set expectations consistently across the team. These are the things I care about. These are the things you need to do well to succeed. This is how I think about performance.

We’re open-sourcing the documents, and hope you find them useful – either as a manager looking for something to share with your directs, or as an individual contributor looking for insight into how managers think about career progression (or at least, how these managers think about it). Standard caveat applies: these docs don’t necessarily represent the opinions of our past or present employers (though I am the CTO at M.Gemi, so).

Enjoy!

P.S. We’re hiring! If you’re interested in joining a high-performing team with well-defined expectations and a focus on personal growth, please send me an email at daniel@[M.Gemi’s domain], and let’s get started!