Curb your exhaustion
Over the past week, I’ve spoken with several people who are all feeling and dealing with exhaustion at work. I also have had a lot on my plate recently and am currently dealing with managing my load. On top of all this, we are all trying to deal with the pandemic and it is unsurprising that we are feeling exhausted. To cope, I am attempting to curb my exhaustion.
The spectrum of exhaustion can stretch anywhere from starting to burn out all the way to total burnout. I’m no expert on the subject but these are some of the things I’ve heard from others and seen in myself in starting to realize that I may be heading in that direction:
- Loss of motivation to do work
- Personal relationships remain unattended
- Dreading going to work the next day
- Low energy to do anything else
- Continually working late into the evenings and weekends
It is important to acknowledge and realize we are all human and have limits. Pushing too hard at something pushes us towards our limits. It is not sustainable to stay operating at that intensity indefinitely. Either you will crash, or you will have to stop or slow down to prevent the crash.
We live in a society (mileage may vary depending on where you live) where putting everything into work is often heralded. Start by Resetting that mentality. It is okay to slow down. While there is no substitute for rest and you should eventually rest, here are some things I’ve done to try manage my current situation and exhaustion:
- Taking a day off here or there. Mondays or Fridays are best as they get you a longer weekend and more time to recoup
- Ruthlessly prioritize, stop doing things and communicate that you won’t be doing those things. Personally this helped me a lot. There was a non negligible level of exhaustion coming from thinking about the insane to-do list I had
- Delegate as much as you can
- Create a regular exercise routine and stick to it
- Talk about it with others you trust
- Turn off anxiety provoking notifications. E.g. Slack reminders, daily to-do list updates
- Slow down wherever you can
- Remember you can’t do everything and that’s OK
- Book a week or a long duration of time off in the future and take that time off
In the end you need to eventually rest so whatever you do, ensure there’s an eventual path to get to rest.
February 27, 2021
Maintaining an exercise routine this past year has been quite difficult. We are all stuck at home and the lines of separation between home, work, exercise, and socializing have become very blurred. There is no longer an office you go to work or a gym that you get to work out in. Instead, we all have to make our homes our offices and our gyms. Creating and sticking to habits in this environment, I’ve found, to be challenging.
Prior to the pandemic, I was an avid “exerciser”. I went to the gym about 3 times a week and played both basketball and soccer. Being part of leagues, playing sports and having a gym routine where I exercised either before work or after the work day prior to heading home made it easy to do. Being stuck at home on the other hand has presented challenges trying to exercise and keep a routine.
Similarly, sticking to a work routine has proved trying. The temptation to work more hours than usual due to being stuck at home, or to go back and solve that thing that you weren’t able to but that keeps nagging at the back of head. The delineation between work and home no longer exists.
In reconciling these challenges and creating new habits I should stick to in the pandemic, I realized that the same simple strategy I apply when creating habits that stick as a leader have helped me become better at keeping these habits and that is to reduce inertia.
Decreasing inertia is critical to successfully make a habit stick. In my one on ones, I employ a similar tactic to ensure the variability of one on ones. Besides the regular one on ones, I schedule monthly career goals check in, and quarterly retrospective discussions in place of them in the schedule. By having these on the calendar, when they arrive, both myself and my report know and are reminded to have the necessary discussion.
Compare this to a situation in which the onus to have these discussions is on me. I could be tired that day and forego the conversation because I’m not up for it, or I simply could forget to do it. Even if I’m not up for it, my report is expecting us to have it and so we do.
I applied the same principle to my work and exercise. For work, I use an office space separate from my room in the apartment that I go to every morning. When I’m done with my day, I walk away from that space never removing my laptop from that area. If I’m tempted to keep working, I need to go back to that space. This added inertia has prevented me from doing so. With exercise, I’ve used the same calendar approach as my one on ones. Blocked out time and calender reminders to exercise have been a great forcing function to actually do so.
If you are ever trying to create a new culture or habit on your team or in your personal life, start with the question of what’s the inertia and build a solution that reduces it.
February 20, 2021
Provide requirements not solutions
Being an engineering team that serves internal customers comes with its ups and downs. One of my biggest pet peeves on such teams is the task of customer requirement gathering. While I can’t speak for non-infrastructure, non-internal development teams, this pattern is highly prevalent on internal teams serving other engineers and technical staff at a company.
It usually goes this way. A customer using your systems has additional requirements or needs that they would like met in order to accomplish a goal. The customer proceeds to communicate this to you as something along the lines of “System X needs to implement feature Y so that I can do Z. Oh, while at it, you should add feature R and fix bug Q that’s been slowing us down”. In the most extreme of cases, you get sent a technical specification detailing features and modifications you should make to the system; diagrams included.
Unfortunately, the biggest challenge you then face, is that you don’t understand what specific problem the customer is trying to solve. You don’t know the exact requirements needed from your system. Sure the customer is presenting a solution to you but they don’t have the same depth or knowledge of the system. They are neither knowledgeable on all the design decisions and trade offs made nor are they typically able to propose a solution that gels with your current ecosystem.
This leaves you in a bit of a bind. It will take a long time to read through the document and understand the proposal. Similarly, it will take significant time to consider the impact of their new feature suggestions on your system. However, you can’t tell them no because they’ll ask why and you don’t know exactly why. You are frustrated that this happened yet again, but eventually suck it up, go through their requests and formulate a response.
Deep down though, you wish they’d tell you what problem they’d like to solve and then give you the opportunity to design a solution that solves it. “We are trying to build this new feature and will require data X,Y,Z from our service. We’ve got an SLA to meet and so need at least an RPS of Q. Per our current tests, our current service infrastructure seems unable to support that. What do you propose?”. That, right there, is the dream. Having grasped their requirements, you’d go ahead and either propose changes needed to your systems/infrastructure or explain why their request is unfeasible.
Instead, you end up going back and forth on their feature request(s). You discuss the details, and the trade offs. You explain and provide more context on your current system and then rinse and repeat. Finally through this dialogue, you grasp what their needs are and provide a possible solution. However, you are both frustrated, and have both spent a lot of time getting to this point. It could have be better.
Why does this happen? Why do attempts to be helpful end up this way? In most cases, the engineer that made the request is trying to be helpful. But, in their attempts to be helpful, they make things worse. I think that situations like this are very common among collaborating engineering teams because of what I like to call the expert fallacy, but that is more commonly known as the Dunning-Kruger Effect.
In the case of the solution provider, this boils down to a little knowledge leading to overconfidence. The phenomenon is best illustrated in the graph below in the difference between an expert and someone that is moderately acquainted.
The mismatch between what people in the Young category think they know versus what they really know is huge. As they believe that they know a lot, they don’t hesitate to provide solutions. I think this happens a lot in engineering because we all fundamentally do similar things: we all code, and build software. This makes it easy to assume we have a good handle of other’s systems. A good enough handle to tell them how it should evolve to meet our needs. Unfortunately, the receiving party of our proposed solution is typically an expert of the system. The expert sees all that is unknown and shudders inside.
How then do we prevent this scenario? I think there are two improvements that can be made on both sides. Firstly, to get better at dealing with customers that propose solutions, harness the skill of asking follow up questions. Focus on understanding what the underlying customer need is so you can propose a good solve. Harness your inner product manager and remember articulation of needs is hard.
On the flip side, if you are requesting changes to a system you neither own nor understand the nitty-gritty of, provide requirements for what you’d like and not solutions. Get better at articulating exactly what you need and leave the proposal of how to solve the need to the system owners. This will save the time of everyone involved and foster a good relationship between you all.
No one goes to their doctor and tells them what to do. Why then do we do that to other engineering teams? Because WebMD came along and we all now think we are “doctors”…
February 3, 2021
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:
- Gap instinct
- Negativity instinct
- Straight line instinct
- Fear instinct
- Size instinct
- Generalization instinct
- Destiny instinct
- Single-perspective instinct
- Blame instinct
- 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.
January 31, 2021
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.
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?
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.
January 20, 2021
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:
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.
January 14, 2021