Irrational Exuberance content on Irrational ExuberanceHugo -- gohugo.ioen-usWill LarsonSat, 11 Sep 2021 09:00:00 -0700Learning about personal finances., 11 Sep 2021 09:00:00 -0700 <p>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.</p> <p>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 <a href="">Employee Stock Purchase Plan</a> 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.</p> <p>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 <a href="">advent of roboadvisors</a>, spent some time researching the options, and read <a href="">A Random Walk Down Wall Street</a>. 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.</p> <p>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 <a href="">low expense ratio funds that significantly improve performance over time</a> and provide <a href="">the safety of a broadly diversified portfolio</a>; I could have easily invested my own money in an inefficient way that easily outweighed the management fee.</p> <p>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 <a href="">r/financialindependence faq</a> and <a href="">Bogleheads faq</a>, as well as lurking in the associated forums to soak up information.</p> <p>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 <em>my</em> perspective to instead <em>our</em> 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.</p> <p>For folks following the Bogleheads methodology, the answer to this problem is writing an <a href="">investment policy statement</a> (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 <em>your</em> approach rather than articulating any generalized truths about investment.</p> <p>Over the past few months we’ve been working on this, coming to our current plan of:</p> <ol> <li><strong>Pursue moderately aggressive growth</strong> &ndash; we want to optimize growth through low cost and diversified funds</li> <li><strong>We manage passively</strong> &ndash; 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</li> <li><strong>Be able to retire by fifty</strong> &ndash; we’re both planning to work for another 15-25 years, but we aim to be able to retire by fifty, particularly given <a href="">this year’s reminder</a> that stopping work isn’t always a voluntary choice</li> <li><strong>Keep a six month emergency fund</strong> &ndash; we keep this in a savings account, with an emphasis on accessibility, we don’t worrying about our emergency fund’s interest rate</li> <li><strong>80% stocks, 20% bonds</strong> &ndash; 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</li> <li><strong>For stocks, target 70% domestic, 30% international; for bonds, domestic bonds</strong> &ndash; 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 <a href="">from recommendations in Bogleheads wiki</a></li> <li><strong>Don’t overthink fund placement</strong> - we follow <a href="">the general guidance of tax-efficient fund placement</a>, but don’t spend too much time worrying because there’s a reasonable level of uncertainty on which particulars will be best</li> <li>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</li> </ol> <p>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).</p> <p>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.</p> <p>More concretely, <a href="">r/financialindependence faq</a>, <a href="">Bogleheads faq</a>, and <a href="">A Random Walk Down Wall Street</a> have been particularly valuable for me.</p>Notes on hiring a Foundation Eng leader., 09 Sep 2021 09:00:00 -0700 <p>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!</p> <p>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.</p> <p>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.</p> <p>To focus your search a bit, there are three questions I’d recommend spending time with:</p> <ol> <li>Is your business fundamentally enabled or differentiated by the technology you need this team to build? (For example, I occasionally get to chat with <a href="">Jasmine Tsai</a> who leads engineering at <a href="">Mux</a>, and streaming technology <em>is</em> their product rather than technology that enables their product.)</li> <li>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?)</li> <li>If your organization scales rapidly, will you hire under or over this particular hire? (Same example as for multi-domains above.)</li> </ol> <p>If you answer yes to the first question, then good news: you shouldn’t be hiring a Foundation leader, but instead a <strong>domain expert</strong> 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 <a href="">staff-plus engineer</a>. Even if you are absolutely certain you need a people leader, I&rsquo;d push you to think through your reasoning once more.</p> <p>If you’re still convinced you want a Foundation engineering leader, then it comes down to a choice between a:</p> <ol> <li><strong>systems operator</strong> who is great at operationalizing, scaling, and structuring systems, and brings structure to chaos while working with eight to 30 engineers,</li> <li><strong>organization builder</strong> 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</li> </ol> <p>If you want a multi-domain leader or someone who will hire underneath themselves, you probably want the (organization) <em>builder</em>. Otherwise you probably want the (systems) operator. If you want a <em>builder</em> for a team below twenty, they&rsquo;re probably going to either (1) struggle to make an impact or (2) scramble to hire into the size they&rsquo;re effective in.</p> <p>A few thoughts on hiring for these roles, as well as selecting which of the roles to hire:</p> <ul> <li><strong>System thinker who is reality-based.</strong> I used to believe that <a href="">systems thinking</a> 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 <em>should</em> work over how things <em>actually</em> 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</li> <li><strong>An operator’s job is providing a predictable environment for product engineering to create a business.</strong> 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)</li> <li><strong>Many successful operators have exposure to Site Reliability Engineer practices.</strong> The <a href="">core SRE practices</a> 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)</li> <li><strong>The builder’s job is balancing business goals against developer experience.</strong> 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</li> <li><strong>Prefer builders who’ve been an operator.</strong> 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</li> <li><strong>Prefer builders with software engineering experience.</strong> 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 <a href="">two-in-a-boxed</a> 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)</li> <li><strong>Avoid builders who lean on hiring as their first tool.</strong> 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</li> </ul> <p>That&rsquo;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.</p> <p>As is usually the case, there is no free lunch.</p>Closing calls: tell the best version of the truth., 26 Aug 2021 07:00:00 -0700 <p>Quite a few companies run you through their interview process, send you an offer nestled in a beautifully designed packet, and finish with a recruiter who’ll ask whether you accept the offer. This is the foundation of a <a href="">hiring funnel</a>, but it’s missing one valuable step: the closing call.</p> <p>By the end of your hiring funnel, both you and the candidate have already invested a lot of time, and even slightly nudging them towards a “yes” will significantly improve your hiring efficiency. (Another prospect for “most valuable hiring step” is the initial phone screen, as it allows you and the candidate to skip most of the process if they’re unlikely to be the right candidate for your role.)</p> <p>Despite the closing call being a key step, my experience is that very few companies train their managers on how to close candidates effectively. That’s a shame because it’s a pretty straightforward process that comes down to:</p> <ol> <li><strong>Offer a closing call</strong>: many folks won’t take you up on it, but all appreciate the offer, and the folks who take you up on it are always a good time investment</li> <li><strong>Show up prepared</strong>: show up on time, be familiar with the candidate’s background, and be ready to articulate why you joined (and are still at) your company. If you won’t prepare for five minutes, then don’t do closing calls; you’ll end up signaling to the candidate that they aren’t a priority</li> <li><strong>Ask what the candidate would like to discuss</strong>: start every closing call by explicitly asking what they’d like to cover. If you ask, most candidates will tell you directly what they’re concerned about. If you start talking before understanding their concerns, you will waste the closing call’s opportunity</li> <li><strong>Tell them why the role addresses their concerns</strong>: once you understand the candidate’s concerns or questions, your challenge is to articulate why this role is the best career step for what they’re looking for. The artistry of the closing call is finding the most compelling path between their starting concerns and accepting your offer. Infrequently even art is no salvation, and you’ll come to realize that the role really doesn’t give the candidate what they’re looking for. That’s disappointing in the moment, but it’s far better to realize now than after they’ve joined</li> <li><strong>Clarify next steps and offer more time</strong>: end the call by explicitly stating the next steps, as well as letting them know you can make more folks available for discussion</li> </ol> <p>If I’m pressed for time to explain these steps, I condense them to two ideas:</p> <ol> <li><em>ask for the candidates concerns</em></li> <li><em>answer them by telling the best version of the truth.</em></li> </ol> <p>It can be tempting to oversell in the closing process to get someone to accept, but don’t get distracted by the shiny lights; you can only retain talented folks by telling them the truth and framing why the truth is a good situation for them.</p> <p>Of course, my approach isn’t the only way to run closing calls. Because companies don’t train their managers on closing calls, folks end up developing their own personal style, and you may find a different approach works best for you. As you evolve your closing call, keep truth and authenticity as your north stars. Sometimes folks want to see friction between honesty and accomplishing a particular goal (e.g. hiring this candidate), but the tension fades away once you frame yourself properly (e.g. retaining an effective coworker).</p>Create capacity rather than capture it., 17 Aug 2021 07:00:00 -0700 <p>Most growth companies are starved for experienced leadership. As they expand, continued growth builds up pressure on their existing leadership. This gets quite stressful! The rare executive manages to build an effective organization solely by investing in their existing team, but most supplement their organization with some external hires to maintain a balance of folks who’ve seen it before and folks who’re actively learning their role.</p> <p>If you’re an executive challenged by your company’s growth, it’s a particularly sweet moment to hire an experienced external leader. Once you’ve hired someone experienced, often more experienced than you, it’s easy to shift your attention towards your next biggest fire. This <em>can</em> work out if you’ve hired a self-aware leader whose experience extends across growth and startup companies, but more often I’ve seen the hire-and-forget formula go poorly.</p> <p>Especially for folks who are very effective in larger companies, there are implicit leadership lessons they’ve learned in a large company environment that can get in their way. Within all those implicit lessons, there is one I’ve encountered frequently enough&ndash;and seen it do enough damage&ndash;that I explicitly warn folks about it: <em>within a large company, it’s more effective to capture existing capacity than to create new capacity</em>, <em>but the opposite is true in startup and growth companies</em>.</p> <p>Several versions of that lesson learned from succeeding in a large company:</p> <ul> <li>If you need more headcount, then convince leadership to require every team to send a volunteer to work on your project</li> <li>If you’re missing a key leader, oblige a leader on a peer team to move to yours</li> <li>Hiring is slow and restrictive, bypass that by recruiting internally instead</li> </ul> <p>While my lived experience suggests that competing for existing capacity is pretty ineffective&ndash;to say nothing of the atmosphere it creates among colleagues&ndash;it clearly <em>appears</em> to work sufficiently well to get the folk using it promoted.</p> <p>Startups and growth companies are different. There is very little present capacity relative to the required capacity a year out. If you’re focused on capturing capacity that exists internally today, then your company is going to fail in a year. Sure, your project might be doing fine when the company fails, but whereas large companies anticipate a meaningful fraction of projects will fail, growth and startup companies depend on almost all projects succeeding.</p> <p>After encountering the misalignment this mindset creates a number of times, my fundamental piece of advice for folks working in startup and growth companies is: <strong>create capacity rather than capture it.</strong></p> <p>If you dig into cases where large company leaders have integrated poorly into a growth or startup company, you’ll usually find a violation of this rule at the core. Infrequently the motivation is a machiavellian prioritization of their own projects over their peers, but much more frequently it’s simply because the large company leader has forgotten how to create new capacity. In that case, it’s either a failure of your interview process that focused too heavily on operating existing systems, or a failure on your guiding the new leader to success. Large company leaders absolutely can transition to smaller companies successfully, but they need your help to do it.</p> <p>(This failure model is quite similar to new leaders who panic their way into a <a href="">Grand Migration</a> instead of learning the existing technical architecture.)</p>Getting to yes: solving engineering manager hiring loops that reject every candidate., 26 Jul 2021 19:00:00 -0700 <p>Hiring engineering managers is difficult, and many companies struggle with it. It’s a challenge to establish an effective interview loop. It’s tricky to convince candidates about your company’s opportunity. It can be hard to even get candidates to talk to you. Solving these issues takes time, but it’s fairly well understood work. What confuses many companies is that they solve all of these issues, and they <em>still can’t</em> hire engineering managers.</p> <p>Companies struggling here often start to manufacture explanations about what’s going wrong: the candidates aren’t good enough, managers aren’t empathetic, <a href="">managers aren’t technical enough</a>, and so on. I’ve labeled this the “getting to yes” hiring problem, and encountered it at both Uber and Stripe when I first joined.</p> <p>The underlying problem tends to be that the organization hasn’t agreed on what their engineering management role entails. Instead, each interviewer relies on their personal preferences or previous experiences to assess candidates. Some interviewers will come from Google with its emphasis on engineering managers writing code. Others will come from small startups where engineering management was a part-time role filled by the founders. A panel with these mixed perspectives will reject most candidates; any candidates it does hire will be hired <em>by accident</em> based on attributes that are only loosely related to the role itself.</p> <p>You can self-assess your organization’s alignment on the engineering management role by asking interviewers what they value, but it’s easier to just go to the metrics. If you’re giving offers to less than 20% of folks coming onsite, something’s wrong. Spend a few weeks incorporating frequent rejection reasons into your upstream phone screen. If your rejection rate remains low afterwards, it’s quite unlikely you don’t have internal alignment on what you need from engineering managers.</p> <p>As an aside, this is also why it’s so helpful to work with an experienced recruiting team. A good recruiting team is watching these numbers and will flag this sort of issue with a broken hiring loop. They may not specifically identify the underlying cause, but they’ll point out that the loop needs some attention.</p> <p>Once you’ve established this as a problem:</p> <ol> <li>Think about what you need engineering managers to do</li> <li>Refine those tasks into four or five key skills for the role</li> <li>Create an interview to evaluate each of those skills</li> <li>Create a rubric to score each of those interviews</li> <li>Train the interviewing team on the new interviews and rubrics</li> <li>Remove interviewers from the loop if they refuse to use the rubric</li> </ol> <p>The first five steps are the fundamentals of creating an environment where candidates and interviewers can succeed, but my experience is that the sixth step is equally important even though it’s rarely discussed openly. Some interviewers simply won’t align with your organization’s vision for engineering management, and they’ll undermine your loop until you remove them.</p> <p>Before removing them, you should&ndash;of course!&ndash;give clear feedback and work with them on why the vision is important. At some point, the organizational need for engineering managers will surpass your time to foster alignment with folks who reject the vision. That’s when you ought to remove them from the interviewing process. There’s a broader topic around whether folks who are persistently misaligned with your organization ought to be part of your organization: it probably depends on the details, and I’ll leave that to a separate discussion.</p> <p>As a closing thought, this happens particularly frequently for engineering managers as it’s a particularly broad role, but it happens for other roles as well. It’s particularly common for executive roles which span such scope and suffer from varied expectations across a varied set of stakeholders. The above playbook works there, too.</p>Pockets of rest enable careers., 02 Jul 2021 05:00:00 -0700 <p>Being burnt out at work feels like this year’s life crisis. Almost every conversation I have with a friend in the industry lingers on the topic of struggling to focus at work. Last week, I was chatting with a friend and we diagnosed their core career ambition as the deep desire to spend several years sleeping. Reflecting on the chaos of the last year, that does, indeed, sound like a solid career plan.</p> <p>When asked for advice, I come back to two core bits.</p> <p>First, try to avoid making career decisions while in a bad mental place. Take a two week vacation. Get out of your house a few times if you’ve been living and working at home for the last eighteen months. Try to restart something you loved but have stopped due to pandemic concerns. You don’t need to find a sustainable long-term solution, just enough of a break to find some space to reflect before making life-altering changes.</p> <p>The second piece of advice I offer is that great careers are often <em>presented</em> as linear growth stories, but if you dig deeply enough they often have a number of lulls embedded inside them. When you’re high energy, these lulls are opportunities to learn and accelerate your trajectory. When you’re low energy, they are a ripe opportunity to rest. It’s easy to forget about these pockets in retrospect, and I recently realized I’ve gotten so practiced at narrating my own career in a particular way that I’ve forgotten my own lulls that have made the faster periods sustainable.</p> <p>Reflecting on my own career:</p> <ul> <li>Yahoo was a period of rapid growth and learning for me. While some folks on the team weren’t working very much, I was working very hard to ramp up</li> <li>Digg was a period of <a href="">rapid growth for the first year</a>, but got much slower as <a href="">we moved towards being acquired</a></li> <li>SocialCode, who acquired the Digg team, was a much slower pace, and I spent time recharging energy. I also entirely stopped writing for about four years starting with the acquisition, largely because I ran out of energy to do it</li> <li>Uber was very intense <a href="">as we doubled every six months</a>, but stabilized after eighteen months once the organizational structure came together</li> <li>Stripe was quite intense early on, directly managing ~25 folks and several areas causing frequent incidents, but once again solidified as the organizational structure emerged over the course of a year or so</li> </ul> <p>When I talk about my career, I’ll usually focus on the exciting times, but every career narrative hides the equally important pockets of rest that enable a sustainable career. It’s easy to look at these lulls as some sort of failure&ndash;they will often feel like a lack of progress&ndash;but they’re a key enabler of long-term success. I’m personally confident that I would have never accomplished the things I am most proud of in my career without these pockets of rest hidden throughout.</p> <p>As a technical or people leader, I’d encourage you to reflect on your career and look for these rest spots. If you don’t see them emerging, then it’s worth spending some time thinking about what you could do to create more capacity in the teams and people around you.</p>Can senior leaders make friends at work?, 07 Jun 2021 07:00:00 -0700 <p>Chatting with a friend recently, they asked a question that I’ve spent time wondering about as well, “Can senior leaders have friends at work?” It’s reductive to pretend there’s one universal answer to this question, but most folks find it increasingly challenging to have friends at work as you get more senior. There are multiple factors at work, and it’s interesting to dig into it a bit.</p> <p>The biggest reason is that your peers have already developed a full life outside of work. Earlier in their career folks tend to look for their work to serve a large role in their lives (employment, friends, a source of identity), but work typically plays a narrower role in their lives after they’ve been working for ten-plus years. They’re open to developing friendships at work, they just tend to get squeezed out by existing commitments.</p> <p>I’ve also found that tenured managers eventually run into perspective-altering events at work that make them cautious about developing work friendships. A few from my own experience: an acquaintance who interviewed with us, wasn’t given an offer, and took their life shortly thereafter; a friend who I managed, started giving performance feedback, a brief punctuation when they threw their resignation paper in my face, and never speaking again; hiring your mentor, them struggling, giving them feedback, and them abruptly disengaging from you; ending up managing a former peer who takes it poorly. Each of these taught me a bit about the obstacles that work friendships face where other friendships generally wouldn’t.</p> <p>Even when they are interested and have time to build friendships at work, leadership roles often come with circumstances that make friendships difficult to build. Rapid growth changes the folks you’re working with frequently. Many leaders foster teams that compete with each other for individual success rather than collaborating together for joint success. Some teams are filled with genuinely kind, helpful folks who nonetheless are fairly transaction rather than relationship driven. All of these can make it difficult to form friendships, even if everyone involved is lovely.</p> <p>If you’ve read that and are still hoping to develop more friendships, most of the time you can cultivate an environment that supports developing more work friendships. Schedule more team events. Prioritize collaborative work together. Just be deliberate about it, and be careful to avoid putting too much energy into it if it doesn’t work. My experience is that you’ll find you’re still developing friends at work, just at a slower rate and inconsistent pace.</p>An interlude., 11 May 2021 21:58:09 -0700 <p>A few months ago around nine on a Wednesday evening, my vision blurred, and I lost my sense of balance. It seemed like a fine time to go to bed. When I attempted to explain my predicament to my wife, it turned out I’d also lost my ability to communicate verbally. I was having a stroke. My wife&ndash;wiser than I and besieged by the mismatched words that I believed constituted communication&ndash;collected our infant son, coaxed me into the car, and we were at the nearby hospital a few minutes later.</p> <p>With Covid protocols in effect, we separated at intake, and I spent the evening alone as I drifted from the emergency room to MRI machine and back again a few times. The situation felt surprisingly abstract. Probably because I wasn’t thinking particularly well, my wife had a different experience. Our son had his own experience, frustrated to be woken up ten hours before his opportunity to wake up us.</p> <p>Slowly I felt a bit better, and tapped out a few messages to my wife. It also felt very important to explain my imminent absence from work, and I spent an unknowable duration tapping, erasing, and retapping a message before finally sending it. Writing these texts was a challenge. In one sense, this was because my brain was in the early stages of recovering from asphyxiation, but in a more concrete sense it was because my left thumb kept sliding from the space bar to the return key.</p> <p>With the morning shift change, I was moved into the neuro floor, passed a swallow test, and control of language slowly returned to me. Our son was with his nanny, and my wife took off work to stay with me during visiting hours. I was at the hospital for two and a half days getting worked up with a bit of everything, including another MRI, several ultrasounds, and a spinal tap. One perk of being at a teaching hospital was receiving the doctor’s very first spinal tap. Which didn’t require much bravery from me&ndash;no one asked my opinion about it&ndash;but impressed me with the true spectacle of learning to be a doctor: imagine learning so much in public!</p> <p>My test count grew due to an absence rather than a risk. Results were pretty normal for someone of my age, an age that is rather young for experiencing a stroke. As they ran out of tests to run, they let me go home. There are few joys like having the last IV removed from your arm after several days in the hospital. Although I’ll admit walking out of the hospital with your wife is a similar joy. Another is going home to your son after spending your first nights sleeping more than a wall removed.</p> <p>The early days at home were rough. This was mostly due to the spinal tap taking a bit longer to close, which made keeping food down difficult for three or fours days. The mental piece was hard too. I read bad fiction on my phone. I struggled, mostly failed, to parent. A few days later I tried using a computer and was overwhelmed. So many windows, all filled with different things. It ended up taking a bit over a week at home before I could start using a computer again. Once I was back at it, I did the smallest bits of writing. I slowly migrated my blog to a simpler setup over the course of three days. After two weeks, I went back to work.</p> <p>I could have taken longer to recuperate, but I think folks who suggest taking longer as a solution miss one of the hardest parts of recovering from a stroke: you want to know how much of your previous life remains available. Will I still be able to do my job? Will I still be able to write? Will I have lost that conceptual spark behind all of it that I’ve wasted so much time being proud and vain about? Will I become a burden to my family? The answer to all these questions is only discoverable by returning.</p> <p>Perhaps most frustrating is that your own confidence and belief regarding the outcome have a large influence in deciding your outcome. You have to take the rest you need. Then you simply have to decide that you aren’t changed. To decide that you’re still the capable person you were before. Well, that’s the beautiful dream, anyway. Some would suggest it’s difficult to retain a vivid memory of your own perfection while also spending every afternoon sleeping your first week back because you’re too exhausted to continue working. But it got better. Each week, a bit better. Fewer forgotten names. Energy levels returning. Better.</p> <p>At some point the question shifts away from returning to who you were, and instead to loving whoever you are now. I’m fortunate that the difference between the past and present feels faint, although in some ways I wonder if that’s simply a newfound inability to perceive the distance.</p> <p>It’s hard to say what someone should take from this experience! There’s a lot of merit in taking nothing away from it: random events happen. Personally, I’ve tried to simply be grateful for all the blessings around me: my wife, my son, my family, access to health care and insurance, a supportive team and workplace, financial stability to weather some of the potential storms. Ultimately, there’s no right way to come to terms with life’s events, we all have to find our own way forward.</p> <p>As part of finding my way forward, I&rsquo;ve been writing less since my stroke. I don&rsquo;t think that will last forever, hopefully it won&rsquo;t even last long, but for now most of my energy is going towards the places it&rsquo;s needed the most.</p>Mailbag: Should we just call them architects?, 26 Mar 2021 05:00:00 -0700 <p>A couple of days ago, I got another question about <em><a href="">Staff Engineer</a></em>, which felt worth digging into a bit:</p> <blockquote> <p>I started reading your new book <em>Staff Engineer</em> and wondering if you can write about your thoughts on the difference between what we know as Technical Architect vs Staff Engineer. It looks like the big companies ditched the &ldquo;Architect&rdquo; title and invented the &ldquo;Staff Engineer.&rdquo; The more I read your book, the more I feel like Staff Engineers are plain old tech architects. Having set up an architect group that reports to the CTO office based on this: <a href=""></a> , I am now confused if I should rename the team :)</p> </blockquote> <p>I hadn&rsquo;t read the linked <a href="">Who Needs an Architect</a> by Martin Fowler, so I started by working through that. The core arguments I read were:</p> <ul> <li>The term &ldquo;software architect&rdquo; means different things to different people</li> <li>Despite that term confusion, there&rsquo;s still software architecture to be done</li> <li>Some &ldquo;architects&rdquo; prioritize mentorship, others decision-making</li> <li>Despite the numerous definitions of &ldquo;Architect,&rdquo; the term is generally understood to refer to the decision-making oriented variety</li> </ul> <p>I agree with all those points, and eighteen years later (the article was written in 2003!), the tactics are clearer: use the Staff-plus engineer titles rather than the architect title.</p> <p>When I worked at Yahoo!, the career ladder went from Senior Engineer to Architect, and from there, the architect titles got increasingly fancy. Software Architect? Sure. Senior Software Architect? A good step. Distinguished Architect? Yeah, most definitely. These titles do a good job of conveying seniority, but they also suffer from artificial specificity. There are many folks out there doing work at the level of a Senior Software Architect who are <em>not</em> doing typical architecture.</p> <p>The Staff-plus sequence of titles decouples seniority from archetype and is more durable for it. You can assess someone&rsquo;s seniority from their title: Staff engineer, Principal engineer, Distinguished engineer, perhaps with some varieties like Senior Staff engineer thrown in for very large organizations. You can separately understand someone&rsquo;s mode of operation by documenting someone&rsquo;s <a href="">archetype</a>: solver, architect, tech lead, or right hand.</p> <p>If you were feeling argumentative, you could have a title for every archetype, but I don&rsquo;t think that would work well in practice. There are two reasons why this is hard. First, archetypes create clarity by creating distinctions, but reality tends to be blurry. Very few folks mix &ldquo;tech lead&rdquo; and &ldquo;right hand&rdquo;, but many &ldquo;tech leads&rdquo; spend some time on doing &ldquo;architect&rdquo; work. This makes evaluating folks a nuanced activity. Second. creating four <em>useful</em> career ladders is surprisingly challenging. It&rsquo;s very possible to add specializing paragraphs to a couple of blocks explaining how a &ldquo;solver&rdquo; might create impact differently than an &ldquo;architect.&rdquo; However, I don&rsquo;t know of <em>any</em> company that operates different ladders for each archetype successfully. Performance ratings seem simple but are nuanced and frustrating at scale across thousands of people.</p> <p>Winding back to the specific question, I would ask the current tech architect team what they want. Long term, I think you&rsquo;d be better off with the Staff-plus titles, but that sort of change needs to happen at the organization level and might take a while. Short term, it&rsquo;s probably not worthwhile to change titles again if the change happened recently unless the team is already excited for the change. If you don&rsquo;t make the change now, slot it into the organizational backlog and figure out when it might make sense later.</p>RSS feed changing! Migrating blog in next few days., 25 Mar 2021 06:00:00 -0700

