Earlier today Silicon Valley Bank failed.  SVB was the most important bank for startups and held many startup companies’ money in addition to venture funds and others in the startup ecosystem.  

SVB fell victim to rising interest rates.  This hit them in two ways.  First, they loaned out deposited funds to the US Government, among others, buying long dated treasury bonds.  These bonds paid low interest rates  when SVB bought them, on average around 1.5%.  Since then, interest rates have risen, and bonds of the kind SVB owned (3.5ish year maturity Treasury bonds) are now paying 4.5%.

Now the US Government is good for the money, so what’s the problem?  Well SVB’s depositors were startups.  As it happens, there has been a downturn in startup-land.  And because of this, VC funding has been hard to come by.  So startups have been burning cash, on average, even more than they normally do.  This means all the startup accounts have been paying out cash, but not bringing in new investments to top those accounts up.

So SVB needed to come up with cash to pay out those withdrawals from the startups’ accounts.  To do this, they sold the loans they previously made using the deposits they got from the startups.  But because rates have gone up, they can’t sell the loans for what they paid for them.  When rates go up, the value of loans go down.

So as SVB sold their loans, for something like 90 cents on the dollar, the value of their assets  (the loans they made) kept going down relative to their liabilities (the startups’ deposits) and people started wondering whether there would be enough money to pay all the depositors back.

Once people started wondering that, more depositors started withdrawals, which forced SVB to liquidate more bonds, enlarging the problem in a death spiral/run on the bank.

There are a lot of problems to be dealt with that arise from this, some having to do with SVB specifically, some to do with the startup ecosystem, and some with the economy as a whole.  I’m going to bracket the SVB and startup ecosystem issues, and focus on the economy wide issues.  People are worried that other banks, who also invested in long duration Treasury bonds, will face a similar problem.  This has caused share prices at other banks to fall.

The Fed can address this, and should for at least two reasons.  First, keeping confidence in the banking system as whole high is just good policy.  Second, the Fed wants to be able to raise and lower interest rates in order to manage the economy.  If raising rates creates systemic banking issues, then it makes it difficult for the Fed to steer the economy as it would like to do.

So, the Fed should offer to exchange, at par value, short duration treasury bonds it owns that pay higher interest rates, for long duration bonds banks are holding that pay low interest rates, and that have a remaining duration that is similar to the Fed’s bonds in the exchange.  A short example: Bank A (not SVB) bought 5 year Treasury bonds 2 years ago that pay 1.5%.  The remaining duration is 3 years.  The Fed should swap its newly purchased  3 year Treasury bonds that pay 4.5% for those 2 year old 5 year bonds (effectively also 3 year bonds) that pay 1.5%.

This way Bank A gets to sell its new 4.5% bonds for 100 cents on the dollar if it needs to, which should remove the need to do so since depositors won’t be worried.  The Fed will hold the 1.5% bonds to maturity, and since the US Government is good for it, it gets paid back, and is only out a bit of interest.  In exchange for being out that bit of interest, the Fed gets to raise rates to manage the economy as it needs to, without worrying about sparking a general banking contagion.

Seems like a win-win to me.

Charles Darwin, in On The Origin Of Species recognized that animals evolve thanks to the pressures of natural selection.  The animals that survive are the ones with traits that are well adapted for the purpose.  A bird with a more agile beak can catch food better, a rhinoceros (unicorn) with a stronger horn can defend itself better from predators, etc.

This kind of thing happens in any environment where there are significant selection pressures on survival.  Take startups, for example.  The ones that survive tend to be the ones that are well adapted to make something people want.

So far, so straightforward.  But, Darwin pointed out another source of pressure that governs how species develop.  Take the peacock, for example.  The male peacock's tail isn't well-adapted for survival, per se.  The tail is long, makes the peacock slower and less agile, etc.  But the peacock's tail also makes the male peacock attractive to other peacocks.

The peacock's tail is a costly signal.  It is costly both in the sense that if a male peacock survives even though he's dragging that tail around, he must be reasonably good at surviving, and because a tail like that is hard to grow without good genes.  Put another way, it's very hard to fake having a good looking peacock tail.  You either have it, or you don't.

