Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Learning about personal finances.
- Notes on hiring a Foundation Eng leader.

Learning about personal finances.

Having a kid around has changed my perspective on many things, among them wanting to get more consistent in how our family approaches financial decisions. This is an area where I’ve spent a fair amount of time educating myself over the past decade, and I thought it might be useful for folks to see how my thinking has developed over my career, particularly given I started out knowing absolutely nothing on the topic.

For the first six years of my career, I accumulated money in a bank account. I didn’t have a 401k. I didn’t participate in the Employee Stock Purchase Plan when I was at Yahoo. I just kept money in a low interest bank account. I’d like to pretend this was because I was shaken by starting my technology career during the 2008 financial crisis, but the truth is that I simply didn’t know anything about handling money. I didn’t spend much, and kept the rest in my bank account.

Over time, I felt increasingly uncomfortable with my growing bank account, and after six years I decided to figure out something different. I started maxing our my 401k, read up on the advent of roboadvisors, spent some time researching the options, and read A Random Walk Down Wall Street. Based on what I learned, I decided to open a robo-advisor account, and moved my accumulated cash there over the course of a year or so.

Some folks are critical of robo-advisors for their fees (typically 0.25% annually of Assets Under Management), but they’re about a quarter the price you’d pay a financial advisor (who generally start at about a 1% AUM fee). The proposed alternative is to directly invest the money yourself, which I think misses the point: I felt uncomfortable investing, so the competing alternative for me was not investing at all, which is much more expensive than a 0.25% AUM fee. Also important is that robo-advisors rely on low expense ratio funds that significantly improve performance over time and provide the safety of a broadly diversified portfolio; I could have easily invested my own money in an inefficient way that easily outweighed the management fee.

For the next seven-plus years I had a recurring monthly transfer from my bank account into my robo-advisor account. The only thing I changed was occasionally tweaking the size of the transfer, although I did start working with a tax accountant to handle the complications of startup equity. This worked well for me, and in the background I slowly educated myself, in particular starting with the r/financialindependence faq and Bogleheads faq, as well as lurking in the associated forums to soak up information.

I’ve remained generally happy with my robo-advisor, but have slowly developed my point of view on the details of how I want to be investing. It’s also shifted from being my perspective to instead our perspective as my wife and I combined our finances and financial decision making. Changes kept accumulating: our first child, our first home, increased charitable giving, opportunities to angel invest, and so on. Altogether, our situation became far more complex than an automated monthly deposit could handle.

For folks following the Bogleheads methodology, the answer to this problem is writing an investment policy statement (IPS). Your IPS describes your investment strategy and is intended in particular to force you to make consistent long-term decisions rather than short-term reactions to the current market. It’s a personal document with the goal of describing your approach rather than articulating any generalized truths about investment.

Over the past few months we’ve been working on this, coming to our current plan of:

1. Pursue moderately aggressive growth – we want to optimize growth through low cost and diversified funds
2. We manage passively – we don’t want to spend much time managing our portfolio. We’re comfortable holding assets through the market crash and recovery cycle. We don’t believe short-term financial decisions are effective. We don’t invest in speculative offerings
3. Be able to retire by fifty – we’re both planning to work for another 15-25 years, but we aim to be able to retire by fifty, particularly given this year’s reminder that stopping work isn’t always a voluntary choice
4. Keep a six month emergency fund – we keep this in a savings account, with an emphasis on accessibility, we don’t worrying about our emergency fund’s interest rate
5. 80% stocks, 20% bonds – we have a lot of working years ahead of us, and want to maximize gains. We plan to hold this ratio for the foreseeable future as a fairly aggressive portfolio, revisiting every ten years
6. For stocks, target 70% domestic, 30% international; for bonds, domestic bonds – we don’t have a target across large, mid and small cap, preferring funds that manage that mix for us. We similarly don’t have goals around REITs, etc. This yields a three fund portfolio for us (domestic stock index, international stock index, domestic bond index), selected from recommendations in Bogleheads wiki
7. Don’t overthink fund placement - we follow the general guidance of tax-efficient fund placement, but don’t spend too much time worrying because there’s a reasonable level of uncertainty on which particulars will be best
8. Omitted here, the full version of our investment policy also includes (1) how we size our participation in charitable giving, campaign giving, and angel investing, (2) our approach to owning versus renting a home, (3) how we want to hold and pay housing mortgages, (4) and a few other bits and pieces

This is just our plan, and it’s by no means the right plan. What works for us right now isn’t what many folks would select for themselves, and that’s great. I’m also certain what we’re doing in a decade may be a bit different than what we’re doing today. Starting from a place of total confusion about financial planning, I’ve come to appreciate that it’s much more valuable for me to make safe, reasonable decisions this month than to pursue some sort of perfection next year (no one agrees on what a perfect financial plan means anyway).

If I could go back and start over, the biggest thing I would change is simply getting started earlier. I wouldn’t worry for a second about the somewhat less efficient initial choices I made, e.g. using a robo-advisor, as they were always an appropriate balance between my comfort level and financial efficiency. If you’re in a similar place to where I was in my early career, my biggest advice would be to start now, and to start cautiously.

More concretely, r/financialindependence faq, Bogleheads faq, and A Random Walk Down Wall Street have been particularly valuable for me.

Notes on hiring a Foundation Eng leader.

I’ve recently had a few folks reach out for advice on hiring a Foundation Engineering leader based on my supporting that organization at Stripe. The first challenge with the question is defining what “Foundation Engineering” even means!

