Thing 1: Trashing Culture

While walking in to work a few weeks ago I saw an employee of a vendor throw his trash at the trash can. Note the phrasing “at the trash can”, since this individual did not succeed in their simple endeavor of properly disposing of their rubbish. And this individual had no choice but to know they failed: they watched their trash miss the bin from 2 feet away.

For those still trying to catch up, I asked AI to depict the scene for me:

The trash was on the ground, and they were walking away as if that was OK.

Now, I had a few options:

1. Accost said contractor, pointing to to evidence, using all sorts of hand waving and “trash belongs in the trash can”-style phrases
2. Quietly double back and put their trash in the receptacle and avoid conflict
3. Do nothing, and hurry on to my desk

Now, stunning revelation, I did #3 and looking back on it I don’t thing it was the right choice. There are many reasons I did nothing (I was late, the trash was improperly trashed in an area I did not have access to behind a fence, it was cold…). But at the end of the day someone trashed my workplace and I did nothing.

This story got me thinking about the concept of culture, and a few lessons stand out:

• Culture is the product of what we do AND what we allow to happen. In this example, I wasn’t the one who did anything wrong, but I allowed it to happen and therefore someone now thinks it’s OK to throw trash on the ground at Delta Air Lines.
• In thermodynamics, entropy (aka disorder) cannot decrease without the use of energy. Restating, order requires an energy injection. In a company, culture requires energy injection. Energy to care, energy to sound the alarm, energy to go to the happy hour, energy to do more than the minimum required….In my example, energy to confront the person who was increasing disorder
• A rhetorical question: do you have the courage to be a culture keeper? If you saw someone doing something that is against your culture, would you say something? Would you think “I can’t believe that” but let it happen?

Thing 2: The Village Wine Cask

The topic of culture reminded me of a good anecdote to share about why your contribution matters, no matter how small. I have shamelessly stolen the content below from here.

A triumphal feast was scheduled in a village and, in order to ensure that all might enjoy in the feast without imposing upon any few, the villagers all agreed each would put one bottle of his best wine into a great cask for the occasion.

However, upon reflection, one villager reasoned that, if he filled his bottle with water, the dilution would be so slight, no one would notice.

So, the day of the feast arrived, and the great cask was tapped and wonder of wonders…nothing but water poured forth!

Every villager had reasoned alike – my contribution isn’t big enough to be noticed!

Thing 1: New Years Resolution Reminders

Every year on January 1st my wife and I do a ‘state of the union’ where we review our prior year against our prior year goals and set new goals for the upcoming year. We have categories like health/wellness, finances, socializing, the kids, trips, etc. The goals can loosely be categorized into habit building (read every night before bed) or one-off actions (take a course on AI). A few from my 2024 goal setting:

• Do skincare and probiotics every day
• 2 Duolingo lessons per day (almost 600 day streak with 2 kids under 2, not bragging but…je suis tres bien a francais)
• Write 12 blog posts (crushing it)
• Work out 3x/week even if its just 20 minutes
• Go on a date once per month out of our house
• Daily journaling/gratitude

Beginning-of-the-year me is always excited and ready to take on the world. Then work starts again, and the kids need to get to daycare, and families are visiting, and we also need to see friends, and then all of a sudden these goals hit the back burner until next year.

This year we are trying two things to keep our goals top-of-mind:

• Scheduled quarterly reviews - these are already on the wall calendar so we can’t forget, we will review the prior quarter and review what we wanted to accomplish and our progress. We will also probably realize that we want to remove some or add different ones because a lot can change in 3 months
• Physical reminder cards - I typed out a table of daily/weekly/monthly/general goals for myself and my wife, printed them out, and laminated them. They are in our bathroom next to our toothbrushes and are there to remind us of the things we should be doing. The hope is that simply having the goals visible in a daily traffic area will remind us enough that they become second nature to act upon.

Stay tuned for the update after our first quarterly 10-Q.

Things 2: The most important financial metric for our family

As part of our aforementioned goals, we do a financial review of the prior year. I diligently track every cent in to and out of our accounts in a custom-built app I’ve made. The challenge is that with so many numbers things can get overwhelming to track: we spent less in category X but we had to get a new roof but it also was a good year for stocks but groceries are more expensive….

The simplify, we care primarily about one north star metric: net income ex-investment returns (NI-exInv). Even better, we look at this as a percent of ex-investment income (NI-exInv%)

The formula for the number is: Total Income - Investment Income - Total Expense; for the percentage you then divide that by Total Income-Investment Income. All of our income is considered post-tax only.

This is our north star metric because it tells us how far below our means we are living, while factoring out the volatility of our investments (primarily stocks). For example, for an example total income of 100k, expenses of 60k, investment returns of 30k, you may look and say ‘wow great we made 40k this year because we made 100k and spent 60k’, but in fact 30k of that was driven by investment returns so in reality you are only living 10k below your means.

Over the past 30 years the SP500 has averaged 11.7% return (non-compounded), and in only 5 of those years has the actual return been within 5% of that number. Stocks go up and stocks go down, and most of us are buying stocks as a long term investment. Therefore, those investments should only be evaluated long-term, rather than caring about the volatile annual returns.

Our target NI-exInv is 35%, meaning on average we want to spend 65% of our ex-investment income and save 35%. This gives us cushion monthly for larger expenses while also allowing us to invest in our future.

The forgotten feedback loop

Many work environments generally function in the following fashion:

• Work is ingested in to a team’s backlog and prioritized against all the other things going on, usually by leadership
• People are assigned items to work on, or people pull items that are at the top of the backlog when they have bandwidth
• Various ‘ways of working’ things happen: team meetings, daily check-ins, broader-team meetings, 1-on-1s with the leaders, interact informally with one another, help each other with little issues, etc.
• The team creates work products: reports, meetings, emails, analysis, content, etc.
• The customers of the work products provide specific feedback on the work products. That feedback either gets handled immediately (change this slide…done), or gets re-ingested into the team’s backlog and re-prioritized
• Repeat until retirement (feel free to go start your own company if this makes you unhappy)

