Tag: Customer Obsession

Heroes In Another Form

Heroes In Another Form

Hard to believe 9/11 was twenty-five years ago. Like most people alive then, I remember exactly where I was: sitting in my little office within the Air Force Research Lab at Wright-Patterson Air Force Base. My wife called and said a plane had hit the World Trade Center. I tried to get more information on the CNN website, but at that time even moderate spikes in traffic could take a site down. Needless to say, a lot of people were desperate for information, and the page completely fell apart (as did every other news site). That lack of updates was agonizing, especially once I got a second call about a second plane. We were all sent home shortly thereafter and thankfully then I could get in front of a (standard definition broadcast) television.

Much will be said today about the heroism and villainy on display that day, in a form more eloquent than anything I could write here. But small things are still worth being grateful for, and in this moment I’m thankful for the scores of brilliant people who built the global infrastructure of the Internet and deployed a robust stack of software on top of it such that the days of page overload and information deserts are mostly in the past (for me, at least; I acknowledge there’s still work to be done on this front, but the barriers are no longer technical).

Getting anything to “just work” is incredibly difficult. On the shoulders of giants, indeed.

Vocabulary Lesson

Vocabulary Lesson

If you couldn’t guess from my prior post, “they” is not one of my favorite words. Another disliked one is “just”.

First, everyone will not just. If your business strategy amounts to “if we all just do our job we will succeed,” you’re on the road to failure. I’ve fallen prey to this thinking before. It seems so simple and straightforward. But it’s ultimately lazy leadership. People have their own motivations, incentives, and goals. This is okay. Being a leader means figuring out how to find the right Venn diagram overlaps between individual objectives and company objectives, learning to fight effectively with the army you have, and in the worst case, making the tough calls where there isn’t enough in common.

A closely related failure mode is “we’ll just hire the right people.” That won’t work either. Yes, you should invest a lot of effort in your recruiting and hiring efforts. But it’s hard! And you’ll get it inevitably wrong, because there are no perfect people.

Finally, while it may sound good, “just get it right the first time” is a fool’s errand. It’s doubly impossible: first, no one can get it right the first time. And second, no one gets the definition of “right” right the first time either, so even if you hit your target with your first shot, you’ll find you were aiming at the wrong one. This is exactly what agile process exists to account for. Change along the way is inevitable so embrace it.

Fun fact: I wrote most of this post while riding in a Waymo for the first time, which feels appropriate. Human drivers don’t “just” either.

The Heart Of It All

The Heart Of It All

“Once code stops being scarce, the only thing left to pay for is care.”

The above quote from Geoff Scott of Kindness Flywheel caught my attention a few months ago. I can’t disagree. I’ve spoken before about the importance of doing small things well even when they won’t be seen, how details matter, and the motivating power of empathy. Care sums it all up beautifully.

This is not a new concept. I’m told the philosopher Martin Heidegger went so far as to consider care (more precisely the German word Sorge) as fundamental to being human. I’m no philosopher (collegiate aspirations notwithstanding) but that certainly seems to make sense at a time when machines are capable of producing so much content without a care in the world. For such content to mean anything, it needs to come from a place of care: for the topic, for the audience, and for the results. If you have that, using generative AI can be a good thing. Without it, not so much.

Care can also be a fantastic way to focus and prioritize. There’s a certain clarity that comes from being honest with oneself about what is cause and what is effect: it’s hard to claim genuine care for a task that’s put off repeatedly or a person that’s kept at arm’s length.

Of course, caring has drawbacks. The associated emotions can be complex and even contradictory. They come with challenges, outbursts, demands, complaints, and a host of other messy stuff that’s no fun in any setting, let alone a professional one. It’s a real effort to channel that emotion effectively (and I know I’m not always great at it), but the spillover is inevitable and not a sign of complete failure or need to panic. Work being stressful is often a sign that you’re doing things right.

I don’t say this to excuse dysfunction, but I’ll take care and its baggage over apathy any day.

My Lips To God’s Ears

My Lips To God’s Ears

Haven’t posted much lately, been busy with the day job, doing an awful lot of prompting (this is more true than ever). But rest assured, here at Making of Things, it’s all human all the time, unless I say otherwise.

It’s fun watching a bunch of agents writing code all once

I’d like to believe I was early to the idea of voluntary disclosure of the use of AI in writing and especially early to the notion of trying to categorize types of AI collaboration (another post written with the help of Claude). My approach was perhaps a bit romantic (whimsical, even), but this one is more methodical: AI Usage Scale. I quite like it!

Related: Don’t be a meat proxy.

Shiny Happy People

Shiny Happy People

I just got back this week from a vacation that I’ve been dreaming to avail myself of for a decade. It was delightful, and once again served as a reminder that to be effective at my job requires periodic distance from it (though admittedly I did check in a couple times, because sometimes I need a break from my break).