The main difference between these two kinds of selection pressures, is the audience.  Natural selection is a first order issue, in the sense that a beak, horn, or what have you either succeeds or fails at changing the facts on the ground.  You either catch the food, or you don't.  You either defend yourself against predators, or you don't.  Your success or failure at these tasks has little or nothing to do with your audience.

The other kind of selection, by contrast, is a second order issue in that traits which are selected for in this way are primarily good at convincing someone else that you are or will be successful.  The key issue here isn't so much the facts on the ground, but rather the change in someone else's beliefs about you.  In other words, the success or failure of a peacock's tail has everything to do with influencing what your audience thinks.

If this seems a little strange, remember that the peacock's tail makes the peacock less likely to survive, because of the hassle of dragging it around.  The peacock takes a loss in terms of the facts on the ground, but gets a win in terms of the effect on his audience.

Ultimately, this is because talk is cheap.  Anyone can say that they're the peacock you've been looking for.  But, like the peacock's tail, what is most convincing are signals that are costly, and therefore not cheap.

The point here is that because effective signals have a cost to them, there can be times when you need to make a choice between effective signals and changing the facts on the ground.  For example, let's say you have a choice of two people for your VP of product.  One of them worked at one of the FAANG companies, Stanford CS grad, Harvard MBA, has all the credentials you could want but is new to your space.  The other one never graduated from high school, but has been obsessed with your space for years, and has built a number of well-thought out but little known open source tools that are highly relevant.  You know that bringing the credentialed person on board will immediately signal to others that you've got momentum.  Bringing the one obsessed with your space on would give your development efforts a significant boost.

In an ideal world, of course, you can get both.  In the real world startups do have to navigate this kind of tradeoff all the time.  It would be easy to say that you should just optimize on one of these pressures, or the other.  But, I don't think we can say that.  Costly signaling can be a powerful force multiplier, especially in a world where investments get made quickly and companies with momentum find it significantly easier to raise capital.  At the same time, you need to build a real business to succeed.

The best you can do here is to recognize the tradeoff and be intentional and deliberate in your choices.  There's no one right answer, but if you understand the challenge, that's a good start.

Way back in 1967, when software development was the domain of giants on whose shoulders we stand today, Melvin Conway made the following observation:

What is an organization's communication structure?  To a first approximation, the communication structure is the org chart.  Here are some very serious and accurate examples:

Now, you are probably quite familiar with organizational charts, and you may even have some considered opinions about how useful they are.

But, Melvin Conway's law is telling you that your org chart has quite a lot to do with how your product will get built.  Why?
 

The logic here, essentially, is that certain communication pathways within your organization are lower bandwidth than others.  Even with the best of intentions, two people on very different teams within the same company can struggle to establish enough common ground to really exchange much information with each other.  I'm sure you've experienced this phenomenon.

Because of this, there is a natural tendency to architect your product around these difficult, or at least lower bandwidth communication channels.  One way to do that is to separate the product into components and have those components interact with each other in well defined and limited ways. 

This can have pretty profound effects.  For example, Amazon's org structure made AWS almost an emergent property of Amazon's business rather than a deliberate strategy.  Amazon, famously, organizes itself into two-pizza teams.  The idea is that each team should be small enough to be fed by two pizzas.  What went along with that was a mandate, back in 2002, that these teams needed to expose their data and functionality to each other through service interfaces.  Which is essentially a fancy way of saying that each team needed t0 publish the inputs they would accept, and the outputs that are expected.  Amazon did not care about what technology its teams used to implement their service, but the communication between teams would be done through service interfaces.  This takes the approach of channeling communication within well defined interfaces to its logical conclusion.

I believe that, back in 2002, this edict was primarily about preserving the ability to organize Amazon into two-pizza teams.  Without this service interface approach, as Amazon grew, any two-pizza team would quickly be overwhelmed by the task of keeping up with the communication with all the other two-pizza teams.  With it, Amazon was able to build out another service which was a directory of its services and the inputs and outputs associated with them.  Then all of these teams could simply discover the interfaces for all the other teams and use them.  The way to preserve two-pizza teams was to tell each team that it should treat all other teams as black boxes and provide a black box interface that all other teams could use.

This organizational structure, which prioritized the two-pizza teams, had the result that the task of creating AWS was approximately equal to the task of exposing some of Amazon's internal services to the public.  That's a much simpler (not simple) task than trying to create a cloud computing infrastructure from whole cloth, as others had to do.

