Fool's Gold

I realized a few weeks ago that if my career exchanging software for money was a person, it’d be 18 years old. An adult. In a few more years, I’ll be crossing a midpoint in my life: the half selling 1s and 0s arranged in just the right order and the other half where I have not. I’m starting to form a way of thinking about this career and my future that I wish I had at its start. A mental shift where instead of wanting to work toward building someone else’s vision, I want to work toward building my own. I don’t yet know what it’ll look like or when it’ll happen, but I think it’ll still involve exchanging software for money.

Overall, I find Silicon Valley and the tech industry as a whole to be increasingly contemptible. It always has been a bit like the gold rush: filled with investors eager to strike it rich and hopeful youth looking to make their way. And I think that mentality of taking instead of building will lead to the same demise the gold rush did: hollowed out shells given false promises and left in disrepair.

As I wrote most of this, I was traveling through parts of Morocco and Spain, spending time on trains and airplanes thinking about cultures, reflecting on my career—trying to grasp a vision of my future. I wrote this for myself, in order to sharpen my thinking, but perhaps you’ll find my perspective and experiences helpful.

I also want to acknowledge the narrative here. I’m reflecting on my career through the lens of trying to understand what it is I actually like about this job. Some details are likely incorrect, some pictures rosier, others dirtier, and I will remain the protagonist of my own story. If you’ve worked with me in the past, you may not see things in the same light. C’est la vie.

In the beginning: a better tool

My first proper job in software was at a tiny startup company in Southern California called Sendio. We leased physical 1U and 2U rack mounted server appliances that stopped email spam through a fairly novel (yet frankly simple) challenge-response technique. Instead of building tools to try to “learn” what email spam looked like, we built a system that attacked the economic incentives of email spammers: it’s easier to send millions of spam messages in hopes of bypassing the filters than it is to have the automation to reply to a response from a single spam message. So we built an appliance that acted as your SMTP gateway, which would require mail from unknown senders to respond to a challenge email in order for the original message to go through. We sold these appliances primarily to small and medium sized businesses and government institutions at a cost that was a bit more than our competitors, which primarily used machine learning and heuristics to sort the wheat from the chaff. The technology worked very well, so the challenge of the company was primarily supporting growth. My job was half development (building additional features and functionality into these appliances) and half “ops” support (SSHing into these boxes to diagnose and work around problems reported by customers with unusual network conditions and environments). It was a near-ideal starting job out of college: the engineering team was small (literally myself and my boss for the first half, growing to 4 engineers at its maximum), I had a supporting and encouraging boss who taught me nearly everything, and endured a never-ending stream of new and exciting features and support cases that caused me to learn more than anyone really ought to know about email and network transport protocols.

From a technical standpoint, I was lucky to start my career at a place where we emphasized system design as a whole. Since we sold a physical server appliance which was managed remotely, I had the privilege of working on practically every aspect of the product: the initial PXE imaging of the servers; semi-automated maintenance, configuration, and deployment of the Red Hat Linux operating system; terminal software to allow our customers to set up and install the server in their network once plugged in; a modified version of qmail, augmented with plugins at each stage of the SMTP protocol able to perform various checks and adjustments; an email web UI for customers to manage their pending verification queue and view their received messages; a suite of tools for both pre-ship quality assurance and remote diagnostics of issues. Reflecting on this experience now, I would not have traded it for the “more desirable” and better paying positions that some of my college friends had gotten at Google, Facebook, or Microsoft. I learned to work in and think about software through all its lifecycle holistically, which would not have happened if I were on—for instance—the team at Facebook responsible for the “like” button.

The business model was honest too. We were in the gold pan selling business: small and medium-sized mining companies would come asking for tools to better separate the gold from the gravel, and we were there selling the best gold pan out there. It cost a bit more, but worked better than the rest. For the first half of my time there, the business was going well, growing at a steady rate—up until the financial crisis of 2008. That crisis changed the economic reality of the company and our value-proposition was just not ready to take it on. Our customers were being squeezed for cash and liquidity—just like us and everyone else—and they were willing to put up with a bit more gravel in their gold. So they settled for a second rate pan, stopped their leases, and pocketed the premium that we charged.

