Factfulness

I just finished reading Factfulness and absolutely enjoyed it. If you are looking for a new book to read, I cannot recommend this highly enough, especially in the current state of the world that we are in. The book delves into facts and figures, enlightening you on the reality that the world has been getting, and is much better than you think it actually is. It then goes on, similar to the style of thinking, fast and slow to describe 10 different “instincts” or ways our brains work that led us to believe the world is far worse off than it actually is.

What really stood out to me reading this book, was the applicability of the 10 instincts of factfulness to leadership, decision making and building technology. As such, I will start with an overview of the ten instincts in this blog post, covering the first, the gap instinct in detail and then cover the remaining 9 in 3 future posts. I’ll explain the instinct(s) and their relevance to leadership and engineering in each post. The book’s authors hopes are that increased knowledge and awareness of them will help us all avoid making overly dramatic evaluations and I hope these blog posts do as well.

As you read either the book, or these blog posts, keep in mind that we all share these instincts. We are all human and our human nature leads us to use these instincts. They are not a shortcoming but instincts we have evolved to have. However, the world we live in now is far different than it was hundreds of years ago. The instincts that served us well then, can inhibit us now. In understanding these instincts, we can use them to our advantage.

The 10 factfulness instincts are as follows. I’ve added links to the gapminder website which provides details on each:

1. Gap instinct
2. Negativity instinct
3. Straight line instinct
   
4. Fear instinct
5. Size instinct
6. Generalization instinct
7. Destiny instinct
8. Single-perspective instinct
9. Blame instinct
10. Urgency instinct

The Gap Instinct

The gap instinct is our tendency to divvy things up into 2 distinct groups, not realizing that most lie in that middle gap. In the book, the authors focus on our gap instinct to bucket the world into the outdated, so-called “developed” and “developing” countries. The authors then go to show that the majority of the world is actually in the middle and this gap instinct blinds us from both seeing and realizing that.

Reading about the gap instinct, I thought about how often this comes up at work. It really is everywhere! It is the fabled “them and us” mentality and is very common among us all. I manage an infrastructure team and a common challenge we face, is supporting the large and diverse group of customers we serve. Given their different and often differing requirements, we eventually have to make trade offs in forming a globalized solution to cater to the different customers. This pleases some and displeases others.

Usually, there are teams that want/have a localized solution they believe solves their problem. They have neither intention nor will they migrate to the global solution. Everyone else (them) just needs to move to their systems. Or, the infrastructure team (them) should leave them be, running their own system. The crux, and what made me chuckle, reading the book is that in most cases this is a small group and the extreme. A lot of customers are typically in the middle, and willing to make migrations provided they are made easier to do. It is however, very easy to, and I personally am guilty of of forgetting about everyone else in between. The heated discussions, and the tug-of-war with these teams not only blind us, they lead us to feeling continually frustrated, reinforcing this view.

It is therefore important that we remind ourselves of this gap. Take a step back and look at the entire picture: How many teams are glad to move, willing to move with some changes, or adamantly against moving. Are you so focused on the extremes that you are missing the middle? Should your strategy change to cater to this larger but often, less vocal group? The answer as always, is that it depends. However, knowing this reality should help you with that decision.

Apply this same methodology to other scenarios at work. In cross team collaboration, are teams bucketed into allies and enemies? Does that capture everyone? Is everyone on the teams in question really that way? Are you viewing your systems as either stable or in dire technical debt? Is this all your systems? Anything in the gap? You get the picture. When faced with two extremes at work, take a step back and ask, what’s in the middle.

To do something or nothing, that is the question.

As leaders, we are continually making decisions, deciding to and taking action on situations as they arise: What technology should the team use? Should I performance manage a report? Deciding what and when to do something is often one of the most critical choices we make: too late or too early will have ramifications.

While it is important to act, and we as leaders should have a bias for action, it is sometimes prudent not to. I believe taking a moment, even if just a minute to decide whether to act before doing so is critical. In this post, I’ll detail my approach to making this determination going over the four different buckets that I place each situation into.

Do Something

The most known and often exploited quadrant is do something. Any situation in this bucket can be regarded as one that requires you to take an action to resolve. When you decide to do something, the first thing to figure out is exactly what you are going to do with the expectation, that you will take this action. This could be to schedule a cross team meeting or to communicate a new process to your team. Items in this quadrant are often pretty clear based on answering:

