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:
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:
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!
]]>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:
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:
Stay tuned for the update after our first quarterly 10-Q.
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.
]]>Many work environments generally function in the following fashion:
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:
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.
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:
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.
Feedback Quality | Range of Angles | Percent Productive |
---|---|---|
None | 0 to 90 | 0% to 100% |
Meh | 15 to 90 | 26% to 100% |
Average | 30 to 90 | 50% to 100% |
Good | 45 to 90 | 71% to 100% |
Great | 60 to 90 | 87% to 100% |
Bad | -30 to 60 | -50% to 87% |
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.
Feedback Quality | Percent Productive | Average days to complete |
---|---|---|
Great | 87% to 100% | 105 days |
None, 1.5x throughput | 0% to 100% | 106 days |
Good | 71% to 100% | 112 days |
Bad, 4x throughput | -50% to 87% | 112 days |
Average | 50% to 100% | 122 days |
Meh | 26% to 100% | 137 days |
None | 0% to 100% | 159 days |
Bad | -50% to 87% | 446 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?
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.
One last point: when soliciting feedback you must act upon it or never receive feedback again. Consider the following scenario:
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.
]]>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.
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!
You’ll need:
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:
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).
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.
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.
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.
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.
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 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.
The key distinction the book makes between programming and software engineering comes from two dimensions: duration and scalability
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.
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:
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.
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:
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.
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:
All of these create a top-down incentive for team members to create scalable Products.
…unless you’ve previously read this article, in which case: thank you for reading.
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:
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!
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):
The Emotional Intelligence Consortium (a real thing, believe it or not) published 19 examples of emotional intelligence financially benefitting businesses - some highlights:
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?
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:
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:
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.
]]>Definition: The problem needs to be defined
Desire: There must be desire to solve the problem
Delivery: The company must deliver a solution to the problem
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.
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/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.
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.
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.
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.
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.
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:
The lower-level events were grouped based on the following rules:
Gymnastics, Artistic Swimming, Equestrian
Athletics (track & field), Modern Pentathlon, Triathlon
Canoe, Rowing
Taekwondo, Karate, Judo
Fencing, Boxing
Shooting, Archery
Swimming, Diving
Baseball, Softball, Beach Volleyball, Field Hockey, Handball, Rugby, Soccer, Volleyball, Water Polo, Basketball, Tennis, Golf, Table Tennis, Badminton
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:
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.
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:
Technology gives you leverage, and that leverage is cost-effective and permissionless (ideas also stolen from above thread). Diving in to those concepts:
Let’s go deep in how technology fares with cost and 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:
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).
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)
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!
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.
]]>