By: Chris Greacen - 03/27/2025
I was bummed to see that 18f got the axe as part of DOGE's cleanup of "radical leftist" government waste (sarcasm). The loss of 18f is a shame because their mission was in fact related to efficiency and value - they were striving to operate in a way that yields reliable, usable software. Software that serves a purpose. In this case, making government software more reliable and more accessible.

This way of looking at software is critical today as more and more of our government services are delivered through some digital channel. We learned hard lessons about the state of software development in the early days of the ACA. It was an actual mess, armies of expensive consultants built bloated systems that weren't reliable, weren't able to talk to each other, and ultimately didn't serve the people whose medical coverage was at stake.

18f sought to reverse the trend in gov-tech by deploying small teams to work with modern tools and techniques to understand the users, their needs or jobs, and craft just enough software to get the job done.

Were they successful? Kinda. They were able to apply their approach to a few high profile systems and ended up helping many people.

One thing I really appreciated about the group was the way they captured their practice in a set of guides. These guides became the gold standard in some gov-tech circles. In fact during Lab Zero's entry into the ADPQ pool, the California Department of Technology required that all entries refer to the 18f playbooks and guides. You can see an example of how this works in Lab Zero's git repo where we captured an example of how 18f plays apply to the craft of software product development.

There are some real basic common-sense concepts that show up here:

• understand your users and what they need
• think about the entirety of your users experience
• keep it simple
• work, build, deliver incrementally, iteratively
• have a leader on your team
• use modern open source tools

But you know what? There are many places where these ideas are still exotic and rare. With some exceptions gov-tech is still one of those places.

So when it became clear that 18f was in the crosshairs of the DOGE-purges, I decided to grab the guides and make a private copy.

Take a peek: https://greacen.com/media/guides/

Need a usability test script example to help get started with user testing? There's a guide for that. Need to lay some ground rules for how your engineers will handle incident responses? There's a guide for that.

Is my hand-made scraper-script mirror/archive special? I thought it was for a bit, but then I came across 18f's git repo (still not deleted!) and saw that they've made it easy for you to grab it. Tip: grab it.