Consumers of your team’s work usually can provide solid, tangible, understandable feedback. This report is wrong. This dashboard is too small. The excel sheet needs these changes. Boom, I can go work on that, I understand it, etc.

The catch: that work product feedback will be processed through the same work process that produced the initial work product. Something seem wrong?

Feedback on how the team delivers work is often forgotten, whereas feedback on the work a team delivers is readily available.

Oh yeah…no one took the time to provide feedback on how the team is delivering their work, aka their work process. This massive input to team work quality/pace never receives dedicated time for a few reasons:

1. There’s no report to critique, no powerpoint deck to slander, no tangible item to discuss; conversations about the intangible are mentally draining
2. Talking about how you produce the work you produce sometimes feels very meta and abstract
3. It is hard to specifically articulate what the team’s work process is in order to improve/critique it
4. Team members have probably been burned in the past by having their suggestions be praised-then-disregarded (”we should try X” → ”wow great idea” → trash)
5. Team members are not confident enough/secure enough to share what they want with their team; they do not want to impose their preferences on others

Regardless of the challenge, it is imperative to collect feedback on the work process.

The definition of insanity is doing the same thing over and over and expecting a different result - Michael Scott

Odds are your team has had at least one person turn over just in the last 6 months. When that happens, team composition changes, and the ideal way of working also changes. Implementing a work process feedback loop enables you to catch the team’s changing composition and adapt the team’s process to the new group.

Will every bit of feedback be productive and useful and meaningful? No. True story: as an Agile Coach one of the teams I coached has their sprint retrospective and the feedback that got the most traction was, “I don’t want to toss the nerf ball to signify who is talking”…

All you can do is turn on the feedback loop and set the team up to mold their work process to their specific way of working.

Good feedback: 50% productivity boost

We are going to go through a hypothetical to prove (or disprove) that feedback can be a productivity boost.

Let’s say your team’s objective is to produce a 100-unit ‘widget’, and your team works at 1 unit per day; the widget requires a minimum of 100 days of work for a perfect team.

However, your work may not directly drive towards the desired end state. There are many inefficiencies that can cause a team to produce work that is not perfectly aligned with the desired direction:

• Inefficiency in vision: the customer does not actually know what they want
• Inefficiency in communication: there is a breakdown somewhere between the message the customer wants to communicate, the words they say, the words you year, and what you interpret the message as
• Inefficiency in delivery: the actual execution of work deviates from what should be created

Restated: a perfectly efficient team will take 100 days, but your team may take 130 days. A different team may take 200 days. What contributes to the difference?

Team work throughput is definitely a major factor: if a team can produce 2 units per day, that is obviously better. Another important factor is output direction, or how aligned your teams output is with the desired direction. And the major contributor to direction: early and often feedback. Providing/receiving feedback limits the percent of work that is unproductive; if you understand the vision and changes, you’re better able to produce work aligned with that vision.

A mathematical model of this scenario assumes that your teams output can be somewhere between perfectly productive (100% in direction of widget) and perfectly unproductive (100% sideways), or even some small percent counterproductive (backwards). In our simulation, we will test 6 levels of feedback, with each level producing different amounts of productive output depending on how good the feedback is.

I ran 500 simulations for each feedback quality, with each simulation representing a team’s journey to produce the 100-unit widget. The team randomly samples a productive percent each day, and continues until they reach the goal of producing 100 units of productive work. The results are quite interesting.

• Shocker of the century: channeling more of a team’s work into a productive direction makes that team produce the correct output quicker. Like and subscribe to my blog for more ground breaking analysis!
• It is surprising how much throughput is required to compensate for poor feedback: Counterproductive/bad feedback slows the team by ~4.5x, so 4x throughput is needed to deliver the correct output in the same time as a normally-paced team with good feedback (112 days)
• Which is easier: increasing throughput by 50% or giving/receiving good product feedback? Because 1.5x throughput is roughly equal to great feedback (105 days)

The obvious caveats aside, it’s clear to see that good feedback can produce more productive teams. How do you give that good feedback?

Ryan’s keys to feedback

Last year I took 7 leadership courses…so you could say I’m pretty well versed in the bulleted list of ‘how to give good feedback’. The list below is from my own experience, not a leadership course, so I think it’s the best one out there.

• Time-sensitive: If I use a lot of filler words, tell me that day, ideally shortly after the presentation. Otherwise, the moment is lost.
• Correct mindset and context: The feedback receiver must be ready to receive feedback (try saying that 5 times fast). This means they must be in the proper mindset, open to receiving feedback (not everyone is at all times), and in the proper environment.
• Generalizable with specific examples: Patterns make the world go round; they allow us to handle unexpected/unforeseen. When giving feedback, tie it to a generalizable pattern and give the specific examples that violated that pattern. This helps the receiver connect the specific feedback to new future scenarios.
  • Example: A slide deck has too many colors
    • Pattern: simplicity helps people understand things
    • Examples: slide 4, 5, 6 used 10 different colors, which distracted from the overall message

One last point: when soliciting feedback you must act upon it or never receive feedback again. Consider the following scenario:

• A coworker or leader says “I’m always open to feedback, stop by whenever, open door, drop on in, pals…”
• You think the team would function better if a change was made to how the team schedules work, so you stop by their office and share that with them
• Since you provided the feedback in a time-sensitive fashion, in the correct context, and with specific examples that are also generalizable, they received the message 100% (great job!)
• Nothing happens.

You are not going to suggest anything to that person again. The lesson: feedback solicitation without action leaves a bad taste in mouths and shuts down any future feedback. A lose-lose.

The problem: Python on different computer types is challenging

