6 min read

Kim's Law

If you can't figure out how to deliver joy to your teams, then inevitably you will lose the ability to deliver joy to customers.
Kim's Law
If you can't figure out how to deliver joy to your teams, then inevitably you will lose the ability to deliver joy to customers.

Show Notes

Today is your lucky day because you're listening to The Imposters Club, the podcast for misfits in tech. And I'm your host, Teddy Kim. Today, let's talk about the two kinds of engineering work because there are two kinds.

Generally speaking, engineering work fits into two different buckets. The first bucket is about delivering joy to customers. How do we do this? As engineers, first and foremost, we think about quality but that's not the only ability we care about. We also care about scalability, reliability, extensibility, usability, etc. The "ilities" are things that the customer can feel and experience. If you can hit most or even some of these buttons, then you have a fantastic product and happy customers. How do you know when you're getting this first bucket of work right? Well, the real indicator is growth. Double-digit growth is a pretty good sign that you're delivering joy to customers. If growth doesn't make sense in your context, you could use NPS or net promoter score as an adequate proxy variable.

Now, let's look at the other bucket of engineering work. Yes, there is another bucket. The second bucket isn't about bringing joy to customers. It's about bringing joy to your team. What goes in this bucket? Well, things like writing clear requirements, batching work correctly, dependency management, pair programming, TDD code reviews, mentoring, refactoring, coaching, recruiting, culture, design, process, repair, etc., etc. This work is what engineers do to make other engineers more effective. Customers don't directly experience this type of engineering work, and they likely wouldn't pay for it. But that doesn't mean it has no value. Because joyful teams create great products, I would argue that this bucket of engineering work is at least as valuable as the first bucket.

So how do you know when you're getting this second bucket of work right? Well, to state the obvious if your best devs are bouncing to go to work at other companies that's a pretty good sign that you need to work on the second bucket. But you don't need to be a science rocketist to figure it out. Look around. Do you see any smiling faces? When was the last time you heard a belly laugh at work? Does your team have spontaneous fun or is your fun organized and sanctioned by the fun police? Now, many tech leaders frankly, don't care about the second bucket because well, they don't care about team member joy. We're all commodity workers. That's the point of a commodity labor market. If people are interchangeable, like Kleenex and uffs, why not just use them up and throw them away? That's the prevailing view.

Well, perhaps the prevailing view is flawed. I think it is. I have made this same observation so frequently, that I have codified it as wait for it, Kim's law. Kim's law states that organizations who suck at the second bucket will eventually also suck at the first bucket. If you can't figure out how to deliver joy to your teams, then inevitably, you will lose the ability to deliver joy to customers. It's easy to see why this would be true.

Let me present the following analogy. It's Sunday afternoon, you're out of toilet paper. So it's time for a trip to the store. Well, when you get to your local supermarket, the parking lot is completely snarled so you sit in the queue slowly dying inside. You just want toilet paper. Why is it so hard to give Super Mart your money? Soon you realize that the parking lot is strewn with dependent shopping carts. Shopping carts are blocking the lane, so people have to drive around them. So that's why you're backed up! Some jack wagon isn't doing their job. Through the plate-glass storefront, you can see a veritable Shangri-La. Donuts, prime rib, and shelves bursting with toilet paper. If only you could get inside and experience all that quality...but you can't get inside. You're stuck in your car in a parking lot full of angry people. Because some jack wagon didn't do their job. Eventually, your annoyance turns into frustration and then you rage quit. You drive off in a huff and make a beeline for a store where you can actually park.

Quality doesn't matter if the customer can't experience it. No amount of hustle inside the store can make up for a jammed parking lot outside the store. Some jack wagon needs to do their job. Well, eventually the shareholders at the supermarket get wind that something is wrong. Why are sales down? Cuz people can't spend money if they can't make it past the shopping carts and into the store. Maybe the solution is to hire someone who can push carts out of the way? But pushing carts out of the way sounds hard and boring. That won't put any sizzle in your resume. Instead, why not engage a pricey executive search firm to bring in a new CEO who can shake things up and turn things around. Now we're talking! What an awesome idea. Inflict more agitation on a system under stress. What could possibly go wrong? Well, sometimes shakeups are good, but you're still not going to Super Mart. The new CEO has a great resume, but he isn't pushing carts out of the way in the parking lot. And that brings us back to Kim's law. Stated another way, if you can't push shopping carts out of the way, it doesn't matter what's inside the store. If you really want to turn the ship around, you need to get good at the second bucket. You need to roll up your sleeves and start pushing carts out of the way.

Here are some examples. Do you have carryover points every sprint? Well, you're not good at batching. Learn how to do it correctly. It's not sexy, but it's necessary for team morale. So figure it out. Do you have a bunch of legacy code that everybody is afraid to touch? It's probably slowing you down. Well, learn TDD and refactoring. Definitely not sexy, but necessary. If you want to evolve your solution. Figure it out.

Do you have a lot of user-reported bugs? Are your coders writing checks that your customer support team has to cash? That's lame. Work harder on getting acceptance criteria. Learn how to do automated testing. Learn how to fix fast rather than ship fast. It's not sexy, but it's necessary. Figure it out. Cart pushing sounds so sensible. Why isn't everyone doing it? Well, I have some ideas. For one thing, at most tech companies second bucket work is seen as low status. And the entire mythology around 10x is based on a heroic coder who is 10 times better than her peers. But only at bucket one activities. That is the point of 10x. It makes no sense but that's where we are as an industry. Welcome to the theater of the absurd. It doesn't matter if you're a socially mal-adjusted Eeyore, if you're great at bucket one, the entire industry is there to kiss your ass.

Well, maybe not the entire industry. When I'm looking for asses to kiss. I look in the second bucket. I'm looking for team players who unselfishly block and tackle for their teammates. I'm looking for people who would rather win than be right. I'm looking for people who play hard even when they're not carrying the ball. In short, I'm looking for people who can push shopping carts out of the way in the parking lot. Check it out. The industry will never acknowledge this, but software of any significance is produced by teams, not individuals. Personal heroics results in trash software, and trash companies.

So how do we fix it? Well, things are changing whether we like it or not. Let's face it, algorithms write code better than humans nowadays. But algorithms can't push carts out of the way. We're starting to realize that we need to hire more car pushers and pay them what they're worth. After all, in a world with Firebase and other platforms as service solutions, why would anyone hire a pure techie anymore? Bucket one is where commodity workers go to die. Bucket two is where your assets live. The tech status pyramid is being inverted and I say, Good riddance. The status quo is lame as shit. Burn it down. Oh, by the way, I am hiring car pushers for my team. Maybe you fit the bill. If you do. Hit me up.

I'm hiring software engineers! Check out the jobs page to see my open positions.