The weakness of weapons
“A weapon is a tool… A tool for killing and destroying. And there will be times when, as an Envoy, you must kill and destroy. Then you will choose and equip yourself with the tools that you need. But remember the weakness of weapons. They are an extension–you are the killer and destroyer. You are whole, with or without them.” - Richard K. Morgan, Altered Carbon
I am scanning the top posts on TowardsDataScience as I write this. TowardsDataScience is one of the most popular data science blog compendiums in the community - thousands of contributors weigh in on the broad field of analytics. The current featured posts look something like:
- “Deep learning on graphs: successes, challenges, and next steps”
- “A Practical Guide to Getting Set-up with PostgreSQL”
- “What’s popping? An Exploratory Analytics Project on What Makes Popular Music Popular”
- “My End-to-End Process for Data Science Projects”
- “Can you remove 99% of a neural network without losing accuracy?”
Scanning dev.to presents a similar bucket of titles:
- “Bullseye! 4 ways to center that damn div with CSS”
- “Containerize your .NET Core app - the right way”
- “6 Super Useful Menubar Apps For MacOS”
Technical education, by and large, looks a lot like this. There’s a description of a tool or algorithm along with some code samples of what’s discussed in the post. There may be a case study on where the tool was applied.
Frameworks, techniques, languages… all of these are weapons. By themselves, they are weak. They are just tools for you to use to accomplish a task.
The engineer who focuses overmuch on particular tools is hindering their own development. Can you really count on React or Python or any specific framework or language being around in five years? Are you learning the true shape of a problem, or just how to bang out a specific piece of code to close a ticket? The difference between the experienced engineer and the novice is the experienced engineer knows how to analyze problems and pick the right tool to address them - not to just apply the specific tools they know to hopefully make something work.
A football-inspired training program for tech teams
Football Manager is a sports simulation game where the player doesn’t control the footballer (soccer player); the player is the coach. The gamer controls starting lineups, tactics, transfer policy, financial decisions, team morale, and the other factors of being a manager. When it comes to match time, though, the player has to watch their simulation play out from the sideline, just like a real manager. Sure, they can bark tactical changes or make substitutions, but they mostly have to watch. Millions of people own the game with several hundred thousand playing every day.
I am one.
The American sports enterprise at nearly all levels does not heavily prioritize player development as a long-term proposition. Players are thrown into a huge pool at their earliest professional age (sometime in the 18-23 age range) and teams draft them. Baseball teams have some sort of minor league system that is affiliated with the club, but American football and basketball basically use university play as a mechanism for filtering talent. There’s not some relationship with the Dallas Cowboys and the University of Texas to send U.S. football players straight from the Longhorns to the Cowboys.
International football clubs, by contrast, develop players through all stages of their athletic careers. The first team, which is the most visible, are the club’s best athletes. The reserve squad comes next (typically players under 23 years old), with under-18 youth players rounding out the training squads. These reserve/youth teams have their own leagues with the squads regularly playing each other. At the highest levels, international clubs aim to begin training players at very young ages and grow them into first-team athletes.
The size and the prestige of the club naturally impacts player development. Liverpool runs top-notch training academies in multiple countries, while fourth-tier club Carlisle has a small locally-focused youth program. Yet the spirit is the same. Clubs invest in junior players before they’re superstars, grow and cultivate them through gradually-increasing levels of maturity, and turn them into first-team players as they come of age.
I think a lot about talent development in my current role. How can I produce a fantastic team of tech-developing athletes? What are the attributes of the international football system that lets it turn out greatness?
Here are some attributes that stick out to me:
- Players are trained in line with the club’s philosophy.
There’s no such thing as a single tactical way to play football. Some teams believe in pressing every minute of every match. Some teams believe in a slow, winding game that wears down their opponents to create chances. A development player can be trained in a way that optimizes the club’s philosophy.
Similarly, it’s silly to believe that all developers are alike. Google’s values are not Amazon’s values. Nor are they Deloitte’s values, where we crave developers who can think about how to solve problems in wildly variant technology environments.
If you’re responsible for the training, you can shape and optimize the team for precisely what the team needs.
- Players and teams both sign contracts that obligate them both for a period of time.
If a 21-year-old prospect signs a three-year development contract with a club, both the player and club are bound to that agreement. If the player has a breakout year at 22 years old, they’re still held to their long-term agreement. On the flipside, if the player fails to grow into a first-team role, the team is still responsible for paying their contractual agreement.
This incentivizes both the club and the player to be on their best behavior. If a player doesn’t work hard to grow, they’re unlikely to secure a more lucrative contract later. If the team doesn’t invest in the player’s development, they lose the chance to have a fantastic first team player operating on a development salary.
To me, this addresses some of the problem of organizational hesitancy to train workers. It’s fairly common in large enterprises to have academic handcuffs - the company pays for a degree with the contractual agreement that tuition will be repaid if the employee leaves in ~2 years. The football system is a variant of that same notion.
- If a contract is to be broken, compensation must be paid.
It’s certainly common for a player to develop faster than either the player and the club expected, and now the contract looks a little silly. If a player was signed on a five-year development contract for $500/week and now they’re competing against elite first-teamers making $50K/week, they are likely to be grumpy about this. At a certain point, they may just shut down.
Transfer fees are designed to address this. This is a cash payment that one team makes to another team in exchange for a player. Player X was making $500/week playing for Club A, but now Club B wants that player to be in the first team? Club B then has to pay Club A a negotiated sum of money, and come to contract terms with Player X.
Entire teams have business models not around winning the league, but around being awesome developers of talent that are then sold on transfers to other clubs. Dutch team Ajax, for example, brought in revenue of 200 million euros, of which 75 million euros stemmed from the sale of a single player.
It’s really easy to say “training should be commonplace” when thinking only of the largest employers. This broadens that aperture. If you’re a mid-sized agency that wants to address a smaller market - and not compete against the FAANGs in anything - this creates the incentive for those leaders to still invest heavily in young talent. Maybe they can pick up a transfer fee for them one day!
- Players grow in the open.
During football season, anyone can pop over to an academy game and scout their next team. There’s regular opportunity to showcase talent! If Player X has a breakout game in front of another club coach, that might mean a transfer, a higher contract value, etc. etc. All of that is in the open. Players aren’t inclined just to show their best work in some interview - they do it every week.
Most engineers who blog in the open about what they’re learning tend to be pretty fantastic engineers over time. The same idea works here. Writing, speaking, publicizing accomplishments and showing up to represent the organization - that both promotes the individual but also promotes the organization who created them.
- The complexity of the task matches the team executing it.
The Liverpool first team is not playing the Carlisle reserve teams. Most of the first team players will make more in payroll than that match would bring to the club in ticket sales. Similarly, the Carlisle reservists wouldn’t learn anything by getting crushed.
Similarly, there’s a matching of problem complexity to capacity to solve it. If part of Google’s testing network goes completely down, the junior engineers may want to take this one on. If the entire prod network drops, that’s a first-team problem. The junior engineers still learn something about fixing problems, but in proportion to their skill levels.
Is the football player development system perfect? No system is. I don’t even know if it would legally work in America with our hodgepodge of right-to-work laws that vary per state.
But there’s something here about incentives to invest in talent development over the long haul. Something that can go beyond just the giant high-$ players in Silicon Valley that can expand industry-wide. Maybe there are some ideas here we can use.
Fine. I'll do it myself.
Pick a topic. Any topic. There is at least one highly detailed book on it in existence somewhere. Once upon a time I read a book on the history of shipping containers and it was amazing.
If I needed to pack up several tons of peanuts (the kind of thing I imagine people ship in boxes), I wouldn’t be able to do it. I don’t even know who the first people I would call would be. Like, do you just call Maersk and say “let’s move some peanuts, give me a quote?” How does this work?
Thankfully, on a day-to-day basis, shipping giant containers is not a requirement of my job. I have chosen to keep that level of logistics at a comfortable level of abstraction where the Internet is a portal into a giant black box where I type in what I need, press a big “Place Order” button, and a series of exchanges made by Other People manage how it gets there.
Yet there is some part of my work that needs a software engineer. It also needs a user experience researcher, an executive decision-maker, an educator, a writer, and fifteen other action-oriented words, responsibilities, and titles. Most jobs are like that.
I couldn’t be any good at my job if I had only read about building software, or studied user experience, or taken a teaching pedagogy course. I would be capable of learning a trade, but I would never have done it myself. I’d still be very junior.
There is no substitute for tinkering. Even if it’s your first try. Even if you screw it up. That is the only way we learn.
Know where your cash comes from
Most of us are paid in cash. Some of us are paid in cash plus some sort of additional compensation (such as health insurance, or a gym membership, or a parking pass), but the cash is really what we care about. Cash pays for our rent and our groceries and our iPhones.
Businesses are not magical cash engines. Someone decides that they would like to produce something (a book, or pencils, or legal advice) and someone else decides that they would very much like to have that thing. So much that they are willing to exchange some of their own cash in order to have it.
You can take any huge, complex business and ultimately track it back to some initial simple exchange. General Electric, which now makes jet engines and health devices, started off making some light bulbs and handing them over to people for cash. Sometimes, an investment gets involved, like the old Star Oil money taking some cash to pay the expenses associated with hunting oil in California.
There comes a point in time where the person who started the whole business may decide that the whole thing could make more money if Person #1 had more time. So they bring in Person #2 and say “hey, I’ll give you a steady stream of cash if you’ll do my accounting / keep my equipment running / drive my delivery truck / etc.” Person #1 has paid Person #2 in exchange for getting some time back while still seeing the same things getting done.
If the business does really well, Person #1 may just give Person #2 a pile of cash and say “I would like these Big Thing X to happen, I don’t care how they get done, here is some money to go do it.” And now Person #2 takes on the title of Chief Something, the owner of his own little business that provides Big Thing X with one customer: Person #1.
Huge, complex businesses are just infinite sub-fragmentations of the same set of cash-for-outcomes transactions I’ve just outlined here. Someone with control over a great deal of resources gives some of them to someone else in exchange for a set of outcomes.
Which brings us back home to the title of this post. If you are anything other than the owner of a business, the cash in your paycheck came because of a series of cash-for-outcomes transactions where somebody with control over more resources allocated a smaller chunk of them to someone else in exchange for a service. You should always know, to the best of your ability, what those transactions were.
Those transactions tend to get revisited on a yearly basis, and how they get revisited can have a big impact on your career path. If someone three levels up from you made the decision “we should build ten new major software features this year,” your position may exist to build one of those software features. If next year, the decision is “we’d like to build TWELVE new software features,” you have an opportunity for an informed raise if you can say “I can build an extra feature for 1.5x my salary. Or half of what you’d have to pay for somebody else,” you have an opportunity. One that you wouldn’t have if you didn’t even know those negotiations were happening.
The flipside is true as well. If your job is dependent on building new software features, and the bosses decide they only want to build eight new features this year, then two of your team members are no longer necessary. Understanding how and why all those transactions are made gives you an early warning system. It lets you take the early moves to respond.
Know where your cash comes from.
Real constraints / self-imposed constraints
There are two worlds in which we live: Mundia and Modia. In the world of Mundia, laws are physical. If you jump, you will come down. If you push something, it will fall over. In the world of Mundia, many things are possible. If you see a new shiny object that you want and it’s not glued to the ground, you can pick it up and take it home with you. In Mundia, things follow physical, immutable laws.
In Modia, our laws are social relationships. Jumping doesn’t matter there, except if you can jump really high or really far, in which case someone will give you a gold Olympic medal that we have decided has Modian value. If you push someone, and they fall over, you will likely be disliked by that person. If you see a new shiny object that you want, you can’t pick it up and take it home with you unless you hand over some money for it, which we have also decided has Modian value. In Modia, things follow laws that everyone who lives in Modia has agreed to follow.
“Cannot” has an impossible-to-dispute meaning in Mundia. It means the laws of the world prevent you from doing something. Only 0.00001% of everyday constraints are Mundian in nature.
“Cannot,” in Modian terms, is mostly a shorthand for “the intensity or volume of actions I/we would have to execute in order to get this done is undesirable for the value I would derive from it.” For instance, Mundian law dictates that I can delete every email from every email account in the entire world. It’s possible. Modian law says that if I did this, I would be thrown in jail before completing my mission, which is undesirable to me.
There are very few real constraints in this world. Most of the time they are self-imposed.
When I was in college, I met a person who knew at 18 that he wanted to live the LA celebrity lifestyle - but he wasn’t a good actor, or musician, or writer. He was an accountant who liked playing with numbers. Most accountants don’t end up hobnobbing with Katy Perry, except for this guy… who figured out how to go be her accountant. When Katy Perry has a question about how her stocks are doing, she calls this guy. And when Katy Perry hosts a house party, she invites him out.
Accountant Guy thought long and hard about what he wanted and how to get it under Modian Law. He couldn’t offer anything of value on the artistic front. He didn’t want to take years of his life trying to develop those talents, as it would cost him the fun years of partying in LA. But he was good with numbers and a responsible individual, so he learned how to be an accountant, built his quals up in the entertainment world, and pushed until he was working for the superstars.
The same is true with all applications of Modian Law. There is always a workaround. It may cost you more than you want. You may have to sit there and let the problem scratch at you for years. But there is always a way out.
When I was in my last course of my undergraduate degree, my professor made the entire class write down a five-year plan in order to get a final grade. We had to discuss what our plans for the future were, and what steps we would take to get what we wanted. I wanted to work in investments then, and I distinctly remember my plan to be an investment advisor by age 27.
Things change, and I’m not an investment advisor. I still remember the plan.
When my professor gave us the assignment, he said, “You may not have any plan yet. But if you have to write one down, and you have to show it to me, your brain is going to make you feel guilty about falling short of what you wrote down. And then you’ll have to take it seriously.” He was right. I wrote one plan down that was half-baked, then realized I would be embarrassed about showing it to someone, so I took the assignment more seriously.
Though I’m not in investments now, the first two years of that plan involved completing my master’s degree in accounting and learning how to analyze financial information. That led me to a Big 4 consulting firm, which led me to where I am today. The plan got me there, even if I didn’t fully follow where the plan led me at first.
The plan is not the point. The point is considering that the future will exist.
With every team I manage, I periodically enforce a 1-2 week vacation period for everyone on the team, including myself. I’m not terribly concerned with what people do with their vacation time - if “silent meditation for a week” sounds amazing to them, great - but I need them to leave. If they don’t leave on their own, we have to force them.
People get sick. People get burned out and quit. People get hit by buses. The team cannot risk a person leaving throwing off the works. And so we have to occasionally road-test their absence. What do they silently do every day or every week that keeps the entire process running without anyone else’s knowledge? Vacations are a way to keep our bus count high.
We vacation-test the manager too. I also leave the scene periodically, with my deputy being the only person who can get in touch with me. This also forces me to constantly delegate and cross-train, such that I am only needed for something that might cause a strategic shift in priorities (and even then, the expectation is that the deputy can probably just confirm things with a text message).
Bus count testing is future-planning. Eventually that team member will get sick, or quit, or retire, no matter what we do. If we aren’t planning for that eventuality, we are not accepting that the future will exist.
Future-planning isn’t just about the negative, it’s about the positive too. Each year, I kick off January by scheduling individual check-ins with the team to discuss New Year’s Resolutions inside and outside of work. It is always revelatory. Sometimes, someone wants to go up for promotion and this is the first time I’ve heard of it. Sometimes, they have an out-of-work goal that may impact work (like training for a marathon where they need to leave every day with enough sunlight to get a run in).
And yet, sometimes, I have team members who haven’t thought of their future beyond maybe the month. Their manager asking about it creates a prompt to force the thought. Now they’re considering “maybe I could run a marathon” or “maybe I will push myself for a promotion.” And then we’re talking about execution plans, not just vague ideas.
We humans are meant to evolve and grow. We are meant to change. We replace all of our cells every 7-10 years and become completely new people, chemically speaking. We have to imagine that the future might exist, and what we will do with it when it gets here. Failing to dwrite down a plan is asking for it to hit us like an unexpected bus.
The creative work
Did you know Ed Sheeran’s song “Shape of You” wasn’t supposed to be sung by him at all? Sheeran wrote it for Rihanna. That’s why it has this cool club beat that is so wildly different from his typical acoustic ballad: he never intended to sing it himself.
He wrote the second verse about an all-you-can-eat buffet and realized that wasn’t really Rihanna’s vibe. So he recorded it himself. Don’t believe me? Look it up yourself.
When I was in college, I spent a year and a half as a songwriting major. This is the kind of thing you can major in if you go to school in Nashville, Tennessee. I had dabbled in writing my own music before and thought maybe a full-blown major would be what I needed to make a career out of my poor attempts at melody.
Songwriting I is about crushing all the romantic notions students might have about songwriting. It was a seminar class led by a songwriter who paraded his Nashville songwriter friends in front of us to share their thoughts on the industry. What I learned spooked me away from a songwriting career forever.
The people I met were professional writers. They fed their families off the songs they wrote. No surprises there. It also didn’t surprise me that these writers wrote a “really good one” once every few years, with a few relatively good ones as fillers (someone has to write track 8 on an 11 track album).
What shocked me was the sheer number of bad songs they wrote.
One of these writers described her process something like this:
- 9:00AM: get into the office
- 9:30AM: finish tuning and noodling around on guitar, proceed to first coffee
- 10:00AM: get jitters out of system
- 10-12: write a verse
- 12-1: lunch
- 1:00-1:30: probably throw away the first verse
- 1:30-2:30: try another verse
- 2:30-3:00: probably throw that one away too
- 3:00-5:00: try something else
- 5:00PM: go home, try again tomorrow
All told, she estimated she wrote between 500-1000 songs per year to get 3-5 good ones. That’s a lot of creative product she wasn’t happy with.
And yet, she created it.
Some people are born natural creative geniuses. Mozart was composing music by age 5 and was producing a flurry of world-renowned music by the time he was 17.
Joseph Haydn was not Mozart. He didn’t learn much of composition at all until he was 20. Both Mozart and Beethoven still considered him a creative mentor. Haydn had to grind it out, working stints as a choir boy, freelance musician, music teacher, and street busker. Haydn wrote over 200 pieces for the baryton (a weird bass viol-like instrument) because his patron decided he liked it and there wasn’t much music out there for it. The prince would abandon the baryton later and demand Haydn create operas instead.
Yet Haydn still had to just figure it out or get fired. No one taught him how to compose for the baryton. No one promised him riches if he wrote the world’s best baryton piece, nor did anyone even promise the baryton would be the next big instrument of Europe. He had to create anyway, or get fired. It was creative work, with a strong emphasis on the work part.
Haydn was a professional songwriter. Probably wrote 500-1000 songs per year.
There’s an apocryphal quote usually attributed to Edison that goes something like:
Opportunity is missed by most people because it is dressed in overalls and looks like work.
And one more recently by Ira Glass with:
Everybody I know who does interesting, creative work they went through years where they had really good taste and they could tell that what they were making wasn’t as good as they wanted it to be. They knew it fell short. Everybody goes through that. And if you are just starting out or if you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Do a huge volume of work.
I have yet to meet a person who completely lacked the capacity for creative work. I meet people daily, however, who choose to not sit themselves at a desk and refuse to stand up until they have a paragraph written. Or 10 lines of code. Or a short description for a character.
Most of them are going to be really bad. I have never written ten lines of code that I didn’t hate and throw away later - usually after I had a hundred lines more. You still made them. They are your ugly babies to love and care for. You made them. That’s awesome.
That creativity is highly unlikely to come from some flash of inspiration. It may never come at all. I wrote six drafts of this post before I finally came to something I’m happy with, and I never really felt some overwhelming sense of happiness with the end product. I just needed it out of my system.
Do the work. It’s not going to be fun. It’s not going to be easy. It’s not going to feel like wine and painting night. It’s going to feel a lot like work.
But wow, you’ll feel great when it’s done.
Asking better questions
Here is a tough reality for most “data science” positions: nine times out of ten, the question that matters most doesn’t need a cutting edge technology solution. It needs a dashboard, a nifty spreadsheet, or a simple report.
Once upon a time, my data science team worked in a supercomputing environment for a whole year. We had access to petabytes of data to answer whatever questions we could ask around a general theme. I wrote beautiful stuff using the latest and greatest libraries and frameworks. I optimized aggressively, changing my code from Python with a shim to native languages.
At the end of the day, the things that produced the most tangible outcomes for that particular project were some canned jobs and an interface for analysts to write some ad-hoc queries for follow-up on whatever the jobs produced.
I had not initially been asking the right questions.
In a now-moderately-famous tweetstorm, venture capitalist summed up the power of code in a few sentences:
Code and media are permissionless leverage. They’re the leverage behind the newly rich. You can create software and media that works for you while you sleep. An army of robots is freely available - it’s just packed in data centers for heat and space efficiency.
“Leverage” has become a bit of a watered-down term in the past decade or so of corporate-speak. More’s the pity. It’s now commonly used to denote simply “using something well” minus its original implication of “with some sort of amplification beyond what you could do on your own.”
Stock traders have a notion of margin: a trader will take out a loan to purchase additional shares of stock than they could afford otherwise. If the price goes up, they pay back the loan and pocket the extra dollars. If the stock goes down, they’re still on the hook for the loan amount. Their equity position is leveraged. The gains are highly amplified, but the losses are too.
Code is a form of leverage. It doesn’t make ideas good or bad, but it amplifies them both alike.
A bad question with code amplifying it becomes a much worse question.
From 2014 through 2018, Amazon tried to roll their own AI-driven resume evaluator that did not work out the way they intended. Their apparent question: “can we use the resumes for successful candidates over the past ten years to predict which resumes we’ll like going forward?”
The results were unfortunate. From the article:
Top U.S. tech companies have yet to close the gender gap in hiring, a disparity most pronounced among technical staff such as software developers where men far outnumber women. Amazon’s experimental recruiting engine followed the same pattern, learning to penalize resumes including the word “women’s” until the company discovered the problem.
The good questions perhaps a few steps backwards in their decision process might have looked something like this:
- When we look at engineers who have been successful at Amazon over several years, what attributes do they share?
- Are these attributes different across teams?
- Are there any apparent biases in these attributes?
- Do these attributes appear to align with the attributes we think we’ll need over the next 5-10 years, or should we be looking for different ones?
These questions don’t need “artificial intelligence.” They need access to the Amazon performance review database, a little bit of SQL, and some forward thinking on the part of management.
Amazon spent four years and untold amounts of engineering code to answer the question they probably didn’t want to answer: yes, we’ve been biased in our hiring over the past ten years. Not how to hire better engineers going forward.
Princeton computer science professor Arvind Narayanan recently gave a talk on “AI snake oil” where he tangentially touched on the topic of bad questions. He breaks advances in AI into three rough categories:
- Perception (content identification, speech to text, facial recognition)
- Automating judgment (spam detection, essay grading, content recommendation)
- Predicting social outcomes (predicting recidivism, predicting job performance)
In “perception” tasks, AI has advanced to the point of human accuracy. Given enough data (which is itself a challenge) and compute, AI can get the job done. In “judgment automation” tasks, AI can mostly get there, but there is a band where humans may disagree. If I train a content recommendation algorithm on one human, but then try it out on a slightly different human, I may get slightly different answers. That’s not necessarily a problem, but it does mean that the data scientist needs to be concerned with how important that yes/no distinction is.
But with “predicting social outcomes,” we see abundant quantities of snake oil - and therefore bad questions. Dr. Narayanan walks through past experiments in predicting recidivism, showing that artificial intelligence methods prove no better than random scoring. And, more perniciously, it predicts “re-arrest” rather than “recidivism,” because that was what the available data tracked.
So not only does the algorithm not work, but it also starts to equate “re-arrests” with “criminal activity.” It doesn’t ever consider if the arrested individuals were later tried and proven guilty or innocent. It assumes that if they were arrested, they must have committed some criminal activity.
Code as leverage. It doesn’t make a question bad or good, but it does make a bad question worse.
If bad questions can be made into horrible questions with data science, how then do we ask good ones?
Suggestion 1: When considering questions, figure out how to solve them with human intelligence before adding data science.
Consider a data science task where we need to segment customers into groups based on likelihood of responding to a particular marketing message. This is commonly done with some sort of machine learning clustering task, but the need was first fulfilled by humans. You’d do focus groups that represented cross-sections of your populace, show them the marketing materials, then gauge responses. Clustering, at its best, is intended to identify better cross-sections of the population, but the ultimate need here is the same.
A human could perform a clustering task. The human would identify sensible numbers of groups (or, in this example, market segments). They’d consider the data available on each of their sample people and place that person into one of their groups.
We can describe our task alongside a human approach to solving the issue - thus, we have a way to validate if anything we do in data science makes sense. Would a human make the same choices given the same data?
Suggestion 2: Identify the discrete problem and describe an abstract solution before writing a single line of code.
On the surface, our marketing problem looks simple. “Break these people into groups.” But there’s nuance there.
“Break these people into groups” feels rough when we say it out loud, but that’s how a lot of data science tasks actually start without foresight. Segmenting into groups that are all 100 people wide, or segmenting into groups by age alone, or by state of residence, would all meet that task’s objective.
“Okay, okay,” you say. “Break this population into groups based on likelihood of responding to marketing.” But now I think: “does that mean ‘all’ marketing? Television versus radio versus online? What does response mean: they liked the ad or they actually went and bought something?”
“FINE.” you now say. “Segment this population into groups based on their likelihood of purchasing a product after viewing online marketing.” I continue to ask: “any product?” “Yes.” “Can you show me how we can track this through all of our systems now - from the advertising release, on through viewing, on through final sale?” “Sure, it’s like this.”
“Segment this population into groups” –> “Segment this population into groups based on their likelihood of purchasing a product after seeing online marketing.”
I have a discrete question now. What about my abstract solution?
Initially, this problem looked like a clustering problem (break into groups). After we refined the question, though, it starts to look like a classification problem. (Buys/does not buy product) We can start to say “my output should generate a ‘likelihood to buy product’ score for each customer. Then we’ll place all of those on a line and group into 0-20%, 21-40%, etc.
All of that was done and written down without a single line of code. But now we know what we want.
Suggestion 3: Map data to your proposed solution. Confirm that it’s the right data.
If we’ve confirmed our question and loosely confirmed our approach, our next thing to nail down is our data - which, in my anecdotal experience, tends to be where things break down most often.
Let us re-imagine our earlier market segmentation problem. Assume that the organization tracks marketing impressions and clicks, and assume that the sales team captures data at the time of sale. Seems great on our surface, right? But - maybe our marketing team has one system that uses a specific Target ID for each prospect, and the sales system has a completely different numbering scheme for sales accounts.
“FINE.” You say again. “I’ll join them on first name / last name and email.” But the sales team can’t give you that information, because it’s personally-identifiable information, and according to company policy it can’t leave the sales system. Your project might be dead on arrival, but that’s at least something you can find out (and hopefully fix) before your project gets started.
This problem is masked from many junior data scientists because so much pre-work goes in to getting it right. Kaggle competitions come with data. Managers should do plenty of pre-work to make sure their team has what they need to get started. A big leap forward in the data scientist’s career is realizing how to go get the data they need to solve the question that will have the largest impact to the business.
Dashboards and spreadsheets
When I first began writing this post, I started with a simple premise: sometimes a simple dashboard or a spreadsheet is the best way to solve a problem. Sometimes, when we frame our question in the right way, that’s all we might need. And that’s okay. That’s why the data scientists were brought in - to answer the need on the table, not try to rope in the niftiest new tech.
But when we get to the point where knocking through those dashboards and spreadsheets becomes rote, automated, and easy - then we open the door for the really challenging problems.
You should have a coach / you should be a coach
I became an official manager of people in 2017. At Deloitte, my current employer, this comes with a substantial shift in responsibilities. I began getting included in a lot more strategic discussions with our executives. My performance metrics started to include business development metrics (sales, marketing pieces, etc.) and my corresponding expectations for time spent on client projects on a day-to-day basis went down. This is all fairly comparable for how most professional services firms work as individuals move up in rank.
But with Deloitte, there’s something new added: I also picked up the title of “coach.”
A coach is a person a skip-level above you whose responsibilities are aimed at guiding you and championing you in your career. A coach has several responsibilities:
- to mentor their coachees
- to represent their coachees well during annual performance reviews
- to keep their coachees in line with the strategy of the business
- to expand their coachees’ networks to other leadership
- to make sure their coachees don’t accidentally step into problems due to inexperience
- to slap their coachees’ wrists when they fall out of line with compliance
- to help them grow their careers
This role (in my opinion) is the single greatest talent-growth differentiator we have. Every organization should have a program like this.
Interlude: a brief word on the environment
For some of our coaching structure to make sense, there are two key pieces of structural context you’ll need.
First, Deloitte is a professional services firm, not a product firm. We sell projects: doing taxes, or writing a research report on Belgian pastry law, or building a nifty dashboard for some arcane mainframe software. Most staff will work on 3-6 projects in a performance year, which means it’s entirely possible they may have just as many different managers. That’s different than most organizations where you have a pretty firm idea of who your boss is for a whole year.
Second, our annual performance reviews are decided by a group of our partners, not by an individual project manager. Sure, those project managers weigh in, but the decision is made by partners.
And, finally, Deloitte is a supermassive company with a lot of people spread out over the entire world. What I am describing below is my own experience in my own little corner of the company; to be honest, I’m nearly certain that the experience may differ across regions and countries.
With that context - let’s talk about coaching.
Everybody gets a coach
Everyone has a coach on their very first day. You don’t have to know anyone, you don’t have to even have an idea about your future path yet. Your first coach is assigned to you. That assignment is somewhat haphazard: it will typically be someone in your division and someone who’s running a little light on coachees (so the average coach has six coachees, but one coach recently had two people leave for another job, they’ll be first on the list for the new crop).
Naturally, this matchup might be suboptimal at first. It’s pretty common for a coach/coachee to get to know each other and realize their personalities aren’t a good fit, or that the coachee might be looking for a mentor with a similar (or different) background to their own. Because of that - coach switches are free! You literally email an address that’s on your own personal HR dashboard and say “I want to change my coach to this new person,” and it’s changed. There’s no review process, there’s no approval… it’s just done.
This assigned-but-changeable relationship gives us two perks: it gives the new folks an anchor point into the culture from the beginning, while giving them freedom to adapt as their knowledge and experience with the company grows.
Your coach represents you at your performance review
Recall our peculiar context: annual performance reviews are group settings, taking into account all of the different projects you may have dealt with over your year. The first thing every coachee learns is that their coach is their advocate with those group members. The coach weaves a cohesive narrative throughout the year and helps with some of the intangibles (like: “hey, this particular project was less great than the others because it was her first time doing this, so we should cut her some slack”).
In an ideal scenario, the coach and coachee should be regularly checking in throughout the year so the coach doesn’t have to try to wrangle a good performance story out of an avoidably bad one. There are no forced requirements for this. The one meeting at the start of the performance review and the one meeting at the end are the only “requirements.”
Your coach is there to grow you with the rest of the business
It goes without saying that direct managers have a broader view of the business’s strategy than a practitioner. And their managers have an even broader view of the business. We believe that giving people an avenue into that broader business picture - as they need it - is important for helping them grow. That’s why our coaches are a skip-level above their coachees. It lets coaches bring in some of that broader business throughout conversations with the coachee, letting them see how strategy is being shaped beyond the things they see every single day. And, on the flipside, it’s good for the coach: they get a vantage point into some of the front-line that they might not typically see otherwise.
Your coach is an arbiter between you and your front line managers
I think single points of failure are, as a general rule, not great. And having a single relationship (the manager/staff relationship) as a single point of failure for an individual’s career is not great, nor is it grounded in the reality of how most people’s day-to-day job operates.
Let’s give a hypothetical: we have a talented systems engineer who has worked great with the security teams and system administrators, but she doesn’t really enjoy working with non-technical people. A re-organization happens and our engineer is now on a team led by an MBA type who’s more of a product manager than an engineering manager. They butt heads. MBA type starts marking the systems engineer as difficult to work with in performance reviews. Engineer gets a bad review and no raise. Engineer bounces to go work for another company.
Now, let’s add a coach in to the mix. Remember, the coach is a skip-level rank above - not necessarily in the chain of command but certainly someone our hypothetical manager will likely know and respect.
Coach hears about the MBA vs. engineer personality divide in a check-in with their engineer. There’s the first opportunity to fix the problem: maybe the coach can offer some tips to help the engineer work better with their new boss. Okay, maybe that helps a little, but it’s still not great. So coach starts asking if maybe it’s better if the engineer changes teams to work more with security. Maybe that fixes it! Or maybe it doesn’t - and maybe the issue is that the engineer just isn’t going to be happy with the new regime. That happens too.
But at any rate, we’ve had several opportunities where the coach can both try to course-correct with their coachee, and where the manager will have to at least explain themselves to another person why they’re unhappy with that engineer’s performance.
Your coach is just there for you when you need to vent
Look, things happen. Sometimes your manager has an off day and makes a mistake that means the team has to stay late. Sometimes you get passed up for a promotion that you wanted (but maybe didn’t deserve yet). Working with people can sometimes be frustrating.
And sometimes you need a trusted mentor to just call and gripe to, without fearing that they’re going to judge you or that there will be repercussions for you needing to vent some steam. Coaches are there for that too.
I don’t think there is much debate on whether “coaches/mentors are good.” It’s pretty well-established that they are. But we take the next step and say “and organizationally, we are going to make sure each person has one and align our own processes around it.” That’s the next level and something that organizational leadership has to make a commitment to do. From this person who’s both a coach and coachee - it’s worth it!
Back in January of 2016, I began a series of monthly blog posts cataloging self-experimentation and meditations that I had experienced over the course of the month. I was capping a three-month binge on Tim Ferriss’s podcasts followed by a thorough reading of The Four-Hour Workweek and a stack of Tim’s blog posts. Something deep in my brain told me that I should begin a similar series of experiments along with associated documentation, and I jumped in. I gave up coffee for the first time. I started waking up at 5:30 for workouts. In my final post (January 2017), I just straight ditched food for a bit, inspired by the work of Dom D’Agostino.
Then, as many of my friends have repeatedly reminded me, I went radio silent.
Oh, sure, I wrote plenty of blog posts, but then I’d scrap them all as being mostly garbage. Nothing seemed to really resonate with me like the monthly posts of that year did. And it’s not like nothing happened, either! Major developments at work, changes in my physical fitness - hell, I even got engaged! Yet the words refused to come in a way that resonated with me. So I kept taking notes, and I waited.
This is a post about self-mastery.
This is not a post about self-determination, or self-experimentation. It is also not a post about skill-mastery.
When I was twenty-one years old, I wanted to control computers. I was unhappy about a lot of stuff - my long-distance relationship, my total lack of a job, the fact that my college and grad school programs weren’t really what I wanted but I was too chicken to take bold steps, you name it, I could find a way to gripe about it. So I got into MIT’s Intro to Computer Science course and I started learning how to control computers. I read TechCrunch diligently and was convinced that if I could just get a job as a developer, I could turn my whole life around. That would fix all of my problems.
Fast-forward to age twenty-five, and someone actually gave me a job as a developer. This is one of the worst things that can happen to you if you started learning how to program in order to change your life. Suddenly, you realize that actual software development can be sometimes really terrible. There is nothing about a career in software development that is actually designed to fix your life. You still have the same problems. This was the start of a pretty nasty downward spiral for me.
Somewhere in this mental morass, I stumbled upon a book list from Jack Dorsey, founder of both Twitter and Square. One of his top four books was The Yoga Sutras of Patanjali, a collection of proverbs on the classical philosophy of yoga. There is no discussion of stretching or postures - this book is about mental state and the philosophy of the self. It’s a religious text (and the translation I got had all the commentary), but it shook me up enough times that I returned to re-read it over and over. The first sutra: “Yoga is the stilling of the mind.” My mind was nowhere near “still”, but Patanjali was at least offering the idea that stillness was something attainable, and you had to practice to get there. It sounded better than the utter hellscape that was my then-current mental state of ambition in six different directions combined with second-guessing and a total inability to focus.
I tried everything. I diligently practiced meditation using whatever app I could get my hands on. I thought that some of Patanjali’s ideas on mindfulness might be easier to use if I saw them in a western Christian context that was similar to how I grew up, so I read Brother Lawrence’s The Practice of the Presence of God. I would try to intensely focus while lifting weights, something that had previously helped focus me in the past. I tried to find focus in code. I got a new engineering job, one that made me feel more “developer-like.” It all culminated in a series of fairly epic panic attacks, and then I discovered Tim Ferriss. (I wrote about all of that here)
Now we’re all caught up to the start of those monthly blog posts, so I can start talking about self-mastery.
Tim Ferriss’s interviewees are experts in their respective fields. They might be major celebrities, or they might be total unknowns, but they are unquestionably experts in something. I hoped to one day be an expert in something, though I didn’t know what. I thought that maybe if I copied what they did, I could be like them. My initial model was Tim himself, who is basically an expert in relentless self-experimentation and writing it all down. Anyone can do that, so I tried it out. Then I took Jocko Willink as inspiration too, so I started waking up super-early. I liked Jamie Foxx’s workout plan, so I started doing lots push-ups and pull-ups. I relentlessly copied EVERYONE.
When you’re trying to learn a skill, you can pretty much take whatever route works best for you to get there. I know that I learn computer science concepts most effectively if I read and take notes as opposed to watching videos. The reverse is true for weightlifting, where I’m better if I just watch a video and emulate it in the mirror than if I read about it. When you’re trying to emulate a person, though, you have to do what they do. “How hard could that be?” I thought. All of the steps are laid out in front of me, I just have to go do them.
Jocko Willink wakes up at 4:30 every day and posts a photo of his watch to Instagram. Jocko sells t-shirts that say “Discipline equals freedom.” Jocko was once asked how to be tougher, and his answer was “if you want to be tougher mentally, it is simple: be tougher. Don’t meditate on it. Just be tougher.” Jocko was asked how to avoid injury during BUDS training and his response was “be tougher.”
I tried and failed to emulate Jocko’s level of discipline. I like drinking beer and playing video games and sleeping in. Jocko does none of these things, because Jocko is constantly preparing and training himself. I said I wanted to act like Jocko, but I didn’t want to give any of those things up.
It’s not just Jocko who constantly reminds me of my total lack of self-mastery, though. My roommate Lauren wakes up every morning to hit the gym before 6:00AM and has typically logged a workout by the time I’m pouring my first cup of coffee. My friend and coworker Brian regularly puts his daughter to bed and then goes into his basement lab to take a Coursera course so he can keep learning, while I am figuring out which new game on Steam I want to buy. My fiancée Linda is able to totally forget about Internet distractions and actually enjoy the world around her, while I can’t stop fidgeting with my phone and regularly have to delete social media apps just to stop playing with them.
I am writing a post about self-mastery because I am not yet a master of myself.
I think I can get there. I think I had to first recognize that there were examples out there and I needed to try to copy them. I needed to fail first to recognize what self-mastery really looked like. And then, after I failed, I needed some processing time to recognize that the strides I took to actually get to failure had put me not too far off from a place I wanted to get to anyway! My relationships are in a happier place. I’m in a much more enjoyable career.
My first steps in processing that failure was to simply wave my hands and say that it was all fine. I would look at my successes, say “can’t be good at everything” and move on. But it didn’t stop the gnawing feeling that I could do better. I’m still frustrated when I lose mastery over myself and sleep in past when I told myself I’d wake up for yoga, or when I grumpily snap at my fiancée because I do not have mastery over which words come out reflexively. Shrugging those types of things off is not acceptable to me, and they are regular reminders of my own lack of mastery.
This is where my head is now, pondering on how to better master myself. I welcome advice and wisdom.