Python’s initial learning curve is very low, but there are many unfortunate complexities when you move from print(”Hello World”) to projects shared across teams across computers and across time.

Dealing with the ‘sharing across teams across time’ problem has more-or-less been solved with git, where you can see the history of a code file, who has worked on it, and what changes they have made and why. The ‘sharing across computers’ is a problem that is much more challenging to solve due to the reliance on environments.

Environments allow users to install different versions of Python and different versions of packages from Python’s incredible ecosystem. An example of when this is useful: I am working two projects, one requires pandas v1.4.2, the other requires pandas 1.0.0; a separate environment for each project allows me to work these simultaneously. Issues with package versions typically do not arise during a relatively short project, but code written months or years ago can have serious package version issues if updates have been made since it was last run.

Environments can be documented and shared in a few different ways; in conda you use this method. The method makes it relatively easy to recreate an environment, but it does not address the differences in computer architectures. I recently ran into a problem where an environment I created on my Windows 64bit computer failed to install on a Linux Python server. I had to manually comment-out the failed packages and install the Linux versions…annoying.

The outcome: Repeatable, 100% shareable Python code for analytics and data science projects

How to solve the architecture problem? Docker! Docker allows your computer (actually any computer) to create containers that make code 100% repeatable no matter where its run. In english: Docker makes every computer seem like the same computer, so code written inside a Docker computer can run anywhere Docker can run.

Docker has a pretty steep learning curve, but there is a quick way to get set-up to start developing your Python code in Docker!

How to run Python files inside a Docker container in VS code

0. Ensure all applications are installed

You’ll need:

• Docker Desktop
• Visual Studio Code
• (Optional) a git installation for sharing your code and environment specs; I use GitHub

1. Install the “Remote - Containers” extension in VSCode

I’m going to plagiarize the extension, since it explains its value proposition better than I can:

“The Remote - Containers extension lets you use a Docker container as a full-featured development environment. Whether you deploy to containers or not, containers make a great development environment because you can:

• Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to.
• Quickly swap between different, separate development environments and safely make updates without worrying about impacting your local machine.
• Make it easy for new team members / contributors to get up and running in a consistent development environment.
• Try out new technologies or clone a copy of a code base without impacting your local setup.”

2. Add container specification files to folder

In the folder you want to open in a container (aka your project folder) you can use VSCode to create the necessary Dockerfile (specifying the development environment) and a devcontainer.json files (specifying the VSCode interactivity with the development environment).

• Ensure VSCode has the proper folder open; it is going to add files to the top-level of the open folder
• In the command pallet (Cmd+Shift+P) click the “Remote-Containers: Add Development Container Configuration Files” option

• Select your preferred Python configuration - I used Miniconda (Python 3)

• Select your Node.js version (depending on your use case this may matter)

• Select any optional add-ins you may need (I did not select any)

And voila, VSCode will generate the necessary file structure in the folder. You’ll see the Dockerfile and devcontainer.json have been added. I’d recommend reading through their contents since you can customize a lot more from the default values they provide you. Versions of these files from my experimentation are here.

3. Open the project folder in the container

Now that you’ve specified the development environment, you have to re-open the current folder within that environment. To do so, execute the ‘Open workspace in container’ command and browse to the current folder (that has the .devcontainer folder within it):

This will re-launch VSCode and start the container process. You’ll see a notification in the bottom right that this is happening - if you click ‘show log’ you’ll get much more information that should look like this:

You can follow along, but I want to highlight the blue text - this is actually the step that executes the Dockerfile. You can open the Dockerfile and see the one-to-one match of the steps to the commands in blue.

And there you have it - you are ready to write your code in a clean Docker Python environment! You can start writing .py files or .ipynb files, installing packages via conda or pip in the terminal, and running your code.

How to share your Docker environment

It’s one thing to develop your code inside of a container, but one of the main reasons you want to do this is so others can execute your code without any worry about packages, computer type, chip architecture, etc. This method defines the container using code in the Dockerfile, so it’s fairly straightforward for others to replicate it - all they need is the Dockerfile and the specifications of the Python environment.

Save your Python virtual environment to an environment.yml file

With your environment activated, in the terminal type

conda env export --file environment.yml

This will create a file environment.yml that includes the entire package specifications for the currently activated environment. An example of this file is here.

Ensuring your environment gets installed within Dockerfile

The last thing you need to do is ensure the code in your Dockerfile that installs the Python virtual environment is uncommented. The lines you need to uncomment are:

COPY environment.yml* .devcontainer/noop.txt /tmp/conda-tmp/
RUN if [ -f "/tmp/conda-tmp/environment.yml" ]; then umask 0002 && /opt/conda/bin/conda env update -n base -f /tmp/conda-tmp/environment.yml; fi \
    && rm -rf /tmp/conda-tmp

This little snippet copies your recently-created environment.yml file to the container, then executes a conda command to install the required files into the container’s base environment. The container’s base environment ends up having the same packages as the environment from which the conda env export –file environment.yml command was run.

And, now your Python code is 100% Dockerized, and whomever has access to your Python code and the contents of your .devcontainer folder will be able to open the folder within a Docker container (step 3) and run it simply!

This post is part 1 of an unknown number of posts I make while reading “Software Engineering at Google: Lessons Learned from Programming Over Time”. It will be based on a hybrid of the best practices from the book with my own knowledge, and will be applicable primarily to non-software engineers (sorry SWEs, you can just read the book).

The parallels between software engineering and your job

The fundamental goal of a software engineer (SWE) or team of SWEs is to create software that produces value for their customers. The key point is that a software engineer’s Product is software but their end state is being a value-add to their customers. The engineering portion of software engineering relates to the culture, processes, and tools to deliver the software (deliver the value).

There are probably a multitude of ways you deliver value to your customers: for the sake of this post (and subsequent posts) I will address these methods of value-delivery as your capital-p Products. These Products are all the things you do and deliver that justify your existence in a company. And following the same logic as above, the culture, processes, and tools to deliver your Products can be considered the engineering portion of your job.