• What is the impact of not doing anything?
• Does the situation get worse if I wait till tomorrow, next week, etc?
• Is it clear what must be done to remedy the situation?
• Are there company procedures to deal with the situation? What do they say?

Collect more Data

In this quadrant, your assessment of the situation is that it is important. However, you are not yet confident enough to take any action because there are pieces of the picture you are missing. Instead, you decide to either figure a way to or to get additional information on the situation in order to take action. For example, requesting metrics from a team member or reaching out to colleagues on other teams to understand how they are handling the situation. With this information in hand, you should be able to decide whether you will do something or do nothing. Ask yourself:

• Do I know how to remedy this situation?
• Do I know everything I need to know to take action? Am I confident or worried about taking the action?
• Should it be addressed urgently or can it wait for some time?
• Is there someone who may know more about this situation?

Wait and Watch

Wait and watch, similar to collect more data is a situation that you deem important but not important enough. It is something that you think you should get round to addressing but can wait. You keep watching the situation and reassessing in case its importance changes and it needs to move to another quadrant. From a prioritization standpoint, these are akin to important but not urgent. Ponder these questions for this quadrant:

• How long can I wait until the situation becomes damaging?
• Will doing anything right now make things worse?

Do Nothing

These are scenarios that you deem as requiring no action on your part. They are quickly forgotten about unless they resurface. Sometimes, items in do nothing are actionable but are intentional left undone in order to coach others or to test the team’s boundaries. To decide if to do nothing, ask yourself these questions:

• Do I have the time to do this? What happens if I don’t do anything?
• Is there someone else that can do it? Should I ask them to or leave it and see if they step up?
• How low is this on the priority list? Will I realistically ever get to it?

Any given situation will move between these quadrants until it gets to a final state of either do something or do nothing and should be reassessed as new information comes to light.

Learning to notebook

I’ve decided to improve my overall knowledge of machine learning. I work in the data space and while my work thus far has been focused on building the infrastructure to ingest, store and analyze data, it hasn’t covered machine learning. With the current industrial trends in the space, I’d be doing a disservice to myself to not become knowledgeable on the subject.

I am also a sucker for learning new things and being good at using Jupyter notebooks is a good, fun starting point. My goal will be to get to a place where I know enough to understand what is going on with machine learning teams but not to the expertise of a machine learning engineer.

What’s my plan to get there?

I don’t fully have one yet. There’s a lot of material available advising what one should do. For starters, I’m not going to bother with Kaggle. I appreciate Julia Evans’ post on the subject. My superficial understanding, is that doing Kaggle is akin to being good at passing problems on project euler. While they are fun problems to solve, being good at them doesn’t necessarily translate into being good at either programming or machine learning.

Instead, I decided to check out what is being taught at my undergrad university. Looking at it, things have really changed in the CS syllabus! When I studied there (2010-2013), machine learning was a part of the AI course and there wasn’t much emphasis on doing any practical work. Now, its a core part of the curriculum!

So, my path is going to be to start with the courses listed below and see how it goes as I’m familiar and comfortable with the Cambridge style of teaching. I especially like the emphasis they are placing on using python notebooks. The order of what I’ll be going through is:

• Scientific computing - this is jupyter notebook 101
• Machine Learning and Real world data
• Data Science - Seems like a good recap of the maths that I likely will mostly skim
• Data Science principles and practice - It’s the follow up to the first data science course
• Machine Learning and Bayesian Inference

Am I really starting from scratch?

Probably not. I know python well and I got about halfway through Andrew Ng’s course (perhaps I’ll come back to this) years ago though I’ve forgotten most of it. I have also learned a lot of the fundamental maths at play: Linear regression, probability, SVMs and neural networks while I was at university. Though I’ll require a refresher on a lot of these, it’s not the same as learning anew. Overall, I hope to do most of my learning through practical implementation.

So here we go. Stay tuned for posts as I go through this. They’ll show up under the learning tag.

Self One-on-Ones

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

1. Do not skip self one-on-ones
2. Self one-on-ones occur every X weeks
3. All self one-on-ones have an agenda
4. Notes are taken from self one-on-ones
5. Self one-on-ones have a schedule balancing career growth, status updates and well being
6. Self one-on-ones have action items that are followed on
7. Go on a walk with yourself if you do walking one-on-ones
8. 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.

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.
etc.

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!
etc.

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.

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.