Go, Do, Be.


A conversation with the A.I.

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:

asking the ai to summarize a web page 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.

asking the ai whether there's anything funny in that story.

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.

asking the ai a second time whether there's anything funny in there.

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.

Starting to think that the ai is the joke.

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.

Marty Cagan on empowered product development teams

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'.

Marty Cagan speaking at Lean Product Meetup

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.

Technical Debt Talk at Bay ALN Meetup

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.

Wishing a good Labor Day weekend, calling out blog posts

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!


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

Two Most Common Sources Of Technical Debt

By: Chris Greacen - 08/28/2023
People say "technical debt" like it's a bad thing. But those who are serious about software development know that this game is all about managing technical debt. Technical debt is a natural part of the landscape in any software development team’s world. It's neither good, nor bad. Yet when trade-offs are mismanaged, technical debt is likely to cause your productivity to grind to a halt. For people who hit that point and wonder why - there should be no mystery about what causes technical debt, the answer is right in front of you.

What is technical debt?

We can thank an early agile-manifesto-ist Ward Cunningham for the term"technical debt" which is a fantastic metaphor for this dynamic. Technical debt, code debt, or design debt functions the same as financial debt: a team can take a shortcut to deliver something quickly, but the short-term advantage of that short-cut can make future work harder. The team gets a convenience in the short run, but has to pay it down with some interest later.

Not all technical debt is equal

Every team at every company regularly makes trade-offs about incurring debt to get something done, then hopefully cleaning it up and refining it afterward. You get a quick win, then you do the work to strengthen or refine your short-cuts. Where this gets dangerous is when it's not a conscious or intentional choice - a team can stumble into a situation where previous decisions they've made have a disproportionately high impact on the work they're doing today. They've built to their best understanding, done their best efforts, but somehow they are still bogged-down. If you find that your team seems stuck in firefighting-mode, unable to deliver new features, facing quality challenges, you may have unintentionally ended up with technical debt.