Software engineering: Many people working together to produce, improve, and maintain software over time

The key distinction the book makes between programming and software engineering comes from two dimensions: duration and scalability

• The duration of a programming task is short; write code so that it runs, then move on. The duration of software engineering is long; write code that can exist, be improved, and be maintained over years, maybe decades
• There are no requirements on scalability of programming task; it can be localized to one person; software engineering requires team scalability in addition to technical scalability (infrastructure, CPUs, etc.); rarely will a software engineering task involve only one person

Because of these differences in duration and scalability, there are differences in the tools, processes, and culture required to best deliver value. You can no longer think just about issues from a programming lens; you must instead think about software engineering issues.

A non-technical version: Many people working together to produce, improve, and maintain Products over time

If we replace ‘software’ with the generic ‘Product’ described above, you can see how the problem sets significantly overlap. You and your teams face a very similar set of problems as software engineers:

• Your Products will have some usable lifespan, and over that time your Products will need to be improved, maintained, deprecated, discontinued, replaced, etc. How you engineer your Products will determine how challenging it is to manage that lifecycle.
• Your Products will be worked on by many different people over this time due to inevitable turnover on your team. The way your Products are engineered will have implications on how easily they scale across people.

Given overlapping problems, you can learn a lot about how to improve your Product/time/people relationships by studying the best practices of software engineering.

Be cognizant of tradeoffs, especially speed vs scalability

Tradeoffs are inevitable, but you should be transparent in your decisions and strive for a culture where changing a decision due to new information is accepted as a best practice. One of the primary tradeoffs to think about between going fast and building for the future. Consider two teams addressing a need:

• Team 1 is focused only on getting the Product out the door, and therefore works in silos, does things manually, does not document how they got to outcomes, and is very dependent on one or two people
• Team 2 understand that the Product will need to be around for a few years, and spends time properly designing the Product, documents how to recreate key portions of the Product, cross-trains for skills sharing

There is not a universal ‘better option’; team 1’s approach likely works better in competitive first-to-market-wins environments, whereas team 2’s approach may very well scale more but they may miss the opportunity. One thing is for sure: team 1 will eventually be addressing issues in the future that they are neglecting today. This speed-vs-scalability tradeoff is one that must be made consciously, with the understanding that time must be allocated in the future pay down the cost of speed.

An often hidden cost of speed is the dependency on exceptional performance. “Go fast” is often used synonymously with “work harder” or “work more hours”, but reliance on exceptionality is not a sustainable model for teams. It is best to ensure there are processes to promote sustainable pace, rather than an always-go-full-speed mentality.

Who is responsible for scalability?

Incentives are usually a great way to predict behavior, therefore leadership is responsible for the culture of scalability. Scalability looks different in different domains, so consider the following pattern: a team member creates a custom, high-visibility Product on a regular cadence. This person is very good at their job and enjoys creating this Product.

Is this team member incentivized to teach other people how to create this Product? No. Are they incentivized to document their process? No. Purely from a work-output standpoint, their value to the company is inversely related to the number of people who can also do their job (basic supply and demand). They actually are incentivized to make their job appear more difficult in order to deter anyone from learning it.

It falls on leadership to address these incentive problems. Some ways of doing this:

• mandatory cross training on all key Products
• Product whiteboard sessions (equivalent to a code review, where the Product and its creation process are reviewed by the team for simplicity/accuracy)
• promoting knowledge sharing (creating the culture)
• including ‘sustainability of Product’ as an evaluation metric

All of these create a top-down incentive for team members to create scalable Products.

Key takeaways

• Software engineering differs from programming in the added dimensionality of time and people
• Your organization also must consider the dimensions of time and people when building your Products
• All tradeoffs should be consciously addresses, especially the tradeoffs between speed and scalability
• Leadership is responsible for incentivizing scalability

…unless you’ve previously read this article, in which case: thank you for reading.

What is Emotional Intelligence?

A 1990 paper by Peter Salovey and John D. Mayer (no relation to ‘Crash in to Me’) set the stage for defining what emotional intelligence is. The exact definition they created is:

The subset of social intelligence that involves the ability to monitor one’s own and others’ feelings and emotions, to discriminate among them and to use this information to guide one’s thinking and actions (Salovey and Mayer, 1990)

From a high level, the pattern used in this definition of emotional intelligence is information gathering (monitor emotion), analyzing (discriminate different emotions), and decision making (guide actions). You may notice that this pattern very much parallel’s the pattern of most data analyses: gather data, find insights, use insight to do something; this probably has something to do with the fact that our brains are very complicated computers, but I digress. I actually prefer this snippet from the paper as a simple definition of emotional intelligence:

The recognition and use of one’s own and others’ emotional states to solve problems and regulate behavior (Salovey and Mayer, 1990)

Going a level deeper, there are four main buckets of emotional intelligence that loosely follow the first definition above:

1. Self emotional appraisal (SEA): How well can one sense, acknowledge, and understand their own emotions. Those who excel at SEA will know their emotions before other people notice them.
2. Others’ emotional appraisal (OEA): How well can one sense, acknowledge, and understand the emotions of others. Those who excel at OEA will be able to read others’ emotions before those people even notice their own emotions.
3. Regulation of emotion (ROE): How well can one control their emotional state, either through moderation of emotion or exacerbation of emotion.
4. Use of emotion (UOE): How well can one channel their emotions towards positive support of their performance or goals

People who are emotionally intelligent do well at understanding both their own emotions and the emotions of others, can control those emotions to prevent them from overwhelming themselves, and can channel the emotions to positive uses. Sounds like a pretty useful skill to have in the workplace!

The Benefits of Emotional Intelligence at Work

