I’ve been spending a lot of my time recently thinking about technology and the idea of value. Also, I have been thinking about buzzwords.

The Illusion of Buzzwords⌗

I am a professional buzz worder. I’m often a PM (ultimate buzz word role), a consultant (need I say more?), and a sales person (uh see the last parentheses block). But, I’m also often a developer (the person who has to make the buzzwords real) and an advisor to founders and execs. This means, I am the one who suffers if the buzzwords get too far ahead of the work. So, I like to think this puts me in a decent position to explore the nuance in this topic.

By themselves, buzzwords don’t bring much to the table. They’re ephemereal. As Kendall Roy put it in Succession, they’re “just nothing, just dusts of complicated airflow”. Who cares if you are a “React dev” or a “data engineer”. No one pays rent in event based architectures for distributed systems. Your software has to bring value. What is value? Basically, you’re either killing pain (reduce costs) or creating joy (increasing profit). That’s it. It does not matter if you have all the buzzwords in the world. If you’re not solving an actual problem, eventually, you will get found out (whether that’s after several rounds of funding is a different conversation all together).

From Job Titles to Value Creators⌗

Patrick McKenzie (aka patio11) has a great post on this idea from the perspective of the individual practitioner (see here: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ ). He makes the case that you should not call yourself a “software engineer”, “data scientist” or anything role based. Instead, you should understand your role and leverage that understanding to sell your expertise based on the clear and direct value you bring. Instead of being a backend developer, you are someone who automates workflows to reduce operations costs. Or consolidates various data sources and increases the number of sales targets identified per quarter. Or something like that. The point is, don’t frame your value strictly through whatever buzzwords are associated with your skill set. Be someone who can reliably and consistently increase an organization’s ability to make money or save money. As Patio puts it, “Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.”

Bring value.

Extending the Concept to Organizations⌗

I’ve been thinking about how this applies in a macro sense as well. I think we can extend the ideas that Patio puts forward for individuals towards organizations as well. Specifically, for businesses. Shifting economic conditions( i.e higher rates, less gambles, and increased focus on cash flow) have brought the markets down to earth in a lot of ways. It is fashionable to be profitable (odd thing to anyone outside of business functions, but generally this was rare during ZIRP). This means people are (sorta) operating and developing products with a thesis more aligned with uh actually doing things that will make more money than they burn. Expectations have shifted and that has brought people a different north star than prior periods. Both for developers and customers. This means businesses are looking at their multiple subscriptions costs, software products and outsourced services and figuring out if their actual and real impact is killing pain or creating joy. Founders and executives are taking hard looks and reflecting on the value the businesses themselves are bringing to the table at the highest level. And they are finally looking at their financial statements to see if uh their revenues > costs. Some are doing this better than others (old habits are hard to break).

The Unforgiving Nature of Value⌗

What’s my point?

I guess my point is that while it’s easy to romanticize our craft while we build products or buzzword our way through an investment pitch, the need to create concrete value is as unforgiving as a physical law like gravity. Developers, designers, and founders should approach their products and companies with this in mind. It has to be something baked into the team’s composition. Granted, this assumes that your purpose is to earnestly create a sustainable business that withstands the test of time. This is mostly due to the fact that everything I’m describing is framed through the perspective of surviving different conditions and evolving situations. If you build something to get acquired within 2 years, it uh sorta matters less if you actually make a profit. But even then, on a long enough timeline, gravity takes hold. Because if your startup gets acquired and fails to turn profit for its acquirer…they’ll shut down that business unit. Which maybe matters less to you if you made your personal fortune in the acquisition. But still, I think success should be measured in how long you can stay in the game, not how quickly you can flip a startup.

How does one operate with this in mind?

I hate to say it but….it depends (I say this about 1000000 times a day). There’s a fine line between being focused on value and going full Jack Welch. I will say it’s easiest at the earliest // scrappiest stages because uh people have to pay rent and buy food. So there’s a pretty inherent focus on value. It’s a bit harder when there’s easy money or capital at hand, but it’s still doable. It takes some strong culture and people being comfortable having real, sometimes difficult, authentic conversations as adult human beings about priorities and material goals. You know, with both empathy and a clear rational perspective. So again, it is hard, but ultimately necessary. Because, eventually, your runway start to run out. Eventually, that burn rate hits 0. Eventually, you have to bring in more money than you spend. Eventually, buzzwords are not enough.