When it comes to the subject of one-on-ones, there is plenty of material available advising on everything from the best questions to ask in one-on-ones to how often to have them. What the vast majority of these literature focus on are one-on-ones that you have with others. From your manager, to executives and your reports. There is however, less focus on a simple but powerful reflection tool that you can use and that is the self one-on-one which I explain below.
What is a self one-on-one?
It is difficult to truly define what a one-on-one is so I’ll borrow a definition from wideangle which I like and is vague enough to cover the plethora of other definitions that exist.
The fundamental reason One-on-One Meetings exist is to give a platform to the direct report to allow them to communicate to you.
Applying this same definition, a self one-on-one becomes
The fundamental reason self One-on-One Meetings exist is to give a platform to you to allow you to communicate to yourself.
Why should you do self one-on-ones?
We have one-on-ones with others because they are useful. They help in career growth, spreading of information and holding of accountability. Similarly, self one-on-ones help with these except for oneself. Self one-on-ones also provide structure/process for the reflection time you may already be blocking out of your calendar regularly. How often do you get to reflection time and are unsure what to think about?
Principles for self one-on-ones
To successfully use self one-on-ones, apply the same principles you use in one-on-ones with your reports to yourself. A few examples are
- Do not skip self one-on-ones
- Self one-on-ones occur every X weeks
- All self one-on-ones have an agenda
- Notes are taken from self one-on-ones
- Self one-on-ones have a schedule balancing career growth, status updates and well being
- Self one-on-ones have action items that are followed on
- Go on a walk with yourself if you do walking one-on-ones
- Whatever other principles you have for one-on-ones
As you start self one-on-ones, it will be awkward at first; Posing questions and talking to yourself. After a while though, they feel normal and help you focus on your own personal growth and well being.
January 9, 2021
Don’t complete their thought
I’ve recently been thinking about why listening can be very difficult. One aspect that always comes to mind, a practice that is exceptionally difficult to give up, is the tendency to finish other’s thoughts. Here’s some similar scenarios to illustrate:
Meet Alice, a senior engineer on a team and Bob a recent addition on the team.
Bob: Hey Alice. Got a sec?
Alice: Sure Bob. What’s up?
Bob: I was trying to use system X and I run into problem Y. I …
Alice: Oh, must be issue Z? That concurrency bug surfaces from time to time.
This can go one of 2 ways. Either, Alice is on the money and has helped Bob figure it quickly.
Bob: Oh! Right! I hadn’t thought about that. Why is that?
Alice: My pleasure.
Or alternatively, Alice is off the mark:
Bob: I don’t think so. I’m seeing more of issue A.
Alice: I see. Must be the installation ordering!
In both these cases, Alice quickly concludes what issue Bob might be facing. With her wealth of experience on the team and deep knowledge of the systems, she is able to usually have a good idea what the issue is. However, in both cases, Alice unintentionally doesn’t allow Bob to complete his thoughts. What else could Bob have said about the issue? He, for instance, could have elaborated on the steps he had taken so far, and how he went about trying to figure out the issue. All this information could have given Alice more context and a better opportunity to coach Bob as he ramps up on the team even better. It also could have fostered more relationship building between them. Unfortunately, this doesn’t happen.
Cases such as this are very common. Let’s look at Juan a manager and Neda, an engineer that reports to him:
Juan: Hey Neda! How’s the project going?
Neda: The project is coming along well. I do have some reservations on it’s value to the company. It…
Juan: What aspects are giving you reservations?
Neda: The project will take Y months and at best generate Z in revenue. I…
Juan: That sounds pretty decent to me. This project has been a long time coming and will have impact around the company beyond revenue. It will…
Juan does a good job trying to understand the problem a bit better at the start asking a clarifying question. However, when he gets a whiff of what he thinks the issue is, he quickly jumps to address it, attempting to complete Neda’s thoughts.
Unfortunately, it isn’t possible to truly know what another’s thoughts are. We simply cannot (yet) read each other’s minds. If we don’t let others finish their thought, we risk souring the conversation and/or relationship: whether that means the other person has to correct us and redirect the conversation or that the other person resorts to not voicing their opinions.
We all have busy schedules and want to be efficient in our conversations. As leaders, we often are having similar conversations with many different people. So much so, that we usually know what the person is “getting at”; it is very tempting to make the connections! The crux though, is that when we guess wrong, it can be disastrous.
So the next time you have the urge, pressing as it may be, to complete someone’s thoughts, hold your tongue. Let them go over what they think even if you’ve heard it all before. Before you respond, ask yourself, have they finished their thought? Are you about to complete their thought because you think you know what they are getting at? Don’t respond until they finish. With all the context they give you, give them that great response! They will appreciate you for it. If you really must, and can’t fight the urge, count down for 5 seconds of silence or try asking a clarifying question instead.
January 3, 2021
Managers should code, but not at work
Should managers code? This question doesn’t seem to have a clear answer. There are proponents and opponents to the debate, each having valid points on their side. I recently coded a side project at work and this led me to reevaluate my stance on this matter. Having gone through it, I can say, that my position has changed from managers shouldn’t code to managers should code, but not at work.
I have been managing engineering teams for a couple of years now and one of the things I did as I transitioned was to stop coding. The main reasons being, attempting to code on your team will make you a blocker to others on the team, there aren’t enough hours in the day to have all your meetings and one on ones as well as code, and it is important to demonstrate trust to your team by stepping back from coding.
On the flip side, as time passes and you aren’t coding as a manager, you get disconnected from your team. You slowly begin to forget what it actually is like to build systems and products. You find it harder to follow some of the team’s technical decisions. In the long run, this can lead in the worst case to a loss of respect from the team due to a lack of credibility.
This conundrum created by these two options leads to an everlasting conflict for engineering leaders. At its heart, is a tug-of-war between the manager and maker schedules. The manager schedule is comprised of continual context switching, moving from meeting to meeting. The maker schedule on the other hand, requires large contiguous blocks of focus time to create. As a manager, your job dictates you operate on the manager schedule but in order to code, you need a maker schedule.
Recently, I got to set up a meeting scheduler application for my team refactoring and deploying Yelp Beans on our systems. It was a ‘side project’ that I started working on during a work hack week and continued thereafter. It is now deployed and in use by the team.
I discovered a couple of things going through this experience. Firstly, I really missed coding and the feelings of accomplishment and success you get from building something, and from locating and fixing elusive bugs. I also realized that I was a lot more disconnected from my teams day-to-day than I initially thought: the nitty-gritty of our dev environment set up, and how we packaged and deployed our services. All in all, it seems that I should code more regularly so I can empathize better with my team.
I, however, noticed that working on this project had an impact on my managerial duties. In some one on ones, I couldn’t fully focus and listen to the subject at hand. At the back of my mind, I was thinking about my code: what optimizations I could make, how to squash the current frustrating bug etc. In the worst of cases, I “hijacked” part of the one-on-one to pair program.
While my team were great sports about it, I do not think it is a sustainable model. I found it very hard to context-switch from my code and to fully focus on meetings: The manager vs maker schedule strikes again. But I enjoyed the experience overall and do not think that fully stopping to code is great either.
In the end, I’m going to continue to code, but not at work. I need a clear delineation between being a manager and coding, so I can fully focus on my team and meetings.
December 27, 2020
I’ve finally decided to bite the bullet and start a blog. Though my hindrance to start was strong, I have discovered a greater impetus. Perusing through the web, I quite often find that I am reading a lot of posts that I find underwhelming. Granted, there is a lot of content out there, and some of it is good.
As I pondered the reasons I keep finding such blog posts, I came to a realization that it may perhaps be simply because a lot of people that feel the way I do, (naysayers?), don’t actually do anything about it. It is far easier to complain about the lack of good blog material than to actually do something about it. So, here I go, trying to do something about it…. Wish me luck
December 23, 2020