Similarly, Lab Zero put a lot of energy into< creating resources that describe how we work. We use these to align with our clients or sometimes teach them something to help refine the way they work (want to know more about Speclets? let's talk!).

Teams that share skills and know-how for highly complex topics like delivering quality software products are worth paying attention to. So I pour one out for 18f.

By: Chris Greacen - 03/21/2024
Everyone is SO VERY focused on AI these days. Everyone expectd this to change our world in a big big way at any moment. People describe this in grand terms believing that this is truly 'unprecedented', but it's happened a couple times before. It already happened in our lifetime in fact.

You can't underestimate the impact that the internet brought to the business world. The change was explosive, radical even. The transformation brought new forms of organizations, new ways of running a business, new ways of connecting with customers. Many household names disappeared because of change brought through modems and cat5 (hello Blockbuster!).

Will A.I. bring the same kind of change? If you drink the kool-aid, it surely will. I see a lot of similarities in some of the shiny-objects that captured a lot of attention in the early dot-boom days of the web. Most were flash-in-pan experiences - got a lot of eyeballs, but offered no lasting value.

I see a little bit of that flash in what these Large Language Models and chat interfaces bring. Somewhat believable answers to questions on almost any topic are, well somewhat believable.

Here's an example:

Me: Can you summarize the story on this web page? https://www.netscrap.com/netscrap_detail.cfm?scrap_id=1 (note: this is my favorite 'scrap' article that's on netscrap.com)

A.I.: The story on the web page is an excerpt from "Masquerade: The Amazing Camouflage Deceptions of World War II" by Seymour Reit (Signet, 1980). It describes a German decoy airfield built in occupied Holland during World War II. The airfield was constructed with meticulous care, made almost entirely of wood, including wooden hangars, oil tanks, gun emplacements, trucks, and aircraft. The Germans took so long to build the decoy that Allied photo experts had ample time to observe and report it. When the decoy was finally completed, a lone RAF plane crossed the Channel, came in low, circled the field once, and dropped a large wooden bomb on the wooden airfield.

Me: Is there anything humorous in that story?

A.I.: The story you provided does not seem to contain any humorous elements. It is a historical account of a German decoy airfield built during World War II, which was eventually destroyed by a single RAF plane dropping a wooden bomb on the wooden airfield. The story focuses on the details of the decoy and its eventual demise, rather than incorporating humor or comedic elements.

Me: Are you sure there's nothing funny in that story?

A.I.: I apologize for the confusion in my previous response. Upon re-reading the story, I found a humorous element in the account of the German decoy airfield during World War II. The humor lies in the fact that the Germans spent a great deal of time and effort constructing the decoy airfield, only for a single RAF plane to destroy it with a wooden bomb. The irony of using a wooden bomb to destroy a wooden airfield adds a touch of humor to the story.

Me: When you say "destroy" in your answer, what specifically was destroyed?

A.I.: In the story of the German decoy airfield during World War II, the following elements were destroyed by the RAF plane dropping a wooden bomb:

1. Wooden hangars: The decoy airfield was constructed with meticulous care, and the wooden hangars were part of the deception.
2. Wooden oil tanks: These were also part of the decoy, designed to look like real oil tanks from a distance.
3. Wooden gun emplacements: These were included in the decoy to make it appear as if the airfield was well-defended.
4. Wooden trucks and aircraft: These were additional elements of the decoy, intended to make the airfield appear operational and attract enemy attention.

The RAF plane's wooden bomb destroyed the wooden decoy airfield, effectively neutralizing the Germans' efforts to deceive the Allies.

And so, there you have it. These things aren't really tuned to the kind of nuance that makes jokes like the one I shared work. They're impressively verbal, but lacking something important. Everyone close to the tech assures me that it's just a matter of time till stand-up comedian no longer a viable career path.

Till then I'll keep looking for better tasting kool-aid.

By: Chris Greacen - 03/18/2024
I had a chance to hear Marty Cagan speak at Dan Olsen's Lean Product Meetup hosted at the Intuit office down in Silicon Valley. Marty has just published a new book titled Transformed which helps to lay out rationale and a pathway for organizations to move from a feature factory to operating more as an 'empowered product team'.

After Marty's presentation I asked him about the thing that's been bugging me - are we even making progress in this industry? Our work at Lab Zero has always been to try to bring empowered software product team practice to our clients. Somehow, this doesn't really seem to fit with much of the industry - most companies are happy to have people cranking out work in a more predictable fashion instead of seeking real value.

Marty talks about "the best" and "the rest" both in this answer and in several of his books- the best companies are some of the most valuable companies on earth right now. They have empowered product teams. The rest don't -- and their value shows it.

Scroll to 47:40 to find me:

Me: I have the microphone... thank you. I’m gonna ask a quick question here.

When things get tough in my business, my business partners and I go to YouTube and we put on one of your keynotes. And we watched you recently: 2018, talking about empowered teams, product management skills, product / engineering collaboration, discovery... it was a long time ago when you were bringing that up. Preaching to the choir here, at least in this case. I love the book, the way you’ve laid it out here.

I’m excited to try to bring that to what we’re doing but like it still seems like the exception and a rarity, where there are empowered teams that have the permission to do the right thing. And are we are we losing the fight? Are we fighting the right way? Can you talk about how we can drive more of the goodness into the world that we work in?

Marty Cagan: Yeah. By the way, you just summarize endless frustration for me.

I mean, look, 20 years I’ve been trying to get more people to work like “the best” and when we look at overall... I mean in the absolute sense, there’s way more people working like “the best”... but in a relative sense, it seems about the same percentage. Which is not very good. I mean, it’s somewhere -- it’s hard to know really -- somewhere like 10 to 20% I would put in that “best” category and 80 to 90 in “the rest” category. I don’t think that’s very good.

One of the things I discussed with Lenny (on his podcast the previous day) I probably shouldn’t have was, why the hell is that not the case? So essentially what you’re asking, and I have a theory, and it’s a difficult one to share -- I did share it with him and but and that is that it’s very frustrating. What motivated this was not… this was more recent than the book… if you have been following — I’ve had a lot of stuff talking about theater -- product management theater, transformation theater, product management

Me: LARPing it's a lot of LARPers in there live action roleplaying.

Marty Cagan: Yes, well, we're both being generous with what's going on but you know, how is that possible? And I what what kicked me -- really frustrated me was one of the biggest organizations in the US at least that trains product managers shared an article. I won't embarrass them publicly, but you know, takes two minutes to figure out... and it shared an article about how they define the product manager role. And I'm looking at this article and I can't believe they said this out loud. Because they don't most people you know, you hear him try to define a product manager they go to... bend over backwards to try to make it sound important. And try to make it sound more than a project manager. This company did not. It was 100%: communication, coordination, and you should know a little bit about engineering, a little bit about design. Like I cannot believe they said this out loud. And this is the primary group creating a certifying product manager. So I'm like we're screwed.

If that's what's going on, and I'm like, how does that happen? Well, my theory is, if you're a brand new product manager, and you join a job, you go to Google, you type something like you know, "how do I product manage" or something? Chances are you will end up with people teaching you from feature team world, or worse. That's just the odds. And by the way, generative AI will only increase the likelihood of this not going well if you think about how predictive text works. So those people they just get put on this path, and they think they're doing -- what they're supposed to be doing. And then their CEO says, I mean, there's one other thing that motivated me was a European CEO told me he had 200 product owners... and he said "the truth is I think if we got rid of all 200, nobody would care." That hurts, right? I mean, that's harsh. But you know, how can I disagree with him?

And "product owners" Have you met? You know, this is thankfully not much of an issue here. I hope none of you have a title on your LinkedIn profile "product owners" you do you should wake up and fix that like right away. That is not a job -- that's a role on a delivery process. That's not a job but unfortunately, these -- I don't know how many millions, maybe of people that have been certified as a product owner. Almost all of them have been certified by an Agile Coach that is never done product. Anybody think there's something wrong with this picture? So it just propagates!

On the other side on the on the side of light -- we have the most valuable companies in the world. Otherwise, I think we would have drowned out a long time ago. So it is bizarre. You're all -- we're all fortunate to be right here. In most of the world. I mean, it's shocking. It really is. So you just asked like a BIG question.

So- I think we're both losing sleep over this topic. There's a missing ingredient in making this fit and making this the obvious choice, the obvious better path. I have a lot of work to do - we all do.

BTW- I took this transcription from otter.ai which was one of the sponsors of the event. I made a couple edits in this for clarity. Go listen to the whole thing on otter.ai.

By: Chris Greacen - 10/19/2023
I recently wrote a post on Lab Zero's blog on the topic of recognizing sources of technical debt. This caught the attention of one of the organizers of the Bay ALN meetups and they invited me to present on the topic.

I put a brief talk together based on the outline of that blog post and delivered it the other night. I think I can embed a couple slides from the deck I used...

The presentation followed this path through the story.

• Intro, caveats
• Tech debt background
• Recognizing trouble
• Two common sources
• Recognizing progress
• The real casualty
• Two questions for you

Give this a listen if you're curious about how this went or if you're interested in Technical Debt.

By: Chris Greacen - 09/01/2023

Hope everyone is all set for a good Labor Day weekend. I wanted to share some updates from the Lab Zero Innovations Inc. team. A couple new posts on the blog hint at some of the recent work that the team has focused on: application modernization, performance improvements, managing technical debt. Take a peek:

I shared some thoughts about the two most common sources of technical debt: https://labzero.com/blog/two-most-common-sources-of-technical-debt

Jeffrey Faden shares his experience in modernizing a React.js application: https://labzero.com/blog/upgrading-an-ancient-react-application

Travis Gaff shares a great way to get server performance data into your browser's developer tools: https://labzero.com/blog/server-timings-rails-performance-metrics-in-your-dev-tools

Let's stay in touch!

http://labzero.com

#technicaldebt #reactjs #applicationmodernization #developertools #applicationperformance #blog #fricassee