At the time, I didn’t see this business as a “we rent out premium tools to small time miners” business. I was bright eyed and bushy tailed, eager to change the world through improving email (no matter how ridiculous that sounds now). And due to either ego or pride, the company was reluctant to change its pricing model. Instead, it focused on trying to make the product even better as an attempt to make it easier to sell—not realizing that most companies were fine dealing with minor annoyances in their email for some cost savings. I bought into this “more is better” vision and thought I could somehow use my skills to improve our gold pan even more so that people would finally see its value proposition and start renting it out again. But my plan was faulty: one person—barely an adult—cannot right a failing economy through sheer will. This impossible task burned me out. So I left the company, fell into a moderate depression, and contemplated leaving the industry.

Mining for gold

After spending about a half a year licking my wounds, I moved to the San Francisco Bay Area with my girlfriend, who wanted to attend art school. Not really knowing anyone up there, I reconnected with some friends I had met as part of being a part of an indie online game maker community. Luck and happenstance through these friends led me to work with them at my second job: IMVU.

As far as I can tell, Silicon Valley is stuck in an endless cycle of trends, of which IMVU was a brief darling. It was founded by one of the tech gurus who popularized “The Lean Startup”—a tech business methodology that can be summarized as: admit you have no idea what people want to buy, so use the scientific method and run as many experiments as you can as quickly as you can to find out what is desirable and then iterate. These sort of trends come and go, using hype and excitement to lure people eager to trade money for books and talks that say those comforting words, “yes, your business will succeed”—even the founder ended up focusing on promoting this Lean Startup idea rather than reaping the fruits his methodology claimed to produce. But this is not to say the Lean Startup was a scam: it demonstrably worked. However there were limits to its effects: If you blindly use hypotheses and tests to guide the direction of your company without a balanced effort to build community, trim unnecessary growth, and think holistically, you will end up building a niche product. And oh we did.

At the time I joined, IMVU had essentially built a regulated economy inside a virtual, extremely online world: an online dress up and chat product. As a regulated economy, there were three primary actors. Consumers would buy virtual credits to spend on virtual clothing and animations so they could dress their 3d rendered avatars to chat and interact with other consumers in fantasy scenes of their choosing and design. The producers were content creator 3d artists, who built and sold their goods (clothing, avatars, animations, scenes & scenery, etc…) that consumers could then purchase with online credits. And the governing entity was IMVU itself: a central bank issuing currency, facilitating transfer for a fee, and selling advertisement space to the content creators. Life is good when you can print money and tax commerce without ever lifting a finger in the real world.

Coming from a systems background, I had the confidence to find myself working in many different areas of this company. I started out working on building integrations with various national and international payment processors (this was the pre-Stripe era, which in retrospect IMVU absolutely could have pivoted into becoming the next Stripe), optimizing the customer acquisition funnel, building out infrastructure and internal tooling for the API platform, and breaking ground on new mobile phone products aimed to expose the business to new audiences and revenue streams through these new and powerful devices.

The engineering team and practice at IMVU was excellent. I have still yet to work with a group that both gelled together so well and innovated technically. I think back on this time fondly, with rose-colored glasses, for a few reasons. The core and trusted group knew each other from the online game maker community I was a part of, which meant I was part of the “in-group” (Some advice: never underestimate the value of being part of the in-group)—we were trusted with decision making, had mutual trust & respect of each other, and could lean on these pre-existing relationships to aid working together. The business desire to run as many experiments as possible as quickly as possible meant we built our technical and business processes to be as nimble and resilient as possible: we deployed to production ~40 times per day and monitored our business metrics accordingly. And we used this nimble and resilient process to be fearless, experimenting both with the product as well as with technologies and architectures.