There have been quite a few studies and reports about the effect of emotional intelligence on all aspects of work performance, satisfaction, turnover, etc.

Chi-Sum Wong and Kenneth Law in 2002 found a complicated yet positive relationship between emotional intelligence and job outcomes, factoring in the emotional labor required for each job (emotional labor is the effort required to present a specific emotion at work; think of a flight attendant being nice all the time compared to an assembly line worker):

• Job performance is significantly correlated with emotional intelligence and moderated by emotional labor
• Emotional intelligence has a strong positive effect on job satisfaction regardless of the emotional labor required of the job.
• Emotional intelligence might only have a desirable effect on organizational commitment and turnover intention in jobs that require high emotional labor while the effect is undesirable in jobs that require low emotional labor (may be explained by the fact that highly emotionally intelligent employees may be put off by a lack of emotional labor required at their job)

The Emotional Intelligence Consortium (a real thing, believe it or not) published 19 examples of emotional intelligence financially benefitting businesses - some highlights:

• Experienced partners in a multinational consulting firm were assessed on the emotional intelligence competencies plus three others. Partners who scored above the median on 9 or more of the 20 competencies delivered $1.2 million more profit from their accounts than did other partners – a 139 percent incremental gain
• In a national insurance company, insurance sales agents who were weak in emotional competencies such as self-confidence, initiative, and empathy sold policies with an average premium of $54,000. Those who were very strong in at least 5 of 8 key emotional competencies sold policies worth $114,000
• The Air Force found that by using emotional intelligence to select recruiters, they increased their ability to predict successful recruiters by nearly three-fold. The immediate gain was a saving of $3 million annually. These gains resulted in the Government Accounting Office submitting a report to Congress, which led to a request that the Secretary of Defense order all branches of the armed forces to adopt this procedure in recruitment and selection

A 2012 study by Reza Gharoie Ahangar examined the relationship between emotional intelligence and job performance for 200 Iranian executives and found significant relationships between higher emotional intelligence and better performance.

And a 2020 study of 400 secondary school leaders in Pakistan found a strong correlation between emotional intelligence and job satisfaction (Suleman, Ali Syed, Mahmood, Hussain)

Phil Knight, the founder of Nike, wrote a memoir of his company’s journey from founding to IPO (Shoe Dog, a great read) and almost every problem described within was an emotional problem: his emotions, his family’s emotions, his team’s emotions, the athlete’s emotions. This is why emotional intelligence is strongly related to success: the ability to sense emotions (yours and others), understand the causes, and channel those emotions in a positive direction is immensely powerful in moving an organization forward. It’s often not the problems that prevent progress, it’s people’s emotion-driven objections with the solutions.

There are likely hundreds of other studies, reports, publications supporting the link between emotional intelligence and job outcomes (performance, satisfaction, turnover, etc.), and outside of work emotional intelligence is obviously an invaluable skill as well. If these studies are true, what can be done to get better?

How to Become More Emotionally Intelligent:

Stop viewing people as a**holes and s**theads. Raise your hand if you’ve seen this cartoon before:

While juvenile, the cartoon represents a culture of distrust and a lack of empathy that exists at many companies. Managers often view their teams as incompetent, and direct reports only see the worst of their managers. With this in mind, let me propose a more empathetic way of viewing one another:

• You are a manager. You try not to let busy work get to your team and handle many simple incoming requests. You do your best to shield them from meetings and represent your division at important cross-divisional meetings. You are frustrated because your direct reports seem to not understand the business problems, and take too long to turn around the things you ask them.
  • An empathetic view: could it be the case that your direct reports feel like they are left in the dark on direction/priority because they do not get to hear the important conversations that occur in the meetings? Or that they don’t get the chance to work on their skills because all of the simple requests are filtered out before they get to them; the only requests they get are the most challenging, which they are underprepared for due to lack of practice?
• You look at your manager and think about the day you get to them her you quit. All they do is keep you in the dark then dump huge projects on you with no context and a tight timeline. Then, they take your work and present it to leadership and get all the credit
  • An empathetic view: could it be the case that your manager actually shields you from a lot of really terrible work, and the stuff that is left over may be the best of the worst? Or that they have advocated for you to be able to present your projects to leadership, but leadership has such tight timelines that the ‘presentation’ becomes a 10-minute grilling session that would seriously affect the motivation of an individual contributor?

So how do we bridge the gap between current state (a**holes and s**theads) and a more empathetic view? Feedback loops and a commitment to understanding.

Feedback loops are an immensely powerful tool for change. Organizations without feedback loops are doomed to remain stationary, whereas ones with feedback loops will inevitable evolve over time (not all feedback loops cause positive change, but that is a different conversation).

How do feedback loops build emotional intelligence? Consider this snippet from the first section of this post:

From a high level, the pattern used in this definition of emotional intelligence is information gathering (monitor emotion), analyzing (discriminate different emotions), and decision making (guide actions). You may notice that this pattern very much parallel’s the pattern of most data analyses: gather data, find insights, use insight to do something; this probably has something to do with the fact that our brains are very complicated computers, but I digress. - Me, 1,000 words ago

Feedback loops are the unavoidable first step in this pattern: information gathering. People will not evolve unless they receive feedback that evolution is necessary; your manager will not change unless they receive feedback that their current method is causing problems; your team will not get better unless you start the hard conversation about performance.

With a feedback loop in place, there also must be a concerted effort towards understanding the feedback. The feedback you receive must not be discarded or ignored; you must make an effort to understand why the feedback exists, which requires an exercise in reconciling perspectives and worldviews. Some of these reconciliations may be:

• Why does your manager think you are underperforming (their perspective) when you are the rockstar of the team (your perspective)
• Why does your report think your management style is suffocating (their perspective) when you do your best to give them room (your perspective)

To reconcile the perspectives you must put yourself in other people’s shoes to understand where their perspective and your perspective differ. Reality is likely somewhere in the middle (it almost always is), but the process of evaluating someone else’s worldview will cause you to better understand their emotions in future situations.