<p><strong>tl;dr - subscribe to RSS via <code>/feeds.xml</code> instead of <code>/feeds/</code></strong></p> <p>The current version of this blog has been running for about four years, since I wrote <a href="">Notes from fifth blog rewrite</a>. It&rsquo;s been running as a Golang service that loaded posts and files from S3, which has worked out surprisingly well for most purposes. However, there are a few things that have taken a bit of effort to keep working. In particular have spent a few hours each year on the GCP Kubernetes cluster, the Docker builds, and LetsEncrypt for SSL. My actual implementation ended up being quite similar to <a href="">Hugo</a>, and over the last bit I decided to bite the bullet to migrate to Hugo.</p> <p>The new implementation is pure Hugo, served over SSL on <a href=""></a>, hosted via a Github page, and continuously deploying via Github pages. I&rsquo;ve always practiced a <a href="">Cool URIs don&rsquo;t change</a> strategy with this blog, and I&rsquo;ve done my best to keep the URIs consistent in this migration as well. There are a few URIs that don&rsquo;t make much sense anymore, for example <code>/all-posts/</code> will redirect to <code>/</code> since all posts are now available on <code>/</code> directly, but generally things are still where they were.</p> <p>The one exception that&rsquo;s been tricky is RSS feed, which more than a decade ago I decided to host at <code>/feeds/</code>, in addition to supporting a number of filters like <code>/feeds/tags/os-x</code> to only get an RSS feed restricted to a given tag. I stopped supporting the filtered RSS feeds some time ago, but still served the general RSS feed to any URI starting with <code>/feeds/</code>.</p> <p>My migration plan is roughly:</p> <ol> <li>Update the existing Golang service to serve the RSS at <code>/feeds.xml</code> in addition to the existing locations</li> <li>Post this entry explaining the RSS feed has moved. My hope is this will support motivated folks to switch to <code>/feeds.xml</code></li> <li>Wait a day for various RSS feeds to retrieve this post, so at least they&rsquo;ll have an explanation if this breaks</li> <li>Hack the Hugo version to copy <code>/feeds.xml</code> to serve at <code>/feeds/</code> and <code>/feeds/all/</code>. Redirect other known variants of <code>/feeds/*</code> to <code>/feeds.xml</code></li> <li>Live with the (hopefully minimal) consequences</li> </ol> <p>I&rsquo;m optimsitic this will work well enough, but I am hopeful that diligent readers will be able to read this as the last entry in my RSS feed and fix it manually. Apologies for the inconvience, and here&rsquo;s to another decade or writing!</p> <p>The overall look and feel is <em>mostly</em> an extension of the existing site, with some ideas borrowed from <a href="">Julia Evans</a> site as well on the story pages.</p>