Where does technical debt come from? (spoiler alert: it's your team)

If you're deep in it, you may be wondering how did we get here? There's a lot of writing online about the causes of technical debt. I'm sure you've read them already. But when you boil it all down, unintentional tech debt comes from two sources: your engineers and your product managers.

Your engineers contribute to technical debt

If your engineers lack the experience and skills to manage complexity, to refactor effectively, to advocate for refactoring/automation/re-architecting, they will build more than you need and have a hard time maintaining it. They may not have the discipline to regularly review, refactor, test, and remove the junk.

  • No standards
  • Not reviewing code
  • No test automation
  • No regular refactoring
  • No regular re-architecting
  • No evaluating new tech or libraries
  • Not helping product managers understand what's needed
  • Not advocating for process

Your product managers contribute to technical debt

If your PMs aren't effective with stakeholder management, if they engage in deadline-driven prioritization, if they have poor collaboration with technical roles, lack of clarity in what customers need, lack of clarity in what the business needs. These all conspire to let your teams write code that does't serve the business.

  • Saying yes to your CEO's hairbrained idea
  • Setting a string of date-driven milestones
  • Being unclear on what your customers really need
  • Not working to solve a measurable problem/solution
  • Saying no when your engineers advocate for time to refactor/rearchitect
  • Saying yes to big bang change

But wait, there's more: technical debt == design debt

Designers face challenges of managing complex technical assets (Figma), contributing to product development, and driving learning efforts to get closer to users. In our experience helping companies develop and deliver software products, we've seen how this kind of trade-off can create a similar compounding-interest with the design effort for a product. People love to start building as quickly as possible and inevitably build something based on assumptions. Maybe they get lucky and their assumptions are good enough to work with - more likely they will miss the mark with their customers. When they get around to learning what their customers really need, they will begin to understand the real effort that's needed.

The impact of technical debt

Each of these things in isolation might not have a big impact on your planning or your business. But in aggregate they'll start to show up. Have you seen something like this: defects piling up, poor application performance, poor UX, reduced customer satisfaction, your teams spending time on manual tasks rather than automating their work (driving up operating costs), simple work carrying too much risk (which nobody wants to take), customers preferring to talk to someone on the phone rather than use your website. The obvious end result is massive waste from friction in delivery and lack of capacity while everyone is fighting fires.

A less obvious casualty is your understanding of the cost of development. My personal peeve about the software development world is that very few teams have clarity on the value of what they're working on. The value of our work needs to incorporate the costs of development. When the costs of development are obfuscated by technical debt, it's very hard for a team to establish clear priorities and make effective tradeoffs.

Solving technical debt challenges

There is no one-size-fits-all solution - everyon's situation is different. We often hear teams lament that they are too busy to get help, so solving this isn't going to be straightforward. Without getting too deep into the weeds, you can see that the only way out is by changing practices that your product and engineering roles lead. A healthy approach to managing these trade-offs include regular reviews and refactoring, prioritizing this work that incorporates learning, maintaining high visibility into debt- generating trade-offs, and relying on partnership between engineering and product management in building your roadmap. Want more specifics to help tame and manage technical debt more effectively? Re-read the bulleted lists above and change all the "nos" to "yesses", and vice versa.

How are you managing these two common causes of technical debt in your org?

This post originally appeared on labzero.com.

Hero photograph by Sergei Gussev via CC BY 2.0

Meme photograph from "When A Stranger Calls (2006)" the internet 

03/08/2023  —  TECH  — 

Lies we tell ourselves: the 10xEngineer

02/13/2023  —  TECH  — 

Reflecting on the project that started it all

02/08/2023  —  TECH  — 

A vision for Lab Zero

01/02/2021  —  TECH  — 

This damn site

04/28/2020  —  TECH  — 

Chris On The Bridge: Build To Learn

04/21/2020  —  TECH  — 

Chris On The Bridge: Self-Healing Teams

04/05/2020  —  TECH  — 

Chris On The Bridge: Embrace Risk

04/05/2020  —  TECH  — 

Chris On The Bridge: Are You Agile?

04/04/2020  —  TECH  — 

Chris On The Bridge: What is Essential?

04/02/2020  —  TECH  — 

Chris On The Bridge: Trust From Home

01/22/2020  —  TECH  — 

Why is Agile Popular?

02/04/2019  —  TECH  — 

12 Signs Your Client Trusts You

06/04/2013  —  TECH  — 

CTA- the most important part of your page.

06/03/2013  —  TECH  — 

All web apps

02/29/2012  —  TECH  — 

Strata Conference

06/29/2010  —  TECH  — 

And Boom!

12/15/2009  —  TECH  — 

Rubicon Project Ad Network Sloughs-off Small Publishers

06/24/2009  —  TECH  — 

Allspaw talks at Velocity Conf.

03/29/2009  —  TECH  — 

Twitter-Based Blog Syndication Flowchart

03/26/2009  —  TECH  — 

Twitter-Based Surf Report Flowchart

01/19/2009  —  TECH  — 

GoFish Becomes Betawave

12/15/2008  —  TECH  — 

Darwin's moth: a survey of behavioral targeting solutions

12/12/2008  —  TECH  — 

100k Pageviews For Free

12/01/2008  —  TECH  — 

The End Is Near

09/03/2008  —  TECH  — 

A day on Chrome

08/20/2008  —  TECH  — 

Digsby will change the way you communicate online

07/16/2008  —  TECH  — 

twitterfountain, fun stuff!

06/27/2008  —  TECH  — 

Post 1000

06/05/2008  —  TECH  — 

Matt Freeman to GoFish

04/17/2008  —  TECH  — 

AdTech: Widgets and Gadgets

04/15/2008  —  TECH  — 


04/09/2008  —  TECH  — 

bashWebTest Lives!

03/24/2008  —  TECH  — 

Simple Rss Widgets

03/19/2008  —  TECH  — 

COPPA, friend or foe?

03/05/2008  —  TECH  — 

Social Widgets

02/18/2008  —  TECH  — 

GoFish, For Reals

02/08/2008  —  TECH  — 

KodakGallery FINALLY integrates with the web

02/05/2008  —  TECH  — 

QA Interviewing: The Phone Screen

01/29/2008  —  TECH  — 

GoFish spilled, again...

01/29/2008  —  TECH  — 

108 Votes for NetScrap.com

01/25/2008  —  TECH  — 

Seeqpod sued by Warner Music

01/25/2008  —  TECH  — 

js-kit comments on greacen.com

01/21/2008  —  TECH  — 

34 million lattes on Howard St.

01/15/2008  —  TECH  — 

Macworld today

01/13/2008  —  TECH  — 

Technorati? Well, ok.

01/13/2008  —  TECH  — 

Netscrap top queries

01/09/2008  —  TECH  — 

Gofish, spilled...

01/09/2008  —  TECH  — 

Caffe Trieste in SOMA is the place

01/08/2008  —  TECH  — 

Vizu Survey on Netscrap.com

01/07/2008  —  TECH  — 

Netscrap's birthday

12/12/2007  —  TECH  — 

ruby, python, or php?

12/10/2007  —  TECH  — 

Zombie Technology

12/06/2007  —  TECH  — 

Hello World, From the phone

09/23/2007  —  TECH  — 

Long time no blog.

09/10/2007  —  TECH  — 

Is it the weekend?

04/25/2006  —  TECH  — 


04/24/2006  —  TECH  — 

Startup moments

04/02/2006  —  TECH  — 

Selenium: Neat!