Over time the process of feedback loop → worldview reconciliation → understanding other perspective will become second nature, and considering others’ perspectives and emotions will become a subconscious part of your interactions at work…making you a more emotionally intelligent person.

1. Definition: The problem needs to be defined

2. Desire: There must be desire to solve the problem

3. Delivery: The company must deliver a solution to the problem

Definition

Problems cannot be solved until they are defined.

Problems typically start as anecdotes, but they cannot stay as anecdotes forever. Definition usually occurs when good analysts piece together anecdotes into a compelling data story.

Problems can be defined in more than one way, and it is best to define the problem in terms of the decision making audience:

• An executive will care about top- and bottom-line impact

• An individual contributor will care a out how their lives can be easier

Problem definitions should be unimpeachable - they need to be known as ‘the truth’, filled with facts and data.

Somtimes it is better to decouple the problem definition from the problem solution; getting agreement on a definition is easier when the solution is not also there as a potential punching bag.

Desire

Problem solving can only occur when there is desire to solve the problem.

Organizations also need to want to solve their problems. Believe it or not, there are many reasons people would not want to solve a problem, including:

• They have other problems that are higher priority in their mind (I’ll get to that later)

• They currently benefit from the problem, either through job security or politics or self-importance (my team gets attention from executives because of the problem)

• They are not incentivised to solve the problem (they don’t pay me to deal with this)

• They may not agree with the problem definition (that’s not the problem…this is the problem)

• They may disagree that the problem is a problem (it’s not a bug it’s a feature)

All of these challenges exist, and any one can be big enugh to derail the problem solving process. People typically do not outright say their reason for not having 100% desire, so you often need to have candid conversations to draw out these reasons. This takes intuition, experience, and understanding of people’s motivations.

Beware of fake desire: desire needs to be genuine in order to actually solve the problem. Fake desire is hard to spot, but a classic symptom is people who are comfortable identifying a problem around peers or subordinates, but do not use the same language around their superiors.

Delivery

Delivery/execution is the work done to actually solve the problem; the other two are focused on organizational alignment.

This step is much larger than the other two and is what companies should be focused on. If companies focus on the other two then they will be unsuccessful - organizational alignment should not take more work than solution delivery.

There are many ways to fail in delivery: bad project management, bad ideas, poor execution, not 100% desire by all required parties, changing of priorities. Getting to a point where delivery issues are the main problems of a company can be viewed as a good thing, since that means that the organizational alignment portion of the problem solving process is effective and delivery improvement can be the focus.

To analyze this, I used medal points: bronze medals receive 1 point, silver medals receive 2, and gold receive 3. Also, the Russian Olympic Committee is being treated as the representatives from the country of Russia (well, duh).

Code for this project is here.

Superlatives

• Best country: USA!
• Most efficient country: New Zealand
• Best program: USA swimming & diving
• Most efficient program: New Zealand canoe & rowing
• Best continent: Europe
• Most efficient continent: Oceania
• Best continent program: European cycling (winning 75% of all medal points)
• Most efficient continent program: Oceania canoe & rowing

Country Winners

Let’s start with the overall medal point count: USA comes out on top with 230 points, ahead of China’s 193 and Russia’s 139. USA also eeked out the gold medal count win with 39 golds compared to China’s 38 golds.

On a per-population basis, things don’t look as bright for the Americans who fall out of the top 15. In fact, there are two significant outliers with New Zealand (population 4.5M) and Jamaica (population 2.7M) standing out above a series of mostly-European countries. For context, USA scores 7.2 points per 10M population, good for 51st overall.

Note that this data has a minimum medal point threshold of 15 – without that threshold the country of San Marino (population 32k) would blow the competition away with their 4 medal points equating to 1,221 points per 10M population.

Country Event Winners

USA absolutely dominated the swimming and diving competitions, receiving 1.5 points per event – equivalent of winning a gold in every other event. The top event winners all seem to be the top medal getters, with the exception being the British and Dutch cycling teams, which won 1.3 and 1.1 points per event, respectively.

When normalizing for population, one again New Zealand and Jamaica stand out. New Zealand won 6 golds and 2 silvers in canoe & rowing events, outstanding for a country with as many citizens as Detroit. Jamaica athletics (track & field) may bring back memories of Usain Bolt and all the great Jamaican sprinters over the years – this year they continued to churn out an impressive amount of medals for such a small country. Take note of the European cycling performers – numbers 3, 4, 5, and 11 on the top 15 are European cycling programs.

Continent Winners

Europe winning this makes a lot of sense when you think about it: many very developed countries, each with dreams of winning medals, all counted together. I was surprised to see Oceania out-achieve both South America and Africa.

Oceania is a runaway winner on continent medals per 100M population. For being the least populated continent in the Olympics (population 43M; Antarctica did not participate this year) they really out-punched their weight. For context, scaling Oceania up to the size of Asia would mean that they would win 13,900 medal points, equivalent to over 6 total Olympic games.

Continent Event Winners

Looking at the event performance for each continent, it is clear why Europe won the most medals. They are 1st 9 of 11 event groups, with runaway victories in cycling and canoe & rowing events.

Think about what winning 4.4 medal points per cycling event means: on average Europe finished with gold, bronze, and 1/5th of silver.

Normalizing by population, Oceania once again dominates the results. The Australian and New Zealand swimmers stand out along with the aforementioned canoe & rowing programs.

USA vs China

I took a deeper dive into the USA vs China medal race to see where each country was getting their medals from – here’s what I found:

• China doubled-up USA in artistry (gymnastics), driven completely from 0 points by USA’s men (the women tied with China)
• USA dominated China in athletics (track & field), winning 55 points to China’s 11; 35 of those USA points were won by female or mixed competitors
• While China was a respectable second place in swimming and diving, USA was #1 by a long shot, gaining 22 points on China in those events
• China clawed back 10 points by finishing gold-silver in mixed doubles badminton and table tennis…who knew those were Olympic sports!