Overall, IMVU was like a gold mining company that took a peculiar methodological approach. While more traditional miners would first survey and study the terrain (and hire the odd douser) in order to find out where to build their large mines, we would instead dig small holes at random looking to find the presence of a vein. And when we struck one, we would keep a small site and follow the path (and only the path) of that vein closely, expecting the same results if we just kept following the vein. I’m not a geologist, but I assume that following a single vein closely is not a sustainable holistic activity to maximize profits finding gold. Sometimes you find a small vein, which eventually ends, leaving you wondering why no matter the direction you look, there just isn’t more gold to be found. Or you end up following a vein which leads you away from more fruitful territory—if you only you had the insight to step back and recognize the geological conditions which led to the formation of that particular vein.

But the approach worked. This business was, is, and likely will be (if it can keep on hustling) “just” a comfortable, marginally profitable endeavor. This sadly does not satisfy the lust of the gold rush financiers and their hype men. Those people look to California with their starry eyes and their hopes for striking it rich in their puffy vests and their newfound, self-manifested wealth they earned with their own two hands. Sigh. If you can’t tell, after five years, I started to grow weary of those people’s way of thinking, and felt suffocated by the endless sameness that came along with it, swallowing the Bay Area as a whole, chewing up and spitting out everything that did not wear their same uniform. So I left.

Community

Seeking an escape from that sameness, my now-wife, our little dog, and I drove across the country as quickly as we could looking for an adventure. New York City is always changing—always being changed—by its people. The people who grew up there and recognize its struggle, the people who flee their home looking to build a better life, the young people who arrive with dreams of making it big, and those who remain after those dreams didn’t quite pan out. I was part of the group captivated by the energy of the city. Through a gracious connection from the CTO of IMVU, I was introduced and eventually took a job at a maturing start-up: Etsy.

I joined Etsy at a transitioning time. It was 7 years old and starting to shed its youthful, rebellious skin—approaching a more respectable-to-men-in-suits way of being. In my first year or so there, it passed through an IPO and moved its offices a few blocks up to a properly branded headquarters in DUMBO, Brooklyn. Etsy was principally a community of makers and sellers—connecting creative and skilled folks who wanted to sell their wares to the public. It was the connecting middle-man, providing a platform for makers to sell and market their work, tools to help with communication & inventory, and a name brand that communicated trust.

Despite being a “tech” company, Etsy was refreshingly people-first. I attribute its success due to just Doing The Work™ to cultivate a community around which it helped reach their audience by providing a service for a fair fee. Many of the makers and sellers turned to opening a shop on Etsy as a supplementary source of income during the economic downturns which were largely caused by the boom/bust cycle of technological and financial engineering of the prior ten years. Etsy was in some ways like the marketplaces in the shanty towns that were the remnants of the boom towns which went bust once the gold dried up.

Cultural value systems

The technology at Etsy was like a cousin who grew up in a different country to IMVU. Superficially, the tech looked the same, yet the way it went about doing things was completely different. For example, both companies had a large PHP monorepo, had a single mainline branch, ran hypothesis-driven experiments to guard against mistakes, and regularly deployed dozens of times a day with much success and few incidents. But the ways they went about deploying their code to production could not have been more different.

IMVU’s deploy process was to merge into the mainline branch when the author was ready, watch the suite of automated tests get kicked off and pass, and—if all was well—they would then be able to announce their intent to deploy and then deploy the most recent passing revision by SSHing into the deploy host and running a deploy command. This command deployed directly to production servers with a slow rollout over a few minutes or so. An automated “immune system” suite of checks monitoring the health of the running hosts and business metrics was kicked off. If the metrics looked incorrect (as they often did, sometimes with false positives), the deploy would automatically and quickly roll back to the prior version. After the deploy was complete, the author could then follow up with an email to a change@ email list, where they could describe both what was changed and the motivation behind the change. All in all, an engineer was expected to be able to merge to the mainline branch and have their code tested and fully deployed to production within 15 minutes.

