Takeaways, Part I 🗒
As I reflect on my career up to this point and think about what comes next, I often find myself thinking back on each phase of my career up to this point and on the things I’ve learned from each phase. There’s way too much to cover in a single issue, but I’m going to start here with my first “real job” and I may decide to continue this as a series to cover other learnings from later organizations and roles.
I’m going to start with my first real, full time job: I joined a New York hedge fund nearly 20 years ago fresh out of college, and worked there for almost six years on things ranging from IT support to risk modeling and everything in between. Here are some of the useful mental models I learned there.
Thing #1: Rigor and Discipline 🏋️♂️
The number one thing I learned, and the number one thing I was trained to do in this role, was to apply strong rigor and discipline to whatever task is at hand. I don’t remember this ever being stated explicitly, but it was a core part of the company culture. We were shown through practice that there’s an easy and a hard way to accomplish any task, and the easy way is pretty much always the wrong way. What’s more, while the hard way is by definition more difficult, it’s often not that much harder, and the results are usually much better. It’s a lesson I use literally every day in my career and in my personal life, and I’ve really taken it to heart since I consider excellence and rigor among my most important personal values.
The most obvious example in my daily life has to do with writing software. There are many ways to write software and many different kinds of software development. When given a task or starting a project most developers are inclined to jump in and start throwing code at the problem. It took me a long time to understand why we’re like this, but for me, at least, it’s because I think best in code, so it’s easier for me to analyze a problem by attacking it with code than with, say, words, numbers, diagrams, or spreadsheets. Throwing code at a problem is the most natural way for me to analyze and understand it.
The problem is that this is the easy way to write software. The hard way involves a lot more careful planning and design work. Any code you write within the first few days of beginning to work on a big project is almost always code that you’re going to need to throw away anyway, so you should take a step back and get the design right before you jump in. It can feel frustrating and less exciting than starting to build, but it’s less frustrating than building something that you later need to throw away and rebuild. I’ve learned this lesson the hard way countless times.
The initial design process almost always involves back and forth with other people, since others are much better able to see and compensate for flaws in your ideas and design. Having said that, I’ve recently found that modern AI tools can at least partially fill this need. When I began working on the Athena project earlier this year I really wanted to jump in and start throwing code at the problem. In the end I spent nearly two months doing planning work before starting to build Athena, and I think the result of that work speaks for itself.
The reality is that there’s a good way and a bad way to ship code. The bad way amounts to spaghetti code: no tests, no comments, no documentation. It’s the sort of “write only” code that you look at again a year or two later and, despite having written it yourself, you have absolutely zero chance of maintaining or improving (to say nothing of handing that task to someone else). The good way is the difference between being a script kiddie and a software engineer: designs, documentation, tests, environment, third party tools and APIs, CI/CD, a real database, the whole nine yards. It can be a pain to set up all of these things when working on a new project, and it’s okay if it’s done incrementally, but these are absolutely part of the “hard” way of writing software that’s also the right way.
This lesson applies to literally every area of life. There’s an easy and a hard way to communicate with the people you care about, and the hard way involves a lot of brutal honesty and difficult conversations but leads to healthier long-term relationships. There’s an easy and a hard way to work out: the easy way involves going for a short jog every once in a while, and the hard way involves consistently pushing yourself to the limit in strength, endurance, and flexibility. There’s an easy and a hard way to eat: the easy way involves takeout and delivery, and the hard way involves sourcing quality ingredients and preparing your own meals. There’s an easy and a hard way to wellness: the easy way involves diet pills and surgery, the hard way includes everything I recently wrote about here. Taken together, these hard approaches to working out, eating, and overall wellness are a lot of work but contribute massively to longevity and quality of life. Heck, there’s even an easy and a hard way to pack a suitcase, and take my word for it as a frequent traveler, it makes a difference!
Hedge funds like the one I worked for consistently outperform the market because they have a dedicated team of hardworking professionals who put in the hours to conceive of, design, rigorously test, and execute on novel trading strategies (and because they have enormous other resources at their disposal). That’s something else I learned: there are no shortcuts to this hard work, and while you might get lucky from time to time, there’s no easy way to consistently beat the market.
During my time working in finance I found this to be a helpful metaphor for life more generally. In life as in the market, hard work may not be a sufficient condition for success—you need a degree of talent, and luck, too—but it’s necessary for any form of meaningful, lasting success.
In my experience the easy way tends to get you in trouble and more often than not leads to significant additional work, while the hard way always pays dividends down the line.
Pick the hard way.
Thing #2: Big Picture Thinking 🖼️
Another important lesson from this job was big picture thinking.
There’s a time and a place for detailed thinking and analysis, and there’s a time and a place for big picture thinking and analysis. The initial design phase of a project, as described above, involves big picture thinking, analysis, and planning. Writing the actual code involves detailed thinking and execution. It’s critical to be able to differentiate which scenario calls for which form of thinking, and to be able to effectively switch back and forth between them.
When it comes to big picture thinking, there are a few mental models that are especially helpful. One which I’ve written about before is the 80/20 rule, otherwise known as the Pareto principle. I wrote about it before because, while it’s a bit counterintuitive when you first learn about it, it’s also fantastically useful. I was first introduced to it in this job, and I continue to use it every single day, personally and professionally.
For instance, you get 80% of the benefits of financial portfolio diversification from the first 20% of the portfolio contents; squeezing out that last 20% is an expensive, laborious, time-consuming process. In data analysis you get 80% of the results from the first 20% of the data; that last 20% will take a very long time, including gathering, cleaning, and fixing bad or missing data. As an investor 80% of the profits you make will come from 20% of the assets you invest in; the other 80% will break even or lose money. There are countless other examples.
Another useful form of big picture thinking that I learned in this job is thinking in orders of magnitude. I was first introduced to the concept in my undergraduate computer science courses when we learned about Big O notation, but it didn’t click at the time. I had to use this tool again and again before I began to understand its power and importance.
Before this, I used to think of math as being about precision: there’s one right answer and many wrong answers. That’s true of high school math problems but it’s almost never true of problems in the real world. For one thing, many problems don’t have one right answer, they have a range of acceptable answers. For another, coming up with an answer that’s approximately right, e.g., within one order of magnitude, is usually not too hard and is usually good enough. And it’s perfectly fine as a first estimation that you can work to refine.
And, yes, the 80/20 rule and thinking in orders of magnitude are related. In my experience, coming up with that initial, order-of-magnitude answer, takes around 20% of the effort and gets you around 80% of the way to the solution to a problem.
There are countless examples of how this, too, is useful. The most obvious is the application in engineering that I already mentioned. It’s not necessary to know exactly how many CPU cycles running a program takes, but knowing the order of magnitude with respect to a particular variable, e.g., the size of the input, gets you most of the way there. The same principle applies to use of storage space, network bandwidth, or any other scarce resource.
It also applies to spending and cost management: as a manager I don’t need to know precisely how much each spending activity is going to cost down to the last dollar, but summing orders of magnitude (e.g., “a few tens of dollars plus a few hundreds of dollars plus…”) will give me a pretty good overall budget estimate with a reasonable degree of certainty. And it’s useful in project planning: it may be impossible to estimate how long a given project is going to take, but it’s much easier to determine that it’s going to take, say, hours, or days, or weeks, or months, which is already fantastically useful information for planning purposes. When doing an exercise like this it immediately becomes obvious which cost or time drivers dominate all of the others due to their higher order of magnitude, which often allows simplifying the math considerably.
One trick: in addition to thinking in orders of magnitude, it’s very helpful to also have a sense of whether your estimate is an overestimate or an underestimate. When summing estimates you can account for these differences, which tend to net out over many items.
This mental model is useful in many other areas. Thinking in orders of magnitude means thinking in logarithmic, rather than linear, terms. I didn’t originally understand why it makes sense to plot certain exponential phenomena, such as compound interest, the spread of disease, and the development and spread of technology (think: Moore’s law), on a log scale. The log scale is a fantastic tool, as it shows changes in relative rather than in absolute term: i.e., it allows us to visualize changes in the rate of growth or decay.
Big picture thinking is useful regardless of the type of work you do, but it’s especially useful for entrepreneurs because of its synergy with bias for action. Waiting until you have complete or perfect information before making a decision is nearly always a mistake, at least in business and engineering, and it’s the sort of thing that kills startups. But you do need some information before making a decision. Knowing that you’ve spent 20% of the time and gathered 80% of the data, and that you can estimate the results to within an order of magnitude, is what you need to confidently make a decision and take action.
All of these concepts were new to me when I began working in finance, and today they’re all such second nature that I don’t even notice myself relying on them, but I know that I use them every single day.
Thing #3: Emperor’s New Clothes 🧥
Everything in finance initially felt mysterious. I had a solid education in computer science, engineering, and math, but the rest was new. I didn’t understand how financial markets work. I didn’t understand the different kinds of securities, how they’re priced, and how they’re traded. Despite working at one, I had no idea what a hedge fund was, what it did, or how it made money.
After six years with the company I had answers to many of these questions, but not to all of the big ones. In particular, while I had a good understanding of the firm’s activities, of the sorts of markets and assets it dealt with, and especially of the asset classes I worked with, I still didn’t fully understand how we made money. In fact, this was one of the main things I worked on: a task called PnL attribution (PnL stands for profit and loss, or profit-net-loss), which is a euphemism for figuring out how we made (or lost) money.
In a reductionist sense you can think of the financial markets as a big black box. At one end you input trades and positions, and at the other end the box outputs PnL (profit or loss). What happens in between is a mystery. We had a pretty good idea how much money we made and lost overall, although even calculating that was tricky. But figuring out which trades had led to which PnL numbers was very complicated, especially given that the firm routinely placed millions of trades in a single day and that many of them overlap.
In the beginning I assumed that the more senior folks at the firm knew precisely what was going on. I assumed that it was either beyond my comprehension—I just didn’t have the necessary experience or understanding—or that I wasn’t privy to all of the relevant information. What I learned over time, however, is that even the most senior people didn’t have a much stronger grasp than I did of the reason behind the PnL numbers.
I’m not sure they understood this, and they may disagree with the characterization. They would surely offer rationalizations, discuss macro market moves and our high degree of expertise, etc., but my very strong sense was that we were actually flying by the seat of our pants. Or, as one of my colleagues more colorfully described it, we continued to turn the crank on the money machine and it continued to spit out dollar bills, but we didn’t fully understand the machine.
I call this the secret of high finance. It can feel like the economy is rigged, that it’s controlled by a cabal of fat cat financiers smoking cigars in dark rooms. I’ve been in some of those rooms before, and I can tell you from personal experience: those fat cat financiers don’t know much more than you and me. This is one reason I find conspiracy theories of this nature unbelievable: the people in charge just aren’t intelligent enough, organized enough, or hard working enough to pull it off.
I’ve since seen the same phenomenon play out in multiple industries and in multiple organizations that I’ve been a part of. The junior folks trust the senior folks and assume that they know what’s going on. They trust that they’re in good hands. But the senior folks are just junior folks who stuck around long enough, or sucked up enough, to be promoted a few times. On average they’re not smarter or more resourceful than their juniors. On average they’re not much more well informed. Sure, executives have a lot of information coming at them all the time, but it’s not all relevant, useful information. And the junior folks, like myself at the time, are the ones in the weeds with their hands in the data day to day. On the things that count the most, it’s safe to say that the most junior folks are often the most well informed. (While it’s unfortunately quite rare, there are a few business leaders who make a specific point of communicating directly with rank-and-file staff. You can see a difference at these organizations.)
In short: the junior folks trust the senior folks and assume they know what’s going on. In fact, the senior folks often have no idea what’s going on, but would never admit this. And the junior folks are unafraid to call the senior folks out on this fact. Perhaps a better name for this phenomenon is the emperor’s new clothes theory of management.
Put another way: there are no important people. There are people who have been there longer and people who joined more recently. There are people in positions of greater influence and authority, and people in positions with less influence and authority. But this doesn’t make such a “senior” person more important, and it doesn’t mean that they actually know what’s going on, or why. Senior folks are often partially checked out, and anyway deal with abstract management and strategy-related topics.
This framework has also been helpful throughout my career. I recommend looking for knowledge and leadership from every corner of an organization, and ignoring the opinion of someone more junior at your peril.
And never believe that someone else is more important than you.