While I was Head of Product Engineering at Atrium, our CTO suggested that all leaders in our organization write personal READMEs to improve our relationships and communications with our teams and across the company. I regretted that we never fully finished that project, so here, many months after the fact, is the finished project. There are many examples of these and plenty of compilations along with some less than enthusiastic posts for anyone looking for other styles and perspectives.
note: Because I left Atrium in 2019, this is more general and conceptual. Many READMEs will have more specifics about a given company’s day to day operations. While this represented how I would work in an organization, depending on my level, certain factors are beyond my control and this post represents the type of culture I would want to work and build.
My favorite part of my role is being a force multiplier for my team. This entails:
Additionally, my role requires me to identify performance issues, establish performance improvement plans, and in unfortunate cases terminate employees.
I get my hands dirty and spend between 5% and 25% of my time doing the same work as my reports. If they are managers than that means spending time having 1:1s and coaching their reports. If they are Engineering ICs that means writing code and reviewing pull requests. If they are ICs in an area I am unskilled in, such as design or marketing that means contributing what I can such as joining review sessions while being mercilessly careful to avoid in anyway being a hinderance to the team, and adjusting accordingly if anyone expresses concern that my presence is a hinderance.
Measuring performance is incredibly important but necessarily a subjective exercise and sometimes I will be wrong. In spite of my best efforts I, like literally every manager in the business world, will occasionally over or under estimate a report’s performance. For that, I apologize in advance.
Performance measurement, for me, begins with my “dirty hands”. Participating in the work of my reports is the primary way for me to gain insight into their performance. Some of the areas of performance that I focus on, at a high level (note that this is far from an exhaustive list):
One personal metric that I always emphasized for myself and my managers was that nobody should be surprised by a quarterly or annual evaluation. Infrequent evaluations are not the time for general feedback, especially regarding performance issues. Feedback should be granular and timely. If a report is surprised by something in their evaluation, then I have failed as a manager to give proper feedback on a timely basis prior to the evaluation.
In many companies these are treated as an exercise in paperwork after a decision has basically been made to terminate someone. I will not work at such a company. When I write a PIP, termination is still a last resort and my sincerest goal is to bring the employee back from the brink and resolve the issue. I take them very seriously and I expect the subjects of them to do the same.
Everyone is busy. Showing up a few minutes late to a meeting one agreed to attend is both disrespectful to the other participants and an inefficient use of everybody’s time. While it should be rare, sometimes circumstances will prevent even the most diligent calendar follower from being on time, in that, an email, Slack, or text (depending on the culture of the organization), must be sent to at least some of the other participants prior to the meeting’s start time so they know to start without you.
I generally have at least a 30 minute 1:1 on a weekly basis with direct reports and bi-weekly with skip level reports. Each one of my reports and skip-level reports will have a living document, generally a google doc, running in reverse chronological order. Throughout week, we both will put items in the document which we need to discuss and agreed upon action items. In cases where my manager does not do this, I do this on my own to “manage up”.
One goal of the shared doc is to minimize surprises during the actual 1:1 and allow us to use our in person time maximally efficiently. I try to review each person’s doc the day before the 1:1, though admittedly it is sometimes only day of, to prepare anything I need in order to facilitate the actual conversation.
The actual conversation tends to be somewhat casual and I find that a walk around the block or coffee shop visit is a wonderful way to promote interpersonal comfort. I try to end these a few minutes early to write quick notes in to the doc as I want to minimize the amount I have to pull out my phone or look at a laptop during the meeting.
Anything else is done asynchronously. All too often, meetings are called so that one or two people can stand in front of a room and read off of poorly designed slides because “people won’t read their email”. I start from the position that everyone on my team is a fully formed adult who can judge what information they need to do their job. Moreover, lecture style meetings are a woefully ineffective way to communicate information, with most eyes in the room glued to laptop screens or phones.
The only decent justification I’ve ever seen for non-participatory meetings is morale, especially for all-hands’ meetings. Atrium did a pretty good job of keeping the energy level in their all-hands meetings high and while there was lecture-style information transmission, that ultimately served the morale side by reminding people that other organizations were staffed by people just as talented and motivated as themselves. The key, to be blunt, is to remember that these meetings serve the audience and to keep them entertained. Reading quarterly sales numbers off of slides in perfect monotone with no questions or context is not sufficient.
Being receptive to feedback, from reports, managers, peers, and others is incredibly important to me. In fact, along with personal discipline (the kind that waits for the second marshmallow), being receptive to feedback is possibly the most important meta-skill in business, if not life in general.
I actively solicit constructive feedback and criticism from my reports. While almost all managers say that they want to run a high feedback organization, it is vital to realize that giving a manager even a small bit of critical feedback can be an absolutely terrifying experience for many employees, especially those on the more junior side.
This is why I go beyond passively accepting feedback and actively solicit it. Moreover, when I am given harsh but constructive feedback from a report, I ensure that it is clear to the report and the larger organization that I am grateful for the message and consider it a strong example of high performance.
While the factual basis of a piece of feedback may or may not be correct, it is an accurate reflection of the perceptions of the giver and the receiver should always give the giver the benefit of the doubt and try to understand the reasons for the feedback and best approaches for resolving any underlying issues. There will be a much longer post about this soon.
One trait in common amongst nearly every individual with a performance issue that I’ve dealt with is some inability to receive feedback. As soon as they begin to hear something constructively critical one can see the wheels in their mind begin to turn to formulate arguments against the feedback. Do not do that. It will not succeed and all it will accomplish is discouraging future feedback. Assume the feedback has a kernel of truth and seek the underlying issue and work on a mutually acceptable course of actions to resolve it.
I’m far from an expert on recruiting. However, I have one practice which according to recruiters I’ve worked with is pretty rare. If an interview isn’t going well, especially an early screen, I will cut it short as respectfully as possible and explain to the candidate the gap between our needs and my perception of their capabilities. I also remain open to the candidate explaining this gap away, although in practice I have never seen that succeed. If a decision is made to pass after the candidate leaves the office, I am also willing to discuss that gap in a quick phone call if asked. Universally candidates express gratitude for the honesty and for saving their time.
Also, I am brutally honest when a candidate asks a question like: “why shouldn’t I work here?“. Ironically one time my manager overheard this and criticized me for being too negative. The candidate, who was a great hire, later told me that my honesty was the reason he took our offer over more lucrative offers from much larger companies.
Note: while the factual basis here of this feedback was wrong, the kernel of underlying truth in the feedback was a perception that I was perceived to be negative and a potential drain on morale. This kernel was correct and something I needed to act on, as described above.
All changes in an organization’s processes should follow some established process. The paradox of change is that diktats from the executive suite or management generally drain morale and are lacking in information held by the stakeholders affected by the change but single person decision making is often the only way to avoid paralysis by committee.
My preferred approach, and credit to the CTO of Atrium for introducing this in a very effective way, is the Request For Comments (RFC)
Someone, literally anybody in the organization, drafts an RFC, including:
With this approach, all affected stakeholders gain transparency into the reason policies are being adopted and documentary evidence of their voices being heard. Quite often, one or more individual will not get what they want in any given change. But, when people know their voice was heard and see explanations for changes, even for those who didn’t get what they wanted, the effect on morale is exceptionally positive.
Company processes and policies should be strong, rigorously followed and very easy to change. There must always be room for exceptions with the conditions for those exceptions recorded in the company handbook. Also, those policies are universal, they apply to the CEO as much as the intern.
All the policies of an organization should be written somewhere commonly known and accessible. The Gitlab Handbook is a brilliant example of this. When a manager is confronted with a situation not covered by the handbook, the handbook should be updated with the resolution for that issue.
(will be the focus of a future post)
Engineering Specific Principles:
If you are a vendor or recruiter who intends to send me an unsolicited email, please note that putting the word “ikigai” in the beginning of the subject tells me that you have read this whole piece and I will read and reply to your message ASAP.