Event Groupings

The lower-level events were grouped based on the following rules:

Artistry

Gymnastics, Artistic Swimming, Equestrian

Athletics

Athletics (track & field), Modern Pentathlon, Triathlon

Canoe & Rowing

Canoe, Rowing

Combat Skill

Taekwondo, Karate, Judo

Combat Striking

Fencing, Boxing

Shooting & Archery

Shooting, Archery

Swimming & Diving

Swimming, Diving

Traditional & Team

Baseball, Softball, Beach Volleyball, Field Hockey, Handball, Rugby, Soccer, Volleyball, Water Polo, Basketball, Tennis, Golf, Table Tennis, Badminton

Weightlifting & Wrestling

Weightlifting, Wrestling

Now that you’re here, this post is about why everyone should build something, anything, with technology. Something big, something small, something useful, something fun, anything to get real-world experience using technology. Two reasons:

• Building something gives you knowledge and creates proof of knowledge
• Building something teaches you about technology, the best leverage available

Building gives you knowledge (and proof)

The “gentleman’s B” concept was fairly common in my MBA program. It was a unwritten and unspoken contract between students and teachers, where the student ‘agrees’ to put forth an adequate-yet-uninspiring amount of effort (going to class, not being disruptive, completing the assignments, not bombing the tests) and the teacher ‘agrees’ to not give them a grade below a B.

This is one of the problems with university, and generally all credentials. You end up with approximately the same ‘proof of knowledge’ as everyone else: a diploma. You can have a good GPA, but GPAs are often inflated and buoyed by easy classes (Wildlife Issues was a favorite at UF undergrad). Extracurriculars and leadership positions are important, but often those are popularity contests.

Much of your career success is the result of people believing you can deliver, resulting in you getting more opportunities. The key thing is belief; it doesn’t matter if you can actually deliver as long as decision makers believe you can. Belief gets you opportunities, but belief requires communication. Take the below image: when your ability exceeds your communication of said ability, additional ability is un-communicated and, in a sense, wasted.

One of the reasons I started this blog was to shrink the communication inefficiency in my life. In a sense, this blog is me building something tangible that (hopefully) communicates that I have the ability to think complex thoughts, put together an argument, and tell a compelling story.

(If you’ve read this far, let me know if it’s working!)

Technology and code is the truest blank canvas there is. You start with an idea and the rest depends on your knowledge and resourcefulness. If you can take an idea or problem, no matter how small or trivial it feels, and deliver a solution you have created tangible proof-of-knowledge that communicates your ability the way no degree or certification can ever duplicate.

When you build you also will start to develop T-shaped skills: you still have your deep specialized knowledge in a specific area (the vertical line in the T), but you will be adding broad-yet-shallow expertise in adjacent skills (the horizontal portion of the T).

You will likely learn some combination of front-end web development, server-side data processing and serving, code versioning, deployment, APIs, HTTP requests, mobile development, and much more. These are all skills that are used throughout the entire world in every company and every application you interact with on a daily basis. Knowing even a moderate amount about the technology you use and rely on is a huge help in understanding how important technology is and how it can be used to scale your impact.

The best part about learning these technology skills is that you will learn them quickly. Learning is always fastest when learning new things, and getting 25% competent in new technology skills is much easier than getting the final 25% competent in your specialized skill.

Technology is how you scale your impact

Even if your job is not directly in technology, your impact is derived from technology. Consider this blog: all I have full ownership over is the words I am writing. The platform, WordPress, is built on technology that allows me to scale my thoughts out to millions of people (yes, there are millions of people reading this).

Technology is the best form of leverage to scale your impact and ideas. If my ideas were shared only with my friends my potential audience would be small (ooh…self-burn). Using technology, the audience is as many people as can read English.

A very smart Twitter thread by venture capitalist Naval Ravikant talks about the power and sources of leverage. He offers three sources of leverage:

• Capital (have more money)
• Labor (have more people working for you)
• Technology (he calls this ‘code and media’)

Technology gives you leverage, and that leverage is cost-effective and permissionless (ideas also stolen from above thread). Diving in to those concepts:

• Capital is, by its nature, the polar opposite of cost-effective and typically requires someone’s permission (someone has to invest in your ideas or project)
• Labor requires permission, since people need to follow you for you to be their leader. Labor is also not cheap.

Let’s go deep in how technology fares with cost and permission:

• Technology is cost-effective: It has never been cheaper to build with technology. You can build a web app completely in the cloud with pretty much all cloud providers ($minimal, my favorite is GCP Firebase), test-deploy locally on a Raspberry Pi ($35), or host it on Heroku ($free). You can develop a iOS and Android apps using Expo, with iterative re-loading and testing. You can deploy APIs and make some money on the side with RapidAPI. You can build machine learning models using scikit-learn in Python ($free).
• Technology is permissionless: You are completely free to build whatever you want, wherever you want, however you want (within the laws of this country). You can build without anyone thinking your idea is good. You can build regardless if you are good at building. You can build while rocking your baby to sleep. You can build then stop then build more when you have more time. There are no rules; you need no permission.

With technology being the best source of leverage available on planet Earth, getting somewhat competent in the tools, concepts, and methods used throughout technology can be a huge multiplier on your impact. In a very real sense, understanding technology enables you to bridge the gap between ideas and solutions, even if you are not the one who ends up building the solution systems. If you do end up finding a true calling building things with technology, the entire world opens up to you, with the only constraint being the problems you choose to solve.

To summarize, building with technology is a no-lose proposition:

• Worst case you learn fundamental tech concepts used throughout society while showing you can deliver
• Best case you learn to capitalize on the best form of leverage available to multiply your impact