I joined Stripe to work with the “Sys” engineering group, which was short for “Systems,” and there were about thirty folks in Sys within the larger infrastructure organization that had… maybe sixty folks working across data, developer tools, financial infrastructure, and so on. We adopted the Foundation title about a year later when the engineering organization did a reorg that joined Sys with Data and Developer Experience, and moved away from having an explicit Infrastructure organization. The Developers group, focused on external developers, joined us a bit later, and at the point I left the overall group was about two hundred and fifty folks.

The major takeaway being that while the scope of a small engineering organization is a relatively pure concept, the boundaries of a larger organization are typically defined by circumstances, constraints, and chaos. The Foundation organization I worked with was broad and pragmatic, and it’s dangerous to pattern match hiring leaders before understanding the details of the role you’re hiring.

To focus your search a bit, there are three questions I’d recommend spending time with:

1. Is your business fundamentally enabled or differentiated by the technology you need this team to build? (For example, I occasionally get to chat with Jasmine Tsai who leads engineering at Mux, and streaming technology is their product rather than technology that enables their product.)
2. Is this a one-domain leader or a multi-domain leader? (For example, are you looking for a data engineering leader, an infrastructure engineering leader, a developer experience leader, or someone who spans multiple domains?)
3. If your organization scales rapidly, will you hire under or over this particular hire? (Same example as for multi-domains above.)

If you answer yes to the first question, then good news: you shouldn’t be hiring a Foundation leader, but instead a domain expert with experience in product engineering plus whatever your specific technological need is. I’d even argue that you probably shouldn’t be hiring a people manager here at all, but instead a staff-plus engineer. Even if you are absolutely certain you need a people leader, I’d push you to think through your reasoning once more.

If you’re still convinced you want a Foundation engineering leader, then it comes down to a choice between a:

1. systems operator who is great at operationalizing, scaling, and structuring systems, and brings structure to chaos while working with eight to 30 engineers,
2. organization builder who is a systems thinker, reasonably experienced at the fundamental domain problems but trusts expertise of others (e.g. not a solo architect who also views themselves as a people leader), and an effective hiring manager for 20-plus engineers

If you want a multi-domain leader or someone who will hire underneath themselves, you probably want the (organization) builder. Otherwise you probably want the (systems) operator. If you want a builder for a team below twenty, they’re probably going to either (1) struggle to make an impact or (2) scramble to hire into the size they’re effective in.

A few thoughts on hiring for these roles, as well as selecting which of the roles to hire:

• System thinker who is reality-based. I used to believe that systems thinking was the fundamental skill for the sorts of work that gets bundled into Foundational Engineering roles. I still believe it’s essential, but I’ve worked with too many systems thinkers who prioritize how things should work over how things actually work. When these folks run into trouble, they often focus on rejecting reality rather than refining their model. This doesn’t work! When system thinking and reality conflict, reality is always right, and rejecting that is a sign of poor judgment
• An operator’s job is providing a predictable environment for product engineering to create a business. Young organizations have mundane infrastructure problems and the operator’s job is to deploy mundane solutions to those mundane problems. An extraordinary infrastructure platform in a young organization will be mostly invisible, creating a solid foundation for product engineering to build a product (which in turn allows the wider company to build a business). Prefer folks who are willing to compromise infrastructure purity for medium-term product velocity. I’ll note that “medium-term” is load-bearing in this sentence, and explicitly different from short-term (this month) and long-term (next year)
• Many successful operators have exposure to Site Reliability Engineer practices. The core SRE practices around creating operable systems and software are invaluable for the operator’s work: things like effective on-call rotations, running incident reviews, determining who owns which pagers, and so on. I stop short of strongly recommending SRE experience primarily because some organizations indoctrinate their SRE teams into a fixed mindset about how things “must work” and that mindset fosters idiomatic leaders that struggle to partner with others, typically to the detriment of product engineering velocity (which is generally the most important thing they’re supposed to enable)
• The builder’s job is balancing business goals against developer experience. As the organization gets larger, the challenge shifts to offering the best developer experience you can to internal engineers while also meeting your security, compliance, cost, and stability obligations. The fundamental challenge is maintaining a good developer experience in the presence of these business constraints, and while also scaling your organization
• Prefer builders who’ve been an operator. It’s very hard to operate an effective organization if you haven’t worked within an organization to understand how it feels to be operated upon. A builder who’s been an operator will build more trust with less thrash
• Prefer builders with software engineering experience. I’ve personally found that the empathy and experience from working as a software engineer is very valuable in the builder role. As always, you can absolutely build a team that compliment a particular skill gap, but this is so fundamental to the builder role that I think you’d end up implicitly two-in-a-boxed if your candidate lacks this experience (as an aside, I personally think the linked article undersells the challenges of the two-in-a-box model)
• Avoid builders who lean on hiring as their first tool. Hiring is essential, but it’s also the least creative way to solve capacity problems. It’s a sign of inexperience or inflexibility to lean on hiring as the first tool to create capacity. Hiring is absolutely an essential tool to use after you understand your constraints, but its a concerning starting place

That’s enough writing fodder for folks thinking about the Foundation leadership profile they want to hire, so I’ll wrap it up with two final thoughts. First, it’s fairly challenging to find folks who do well on all dimensions of the builder profile, and they’re likely already considering quite a few opportunities. Second, even if you feel confident because your team includes an operator who you hope will grow into the builder role, many operators struggle transitioning to builders without active support broadening their skillset.

As is usually the case, there is no free lunch.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!