Chris Eppstein

A year ago, if you had asked me whether our engineering team at Owner.com was truly adopting AI, not just dabbling, but actually integrating it into how we work, I would’ve said no. We had a few early adopters playing with tools. A few GitHub Copilot installs. Some LLMs used here and there. But nothing close to an org-wide shift. That’s all changed. And while we’re still evolving, I’ve seen what it takes to start moving the whole team forward. First: hire people who are curious. We’ve put deliberate effort into bringing on engineers who are open to trying new things, who see AI as an accelerant, not a threat to quality or process. It’s subtle, but it matters. You can’t force this mindset into a team. You build it from the start. Second: find your champions. Every org has a few folks who tinker in their off hours, who show up to standups with something cool they just built. Identify them. Support them. Make them visible. They’re your internal force multipliers. Then: show up yourself. I’ve made a point of using AI in my own day-to-day work. Whether it’s brainstorming in ChatGPT, automating routine writing tasks, or even building simple prototypes, when the team sees leadership leaning in, it shifts the culture. Boldness is contagious. We’ve also created real space for experimentation. Our internal AI hackathons have surfaced some of the most creative, practical tools we now use: automated code generation for straightforward tasks (more on this exciting stuff in a future post), auto-generated tests, and internal bots. Not all of them made it to production, but they created momentum. And that momentum changes everything. On measurement - we’re still figuring it out. Traditional metrics like velocity and story points fall short. We’ve started thinking about time saved, friction reduced, and AI-assisted workflows adopted, but I’d be lying if I said we’ve nailed it. It’s an active conversation, and we’re learning as we go. Throughout it all, we’ve kept our engineering guardrails. Code reviews still matter. Design quality still matters. AI is there to raise the ceiling, not lower the bar. This isn’t about chasing hype. It’s about giving your team better tools, faster feedback, and more creative freedom. The orgs that figure this out now are going to be miles ahead six months from now. There’s no playbook yet. But that’s the opportunity: you get to write your own. At Owner.com, we’re not waiting for someone else to figure it out. We’re leading from the front and taking the future into our own hands.

138

8 Comments

Have you been a victim of workslop 🪣? A recent HBR report on bad AI content at work really hit home for me. I've seen it everywhere and I know you have too. Workslop is that super polished-sounding content that looks impressive but says so little and lacks specifics in your work context that it offers no real value and even wastes time (HBR says AI slop is wasting $186 per employee per month). LLMs are incredibly impressive and are starting to make a dent on actual work (see OpenAI's latest research). But if companies rush to deploy any AI solution and don't think about training, metrics, or grounding it in their own work context, it's going to lead to wasted time and workslop. Why the rush? I've heard it firsthand in customer meetings: "We need AI or competitors will eat us alive." One report found 77% of CEOs feel competitive pressure to adopt it. So here are some my tips to get more out of AI deployments and reduce that workslop. 1. 📊 Your work context matters! Don't rely on a vanilla LLM or generic "enterprise chatbot."  It must be tuned to your work content, metrics, and data. Many chatbots only connect superficially to 3rd party content, or pull in personal files but not shared ones. So they aren't very effective. (Check out Dropbox Dash, we do this really, really well). 2. 🎯 Define your success criteria Know what you're solving. If you want fewer errors or faster delivery, measure that. Don’t just declare success because "AI is deployed." For software development, many companies see success when all devs are using an AI coding copilot. Or "generating code with AI". But for what purpose? Faster deployments, fewer bugs, improved feature velocity? That's what you need to measure. 3. 🛠️ Training and culture That blinking chatbot cursor is intimidating. In one survey, 49% of workers felt pressure to adopt AI, but 55% didn’t know how. The best deployments invest in training, shared playbooks, demos, and mentors. And don’t just do it once and think you are done. Ongoing measurement, monitoring, and training is needed. Also, look for AI tools that aren't just a chatbot. Products that blend seamlessly in the background. Not everything needs to be solved with a language model. 4. 🚀 High performers are going to highly perform and vice versa Ignore AI for a second. Top performers always seem to "figure it out" in the workplace. They learn the new tool and incorporate it into their workday. And so AI deployments are just new tools. It’s critical to watch and observe their output and use them as mentors (above). But others may simply take AI output and present it as their own. Workslop! And unless you guard against that (via reviews, performance management, feedback, and coaching), you're going to get more workslop. And that annoys and slows down everyone else. AI is nothing new here. Don't assume AI is some magic bullet and everyone's performance will rise. Don't just deploy it and forget it!

40

1 Comment

The Andrej Karpathy interview is really, really great, I listened in its entirety and plan to listen again. Worth bearing in mind that our industry in general is incredibly optimistic, and the downside of this optimism is that we often can see where things are going long before the tech will be ready, see: self-driving cars in the 2010s, we all thought it was Right Around The Corner, it wasn't. Currently, people are talking about how LLMs are going to obviate entire classes of jobs, but in practice we all see them fail at very basic tasks, while we also underestimate the complexities of most jobs we claim AI will obviate. My own experiences using LLMs for coding assistance, chess coaching, and musical analysis is that they are currently good for small, focused tasks, but often fail at very basic sorts of analysis in completely unintuitive ways. Just this morning, ChatGPT advised a move that would have immediately lost me a queen in a practice game. We've all probably spun our wheels for hours coding when an LLM is going in circles. The whole interview is fantastic and well worth a detailed listen!

31

1 Comment

Ok Rust, there is a lot I genuinely love about your language design, but can we all acknowledge having self and Self as keywords that mean different things was a horrible decision. I don’t care what the rationalization was - having a key semantic characteristic differ by freaking capitalization is absurd. We shouldn’t sound like philosophers when we write code - “we each have multiple selves, and they represent different meanings”. Anyway, CodeQL has Rust support now, so for all of the security minded devs there is finally a global interprocedural analysis engine at your disposal.

68

23 Comments

"Because engineers had been through brainstorming and story mapping, they were able to identify the most promising direction and find a way to implement one key piece of it pretty quickly." Want to get your engineers more involved in continuous discovery? Learn how Ellen Juhlin, Senior Director of Product Management at Orion Labs, successfully brought engineers into the discovery process. Key takeaways from Ellen's experience: 🎯 Start by inviting engineers to customer interviews as listeners and note-takers 💡 Include engineers in brainstorming and solution mapping sessions 🗺️ Use assumption mapping to help engineers focus on validating ideas 🔄 Don't worry about following a linear process - iteration is key 🎯 Begin with just one or two engineers rather than the whole team 🤝 Keep engineers connected to business outcomes Check out the comments for a link to the article. ❓ What's one small step you've taken to include engineers in discovery work? Share your thoughts in the comments below.

39

4 Comments