Why I decided on OMSA

I decided I wanted to get a second masters degree in mid 2018 when I was working for IBM around some incredibly smart people who had so much technical knowledge. I was in a project manager role and had a strong sense of imposter syndrome trying to wrap my head around what it is I was supposed to be managing (I still don’t know what an analytics cube is).

When considering the sources of power outlined below, I tend to think that the ones in the ‘personal power’ category as more authentic and legitimate, and I have always admired those who have strong expertise in technical subjects. I decided I wanted to get more technical depth, and have always enjoyed analyzing data, so figured an analytics degree would be up my alley.

I am already a graduate of a 2-year full-time MBA so more full-time school was a no-go. Conveniently, Georgia Tech had a fully-online 2ish year analytics program that was very affordable, so I got together my resume, asked for recommendations, and applied.

I ended up getting accepted to OMSA in fall of 2018 to start in the Fall 2019 term. I was somewhat disappointed since I wanted to start right away, but luckily there was the option to take some courses for credit prior to starting in the program (more on that later).

My OMSA experience: The good, the meh, and the bad

The good

• Exposure to some of the best professors in the country: Georgia Tech is ranked as the #8 best engineering school in the country; the OMSA program is a combination of industrial engineering courses (#1 in US), computer science and engineering (#5 in US), and business information systems (#5 in US)…can’t beat that
• Exposure to fascinating content and concepts: This may be applicable to all analytics degrees, but it’s worth emphasizing how much I’ve learned. Before starting, machine learning was more like the movie Smart House; now, I know it’s all just optimization in disguise (well, mostly)

• The cost: The degree cost me $10,430. Compare that to the other top programs here: Carnegie Mellon ($67k), Cal Berkeley ($73k), Harvard ($35k). It’s incredible that the program is so affordable.
• The Micromasters option: I had two semesters of waiting between when I got accepted to when I started the program. Conveniently, GaTech offers three OMSA courses via a Micromasters certificate that counts for credit towards your degree. I took those courses before starting the actual program, and scored well enough to get transfer-credit for all three. Taking the courses through the MM is cheaper than taking the same course through GaTech, but there is no guarantee you will get credit (GaTech is weirdly vague about what grade you need in the MM courses to get transfer credit).
• The Slack community: One of the cons of a fully-online program is no hallway conversations, classroom discussions, etc. OMSA’s equivalent is a very active Slack workspace, with channels for all the classes. While I did not participate very often in the main discussions, I found the Slack very valuable for reading others’ thoughts and getting help in my classes.

The meh

• I self-taught many things: Without the financial skin-in-the-game, I doubt I would have had the discipline to actually learn these concepts, but in the online setting I was often googling the concepts and learning on my own. A few classes I didn’t even watch the lectures at all, and learned while doing the homework and projects. Comparing to my MBA, where in-class discussion of concepts was a key value-add, I wonder if those discussions even occur in the in-person version of an analytics degree, since concepts are more technical/math-heavy.
• I paid for a piece of paper: I will soon have three expensive pieces of paper. I enjoy learning, but I realize there are better ways to learn than lecture-homework-lecture-project-exam-grade-repeat. This is (99.99% chance) my last formal degree – the rest will be learning-by-doing with hobbies/personal projects.
• It is a lot of work: Expected, but worth noting. I spent many weeknights staying up late watching lectures or doing homework, and basically dedicated one of my weekend days to the program. I am lucky to have a great support system which made things easier, but it definitely is not for the faint of heart; expect it to be a grind.

The bad

• Some courses were flat-out bad: This happens in academia, but is still worth noting. Typos in homeworks, boring/bland lectures, and confusing test questions were not common but existed in pockets.
• I did not take advantage of office hours: I didn’t once participate in office hours (not a complaint on the program; I never prioritized it), so I felt somewhat disconnected from the instructors. I mostly used Slack channels to ask questions on homework to my peers.

Highlights

Favorite classes

• Computing for Data Analytics (CSE6040): The first course I took in spring 2019. Best exam format (24-hour Jupyter notebooks with hidden test-case cells; if your notebook runs end-to-end you get a 100%), very cool concepts
• Computational Data Analytics (ISYE6740): Aka machine learning 1, very tough assignments but I learned a lot. Did a great job balancing math, coding, and concepts.

Most memorable concept

Spectral clustering: Clustering is often done by distances (how close is a point to the other points). Spectral clustering uses graph theory and an adjacency matrix to properly cluster atypical shapes (see the circles in the below image; source)

My course schedule

• Spring 2019 (2 Micromasters classes): Computing for Data Analytics; Data Analytics in Business
• Summer 2019 (1 Micromasters): Introduction to Analytics Modeling
• Fall 2019 (2): Bayesian Statistics; Simulation
• Spring 2020 (1): Data & Visual Analytics
• Summer 2020 (2): Computational Data Analytics; Data Analysis for Continuous Improvement
• Fall 2020 (2): Deterministic Optimization; Regression
• Spring 2021 (1): Practicum (employer-sponsored capstone project)

Biggest ‘OH S**T’ moment

I got my dates mixed up and forgot to submit my final assignment for Data Analysis for Continuous Improvement, which was worth something like 40% of my grade. This was going to delay my graduation a semester and cost money…I was not happy. After throwing a temper tantrum, I messaged the instructor who was very understanding and let me submit late for no penalty. Thanks Lee!

Biggest challenge

I was taking two pretty tough classes in Fall 2019 (Bayesian Statistics and Simulation) while traveling 4-days a week for work. On top of that, my wife and I got a dog, bought a house and moved, all within a 3-month span.

I not-so-fondly remember sitting at the kitchen table doing a Simulation exam on a Sunday night after moving the day before. Boxes were everywhere and my wife was unpacking, but I had to do this exam before 11:55pm that night, and was getting on a plane the next morning. That was tough; I am lucky to have a great support system.