Before contrasting this with Etsy, there are a few important things to call out that are necessary cultural practices to support IMVU’s way of deploying. Because the automatic rollback immune system was very sensitive (ex: if in a one minute window, random chance led to fewer transactions than expected), engineers expected their changes to be rolled back. As a result, there was a culture of all code being written and reviewed with the assumption that it would be rolled back. So practically all changes were both forwards and backwards compatible. Additionally, since the merge-to-100% duration had a fairly strict expectation of being less than 15 minutes, the automated suite of tests needed to be reliable, distributable, and fast. To accomplish this, IMVU widely used a dependency injection/service provider/test double pattern across its codebase, where “fake” implementations of a “real” dependency would be used at test-time to allow tests to execute without needing to perform slow or unreliable actions (like disk read/write, network I/O, checking the time, sleeping, communicating with 3rd party services, or producing random numbers). A smaller number of parity tests ran the same test code against the “fake” and “real” implementations, to ensure the contract guaranteed by their interfaces behaved the same in tests and in production. A small number of Selenium tests were present to verify critical flows (login, purchase transactions, etc…).

The system was also strengthened by its culture when things went wrong. If a broken commit landed into the mainline, it would need to be addressed before further deploys could continue. This was in the style of Toyota’s “hold the line” principle: systemic failures stopped production deploys for everyone until they were addressed. And to make this work, the culture valued reliable & fast tests. The practice to maintain that was when a test failed, the state of the system it ran on was saved at the time of failure, and engineers were expected to investigate and understand why the tests failed and use that learning to improve the test to remove the source of entropy. There was an ethos of treating test failures like a crime scene investigation. IMVU had a very low tolerance for mucking around with the crime scene, so very little disabling of broken tests, and no re-running“flaky” tests to get them to “pass”: re-runs were considered too time consuming, given the 15 minute goal.

Emergency overrides for deploys were present, allowing the system to proceed through failing checks if necessary. And when things broke, IMVU had a culture of celebrating those who managed to break this system, and a certain amount of pride was taken if you could cause all but one test to fail, or if you managed to break things in a way which eluded detection by the immune system. A Toyota-style “five whys” postmortem would be held after incidents, revealing the cascade of causes for these incidents. And unlike the practices I’ve seen at other companies since, the path of these questions was not limited to computers: managerial questions were also discussed in these postmortems (i.e. Why was this person not trained on how to use the deploy system properly?).

Etsy did things differently. In contrast, they deployed first to an only-internally-accessible environment (lovingly named Princess) which shared data persistence with the production environment prior to hitting customer-facing production. To deploy their code, engineers would join a deploy train (a size-limited group of other engineers wanting to deploy). When the train was at the front of the queue, its metaphorical doors would close, and engineers would then merge their changes into the mainline branch. Once everyone was merged in, the driver of the train (the first to join that batch) would click a button to deploy the batch of changes to Princess. This also kicked off the suite of automated tests, which would notify the train of their failure. In parallel, engineers would manually verify their changes on Princess and confirm things were safe to proceed. Once all engineers participating in the deploy gave the go-ahead, the conductor of the deploy train would push the button to go to production and manually watch the graphs of primary metrics and business metrics. “Dark” merges could occur at any time and would be included in the next deploy train, but were encouraged only for changes that were for fully disabled/inert code. Test failures were non-blocking, and it was fairly common for a train’s code to reach production prior to all of the test suites fully passing. Nothing was automated, and rollbacks were largely considered a Bad Idea. Instead, rolling a fix forward (i.e. pushing and deploying a revert or bugfix/band-aid) was preferred. Coordination tooling was there to help group the trains and mark the passengers as “good to go” to the next stage.

