Preface
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 Role
My favorite part of my role is being a force multiplier for my team. This entails:
- Identifying blockers to productivity and output.
- Mentoring and establishing learning and development plans.
- Recruiting and team building.
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.
Performance
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.
What I look for in measuring performance
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):
- Output - Again, this is subjective and highly role dependent.
- Collaboration - Is the individual a positive or negative influence on the team? Do other team members find themselves “cleaning up after them” or this individual a reliable contributor. Does the individual communicate clearly and empathetically with the team? For senior individuals, do they actively foster an inclusive communications culture or let the loudest voices in the team drown out more quiet individuals.
- Learning and Development - Is the individual taking ownership of their development and following through on those plans? For more senior individuals, are they proactively supporting the L&D of more junior teammates.
- Feedback - Does the individual effectively give and receive feedback to others on the team, including to more senior members and managers.
- Fully formed adult - This is a bit difficult to explain and will be the focus of a future post, but the very brief summary is do they regularly blame circumstances or other people for problems instead of identifying actions under their control to improve a situation. The Obstacle Is the Way represents the mentality I want to promote.
No Surprises
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.
A note on Performance Improvement Plans
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.
Meetings - In person or over video
Early is on time, on time is late, and late is unacceptable.
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.
One on Ones
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.
Meetings have two justifications: (1) participatory, inclusive discussion and (2) morale. Nothing else.
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.
Participatory, Inclusive Discussion Meetings
- If they are recurring, begin with a review of previous action items (AIs)
- It is the job of the leader of the meeting, generally the most senior individual to solicit comments from every attendee. The goal is to find the best ideas, not the loudest. Furthermore, if someone has nothing to contribute, their presence may not be required. The exception is if they are there to observe and learn from the discussion, but this should be an intentional choice, not incidental.
- The meeting ends with establishing future AIs and directly responsible individuals.
Morale Meetings
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.
Communicating With Me
- I strive to maintain and expect my team to strive to maintain a 24 business-hour response time on emails. Note that this excludes weekends and holidays.
- Text Messages / Slack messages etc can always wait until EOD unless otherwise noted.
- If I’m not calling you, its not urgent or an emergency.
- Your phone should be on and able to receive calls during whatever business hours are agreed upon.
- If I am calling you unscheduled, it is urgent and should be answered or called back as soon as convenient.
- If I call you twice, it is an emergency. Pick up.
Feedback and Radical Candor
Kim Scott has said it better than I ever could. Read her book.
Feedback
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.
It starts at the top
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.
All feedback is correct
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.
Feedback in Recruiting and Hiring
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.
Meta Policies
Change Management
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:
- Statement of the problem.
- Proposed solution.
- Discussion of the alternatives.
- Identification of DRIs for all action items in the solution.
- Identification of required approvers for the RFC.
-
The RFC enters a public comment period where anyone affected can make comments, or even proposed edits on the RFC. Google Docs is brilliant for this.
-
If the RFC is approved by the necessary approvers, it becomes law.
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.
Strong Convictions, Loosely Held
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.
Handbooks
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.
Please note:
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.