There are certainly pros and cons to Amazon's approach.  For one thing, AWS can't really be said to have a single user experience.  There are many different user experiences, almost one for each AWS service and that can be disorienting.  For another, the documentation on AWS is centered around each individual service.  But, most AWS users want to stitch together at least a few different services.  It's often better to search the Internet for examples about how to knit AWS services together rather than try to find the answer within AWS' own documentation.

And I know many of you are mapping this entire post on to the running discussion about the trade offs between microservices and monoliths.  That's an important discussion with lots of implications for development, operations, testing, scalability, etc. etc. 

The point here is that we think that these strategic choices about the tradeoffs between scalability, flexibility, consistent user experience, technical architecture, etc. are made by product people who are thinking about product market fit in partnership with engineers thinking about the right technical implementations to support the product goals.  We, quite rightly, lionize people who can craft insanely great products.  It's hard to do!

When you think about org charts, you probably don't associate them with Steve Jobs levels of awesomeness, do you?

But Melvin Conway and I are here to tell you that the way you structure your organization has a huge impact on the space your product leaders have to operate in.  There's a well known, but no-less fantastic quote (which I hope I am quoting accurately):

That thought really applies here.  Before your product team can start thinking about how to craft your product, and how to achieve product-market fit, your organizational structure has determined much of the structure of your product.  Just as logistics sets boundaries on the tactical and even strategic choices available to armies, so do organizational structures set boundaries on product teams.  So, if you separate organizational structure decisions from your product decisions, don't be surprised if your product leadership runs into frustrating barriers that product-oriented frameworks, tools and training are ill-equipped to solve. 

It's worth remembering that among the very first decisions Steve Jobs made about the development of the original Macintosh was that the Macintosh team would be in its own space, set apart from the rest of Apple.  They even took to flying a pirate flag, to demonstrate their willingness to go their own way.  I'm not sure how or even if this structure was reflected on Apple's formal org charts, but I am sure that it had a profound effect on the development of the Macintosh.

Startups, in their earliest stages, don't have to worry about many of these trade offs.  At the beginning, your team is small enough to support high bandwidth communications among just about the entire team.  But as you grow larger than hunter gatherer bands, you'll need to make decisions about how to structure your organization because our natural methods of group organization, being adapted to groups of hunter gatherer size, can no longer fill the gap.  Many, if not most organizations think about their own internal needs when they make these choices.  But as we know, because Melvin Conway taught us, those choices also impact your product design, your product market fit and your customer.  Choose wisely!

One of the things I looked forward to as I was getting back to blogging was coding up a blog.  I've done this a couple of times before, and I figured that Rails would be a good tool to try and use, especially since the first popular demo for Rails back in 2005 was a video showing how to build a blog.

If you're reading this post, then you're reading it on the blog I built with Rails 6 and Ruby 3.  Hi!

I have built a bunch of software with Ruby and with Rails but it's been a while since I built a blog.  So, here are my impressions.  The core components of Rails are still as helpful as ever in terms of rapidly creating CRUD (create, read, update, delete) interfaces to the database.  ActiveRecord is a nice ORM and provides the flexibility to drop down to SQL when you need it.  Not too much has changed in terms of that core functionality in all this time.

What has changed?  A few things.  I'm a fan of View Components.  Maybe it's just me, but in the past I had issues with keeping my Rails views from turning into spaghetti code.  There was too much mingling of business logic with markup.  View Components doesn't entirely solve that problem (though I'm sure some of it is just me being lazy) but it sure does help a great deal.  View Components gives you a ruby script coupled with a view template and requires you to declare explicitly all of the variables that will be passed to the script, and through the script to the template.  This makes it much easier to create a clean separation of concerns.  From there it is easy to compose pages using your stable of View Components, and reuse them as needed.

View Components also plays nicely with Stimulus Reflex.  Stimulus Reflex lets you use some simple declarations in your markup that then sets up reactive interfaces without needing React itself.  It provides a way to gradually make your user experience reactive and modern, but exposes a lot less complexity to the developer than something like React would.  For some applications you want access to the complexity and control that React can provide, but for a fairly simple blog, Stimulus Reflex seemed like the right fit to me.