Before heading out I’d wrapped a multi-week project that was a collaborative effort across several organizations. That kind of achievement feels good in and of itself, but I was also reminded that working with great people can be quite a bit of fun. And that fun can power great results. Happiness in work matters!

The project in question was related to verifiable credentials, of which I’ve spoken before. That post has some solid background links on the topic; here’s another series from NIST that’s also instructive:

Or if you have even less time, these one-page introductions to three fundamental concepts, from my friends at Freewallet:

Happy reading!

Maintenance Matters

Maintenance Matters

In case I haven’t said it explicitly enough, I’ll do so again here.

I wrote these definitions a couple years ago in an effort to bring some formality to what would be covered under a maintenance contract. They served well enough to pass along here.

Major Issue: Problems that impede core functionality, such as:

  • application fails to load
  • users cannot log in
  • workflows are inaccessible or fail

Minor Issue: Problems that do not impede core functionality, such as:

  • slow, but functional, responses to user interactions
  • workflows succeed but are sub-optimal
  • typos and visual glitches

Feature Enhancement: Updates that meet all of the following criteria:

  • do not fundamentally alter an existing capability
  • do not create a new user workflow
  • do not require new integrations with or data from external systems

New Feature: Updates that meet one or more of the following criteria:

  • add a capability that did not previously exist in the system
  • create a new user workflow
  • require integration with an external system

Environments

  • Dev: where software engineers do their daily development work
  • QA: where vendor work is tested before going to customer for acceptance
  • UAT: where customer performs final test and acceptance of features
  • Production: where users access the system
All’s Well That Ends Well

All’s Well That Ends Well

I reposted the broader announcement on LinkedIn, but thought it’d also be worth capturing here, that the final proposals for the Technical Executive Leadership Initiative class I took earlier this year have been published. I was part of a great collaborative team; while I had some contributions across the board, my focus was primarily the mockup website and accompanying demonstration.

If you’re a technologist working in the public sector and want to get better at working with government, I highly recommend this program. You’ll also get a nifty public profile out of the deal (as if I needed more to add to the collection).

I’m now reminded that it’s been a few years since I’ve had a professional headshot taken, something I should probably rectify.

The Truth Sets You Free

The Truth Sets You Free

Editor’s Note: I’m going to be going through some old drafts and either get them published or delete them. This beauty is from a few years back when I was trying to reap at least some benefit from visiting my least favorite city, Las Vegas. Thank goodness I can now get Marriott Bonvoy points at any MGM hotel instead.

This is an impressively bad error message I ran into while trying to create an account on the MGM Resorts website. The input screen even had instructions on password format, so the framework was there to do the right thing, but they didn’t mention length, nor did they validate it in the UI.

Of course I had to dig into Developer Tools to see what was going on. A useful error message was right there. C’mon MGM, do better.

Also, a 20 character limit for passwords? That’s dumb.

Imagining Dragons

Imagining Dragons

Editor’s Note: I wrote the first draft of this post back in December, before I’d truly discovered Claude Code. Not sure it’d play out this same way now, several months later. I really ought to get back to it and find out.

I used Amazon Kiro to build a thing that I hope to publish eventually. But in the meantime, I’ll share an anecdote from my experience with it.

The spec-driven development model makes a lot of sense to me. In a few minutes with Kiro, I thought I had a solid description of what I wanted to build. Kicked off the tasks, let things cook for a while, and after a bit, I was told things were ready to test.

Not quite sure where to begin, I asked for a full end-to-end walkthrough in the README. The model wrote a great one with detailed, step-by-step command line instructions. I was excited to try it out. Opened up my terminal, Ctrl-C Ctrl-V-ed the first command, and… error: option not supported.

Tried another one, same thing. Weird.

Did a bit more investigation and came to a shocking realization: Kiro had hallucinated the entire walkthrough.

At first I was upset, but in truth, it was okay! Because I just told Kiro to read the README in detail, and turn the walkthrough into reality by building all the stuff it had invented, and retroactively put it in the spec.

Legitimate approach? Perhaps. But next time, maybe I’ll have it build the experience first, and then the code? Work backwards from the customer, anyone?

All Around You

All Around You

Ever need to run a bunch of parallel bash commands with the same executable but different arguments? And be able to watch their stdout streams without them being intermingled? And get a brief report on successes and failures at the end of it all?

Yeah, me too.

Had Claude Code whip me up this script just now. Works like a charm.

Not entirely relevant, but did the above while three other coding sessions were summarizing my past six months of activity, refining a podcast script, and putting together a set of questions for an RFP response.

While on an airplane.

The world can be a messed up place at times, but it’s still full of magic and miracles.