Interestingly, the culture of celebrating failures was shared. Etsy celebrated by awarding the person who managed to break the website in a spectacular fashion by passing them a physical knit sweater which had three arms. Postmortems were larger format, open meetings used to build a story around the incident. The moderator walked through the events that led up to an incident and the actions taken. “Why did you do that?”-style questions were asked to responders to build context and help document the system. And follow-up items were taken throughout.

This contrast between the two styles of deploying was initially startling. I thought the automatic rollback system was a necessary immune system needed to deploy dozens of times to production each day. The lack of these guard rails, the fact that code could touch production data before the full suite of automated tests passed, and the delay needed to roll fixes forward (due to avoiding rolling backward) made me very nervous.

And yet deploys worked smoothly and things were just fine. When I raised my concerns, I was met with surprise and offered articles written by past Etsy employees about how You Cannot Roll Back Software™ safely. What a shock! My lived experience of having done that for years was denied as not being possible, and I experienced an equivalent dissonance seeing a system working perfectly well that I was certain lacked the safety necessary to achieve dozens of deploys a day.

Cultural system shock

I learned through this experience that software systems are cultural systems. Things that can be done in one culture may be impossible in another, and things unimaginable in another culture may be commonplace in your own.

For instance, just the other day, I was walking through a lovely and clean public park in Marrakech, enjoying the scent and sight of the scores of orange trees all filled with oranges and orange blossoms. Later that day, I happened to read the comments on a Reddit r/NoStupidQuestions post asking, “why don’t cities grow fruit trees?” with commenters mostly saying how it would be impossibly expensive, due to needing to deal with problems of irrigation, pests, disease control, and rotting fruit. And here I was in a developing nation taking in this impossibly expensive feat with my own eyes and nose! The reality is that the culture in Marrakech and many other places in the Mediterranean region value the gift that fruit trees give: joys to the eyes and a lovely scent to the nose. So they do the work to make them present in city streets and public parks—it is a part of the culture to tend to these trees so they may live and we may enjoy their life. It’s cultural infrastructure.

Some people think their own culture is the only culture there is, and make absolutist proclamations about what Can And Cannot™ be. Some people evangelize their culture as the One, True Culture™. These people are wrong in their conclusion, but at the same time should not be completely ignored. They are merely passionate about the practices and byproducts of their own culture—perhaps naive about the ways of other cultures—and certainly would prefer to live in a world with their culture as the monoculture. But that is a fantasy. Cultures of all kinds are worth experiencing and understanding, no matter how baffling they may seem at first blush.

Perhaps when thinking about building your own company (a company is a community, and a community is a culture), a better way is to look around to see what cultural values exist elsewhere that make the impossible that you want possible. To take the time to understand what practices and values exist that make those impossibilities viable. That way you may adopt them as your own practices and values, which will allow you to do what some people consider impossible.

And so I came to understand that Etsy’s way of deploying was one which encouraged community, shared responsibility, and collaboration. A random leader is chosen to safely deliver the collective code to production, with stops along the way for the group to confirm their portion of the change is behaving correctly. This reinforces community and encourages collaboration. A postmortem is a tool to encourage systemic learning, storytelling, and the documentation of the maintenance of systems. This reinforces community and encourages learning.

And I came to see IMVU’s culture as different with different goals. A single person being capable of committing their change and deploying it to production in 15 minutes was the standard. When these individual changes were performed, the individual could share and document their changes and context to a broader audience (especially interesting for support staff and QA staff). This reinforces community and encourages independent action toward improving & sharing. When the production line broke, everything was paused and analyzed to get things back in order—but since everyone was affected, everyone wanted to help. This reinforces community and encourages teamwork.

Both companies had cultural engineering processes that were intentional, yet built and maintained by the individuals. They were both like a surprisingly sturdy bridge over a river: the planks were the actions of individuals and the rope binding it all together was the shared cultural value system. And the maintenance and education practices shared by everyone crossing that bridge helped maintain it and strengthen it over time.

Culture is community is strength

It’s no mistake that Etsy’s culture in engineering was that of building community and helping each other. The entire company was a fractal of that ethos, both internally and externally. For its customers, Etsy built a community of makers and helped them by giving them tools and a platform for making their business more successful.