Rails made handling file uploads and rich text editing pretty straightforward with Active Storage and Action Text.  Though I think that with Action Text, Rails may have strayed too far in the direction of convention over configuration.  There were a number of occasions where I wanted to change the behavior of Action Text to align image and text, to have images render appropriately in the email newsletter format of these posts, etc.  Action Text doesn't expose easy ways to configure those things, or much else.  I ended up having to dive into the internals and/or create some helper functions to parse and edit the html that Action Text creates.  Neither of these were a particularly Rails-like developer experience.

I also spent way too much time configuring Action Text's direct upload feature to play nicely with AWS S3 as the storage backend for image attachments.  You would think that this configuration would be well-documented, but it was not in my experience.  For anyone else who might find this and be looking for advice, installing the rack-cors gem was the answer for me.  In retrospect, that makes complete sense, and maybe it should have been obvious, but I suspect there are others who would benefit from having the requirement explicitly called out in the documentation.

After all of that, I still didn't get a rich text editor that I would be particularly happy putting in front of other users, there are too many sharp corners in the UX.  Since I'm the only one blogging here, that doesn't matter much for my use case.  There are certainly other rich text editors you can use out there, but Action Text is what comes bundled with Rails.

I also spent a fair amount of time using Tailwind CSS to style the site.  Rails makes it easy to integrate Tailwind and Tailwind in turn makes it easy to create a responsive interface that looks reasonably good.  Tailwind makes applying CSS more efficient, which isn't saying too much, but every little bit helps.

All in all, I think Rails basically delivers on its mission in 2021, which is to make a developer or a small team of developers productive.  I certainly felt that I was skipping a goodly amount of boilerplate so that I could get on with shipping the blog to production.  The recent additions to the ecosystem of View Components and Stimulus Reflex let me create a reasonably modern UX quickly with little complexity, and that is a significant win in my book.  Though there were a few rough edges, I think if you haven't looked at Rails in a while, it might be time to check back in and see what you've been missing.

In July - August 2020, Mercer Consulting found that approximately 94% of employers said that productivity had stayed the same or improved since their employees first started working remotely as a result of COVID-19.

And, employees seem to like their new, more productive remote work setup.  Bloomberg reports that a survey done in May 2021 shows that 39% of employees would consider quitting unless their employer was flexible about remote work.  Among Millennials and Gen Z, nearly half (49%) said they would consider quitting in that circumstance.

You would think that employers would be falling over themselves to make remote work a permanent thing.  You don't necessarily see opportunities every day to improve productivity by offering a working environment that employees really like.  On top of which, remote work offers companies the opportunity to save significant real estate costs.  This study from Savills Studley covering the period 2011 - 2015 shows that companies in the S&P 500 spend between 0.5% and 2.0% of revenues on rent.  Over that time period S&P 500 companies averaged operating profits of roughly 10% of revenues.  Very roughly speaking, those figures suggest that eliminating rent expense could boost the average S&P 500 company's value by something like 5 - 20%!

So, moving to remote work offers companies a way to boost productivity, make employees happy and directly improve the bottom line.  Seems like a pretty straightforward way to maximize shareholder value to me.

And yet, I see a lot of companies focused on planning for when employees will be coming back to the office.  The Omicron variant has delayed these plans, but the fact remains that the plan (however long delayed) at many companies is for employees to come back to the office, rather than shift to remote work permanently.

Personally, I think those plans are likely to be delayed indefinitely at many companies, no matter what happens with future COVID-19 variants.  We've come a long way since March 2020 in terms of understanding how to work remotely, and I don't think there's a way to just put the remote work genie back in the bottle now that employees see how much they like it.

Even so, I am very interested to understand why so many companies are so committed to their back to the office plans, in spite of the business incentive to commit to remote work for the long run.  I think a key driver is that managers find navigating remote work challenging.  In the surveys I have seen, managers tend to feel that working in the office is beneficial.  This survey from Future Forum shows that 44% of executives want to return to the office full time, compared to 17% of non-executives.  75% of executives want to be in the office 3-5 days per week, but only 34% of employees want to do that.

As we have moved to remote work, we've adapted many of the tools that we used to use in the office.  SaaS has been a big part of enabling that transition.  Just because SaaS tools are remote-compatible, however, doesn't mean that they are remote-native.  Managers are, I think, particularly exposed to the lack of remote-native tools.

A remote-compatible tool usually helps people manage work.  Salesforce helps people manage sales, Hubspot helps people manage marketing, Github helps people manage code, etc. etc.  Most of these tools help you record some project or task, and then manage that project or task through a pipeline.  What they aren't focused on is helping to manage the performance of the team in charge of that project or task.

We have a zillion tools to keep track of tasks, but very few to help us understand the health of our organization.   Managers who have been used to flying under visual flight rules, now have to fly by instruments, except the cockpit has no (very few?) instruments they can use.  I'm interested to explore this area.

Kind readers, if you'd like to login (there's a button to login with your Google account on the right near the top of the page.  I assure you the process is painless) and leave a comment, what kinds of questions would you like to know about your organization, so that you (or your manager) won't feel like you're flying blind?

There's a funny meme that I see going around sometimes in cryptocurrency circles:

The implication is that while cryptocurrencies may seem kind of strange and made up, the monetary system and the US dollar is also strange and made up, so really there's no difference.  And, since there's no difference, crypto is just as good and valid as the dollar.  Further,  if you can open your mind and look past the "Matrix" of these made up things, you'll be able to grasp the underlying reality (what this is exactly, is a little unclear, maybe I took the blue pill).

Though this is funny, and there's a grain of truth to it, this is, of course, silly.

It's true in some sense that both the US dollar and Dogecoin are made up, but it doesn't follow that they are the same or that there aren't meaningful differences.  For one thing, dollars have value because, if you are a US taxpayer, they're what you use to pay your taxes.

But more broadly, saying that because two things don't have physical reality means that we can't distinguish between them is just silly.  We distinguish between "made up" things all the time.  For example, if you meet someone and their job title is "CEO" and you meet someone else and their job title is "Venture Capitalist" that tells you something meaningful.  Those job titles are absolutely made up, but it doesn't follow that they are the same.  We can and do distinguish between things like this all the time.  In The Matrix we learn that there is no spoon.  But, that doesn't mean that we can't tell the difference between a spoon and a fork.

The fact that a bitcoin, for example, trades for different amounts of dollars from day to day means that we can and do make meaningful distinctions between those two things.  If we couldn't tell the difference between them, then why would the price of bitcoins ever change?  And if the price of bitcoins never changed, that would make a nonsense of the whole cryptocurrency project.

I'm old enough to remember the heady days of the late 90's, and some of the rhetoric around cryptocurrencies reminds me of how people talked about the Internet back then.  Blockchains are a fundamentally new computing primitive, and that's really cool and valuable.  But let's not fool ourselves and pretend that all else will be swept away by them.  That kind of muddled thinking makes it harder to build the future.

It turns out that a lot of people like working from home.  One of the things they like about it is that they don't have to commute.  This survey suggests that Americans dislike commuting so much that 35% of us would take a pay cut in exchange for the ability to work from home.

Since the pandemic has pushed more people into remote work that means a lot of us have gotten a stealth pay raise.  After all, if you would be willing to take a pay cut to work from home, and then you get to work from home without a pay cut, you've essentially gotten a raise, though that raise comes in the form of not commuting twice a day rather than in the form of dollars.  The most recent inflation numbers we have show it running at about 6.8% in October 2021.  This is well above the Fed's target of 2%.  There are a lot of factors that go into that.  Most importantly, we've all shifted from buying as many services (it's hard to get a haircut in a pandemic) and towards buying stuff.  With demand for stuff up, prices for stuff have risen.

What many economists really worry about, though, is a wage price spiral.  This is when prices go up, causing wages to increase, pushing up prices further, and so on and so forth.  We haven't seen much of this so far.  I think one reason is that many people are getting increased compensation in the form of not commuting.  But, because this isn't dollar compensation, it doesn't push inflation higher

I think remote work is here to stay, as long as the labor market stays tight.  And, tight labor markets are typically when you would worry about inflation.  By encouraging working from home we may have inadvertently created a nice relief valve for inflationary pressure.  That would be a bit of a silver lining to the pandemic, in economic terms at least.

Looking forward to serving up my very own brand of hot, fresh, takes for the Internet to enjoy.