For its staff, Etsy had a number of programs both official and unofficial which built community and helped uplift it. A program where people managers across the company were assigned to support group “pods”, which met monthly for an hour to talk with each other about their managerial challenges in a safe space. A rotation program where engineers were encouraged every few years to embed in another team, which would host them for 4-8 weeks—both assisting the team, learning a new area of the company, and forming cross-organizational communicative bonds. A “school” program where employees could hold classes to teach non-work-related skills they know to others (I taught a music theory appreciation class, and attended a stained glass window making class).

Unfortunately as the company grew with its public ownership and starry-eyed investors, it started to lose a bit of this ethos, both toward its sellers and internally. It was common for early employees of Etsy to visit sellers in their studios and workshops. But that was harder when the staff grew, logistics became difficult, and the budgets got scrutinized. The investors’ push to grow the company beyond sustainable means gave way to unfortunate changes. I saw the writing on the wall and left the company right before the first round of layoffs prompted by an activist investor. As for Etsy now, I can’t say. But I’d imagine that it’s hard to maintain a culture of building and helping community internally and externally when you have rounds of layoffs of your staff.

A brief departure into healthcare

After leaving Etsy, I ended up joining a healthcare startup for 11 months. It had a tremendous amount of funding, and the founders practiced a form of company building that I can only describe as churn and burn. The tenure of an engineer was quite short, less than two years, and the company was operated by founders who believed that things worked best on a need-to-know basis. There was no fundamental trust from the top that people could do the right thing in the right environment and therefore no desire from the top to support any sort of community culture that benefits itself.

From a technology standpoint, things were all over the place. It managed to both have a monolith and microservices in its architecture. I attribute the architecture directly to the churn in its staff. There was no “way to do things” here, and even if there was, the constant hiring and attrition led to a sort of tragedy of the commons with respect to software practices. People with experience elsewhere joined and continued working in the ways they experienced elsewhere. People picked up the half-finished work left by the previous generation and attempted to finish it without understanding fully the tradeoffs made in its initial construction. This generated an unhealthy amount of fear and uncertainty in the software itself: people were not motivated to improve things, so things never got improved.

And even my own actions contributed to this fractured system. I was tasked with building out an Electronic Medical Records (EMR) integration, and did so explicitly and intentionally not using any of the existing shared technology. I tried to build a bit of an oasis in this new venture. Sure, it worked and may have helped ship our initial product on time—but it detracted from any sense of shared responsibility from the rest of the org. And surprisingly (though not so much in retrospect), when you try to build an oasis outside of the rest of the org, there’s a certain amount of “why do they get to do that” resentment that can grow, which divides more than it improves things. Ultimately when I decided to leave the company, I felt as though I had just added on to the pile, rather than made any substantial progress improving the whole.

The saving grace of this company was its people. Despite having absolutely terrible (I do not call out people like this lightly) leadership, it did have good employees. Everyone wanted to make it work, and understood that there were some… uh… challenges at the top that needed to be worked around. This in a way built a sense of community and culture, but at the end of the day it was one formed in opposition rather than in a desire to help each other grow. A plant can have some beautiful foliage even if it has some root rot.

I learned from this whole experience that culture comes both from the people at the top and the people at the bottom, mediated by the people in the middle. You cannot manage your way from the middle into a better culture. I may be overreaching with this diagnosis, but I believe my boss, who I joined this company explicitly to work with (as I admired him—and still do!—and his work at Etsy), burned himself out trying to build a culture from the middle out. It just must be exhausting to hold a structure up from the middle outward.

Overall, reflecting on my time there, I have some advice:

1. Research the executive team to get a sense of their character and to find any prior/active lawsuits before joining a company. Only then should you ask yourself if you really want to work under them.
2. Very good people can end up working under very bad people. And while a bad work environment can bring people closer together—this isn’t a good thing in the long term.
3. Culture comes from both the top and the bottom. If the top is missing it, the bottom has no incentive to build and maintain it.
4. “Pour money on it” is a strategy that keeps a business running much longer than you think it can. And even if you think you’re a critical cog in the machine, which will fall apart when you leave, it won’t—anything can be replaced by pouring money on it. I’ve known people who have stayed at jobs for years despite wanting to leave. Stuck there because they didn’t want the things they had built and still care about to fall apart. This sort of thinking is a trap.

Words matter

After my brief departure into healthcare, I reached out to my network to see who was hiring, and an friend I knew from Etsy pointed me in the direction of Slack, which I ended up joining. At the time I joined, it was pre-IPO, growing fantastically, and had the power of an incredibly strong brand (Some advice: do not underestimate the power of a brand). While Slack was a SAAS company, it liked to think of itself as a Quality Consumer Product™. It earned its money from businesses, but earned its respect from people by making actually-enjoyable-to-use software.

I’m sure others I worked with will disagree with me about this, but I think I can single-handedly attribute Slack’s success in business to its use of language—its copywriters. Ok, maybe there was a heavy dose of luck involved too, but luck is table stakes when it comes to business success. My claim is that the language and tone Slack exuded was the foundation of both the product and the culture that made a billion dollar company that sold a chat program to businesses. This is not to discount the great work done by the sales team, the brand marketing team, the product designers, and everyone else involved. But honestly, you could take everything away except for the way Slack made you feel through its use of language, and you’d still have Slack.

An internal memo written around the time it was first released can be found here (https://medium.com/@stewart/we-dont-sell-saddles-here-4c59524d650d). It is a justification of the marketing stance of selling “organizational transformation” and a call to action of how it will be done through extreme quality. The metaphor used is, “we don’t sell saddles here, we sell the experience of horseback riding”. You don’t sell the tool, you sell the benefits and experiences the tool gives you. And that makes real behavioral changes in your customers, which builds your market.

The thing that sticks out to me about this memo is how it places value in the power of words. The first thing a person perceives about a product is how it uses words. And the memo states that the way to make Slack work is to make a very good product. I took this to mean one where words matter and they should all be welcoming, accurate, purposeful, and thoughtful.

It’s this sentiment that I think made Slack Slack. For the most part, the people were welcoming, the way people communicated was accurate, actions were purposeful, and people were thoughtful. This wasn’t always the case, and I myself am painfully aware of the times I let my frustration speak before being thoughtful, but it was more common than not. It was a good place to work because of the way it made me feel, and I miss it. But as those starry-eyed investors invest, they tend to squeeze everything good to get another dollar. And now it’s owned by a company led by a CEO who once belittled his now-ex-co-CEO publicly in an all-hands meeting by making fun of his shoes. You can’t make this shit up—time will tell how that all goes.

Selling shovels

And so now I find myself at another large tech company. One which sells picks and shovels and helmets and jeans and surveying tools to the other gold miners. The products are all fairly good quality and can work well together. The business sells tools and the confidence having those tools gives you. The people are mostly nice and smart, though a bit stereotypically tech. The company is strategic and doing well. There’s not really a strong sense of a culture and a way of doing things, but who needs that when you’re just selling shovels.

But I just can’t shake the feeling that when I take a step back and look at this company and the rest of the tech industry, there’s no there there.

This isn’t really how I wanted to end this, but I don’t know what comes next. Again, I think my shift is just in seeing things for what they are—and while I’m not sure that I like it, I appreciate its clairty. Maybe this is just middle age approaching, and the there that’s missing is the nostalgia of my youth.

But I’m also sure that for better or worse I do actually like the potential of computers as a tool to help people be better people. So I’ll probably still exchange software for money. And when I do ever decide to build something that I want to build in a way I want to build it, I’m going to start first with making a culture, growing a community from that with intentional actions and words, and then (and only then) building something to help make that community better for a fair fee.