Podcasts about Jira

The legendary American Football coach, Vince Lombardi, said: “It's not whether you get knocked down, it's whether you get up."  Now that's true in American Football, and it's also true in life.  No matter how well you plan your day or your week, your plan will inevitably get attacked by outside influences.  A disorganised, reactive boss, a tired son or daughter who won't get out of bed in the morning, a traffic jam on the way to an important meeting, or your accountant telling you that you need to pay a big tax bill.  These are all sudden, impossible to plan for attacks on your carefully planned day.  Having a plan is one part of a productive day. Having an arsenal of tools to defend your plan is another. And it's that part that most people never prepare for.  In this week's episode, I will share with you a few ideas that will help you defend your plan and show you how to get back on track if you are prevented from following it through.  Let's go. Links: Email Me | Twitter | Facebook | Website | Linkedin   Learn more about the Quiet Productivity Method here Get Your Copy Of Your Time, Your Way: Time Well Managed, Life Well Lived Plan Your Week With Me: The Weekly Planning Matrix.   The Working With… Weekly Newsletter Carl Pullein Learning Centre Carl's YouTube Channel Carl Pullein Coaching Programmes Subscribe to my Substack  The Working With… Podcast Previous episodes page   Script |425 Hello, and welcome to episode 425 of the Your Time, Your Way Podcast. A podcast to answer all your questions about productivity, time management, self-development, and goal planning. My name is Carl Pullein, and I am your host of this show.  Whenever I ask a client how their week went, most answers are negative.  They usually go something like: “Well, it started well. I got everything I wanted done on Monday and Tuesday completed, but then I had to suddenly go out to see a customer on Wednesday morning, and that just threw me off track. I didn't get back to the office until 4ish, and then I had to report back to my boss. That went on until 6:00 pm. Argh! It was a disaster”  Well, was is a disaster?  Perhaps not. All it was was one day out of five that did not go as planned.  It's possible that a day like this will have put you behind on your plan for the week. It could also mean that getting everything you want done that week will no longer be possible. But that does not necessarily mean it's become a disaster.  The issue really is not preventing things from going wrong; that would be a challenge beyond almost everyone. Instead, the focus should be on recovering from an unexpected event or interruption to minimise the damage to your plan.  And in this week's episode, I will share a few ideas to help you quickly get back on track after one of these inevitable, unexpected events. But before I do that, I'd like to hand you over to the Mystery Podcast Voice for this week's question, but sadly, once again, she's sunning herself in a resort somewhere, so I'm afraid it's me reading out the question again.  This week's question comes from Will. Will asks, “ Hi Carl, I've finally become consistent with my weekly planning (thank you for the tip about doing it on a Saturday morning). My problem now is when I look at my plan at the end of the week, I've got practically none of it done. There's always some emergency that throws me off my plan. How do I get myself to stay on track?” Hi Will,  Thank you for your question.  Now, the first thing I would tell anyone is not to go for perfection. If you have ten things that you plan to get done over the next seven days but only manage to do seven, I would say that was a pretty good week.  You did seven important things that you wanted to do. That's a 70% success rate. I'd take that.  The reality is you are unlikely to ever hit 100%. I know I never have; in fact, I don't think I've ever met anyone who has.  There are just too many things that can happen that will throw you off track. Plus there's the human side of things too.  We often expect to be able to do far more than is possible, and then there's always a missing piece of information that you need to ask someone else for, and they are away all week at a conference and won't be able to send it to you until next week.  There could be a proposal you submit, anticipating approval, only to have it sent back to you for adjustments that will then require resubmitting.  None of these can be anticipated; building in some buffer time can help, but it's still not likely to give you a 100% success rate.  If you are hitting 100% consistently, that's likely to suggest that you are not pushing yourself hard enough to develop, but that's a whole different story.  One trick I often suggest to my coaching clients is to build in a “catch-up” afternoon, or, if you can, a “catch-up day”, later in the week where you avoid scheduling meetings or other commitments and keep it free for catching up on anything you may have fallen behind with. For example, I don't schedule anything on a Thursday afternoon. I often have meetings mid-morning (I think of it as a calls day), and one task: writing this script.  Other than that, there's nothing. This means that if I am behind on anything, I have a whole afternoon to catch up. (There's always something I will be behind on) This week, I am behind on a few videos I want to record. Should have got them done yesterday, but I ran out of time. So, this afternoon I will be recording.  Another tip is to look at your weekly plan not as a task-level plan, but as a set of objectives. In other words, plan for bigger things such as making progress on a project, getting four exercise sessions in, clearing a backlog or resolving an issue with a customer.  This is a reason why I developed the Weekly Planning Matrix. It's four squares representing four areas of your life:  Core work: the work you are employed to do. (Just as an aside here, if you're a part of my Learning Centre, last week's Learning Note has an excellent example of how Warren Buffett identified his core work) Projects and issues: these are the higher-level things you want to make progress on professionally. Personal: For things that need addressing in your personal life, such as scheduling a doctor's appointment, deciding how many exercise sessions you will do, etc.  And finally, the radar, which is for things you do not need to do anything about but should be aware of. For instance, if your in-laws are coming round for a few days later this month, or you're waiting for a package to be delivered.  Because you're limited for space in each square, you become mindful about trying to do too much. If your projects and issues square is full, and next to that you see all your core work tasks, you will instantly see if you are being over-optimistic about what you can get done that week.  I'll leave a link to a video I did on doing the Weekly Planning Matrix in the show notes for you. The next idea is related to your daily planning.  Because it is almost inevitable that an unexpected event will occur at some point during the week, your daily planning can be used to reassess your weekly plan.  Let me give you an example from my week this week. I planned to record some additional videos on Tuesday, but when I went to set things up, I discovered that the local government had decided Tuesday was a great day to dig up the road right outside my office. Jackhammers, reversing vehicle warning beeps, and road cleaners were all in full operation. It was an orchestra of wonderful modern city life noise That plan had to be scrapped. So, I looked at my calendar and saw that Thursday afternoon was clear (it always is, remember, for catch-up), so I moved the time block to Thursday afternoon.  Now, I did that calendar adjustment as soon as I realised I wasn't going to be able to record the videos, but I could easily have left it until later in the day, when I did my daily planning.  That's why your daily planning is so useful. It allows you some time each day to step back, reassess your plan for getting the important things done and make any alterations based on the new information you have.  And that brings me onto the timing of your daily planning.  Time and time again, when one of my clients switches over to planning their day the evening before, they tell me that it was life-changing.  It's life-changing because you will immediately discover your evenings are more relaxing. Once you've planned the day, your brain lets go of all the stuff you're feeling a little anxious about. It quietens down.  You also find you sleep better because you know what you will be doing the next day and that all your “bases” are covered, so to speak. No more “oh Crikey. I forgot to do X” just as you're drifting off to sleep.  And when you begin your day, you're already clear about what needs to be done. That gives you a tremendous amount of focus and prevents you from going looking for trouble by looking at your actionable email, sifting through Slack or Teams messages or going into Jira looking for open tickets.  Now, I know all that's well and good, but what happens if one of these legendary Unexpected Events happens when you're in the middle of doing your most important work for the day?  This is the proverbial Vince Lombardi's “getting knocked down” situation. And as Vince Lombardi says, it's all about getting back up again once you've been knocked down.  The only thing I've found that works here is that once you've dealt with the Unexpected Event, pause. Yes, that's right. Stop.  Just briefly. Look at your calendar and see when your next committed appointment is, and take a look at your prioritised task list and see what's left to do. Often you will find that now that you no longer have the time you thought you would have, some of the remaining tasks can be rescheduled to another day.  You may need to send a quick message to someone who is expecting something from you, but what you want to be doing is resetting your priorities based on the time you have left.  For those of you who wisely set aside time to deal with your actionable emails and messages, you could reduce the time you spend there. For instance, if you have an hour protected for admin and communications later in the day, cut it to 30 minutes.  Remember, with things like messages and emails, one is always greater than zero. Giving yourself thirty minutes today means you're not going to have to find an extra hour tomorrow. What was that old proverb, “a stitch in time saves nine”? Something like that.  I would add an extra tip here. Something I've found very helpful. That is to reassess your prioritised task list between each session of work.  Emails and messages, for example, can be devastating to even the best-laid plans. Given that most of us check our messages between sessions of work anyway, there's always the danger that you'll find an Unexpected Event” that requires thirty minutes or so of your time.  So, give yourself a few minutes away from your desk and mentally re-evaluate your plan for the day. Be comfortable switching things around. For example, if you have to attend an unplanned meeting after lunch, you may find that moving your communication and admin time forward will reduce any pressure you may feel after the meeting.  So there you go, Will. I hope that has helped. Thank you for your question and thank you to you too for listening.  It just remains for me now to wish you all a very, very productive week.   

It's time to celebrate the people who keep Jira running and teams moving forward: Jira Admins!Join us for this special Jira Admin Day episode of The Jira Life as we bring together a panel of experienced Jira Admins from across the Atlassian community to share their stories, lessons learned, favorite tips, biggest challenges, and the moments that made them love, and sometimes question, the role.Whether you're a seasoned administrator, new to Jira, or work alongside Jira Admins every day, this conversation is packed with real world experiences, practical insights, and plenty of community spirit.Bring your questions, share your own experiences in the live chat, and help us recognize the incredible work Jira Admins do every day. This episode is all about learning from one another, celebrating the community that keeps teams successful, and having fun along the way.The Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!⁠https://ace.atlassian.com/the-jira-life/⁠Or Follow us on LinkedIn! / the-jira-life Become a member on YouTube to get access to perks:⁠   / @thejiralife  ⁠.Hosts:Alex "Dr. Jira" Ortiz / alexortiz89 / @apetechtechtutorials Rodney "The Jira Guy" Nissen / rgnissen ⁠https://thejiraguy.com⁠Sarah Wright / satwright Producer:"King Bob" Robert Wen / robert-wen-csm-spc6-a552051 Executive Producer: Lina OrtizMusic provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codes / monstercat Outro: Fractal - Atrium / monstercatinstinct

In this episode of The Product Podcast by Product School, Carlos González de Villaumbrosia sits down with Saral Jain, SVP of Engineering at Snapchat, the last independent social platform operating at global scale, with 956 million monthly active users closing in on the one billion mark and a community that opens the app more than 30 times a day. Saral joined Snap nine years ago, right around the IPO, after nearly a decade leading engineering teams at Amazon Web Services, and today leads all engineering for Snapchat, spanning product experiences, multi-cloud infrastructure, and the company's machine learning and generative AI platforms.What you'll learn:How Snap lets designers and product managers ship production code, with an AI agent running the first review pass on 90% of code within 5 minutesWhat Casper is: the AI teammate any team at Snap can invoke from Slack or Jira to build a working prototype from a conversationHow Snap turned company-wide AI adoption into business impact after early prototypes were being built and thrown awayHow lean startup squads mix engineers, designers, and data scientists to launch zero-to-one bets inside a mature platformKey takeaways:Quality control does not have to slow down who gets to ship, it has to change what reviews the work firstWidespread AI adoption is not the same as business impact, and the gap between the two is where most AI investment is being wasted right nowSmall, cross-functional teams with blurred roles can move faster than traditional org structures, even inside a billion-user companyCredits:Host: Carlos Gonzalez de VillaumbrosiaGuest: Saral JainSocial Links:Find out more about Product School hereFollow our Podcast on TikTok hereFollow Product School on LinkedIn here

AI is changing the way we work, but it's also changing the way we think, communicate, learn, and create.In this episode, we move beyond the usual conversations about productivity and automation to explore a bigger question: What does it mean to stay human in the age of AI?We discuss how AI is reshaping the workplace, creativity, decision making, and human connection. As AI becomes more capable, how do we ensure that curiosity, empathy, critical thinking, and authentic collaboration remain at the center of what we do?We also explore some fascinating economic questions. What happens when AI becomes expensive to run because of token costs? Could there be situations where human expertise becomes more cost effective than AI? And what does the future look like if experienced developers become scarcer than demand?Whether you're a developer, founder, creator, or simply curious about where technology is taking us, this conversation is an invitation to think beyond the tools and focus on the people using them.In this episode:How AI is changing the way we think and solve problemsThe future of human work alongside AICreativity, communication, and learning in an AI first worldWhy being "more human" may become our greatest advantageThe surprising economics of AI, token costs, and human expertise

Aliu Adewale: The Over-Communicator vs. The Over-Ambitious—Two Patterns Every Scrum Master Should Recognize Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Over-Communicator Who Negotiated Every Scope Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "This is a guy who over-communicates everything." - Aliu Adewale   The best Product Owner Aliu ever worked with did something simple that almost no PO does. Before each refinement, he'd pull up the Jira board, record himself walking through every user story, explaining acceptance criteria, talking through the end goal one ticket at a time—and post the video to the team a day or two ahead. This was before Loom existed. The result: refinement felt less like discovery and more like "walking it back"—the team arrived already prepared, with real questions, ready to engage. He still attended every refinement and never missed a comment in Jira. But the second skill Aliu names matters even more: negotiation. This PO never let scope creep into a sprint mid-stride without consulting the team first. "If we add these two requests from leadership, what's the impact? Do we need to take something out?" And if the team said no, he didn't force it. He went back to leadership and named the consequence: "If we add this, here's what happens. Are you okay with that?" Over-communication and negotiation—two skills that protect the team and the product at the same time.   Self-reflection Question: When was the last time your PO asked the team's permission before adding work mid-sprint? The Bad Product Owner: The Over-Ambitious PO Who Never Said No Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Every yes to something unimportant is a no to what matters." - Aliu Adewale   The Product Owner Aliu names as the anti-pattern is the over-ambitious PO—the one who never says no. Never to stakeholders, never to the business, never to a new feature request. He never considered the size of the team or the capacity of the team. He was blind to it. Underneath the behavior, Aliu sees a pattern: POs who want to keep their job by saying yes, stakeholders who keep asking because they think they have to, and a team on probation that doesn't feel safe pushing back. The damage compounds—more features delivered, less value per feature, and eventually the team itself starts to break. Aliu's framing is sharp: "More features don't equal more value. Sometimes more is just less." The job of the Scrum Master here is to coach the PO on when to say no, when to say yes, and how to recognize that on the phone in front of you right now, 90% of the features in that app you're staring at—you never use them. Built. Shipped. Ignored.   In this segment, we refer to Product Owner anti-patterns and the courage required to challenge stakeholder demands.   Self-reflection Question: Is your PO measuring success by features shipped, or by features used?   [The Scrum Master Toolbox Podcast Recommends]

AI is not just changing how engineers write code. It is changing who gets close enough to shape the work.In this episode of The Tech Trek, Robert Stewart, CTO at Arbital Health, joins Amir to talk about how AI is bringing actuarial subject matter experts closer to product and engineering teams, especially in healthcare and risk based contracts. Robert shares how his team is pairing technically minded SMEs with software engineers, using AI tools in development, and rethinking technical hiring now that AI assisted coding is part of the job.Practical Takeaways• AI can reduce the distance between domain experts and engineering when the SMEs can clearly describe requirements, acceptance criteria, and edge cases.• Pairing a subject matter expert with an experienced engineer can be more powerful than traditional pair programming because each person brings a different kind of judgment.• Better written requirements matter more in an AI assisted workflow because tools can work directly from detailed tickets and context.• Technical interviews may need to test how candidates use AI, not whether they can avoid it.• Hiring teams need stronger signals around identity, environment fit, prompting skill, and how candidates respond to AI output.Timestamped Highlights00:00 Robert Stewart on Arbital Health, value based care, and the role of actuarial expertise in healthcare infrastructure.03:06 Why actuarial knowledge is hard to transfer into engineering teams through normal handoffs.04:40 How AI helps subject matter experts move closer to product and engineering work.06:08 Why engineering fundamentals still matter, even when AI makes code easier to create.09:55 How Arbital Health is using Cursor, Claude Code, and human review in a regulated environment.14:52 Why more detailed Jira tickets are becoming more valuable in AI assisted development.17:10 How AI is changing technical interviews from “you may use AI” to “you must use AI.”22:16 What suspicious candidates, remote interviews, and fake profiles are forcing hiring teams to rethink.One Line That Stuck“You can judge an expert by the type of questions they ask.”Pro Tips• Ask candidates to share their screen during AI assisted technical interviews.• Watch how they prompt, not just what they produce.• Look for whether they catch strange or weak AI output.• Use a rubric, but also evaluate whether the candidate fits the way your team actually works.• For AI generated code, add stronger human review, especially in regulated environments.Subscribe to The Tech Trek for more conversations on how technical teams are adapting around AI, data, product, platform, hiring, and engineering execution.

If Your ScrumMaster Only Runs Meetings... You're Wasting Your Best LeaderAsk ten people what a ScrumMaster does, and you're likely to hear ten different answers."They run the Daily Stand-up.""They schedule Sprint Planning.""They update Jira.""They remove impediments.""They're the Agile coach.""They're the team's project manager."Some of those answers are partially correct.Most of them are incomplete.And that's becoming one of the biggest challenges facing Agile organizations today.Somewhere along the way, many companies unintentionally shrank one of the most influential leadership roles on an Agile team into something much smaller.A meeting facilitator.A calendar manager.A process referee.Someone who reminds everyone when the Sprint Review starts.That's not what the ScrumMaster role was designed to be.In fact, if that's all your ScrumMaster is doing...You're probably missing the greatest opportunity that role has to offer.Let's imagine two ScrumMasters.The first arrives every morning with a checklist.Start the Daily Scrum.Update the board.Send reminders.Schedule Retrospectives.Close completed stories.Generate reports.Stay organized.Nothing wrong with those activities.They're important.But now let's look at a second ScrumMaster.This person notices that two team members have stopped collaborating.They coach a Product Owner struggling to prioritize competing stakeholder requests.They help leadership understand why multitasking is slowing delivery.They facilitate a difficult conversation before it becomes a lasting conflict.They identify organizational policies that create unnecessary delays.They mentor new leaders.They build trust across departments.They help people solve problems they didn't even realize existed.Which ScrumMaster creates greater long-term value?The answer seems obvious.Yet many organizations still spend far more time measuring the first set of activities than the second.Why?Because administration is visible.Leadership often isn't.You can see a meeting on a calendar.You can't always see trust being built.You can count completed ceremonies.It's much harder to measure improved communication.You can track whether a Retrospective happened.It's much more difficult to quantify whether people actually feel safe speaking honestly during it.That's the challenge.The most valuable work ScrumMasters perform often happens between the ceremonies.Not during them.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

Aliu Adewale: The Counterintuitive Fix—How Collapsing the Jira Board Sparked Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Collaboration is the foundation of a successful Scrum team." - Aliu Adewale   Aliu walked into a team where the daily standup was theater. Developers delivered their tickets and forgot about them. QA picked up "their" column. Front-end, back-end, senior architect, junior developer—everyone was a champion of their own silo. Nobody engaged during refinement. Nobody called anything out. The board had close to ten columns, one per specialty, and it was working exactly as designed: as a handoff system. Aliu's diagnosis is sharp—the foundation of the team's problem wasn't the people; it was the tool. The Jira board was visualizing silos and the team was living up to it. The fix was counterintuitive: he collapsed the board from nine columns to three—To Do, In Progress, Done. Once "In Progress" was the only place where work lived, nobody could hide. A QA needing to know when a ticket would be ready had to talk to the developer. A stakeholder asking for status meant everyone on the ticket had to communicate. The team had no choice but to collaborate. As Vasco frames it in the episode: by creating the smaller problem of "hiding status," Aliu solved the bigger problem of "no collaboration." Sometimes you have to make things a little worse so they can get much better.   In this segment, we refer to the Agile value individuals and interactions over processes and tools, and to the recognition that the tools we choose shape the behaviors we get.   Self-reflection Question: Is your Jira board designed to enable collaboration, or to enable handoffs? Featured Book of the Week: Surrounded by Idiots by Thomas Erikson For Aliu, the book that most inspired him as a Scrum Master is Surrounded by Idiots by Thomas Erikson—a book he discovered through a recommendation on this very podcast. The provocative title pulled him in; the content gave him something he could use every day. As a Scrum Master, you work with people from different backgrounds, different communication styles, different ways of seeing the world. The book maps four personality patterns and, as Aliu puts it, "it might not be a hundred over a hundred, but at least ninety over a hundred about personality and human relation." For someone already working on his emotional intelligence, it became a tool for understanding why a message that landed clearly with one team member completely missed another—and what to do about it.   [The Scrum Master Toolbox Podcast Recommends]

What gives one enterprise an AI advantage over another? According to Atlassian Chief Product & AI Officer Tamar Yehoshua, it’s not simply access to the latest models, it’s the depth of enterprise context. In this episode of Technovation, Tamar joins Peter High to discuss how Atlassian is leveraging decades of workflow history through its Teamwork Graph to power AI across Jira, Confluence, and Rovo. She explains why enterprise context is becoming the defining ingredient for AI success, how software must now be designed for both humans and AI agents, and why leadership judgment becomes even more valuable as AI accelerates software development. Tamar also shares Atlassian’s approach to AI Builder Weeks, measuring AI productivity, building open agent ecosystems, and helping customers realize measurable business value from AI investments. This episode is presented by Mailtrap — Modern Email Delivery for developer & product teams. Learn more at mailtrap.io

What if your Trello boards could do the work for you?Join us for our special Trellopendence event where we explore how automation can transform the way teams manage projects, tasks, and workflows. We'll discuss how to think about automation before building it, share some of the most valuable Trello automations every user should consider, and demonstrate how Trello works alongside powerful tools like Claude, Zite, PixieBrix, and more.We'll also take a look at some of the latest Trello updates and discuss practical ways to streamline your work without adding complexity.Thank you to ikuTeam for connecting and collaborating with The Jira Life. ⁠https://ikuteam.com⁠The Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!⁠https://ace.atlassian.com/the-jira-life/⁠Or Follow us on LinkedIn! / the-jira-life Become a member on YouTube to get access to perks:⁠https://www.youtube.com/@thejiralife/..⁠.Hosts:Alex "Dr. Jira" Ortiz / alexortiz89 / @apetechtechtutorials Rodney "The Jira Guy" Nissen / rgnissen ⁠https://thejiraguy.com⁠Sarah Wright / satwright Producer:"King Bob" Robert Wen / robert-wen-csm-spc6-a552051 Executive Producer: Lina OrtizMusic provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codes / monstercat Outro: Fractal - Atrium / monstercatinstinct

#357: Type a prompt, get code, fix the hallucinations, type another prompt. That is vibe coding, and it is a fine place to start. It is a terrible place to stay. So what comes next - and is spec-driven development actually it, or just waterfall wearing a new hat? Here is the reframe that runs the whole conversation: everybody already works from a spec. Even the person who swears they are winging it has a spec in their head - which language, where it runs, what it does. The real question was never specs or no specs. It is whether you write them like waterfall, one giant document before anyone touches code, or like agile, just enough to start and the rest discovered as you go. A design is only validated when you implement it - everything before that is an educated guess. So instead of spending a month on one detailed design, build five throwaway MVPs in a day. Fully operational. Frontend, backend, running in a cluster, connected to a database. Show them to customers. Pick the one that works. Then have the agent write the spec from the winning code, and throw the code away. The spec is the output, not the input. A PowerPoint took you a month and told the customer nothing. A working thing they can touch tells you everything. Viktor and Darin push on where this breaks. Over-specifying gives you a false sense of security - you are lying to yourself that you know everything up front, and you do not. Legacy systems? The code is the only complete spec - any document written thirty years ago is fiction. Performance? Measure it in production and be lightning-fast to react. Greenfield, CRUD, clear API contracts - those genuinely want a spec first. The part nobody on the org chart wants to hear: this does not delete the business analyst or the developer. It collapses the roles. The code monkey who pulls a Jira ticket, does the work, pushes it - that job is turning into tech lead, architect, product manager, all at once. Plan mode writes the spec with you, not for you. You write it to a file because you cannot review what you cannot see. And you review the tests harder than the code, because the tests are the spec made executable. Specs were always supposed to be living documents. Now there is finally no excuse.   YouTube channel: https://youtube.com/devopsparadox   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Most API testing stops at the happy path. The problem is that the bugs that actually hurt you in production are sitting in everything many testers skip, like the boundary values, the oversized payloads, the missing tokens, the security headers, the inputs that make no sense at all. In this episode, Joe sits down with Liudas Jankauskas, who has spent almost twenty years breaking software and testing APIs since 2008. Liudas demonstrates Rentgen, his free and open-source API testing tool, live on screen. You'll watch him take a single request from a real app, map it in seconds, and generate dozens of tests covering security, boundaries, performance, and load—all from one click. You'll learn: How to discover APIs hiding under the hood of any application, even when there is zero documentation Why happy path testing leaves you exposed How to run a fast hygiene check before your real automation ever starts Liudas also explains why Rentgen runs completely locally with no server and no data leaving your machine, making it safe for banking, healthcare, and other regulated environments. Plus, he demonstrates the killer Copy Bug Report feature that drops a standards-based ticket straight into Jira or Trello. In This Episode You'll Discover How to find and test undocumented internal APIs using the browser DevTools Network tab Why happy path-only testing misses the bugs that matter most How Rentgen turns one request into security, boundary, performance, and load tests automatically Where Rentgen fits in your workflow as a pre-automation hygiene layer—not a Postman replacement How to use it for regression by comparing results across environments The one piece of advice Liudas gives every tester to level up their API testing Try Rentgen, free and open source, at Rentgen.io. Connect with Liudas Jankauskas on LinkedIn: https://www.linkedin.com/in/liudas-jankauskas/

Level up your leadership: https://forms.gle/nqRTUvgFrtdYuCbr6 What if the secret to leveraging AI in game development isn't about just writing code faster, but getting your team to be more rigorous before a single line is even written? In this episode of Building Better Games, Ben talks with Landon (CTO) and Jean-Eric (Product Lead/Producer/Tech Artist) from Believer. Together, they pull back the curtain on how agentic coding tools and custom internal bridges like Claireon didn't just accelerate their systems development from months to a single week—they completely flipped their production pipeline on its head. They dive deep into why AI forces game dev teams back into a structured setup at the start, how it alters the role of engineering leaders, and why the ultimate bottleneck has officially shifted back to human creativity and polish. What You'll Learn in This Episode: What shifted when a veteran studio integrated agentic coding directly into the Unreal Engine editor, reducing a three-to-six-month development cycle to one week Why relying on AI to "one-shot" solutions fails, and why true velocity requires human experts to break down tasks into strict decision-making frameworks How to build customized, dynamic production dashboards that match your personal mental model rather than getting bottlenecked by the default constraints of Jira and tools like it Why the traditional middle-of-the-pipe engineering grind is disappearing, forcing studio leaders to double down on upfront alignment and end-of-pipe playtest validation If you're a leader in game dev who is skeptical of the generative AI hype but drowning in backlog management and long engineering cycles, this episode is for you. Learn more about our guests:

What if the biggest barrier to successful AI isn't the model itself, but the lack of context behind every decision your teams make? As AI agents become more capable, how do organisations ensure they understand the people, projects, documentation, and history that shape real work? In this episode of Tech Talks Daily, recorded at Team '26, I'm joined by Taroon Mandhana, CTO of AI and Teamwork at Atlassian. His responsibilities span engineering for products including Jira, Confluence, Loom, and Trello, alongside the company's AI strategy and the development of Rovo. Our conversation explores why Atlassian believes AI should become a teammate rather than simply another chatbot. Taroon explains why enterprise context has become one of the most valuable assets in the AI era. While today's foundation models continue to improve at an incredible pace, they still lack the organisational knowledge that human teams naturally accumulate over time. Atlassian's Teamwork Graph aims to bridge that gap by connecting people, projects, documentation, code, goals, and conversations into a living knowledge network that AI agents can use to produce more accurate, relevant outcomes. We also discuss why Atlassian has chosen an open approach, making its Teamwork Graph available through technologies such as MCP rather than limiting it to its own AI products. Taroon shares why interoperability will become increasingly important as businesses adopt multiple AI platforms and why organisations should be free to use the agents that best suit their needs without losing access to valuable business context. Another fascinating part of our conversation focuses on how Atlassian's own engineering teams are changing the way they build software. Smaller teams, tighter collaboration, AI-assisted development, and faster iteration cycles are allowing products to move from concept to release in weeks rather than months. Taroon explains how AI is changing both software development and the structure of engineering teams themselves. We also examine where AI should take ownership of work inside platforms like Jira, where human judgement remains essential, and why successful organisations are treating AI adoption as an ongoing product journey rather than a one-time technology deployment. If your business is looking beyond isolated AI experiments and wondering how to build AI into everyday work, this conversation offers valuable insight into the role context, openness, and organisational change will play in the next generation of enterprise software. As AI becomes part of every workflow, what do you think will become the real competitive advantage: better models, or better organisational knowledge?

Fala, jovens.Você consegue dizer como cada pessoa do seu time está de verdade?Não estou falando de entrega, Jira, bolinha verde ou câmera ligada. Estou falando da pessoa por trás da tela.Neste episódio, a Tatiane fala sobre liderança híbrida e o desafio de perceber se o time está bem quando ninguém está no mesmo lugar. A conversa passa por presença online, confiança, comunicação remota, 1:1 que virou reunião de status e o risco de transformar cuidado em vigilância.Porque liderar à distância não é controlar cada minuto. É criar combinados claros, abrir espaço para pedir ajuda e construir um ambiente onde as pessoas possam falar antes de chegar ao limite.Presença não tem a ver com estar online. Tem a ver com estar acessível.Seguem os links das minhas outras redes sociais:Instagram - ⁠https://www.instagram.com/brunobribeiro/⁠TikTok - ⁠https://www.tiktok.com/@brunoribeiro.oficial⁠Facebook - www.facebook.com/brunobr.oficialYoutube - www.youtube.com/brunobribeiroLinkedin - ⁠https://www.linkedin.com/in/brunobribeiro⁠Blog - www.brunobr.com.brDá o play e reflete com a gente. Nos vemos no próximo Spoilers da Vida.

Olaitan Fashanu: The PO Who Doesn't Care vs the PO Who Always Has the Answer Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   In this episode, we refer to a recurring theme in past podcast episodes—the proxy product owner who can't make decisions because they're not theirs to make. The Great Product Owner: Always Available, Always Decisive, Always Has the Context Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "There was nothing you tell, any questions you have about a particular feature that this guy doesn't have an answer to. And that really moved the team so fast." - Olaitan Fashanu   The best PO Olaitan ever worked with was the mirror opposite of every anti-pattern he'd seen. Deeply involved in refinement. Took backlog management seriously. Always brought the context. Always available to the team. And—maybe most importantly—always ready to make a decision when devs surfaced trade-offs. The team could ask any question about any feature, and the answer was right there. Not "let me check," not "I'll get back to you," not "what do you think?"—a decision. That single quality, Olaitan says, was what moved the team faster than anything else. As a Scrum Master, when you see a great PO at work, you also see the amplifying waves of impact: motivation rises, quality rises, ownership grows. Olaitan's takeaway is sharp: the success of our job depends on how well the product owner does theirs.   Self-reflection Question: When was the last time your PO made a real-time decision that unblocked the team in a single conversation—and what's preventing that from being the norm? The Bad Product Owner: Doesn't Care About Impact, Can't Make Decisions Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The product owner cares about delivery. We just need to release to the customer. That is something I don't like." - Olaitan Fashanu   Olaitan describes two anti-patterns wrapped into one bad-PO type. The first: the PO who doesn't care about the impact of their work on the team. Tickets dropped without context. No refinement. No problem framing. Just "ship by end of month." The data shows up in Jira if you're paying attention—patterns of churn, quality issues, customer complaints, slow market response. Beyond the numbers, the team loses motivation, frustration creeps in, and eventually you lose the team entirely. The second anti-pattern, layered on top: the PO who can't make decisions. Developers come back with two options and the trade-offs—and the PO can't pick one. Vasco connects it to the proxy PO pattern explored in past episodes—a PO whose decisions aren't actually theirs to make. The cost is the same either way: the team stalls, ownership erodes, and stakeholder conflict grows.   In this segment, we refer to the proxy PO anti-pattern explored in earlier episodes of the podcast.   Self-reflection Question: Is your PO unable to decide—or unable to be allowed to decide? The difference changes which conversation you need to have, and with whom.   [The Scrum Master Toolbox Podcast Recommends]

Most engineering teams are still optimizing for the wrong thing. They chase the speed of code when the real bottleneck is the speed of context. Matt Watson and Eban Bisong, founder and CEO of Senvi, get into what actually changes when AI moves from a coding tool to a teammate.Eban has spent his career as a founding engineer, and his approach is hands-on: don't tell skeptical engineers AI works, show them, every standup, until the pushback turns into excitement. At Park DNA he built "RTD2," an OpenClaw-powered droid wired read-only into their data sources, Slack, and Jira. It answered support questions before an engineer could, created its own bug tickets, and joined meetings through Fireflies so nothing got lost. The lesson underneath all of it: record everything, because the team that captures the most context ships the right thing fastest.Matt also shares his own three-week rabbit hole with Claude Cowork, $8K in tokens, a fully rebuilt Full Scale website, a thousand dead blog posts deleted, and 200 more rewritten. They go a few rounds on why it's a bad time to be a coder but a great time to be a builder, why "good enough" is a real standard and not a cop-out, and why ownership beats asking permission every time.If you build software or lead an engineering team, listen now. And if you want to try Eban's voice-first AI journal, visit senvi.ai.⏱️ Episode Breakdown00:42 From Founding Engineer to Solo Founder01:52 Using AI as an Engineering Leader03:24 Building RTD2: An AI Teammate for Support05:27 The Speed of Context, Not Code06:11 Why You Should Record Everything08:59 Winning Over AI-Skeptical Engineers11:50 The AI Spectrum Across 80 Clients13:35 A Bad Time to Be a Coder, a Great Time to Build14:03 Why "Good Enough" Is Good Enough14:52 Human-in-the-Loop and Reviewing AI's Work16:28 Going All-In on Senvi19:01 Validating the Product With a Beta Group21:01 Bootstrapping a Truly AI-Native CompanyLinks & ResourcesConnect with Eban Bisong on LinkedInSenvi.ai - senvi.aiWhat Smart CTOs Are Doing Differently With Offshore Teams in 2025Subscribe to the Global Talent SprintFull Scale – Build your dev team quickly and affordablyIf you're trying to get your team out of the basement and into real product ownership, this episode is your playbook. Stop being a ticket factory. Build teams that think, create, and lead.Follow the show, rate it, and send this to someone who's still trying to do “real Scrum.” They need it more than you do.

The Atlassian ecosystem is changing faster than ever, and navigating where the platform is headed can be tough for users and enterprises alike. In this episode, we sit down with ecosystem veteran Larry Brock to unpack the massive shifts happening right now inside the Atlassian community and product lineup.We dive deep into the merger of Atlassian Community and University, the rise of the Content Creator Champion, and what the role of a "Regional Director" actually means. Plus, Larry gives us the inside scoop on the legendary #findLarry story and breaks down what the Community Advisory Board (CAB) is working on.But it's not all community talk—we tackle the hard-hitting product questions every enterprise leader is asking: Is Data Center reaching its End of Life (EOL)? What does the end of the Confluence "legacy editor" mean for your teams? And where exactly is Atlassian going next?Whether you are a Jira admin, a project manager, or an enterprise leader trying to get a return on your software investment, this episode is packed with insider knowledge you won't get anywhere else.Thank you to ikuTeam for connecting and collaborating with The Jira Life. https://ikuteam.comThe Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!https://ace.atlassian.com/the-jira-life/Or Follow us on LinkedIn! / the-jira-life Become a member on YouTube to get access to perks:https://www.youtube.com/@thejiralife/...Hosts:Alex "Dr. Jira" Ortiz / alexortiz89 / @apetechtechtutorials Rodney "The Jira Guy" Nissen / rgnissen https://thejiraguy.comSarah Wright / satwright Producer:"King Bob" Robert Wen / robert-wen-csm-spc6-a552051 Executive Producer: Lina OrtizMusic provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codes / monstercat Outro: Fractal - Atrium / monstercatinstinct

Platform work doesn't look like a typical “one product, one user journey” world, and in this episode, we dig into what that really means with platform Product Leader Ashana Singhania. With a decade of experience across financial services at American Express and Goldman Sachs, Ashana has worked on both consumer-facing experiences and the complex platform layers that power them.She walks Matt and Moshe through how platform products differ from traditional products: instead of a single user flow, platforms support multiple product lines, regions, risk profiles, and entry points, all sitting on shared infrastructure like identity, decisioning, and risk data. That reality changes everything about how a PM does strategy, prioritization, communication, and stakeholder management.Join Matt and Moshe as they explore with Ashana:What “platform” really means in practice, and how horizontal capabilities underpin vertical consumer productsHow platform PMs think differently about impact when results show up indirectly through many dependent productsWhy tools like Productboard, and Jira need to be used differently for messy, non‑linear platform workTechniques for breaking down use cases, mapping the full scope, and prioritizing across multiple product lines and geographiesThe critical role of documentation, especially around variations, so teams don't assume behavior is the same everywhereGovernance and failure modes:Over‑standardization that harms UXToo much flexibility that creates chaosHow to design a strong core plus controlled adaptationPartnering early with compliance, risk, ops, and legal in financial services so platform changes don't get blocked lateHow AI is (and isn't) used today in financial platforms, from fraud detection and behavior insights to reducing manual work, and where trust and regulation slow things downAshana's approach to defining a platform vision, living roadmaps, and reserving capacity for platform evolutionA sneak peek at her new venture on income‑based affordability assessment in real estate and beyondAnd much more!Want to connect with Ashana?LinkedIn: https://www.linkedin.com/in/ashanasinghania You can also connect with us and find more episodes:Product for Product Podcast: http://linkedin.com/company/product-for-product-podcastMatt Green: https://www.linkedin.com/in/mattgreenproduct/Moshe Mikanovsky: http://www.linkedin.com/in/mikanovskyNote: Any views mentioned in the podcast are the sole views of our hosts and guests, and do not represent the products mentioned in any way.Please leave us a review and feedback ⭐️⭐️⭐️⭐️⭐️

Six months into her first management job, Anu Bharadwaj got the feedback no leader wants to hear: she was too intense, she pushed her team too hard. She was stunned. She was only asking them to do what she would do herself.Anu Bharadwaj began at Microsoft building video games, then made a bold leap to Atlassian in 2014, where she rose from product lead on Jira to COO and then President. Along the way she shaped Team Anywhere, led one of the company's hardest cloud transformations, and kept returning to a single question: how do teams actually work better together?I came to this conversation as someone who made the same early mistake she did. In my first years at Microsoft I was known as Mr Plus, always asking for more, always raising the bar, until coaching taught me the difference between driving people and leading them. Anu and I share a Microsoft DNA, and most of this episode felt like comparing notes.In our conversation, we explore: → Why leading people is never about you, and the manager feedback that taught her the hard way → How a values exercise she runs with every team becomes the real source of psychological safety → Energy management over time management, and why self-care is not selfish → Why an AI rollout fails when leaders treat it as a tools problem instead of a human fear → What an AI-native company actually looks like, and why judgment stays human"When you lead people, it is not about you. It is about them. You want to understand what they want, and take them to a place they want to go." Anu Bharadwaj, former President of AtlassianIf you have ever pushed a team toward your finish line and wondered why they were not following, this conversation will stay with you.RELATED EPISODESPete Carroll, Seattle Seahawks head coach (2021), Learning to "always compete": https://www.buzzsprout.com/1798971/episodes/9268299Kathleen Hogan, Microsoft Chief People Officer (2022), Empowering people to achieve more: https://www.buzzsprout.com/1798971/episodes/10382268 Ranjay Gulati (2023), Creating purpose-driven teams: https://www.buzzsprout.com/1798971/episodes/12903145New here? Subscribe to Positive Leadership & You for one edition a month, written for leaders who want to build companies and communities people thrive in. https://www.linkedin.com/newsletters/positive-leadership-you-6970390170017669121/Want to go deeper? Listen to the Positive Leadership Podcast on your favourite platform. 130+ conversations with the leaders, founders and thinkers shaping a more human future of work.

Olaitan Fashanu: When the New PO Stops Refining—and the Team Starts Self-Destructing Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If we're actually doing the job of refining this ticket properly, then we will not be creating this tension in the team." - Olaitan Fashanu   The team was working well. They had a strong PO who came to refinement with the problem clearly framed: this is what we want to solve, here's the context, here's the user story, here are the acceptance criteria. The team picked it up, refined it, ran with it. Then change came. A new PO joined—and the routine collapsed. The new PO cared about one thing: hitting the delivery date. Tickets dropped into Jira with no context, no problem statement, no acceptance criteria. Just "this needs to ship by end of month." Within weeks, Olaitan saw the symptoms cascade through the team. Developers asked designers what tickets even meant. QA struggled to maintain quality. Tension built. The diagnosis was clear: refinement had broken. His fix? Bring back the Definition of Ready as a non-negotiable shared standard, and introduce a product trio—business viability, technical feasibility, and design usability collaborating on every story before it reaches the rest of the team.   In this segment, we talk about the Definition of Ready and the product trio collaboration model.   Self-reflection Question: What's the symptom you're seeing in your team right now—and could the real source be how stories are getting refined, not how they're getting built? Featured Book of the Week: The Secrets of Facilitation by Michael Wilkinson Olaitan calls out The Secrets of Facilitation by Michael Wilkinson as the book that shaped how he handles difficult moments. The book teaches the power of asking the right question at the right time—clarifying questions, probing questions, the questions that drive a stuck group forward. "You will understand how, when to ask clarifying questions, ask really powerful questions that will help you drive or probably help you reach your goal in any session you find yourself." For Olaitan, the biggest payoff was learning to manage group dynamics in real time—what to do when something said in a meeting lands badly, when a comment threatens to derail the room. As a Scrum Master, you live in those moments. This book hands you a toolkit for them.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: The Scrum Master Who Tried to Force His Way In—and Got Schooled Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When you want to make things work, you need to find a way to carry people along. Lead, not by forcing your way on the team, because you're working with smart people, you're working with professionals." - Olaitan Fashanu   When Olaitan transitioned from project management into the Scrum Master role, he carried his old habits with him: enforce, push, drive. Then he walked into a team of senior developers. In one retrospective, a team member casually suggested that someone could help set up Jira properly. Olaitan took it personally—wasn't that his job? The next day in the daily standup, he called it out publicly. The reaction told him everything. The team member shut down. The PO pulled him aside afterward to say, "We could have had a better discussion around this." That moment, Olaitan realized that having no formal authority isn't a weakness to compensate for with force—it's the whole point. The job is to influence, to nudge, to coach—even when the conversations are hard. Especially when they are hard.   Self-reflection Question: When was the last time you raised a difficult topic in a way that closed the conversation instead of opening it—and what would it have cost you to bring it up differently?   [The Scrum Master Toolbox Podcast Recommends]

This week the TJL crew sits down with Kayode Faith, a longtime Jira admin who's just launched his own podcast, The New Shape of Work and had one of the TJL crew members as his first guest (guess who!?). Kayode opens up about how a recent summit completely changed his perspective on Forge, and the crew swaps stories about the unexpected professional relationships and friendships that come out of these events.From there, the conversation turns reflective: Kayode looks back at how the Atlassian ecosystem has evolved over his six years as a Jira admin, and shares what he's most excited about going forward — starting with never having to do another nerve-wracking Jira Data Center upgrade again. The crew also digs into the real-world frustrations of working in this space, including Kayode's experience supporting a nonprofit client with little to no budget for essential apps, including backup solutions for Jira and Confluence Cloud.Expect candid stories, shared scars, and plenty of laughs as the crew welcomes a fellow admin (and fellow podcaster) into the fold.Thank you to ikuTeam for connecting and collaborating with The Jira Life. https://ikuteam.comThe Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!https://ace.atlassian.com/the-jira-life/Or Follow us on LinkedIn!  / the-jira-life  Become a member on YouTube to get access to perks:https://www.youtube.com/@thejiralife/...Hosts:Alex "Dr. Jira" OrtizRodney "The Jira Guy" NissenSarah Wright"King Bob" Robert WenLina Ortiz   / alexortiz89     / @apetechtechtutorials     / rgnissen  https://thejiraguy.com   / satwright   Producer:   / robert-wen-csm-spc6-a552051  Executive Producer: Music provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codes   / monstercat  Outro: Fractal - Atrium   / monstercatinstinct  

#355: Picture your engineering team a year from now. A coding agent doing the coding. A testing agent on tests. A security agent on security. An infrastructure agent on infrastructure. All of them wired into GitHub and Jira, all of them working right alongside the humans. Not science fiction either - Atlassian and GitHub are already shipping these features. So out come the stats everyone loves to quote. AI code introduces 1.7 times more issues. Half of it ships with security holes. Code duplication is through the roof. AI-assisted PRs take four to five times longer to review. The response to most of it: so what? If you have a way to detect the issue and feed it back, that is just the SDLC doing its job. Couldn't care less if it is 1.7x or 50x more issues - what matters is what is left at the end, per feature shipped. Security holes? You have scanners. Detect, fix, ship. The only real problem is when you skip the detection or sit on the fix for months, and that has nothing to do with AI. Here is the one stat that actually sticks: PR reviews backing up. Speed up coding and leave everything downstream at human speed, and you have not sped up delivery - you have just moved the pile from Jira tickets to pull requests. The review pipeline was built for human speed, and now it is the bottleneck. The blunt fix: stop letting AI write 10,000-line PRs, work in smaller chunks, and accept that the job is about to get mentally harder. Delegate the tedious work and what is left is the demanding work - architecture, taste, is this even the feature we should ship. The silly stuff, does every function have a comment, is it camel case, goes to the machine. Spend your time there and you are wasting your talent. Offshoring never worked when the only goal was cheaper - chase the cheapest engineers, then chase even cheaper ones, and you end up dragging the work back in house. Same trap with AI. Offshore to Opus, then Sonnet, then Haiku, then Llama on a laptop. If cheaper is your primary motivation, you are doing it wrong. The win is qualitative, not the price tag. Where does it land? Three people per product, end to end - frontend, backend, database, deployments. Augmented at every stage, not autonomous. A human still pushes the final button to prod, the way you never let a Jenkins pipeline deploy straight to production without a check. Full autonomy is coming the way self-driving cars came: not in a year, not everywhere at once, and not by flipping it on at 4pm on a Friday. Even when the technology is ready, you are not. And if you think none of this touches your job, there is a story here about a textile factory built in the eighties that ran on five people. Knowledge work is next. The only exception is a monopoly, and you probably do not have one.   YouTube channel: https://youtube.com/devopsparadox   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Aji and Sally are back together again, this time to discuss the different apps they use to make their workflows and To Do lists easier and quicker to achieve. Sally dives into the Notion calendar system which she uses to coordinate her many Google calendars, Aji looks back on using Jira to co-ordinate their international move, before they both reminisce about the benefits of using Alfred as people with ADHD. — There's still time to secure your place at thoughtbot's upcoming UK meet ups over the next month. London Tech Leader Meetup - Tuesday June 23rd Brighton Tech Leader Meetup - Wednesday June 24th Brighton Ruby - Thursday June 25th Evolve - Friday June 26th Your hosts for this episode have been thoughtbot's own Sally Hall and Aji Slater. If you would like to support the show, head over to our GitHub page, or check out our website. Got a question or comment about the show? Write to our hosts: hosts@bikeshed.fm This has been a thoughtbot podcast. Stay up to date by following us on social media - YouTube - LinkedIn - Mastodon - BlueSky © 2026 thoughtbot, inc.

We go from horror side quests and Big Corp nostalgia to a practical breakdown of how to build team processes people will actually follow. We share how to map workflows, get buy-in, use tools like Jira for accountability, and turn bottlenecks into data you can use to improve the team.• canceling vacation to avoid getting sick and the reality of being immunocompromised• why horror comedy is hard to nail and why Widows Bay works• the gut-punch of watching an old company get acquired and its sign come down• time off as a tool for rest, focus, and even video game deep dives• building process from a flowchart first, then getting stakeholder approval before implementation• treating process as an ongoing feedback loop, not a one-time rollout• using Jira, Kanban, and strict transitions to make process real and enforceable• piloting new workflows with champions to drive adoption and surface gaps• handling resistance from the old guard and using accountability chains to keep work moving• avoiding process bloat and using process data to justify hires and resourcesIf you want to help out the show, you can. You can join our Patreon right now. In the show notes, whether you're listening or you're watching, there is a link tree that'll get you access to our website, the merch store. But more importantly than that, our Patreon, where you can support the show monetarily and keep it going. If you want to join the conversation, we have a Discord, you can get in there, same place as everywhere else.Support the showClick/Tap HERE for everything Corporate StrategyElevator Music by Julian Avila Promoted by MrSnoozeDon't forget ⭐⭐⭐⭐⭐ it helps!      

Jira Turned Agile Into a Micromanagement ToolThere was a time when Agile felt liberating. Teams owned their work, conversations mattered more than documentation, and progress was measured by outcomes, not activity. Then somewhere along the way, tools stepped in to “support” the process. What followed in many organizations was not support but substitution. Jira did not break Agile by design. It became the easiest place for organizations to quietly reintroduce control, visibility, and ultimately micromanagement under the label of transparency.- [website] ⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

Being a Jira admin has never been more complex or more critical. In this episode, we sit down with Peter Kerrigan, Head of Customer Success at Solcoro, for a no-holds-barred conversation about the real struggles, hard decisions, and thankless work that goes into keeping an Atlassian environment healthy, scalable, and sane.Whether you're managing a scrappy single-instance setup or a sprawling enterprise layout with dozens of sites, this one is going to hit home.We dig into the topics that don't get talked about enough the ones that keep admins up at night and that no Atlassian certification ever fully prepares you for.Thank you to ikuTeam for connecting and collaborating with The Jira Life. https://ikuteam.comThe Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!https://ace.atlassian.com/the-jira-life/Or Follow us on LinkedIn!https://www.linkedin.com/company/the-jira-life/Become a member on YouTube to get access to perks:https://www.youtube.com/@thejiralife/joinHosts:- Alex "Dr. Jira" Ortiz https://www.linkedin.com/in/alexortiz89/ https://www.youtube.com/@ApetechTechTutorials- Rodney "The Jira Guy" Nissen https://www.linkedin.com/in/rgnissen/ https://thejiraguy.com- Sarah Wright https://www.linkedin.com/in/satwright/ Producer:- "King Bob" Robert Wen https://www.linkedin.com/in/robert-wen-csm-spc6-a552051/Executive Producer: - Lina OrtizMusic provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codeshttps://www.youtube.com/c/monstercatOutro: Fractal - Atriumhttps://www.youtube.com/c/monstercatinstinct

BONUS: Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC Most teams are adopting AI to write code faster. But what if code generation isn't your bottleneck? Mooly Beeri has spent 25 years diagnosing where software organizations actually underperform — from Microsoft to Philips to automotive — and his message is clear: measure before you automate, and tie every AI investment to a business KPI. The Pattern Debugger's Origin Story "I've been identifying patterns way before AI was doing that. One of my first jobs was Microsoft, and I got the opportunity to work in engineering excellence. Every single simple improvement would make the lives of so many people better and the code better and the products better."   Mooly's career started at Microsoft in engineering excellence, where he discovered his passion for finding process areas that need improvement. From there he built the first software centre of excellence for Philips, spawned it into a separate business, and has been doing the same process excellence work across healthcare, telecom, and automotive ever since. His framework: understand where you're bleeding quality, revenue, or budget — then intervene there, not everywhere. Improvement Doesn't Mean Progress "There are too many efforts to improve too many things that don't really matter. The ability to tie a specific improvement to what actually means progress for a business — that, for me, is one critical component that's missing in many transformations."   Mooly's core insight applies directly to AI adoption: everyone has an improvement plan, but few can answer "how does this improvement improve business performance?" If you ask that one additional question, you can probably cancel half your improvement projects — the ones that make people feel good but don't move the needle on time to market, quality, or cost. The Code Generation Trap "It's like saying a book author is more productive because they write more words. The unit of work is not the number of lines of code they produce. The unit of work is a piece of code that works, that is tested, that is fully reliable, that meets a customer expectation, and eventually generates revenue."   Data from Faros AI shows individual developer PRs went up 98% with AI tools — but organizational delivery actually dropped 1.5%. More code, same or worse outcomes. Mooly explains why: most organizations invest in code generation not because it's the most effective thing to improve, but because it's the easiest step to automate. There are 35 steps in the SDLC. Picking code generation gives you a 1-in-35 chance of striking gold. As the saying goes: hope is not a strategy. Where AI Actually Works in the SDLC "The best usages would be in areas of the SDLC where there is a lot of data that needs processing and needs some detection of patterns — where AI is really, really good."   The most successful AI applications Mooly has seen with clients:   Defect root cause analysis — training AI agents on thousands of Jira bugs to find patterns humans can't see. In one healthcare client, AI analysis revealed that "false positive" bugs were actually compromised requirements — the dev team was closing real deviations as unimportant because they didn't have time to fix them Code review enhancement — AI scans incoming defects and generates a live, evolving checklist so reviewers spend their limited time checking for the most probable problems Test generation — unit, component, and functional test creation where AI can leverage existing test patterns and requirement data Requirements review — correlating requirements against strategic objectives, OKRs, and historical defect patterns to find contradictions before coding begins The Thinking Process You Can't Automate "The developers going through the process of converting requirements into code — it's actually a thinking process. It creates a lot of discussions with the product managers, a lot of back and forth, which help refine the requirement. This entire exchange is gone out the window when you have AI generate the code in 5 minutes."   When AI generates code instantly from requirements, it eliminates the human feedback loop that catches contradictions and incomplete specifications. The FDA has recognized this: every AI-assisted step in medical device software must be guardrailed by human activity. If you generate code quickly but still need a human review, the speed gain disappears. The value of coding was never just the code — it was the thinking. Map Every Investment to a Business KPI "If your uncle ran a bicycle repair shop and you said, let's advertise in the local newspaper, the first question he'd ask is: how many new customers will we get? The business logic hasn't evolved so much. If you want to do something — how will this impact your revenue, your customer retention, or your cost of producing goods? If you can't answer these things, don't invest."   Mooly's advice is deceptively simple: before adopting any AI tool in your SDLC, ask yourself which of three business outcomes it will improve — faster time to market, higher quality (fewer customer issues), or better margins (lower execution cost). If you can't draw a direct line from the AI investment to one of those outcomes, you're doing improvement theatre. About Mooly Beeri Mooly Beeri is CEO and co-founder of BetterSoftware, a consulting firm with over 25 years helping companies across healthcare, telecom, and automotive transform how they build software. His work focuses on diagnosing where software organizations underperform and designing targeted interventions — not blanket transformations.   You can link with Mooly Beeri on LinkedIn.

AI Ready: Ahmad Ghabboun Ahmad Ghabboun built a Demo Day–winning AI product during his MSIS program — after arriving with no plans to work in AI at all. He breaks down how his mindset shifted, how his design background made him a stronger prompter, and how to build AI fluency that actually holds up in interviews. Useful for students and early-career professionals trying to get AI-ready without faking it. Ahmad Ghabboun is a Master of Science in Information Systems (MSIS) 2026 Graduate at the UW Foster School of Business. Before Foster, he spent roughly fifteen years in UX and product design, building web applications for startups. At Foster he built several generative-AI tools in his coursework, including Synapse, which won Best Business and Tech Product at the MSIS Demo Day. He is targeting product management and technical product roles. What you'll learn Why naming the specific AI model you use — and justifying it — matters more in interviews than saying "I use AI" How a design background translates into sharper, more technical prompts How to keep a human in the loop so AI assists your judgment instead of replacing it Why AI's tendency to agree with you makes human and second-model pushback essential How to stay current with fast-moving tools without trying to learn everything The difference between a productivity mindset and a learning mindset in school Key moments The third-quarter AI classes that moved AI from "not on my list" to his career focus The origin of Synapse: manually juggling answers across Gemini, Claude, and a third model How Synapse runs a dual-model validation and a judge step to flag gaps for technical PMs Why interview proctoring now detects AI use — and what a "perfect" AI answer signals to interviewers Ethan Mollick's "jagged edge" and why it shifts with every model release Resources mentioned Lovable; Replit; Gemini; Claude; ChatGPT; Jira; Azure DevOps; GitHub; Ethan Mollick's "jagged frontier" of AI capability.

Catherine Solazzo is the Chief Marketing Officer at Appfire, a leading provider of software applications that help developers optimize their efficiency on platforms like Jira, Salesforce, and monday.com. With over 20 years of experience in marketing and digital transformation, Catherine has led high-performing teams at global tech giants and was recently recognized on the CRN Women of the Channel 2026 list. Under her marketing leadership, Appfire reaches over a million users every quarter through its technical documentation site. In this episode… Marketing today goes beyond just awareness, demand generation, or a polished campaign. It extends into the product experience, customer feedback, partner enablement, and every handoff that shapes revenue. So what does it really take to build a modern CMO mindset? According to Catherine Solazzo, a seasoned marketing leader with deep experience across developer ecosystems, the answer lies in thinking beyond the traditional marketing boundaries. She explains that elements like technical documentation, release notes, product pages, partner programs, and customer feedback are not secondary functions; they are critical touchpoints that help buyers understand, adopt, and expand with a product. Catherine emphasizes that by taking ownership of this entire journey, marketing teams can move faster, use data more effectively, and create a more cohesive go-to-market motion. In this episode of the Revenue Engine Podcast, Alex Gluz is joined by Catherine Solazzo, Chief Marketing Officer at Appfire, to discuss building a CMO mindset for modern marketing. Catherine explains the CMO+ model, how to align product and marketing, and why demand generation should go beyond lead volume. She also shares advice on partner enablement and creating repeatable operating models.

What does it actually look like to embed social impact into the DNA of a leading tech company — not as a PR footnote, but as a core operating principle? This week, we sit down with Jessica Hyman, the person at Atlassian tasked with answering exactly that question.As a key part of the Atlassian Foundation and the company's Chief Sustainability Officer, Jessica oversees everything from Atlassian's environmental commitments to its global social impact programs. We dig into how she navigates the tension between ambitious sustainability goals and the realities of running a high-growth software company, what the Atlassian Foundation is building for the long term, and why she thinks the tools teams use every day — yes, including Jira — can shape a more equitable future of work.This discussion looks beyond the typical outcomes such as new features of Rovo to understand how one of the world's biggest collaboration platforms approaches its obligations to the planet and its communities. If you're ready to look at Atlassian from a different perspective, this conversation is for you.Thank you to ikuTeam for connecting and collaborating with The Jira Life. https://ikuteam.comThe Jira Life=====================================Having trouble keeping up with when we are live? Sign up for our Atlassian Community Group!https://ace.atlassian.com/the-jira-life/Or Follow us on LinkedIn!https://www.linkedin.com/company/the-jira-life/Become a member on YouTube to get access to perks:https://www.youtube.com/@thejiralife/joinHosts:- Alex "Dr. Jira" Ortiz https://www.linkedin.com/in/alexortiz89/ https://www.youtube.com/@ApetechTechTutorials- Rodney "The Jira Guy" Nissen https://www.linkedin.com/in/rgnissen/ https://thejiraguy.com- Sarah Wright https://www.linkedin.com/in/satwright/ Producer:- "King Bob" Robert Wen https://www.linkedin.com/in/robert-wen-csm-spc6-a552051/Executive Producer: - Lina OrtizMusic provided by Monstercat:=====================================Intro: Nitro Fun - Cheat Codeshttps://www.youtube.com/c/monstercatOutro: Fractal - Atriumhttps://www.youtube.com/c/monstercatinstinct

Maria Skvortsova: The Team That Gave Up — When Green Reports Mask a Sinking Ship Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They said, 'Yeah, we know, but no one will listen to us.' And they just gave up — waiting for the ship to sink so they could swim away." — Maria Skvortsova   Maria walked into a 20-person migration team where the PowerPoint reports glowed green but the reality on the ground was covered in red flags. Developers were building features against requirements that had already changed — nobody had told them. The scope was impossibly large, and when Maria asked the team why they hadn't raised a red flag, the answer shook her: "No one will listen to us." The team had given up. They were waiting for the project to fail so they could leave. Maria's first instinct was to observe — spend weeks understanding the dynamics, the communication patterns, the culture. But she learned the hard way that when a team is already drowning, there's no time for a slow ramp-up. She needed to act immediately. Her breakthrough came from a simple technique: replacing some daily standups with an async RAG (Red-Amber-Green) status system in Jira. Team members just chose a color for each story — no explanation needed. It gave them psychological safety to signal problems without speaking up in a 20-person meeting. From there, Maria broke the team into smaller cross-functional groups — one QA, one developer, one consultant — so they could actually discuss features instead of hiding behind silence.   In this episode, we refer to Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem. Also check out the episode with Barry and Christiaan, authors of the book, on the podcast.   Self-reflection Question: When you join a new team and sense that something is deeply wrong, how long do you wait before acting — and is that waiting period serving the team or just your own comfort? Featured Book of the Week: Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem Maria chose Zombie Scrum Survival Guide because, as she puts it, "Most Scrum Masters learn by the happy path. We all know how it should be. But we rarely think about how it should not be." The book focuses on detecting anti-patterns early — before they become entrenched behaviors that are much harder to break. Maria finds it especially valuable because it provides concrete experiments you can try with your team to shake off the zombie symptoms. Her advice: start here, because understanding what bad looks like is just as important as knowing the ideal.   [The Scrum Master Toolbox Podcast Recommends]

This conversation with Gil Broza goes straight at a question many product leaders are quietly wrestling with: how do you bring AI into product development without breaking everything that already works? Gil, author, coach, and long-time agility expert, returns to talk with Matt and Moshe about “reshaping product development for AI's impact,” focusing not on building AI features, but on how AI is changing the way product and engineering teams work day to day. He argues that while AI massively increases speed and output, it doesn't change the fundamentals of good product development: clear direction, evidence-based judgment, solid technical foundations, and healthy teams. Join Matt and Moshe as they explore with Gil: - Why AI is a “turbo engine in a car with old brakes” if you drop it into a system designed for human speed. - How leaders confuse more output with more value, and why faster code can just mean “legacy code years ahead of schedule”. - The difference between real agility and “performative Agile” (ceremonies, Jira theater) when AI tools are doing more of the work. - How to think in systems: what you're actually optimizing for (predictability, innovation, time-to-value) and how AI changes the constraints and feedback loops in your org. - Practical blind spots leaders miss with AI adoption: - Treating AI as an implementation, not a transformation - Ignoring cognitive load and burnout when people work all day with agents - Shrinking teams for “efficiency” and accidentally increasing isolation - The three main ways to use AI in product development, and why you should be explicit about each: - As a pairing partner (thinking, coding, design) - As an autonomous agent - As “just” automation (summaries, note-taking, etc.) - Why skipping prototyping and experiments is now “less excusable” when AI can create testable prototypes in hours instead of weeks. - What changes (and doesn't) in roles like PM, engineer, and scrum master when AI becomes a real team member. - Concrete steps leaders can take: apply systems thinking, revisit mindset and values, redesign ways of working for AI-speed conditions, and invest in continuous improvement again. - How Gil's new courses (“Reshaping Product Development for AI's Impact” and “Leading AI-Enabled Product Teams”) help product and engineering leaders do this work intentionally. Want to go deeper or work with Gil? - Website & courses: https://3pvantage.com/  - Newsletter & articles: https://3pvantage.com/subscrib.../  - LinkedIn: https://www.linkedin.com/in/gi.../  You can also connect with us and find more episodes: - Product for Product Podcast: http://linkedin.com/company/pr...-podcast  - Matt Green: https://www.linkedin.com/in/ma... - Moshe Mikanovsky: http://www.linkedin.com/in/mikanovsky  Note: Any views mentioned in the podcast are the sole views of our hosts and guests, and do not represent the products mentioned in any way. Please leave us a review and feedback ⭐️⭐️⭐️⭐️⭐️

Malaayiin xujey ah oo ka kala yimid waddamada Islaamka ayaa isugu yimid magaalada barakaysan ee Maka ee dalka Sacuudiga, si ay u gutaan waajibka Xajka ee sannadkan, iyadoo uu heerkul-kuna gaarey 48 degrees.

What does AI transformation actually look like inside one of the world's largest engineering organizations? At Team '26 in Anaheim, I recently sat down with Jason Andrews to unpack how Cisco transformed decades of fragmented tooling, disconnected workflows, and spreadsheet-driven operations into a unified system of work built around Jira, Confluence, Jira Service Management, automation, and AI-ready workflows. And honestly, this conversation felt refreshingly practical. Jason oversees engineering operations across Cisco Networking, a business unit with around 22,000 engineers and product managers representing roughly $40 billion in annual revenue. So when he talks about transformation, this isn't theory. This is operational change happening at enterprise scale. We discuss how Cisco consolidated more than 85 Jira instances, reduced tooling spend by 54%, and accelerated reporting by 40x while creating a far more scalable engineering organization. But as Jason explains throughout the conversation, the real challenge was never the technology itself. It was getting teams to rethink how they wanted to work moving forward rather than simply migrating years of technical debt into modern systems. One of the strongest themes in this episode is the difference between transformation and migration. Jason explains why organizations often fail when they focus only on moving systems rather than changing workflows, behaviors, and operational culture at the same time. We also dive deep into AI adoption inside engineering organizations. Jason shares how Cisco is already seeing significant productivity gains from AI-assisted development, why organizational context matters so much for enterprise AI success, and why he believes the industry is still massively underestimating how much structured data and workflow consistency AI systems actually require. Along the way, we unpack scenario planning in the AI era, why annual planning cycles are becoming increasingly fragile, and how leaders can move from rigid long-term roadmaps toward more agile operational playbooks capable of adapting to constant disruption. There's also a fascinating discussion around the so-called "SaaS apocalypse," the limits of AI-generated software, and why Jason believes humans will remain central to enterprise operations for years to come, especially in organizations managing millions of lines of legacy code and decades of accumulated institutional knowledge. If your organization is currently navigating modernization, operational complexity, AI adoption, or large-scale systems transformation, this episode is packed with lessons learned from the front lines of enterprise change. And perhaps most importantly, Jason offers a reminder that AI alone is not the strategy. The real opportunity comes from reducing friction, improving context, and helping teams spend more time solving meaningful problems instead of manually stitching systems together.

Tish Guinn hosts this look back at the Build It Together and Atlassian Team 26 conferences held this month in Anaheim, California. She's joined by Marc Brickley, Moser's Director of Application Development, and Malinda Lowder, our Director of Sales and Marketing, who were also at the conferences.We cover what stood out at both conferences, recap some of the conversations we had around Clear Path, the importance of building authentic connections, and how organizations can turn conference interactions into long-term partnerships and opportunities. There's also plenty of reminiscing about karaoke with a live band and the skating rink at the post-Team 26 bash. 

Jack sits down with Tapan Patel, Gearset DevOps Leader for 2026 and DevOps Lead for the Salesforce practice at Braze, a publicly traded omnichannel platform where every change management decision is subject to SOX audit scrutiny. Tapan brings a rare blend of project delivery experience, release management rigour, and genuine passion for building DevOps not just as a set of processes, but as a culture.The episode is a masterclass in phased, people-first DevOps rollout. Tapan walks through exactly how he's taken Braze from change sets and manual deployments to a governed, audit-ready CI/CD pipeline over the past year and a half — breaking it down into four distinct phases and sharing what actually worked, what took longer than expected, and where he's headed next. Tapan shares his rounded take on AI, including where it's already adding value in the pipeline today, why agentic autonomy in prod is still a way off, and how Claude, Jira and Gearset's reporting API are becoming a powerful combination for DevOps KPI tracking.00:01 – Intro & Meet Tapan Patel00:40 – Tapan's Journey: From Data & Analytics to Salesforce DevOps02:12 – What DevOps Actually Means as an Organisational Culture04:10 – DevOps in a SOX-Audited, Publicly Traded Company05:10 – The State of DevOps at Braze When Tapan Joined08:14 – Shifting Mindsets From Change Sets to a DevOps Tool10:32 – Precision Deployments: Why Page Layouts Break Everything11:49 – Stakeholder Visibility & the Value of Issue Tracking Integration13:36 – What Tapan Values Most About Gearset15:53 – The Four Phases of CI/CD Rollout at Braze19:16 – Phase Two: Stabilisation & SOX Integration20:30 – Phase Three: Automation Layers & QA Integration21:18 – Phase Four: Maturity & Minimal Intervention22:55 – The Admin Learning Curve for DevOps Adoption25:25 – Continuous Improvement as a Practice, Not a Project28:34 – Where AI Fits Into the DevOps Pipeline Right Now31:07 – Supplementary vs. Agentic AI: Why Tapan Is Taking It Slow33:14 – Using Claude + Gearset Data for Sprint Analysis & KPI Tracking36:00 – The DevOps KPIs That Matter at Braze37:24 – Closing Advice for Anyone Starting Their DevOps Journey

What happens when AI stops being a feature and starts reshaping the very craft of design itself? Live from, I sat down with Charlie Sutton for a conversation that went far beyond product interfaces and pixels. As Atlassian unveiled its latest AI ambitions around agents, context, and the Teamwork Graph, Charlie offered a fascinating look at the human side of that transformation and why design may become even more important as AI becomes embedded into the way we work. Charlie shared how Atlassian approaches design at scale across products like Jira, Confluence, Loom, and Rovo, explaining why every interaction should feel intentional and cohesive, even when built by hundreds of people across dozens of teams. But this conversation quickly moved into much bigger territory. We explored how AI is changing the relationship between designers, developers, and business teams, and why the traditional barriers between idea and execution are rapidly disappearing. One of the most thought-provoking parts of the discussion centered around democratization. Charlie argued that while AI tools have dramatically lowered the floor for creativity, they have also raised the ceiling for what users now expect from software experiences. Anyone can prototype an app today, but expectations around quality, coherence, trust, and usability are climbing just as quickly. We also unpacked the growing shift from prompting AI to delegating work to AI agents. Charlie explained why assigning work to agents increasingly resembles managing human teammates, from defining goals and success criteria to understanding strengths, limitations, and context. That naturally led us into a deeper conversation about trust, transparency, and why users must always feel they can "pop the bonnet" and understand what AI systems are doing on their behalf. Another major theme throughout the episode was context. Charlie shared why Atlassian sees organizational context as one of the defining challenges of the AI era and how the Teamwork Graph is helping connect people, projects, conversations, and knowledge across the company. He compared this moment to the first time many of us used Google search and suddenly realized the scale of what was possible. We also discussed how AI adoption is unfolding differently from previous technology waves. Instead of adoption trickling down from hardcore technical users, Charlie is seeing rapid experimentation from marketing, HR, and design teams looking to reduce repetitive work and communicate ideas more effectively. Even his own mother, he joked, has become an AI power user before he has. From AltaVista nostalgia and Ask Jeeves memories to serious conversations about the future of human creativity, this episode captures a rare and honest perspective on where design, collaboration, and AI may be heading next. How will organizations balance personalization with shared experiences as AI becomes embedded into every workflow, and what role will human creativity play when everyone suddenly has access to the same powerful tools? Please check the partners of the Tech Tech Talks Network Learn more about the NordLayer Browser Visit Denodo.com

What happens when one of the most iconic teams in Formula One decides to rethink how work gets done behind the scenes completely? Last year, Atlassian Williams Racing made headlines when Atlassian entered Formula One as both title partner and technology partner. At the time, many people saw the partnership as another high-profile sponsorship deal. But over the last twelve months, something much bigger has been unfolding inside the Williams organization. At Team '26 in Anaheim, I sat down with Andrew Boyagi and Matt Harman to unpack how AI, data, workflows, and organizational transformation are reshaping life both at the factory and on the grid. This conversation goes far beyond racing. Matt explains how Williams is reducing the time between "idea to track," compressing development cycles so upgrades arrive at race weekends weeks earlier than before. One striking example involves reducing front wing lead times by a factor of three through parallel workflows and better collaboration, allowing performance gains to reach the circuit three race weekends sooner. Andrew shares how Atlassian's system-of-work philosophy is being applied in one of the most data-intensive environments on earth. We explore how tools like Jira, Confluence, Loom, Rovo, and Teamwork Graph are helping engineers, strategists, operations teams, and factory staff make faster decisions with less operational friction. We also discuss how AI is changing engineers' roles, why organizational context matters more than raw intelligence, and how Formula One teams balance human instinct with AI-driven precision in race strategy decisions. Matt offers fascinating insight into how AI helps teams process decades of historical race data in real time while still relying on human judgment in critical moments. Along the way, we explore the cultural transformation underway at Williams, including the shift away from endless meetings toward faster, outcome-focused collaboration. Matt explains how tools like Loom and Confluence are helping teams make decisions more efficiently while spreading knowledge more effectively across specialist departments. Andrew also reveals some eye-opening metrics from the partnership so far. Since rolling out Atlassian's Teamwork Collection, teams have reportedly increased throughput by 83%, while low-value meetings have been reduced by 863 hours in a single month across 200 people. Perhaps the biggest takeaway from this episode is that Formula One may actually be a perfect reflection of the challenges facing every modern business. As Andrew puts it during our conversation, Formula One is ultimately "an enterprise performance problem," just operating at 300 kilometers an hour with millions of people watching every weekend. If you've ever wondered what enterprise transformation looks like when milliseconds matter, this episode offers a fascinating look inside one of the most ambitious AI and workflow transformation journeys happening anywhere in business today   Please check the partners of the Tech Tech Talks Network Learn more about the NordLayer Browser Visit Denodo.com

Software delivery clarity has become one of the most important competitive advantages for engineering organizations. Teams are shipping faster, AI-assisted development is compressing implementation timelines, and traditional project management systems are struggling to keep pace with modern software delivery realities. During the conversation with Alex Polyakov, one idea surfaced repeatedly: most project management systems promise visibility but fail to provide actual operational clarity. Teams still discover delays too late. Executives still receive bad news at the last possible moment. Developers still spend excessive time updating systems rather than building software. That disconnect is exactly what inspired Alex to rethink how engineering organizations manage software delivery. About Alex Polyakov Alex Polyakov is the founder of Project Simple AI, a platform focused on improving transparency and discipline across software delivery workflows. With more than 25 years of experience spanning software engineering, architecture, product management, entrepreneurship, and startup leadership, Alex brings a deeply practical perspective to modern development operations. He has worked as an Application Developer, Senior Engineer, Tech Lead, Software Architect, Solutions Architect, Product Manager, Entrepreneur, and Startup Founder. Today, his focus is helping engineering teams gain visibility and operational discipline without adding unnecessary complexity. Alex also hosts the "Let's Talk Agile" podcast on YouTube, where he discusses modern software development challenges and Agile transformation realities. LinkedIn: https://www.linkedin.com/in/alexpolyakov/ Why Software Delivery Clarity Still Doesn't Exist Most organizations believe they have visibility because they use Jira, Azure DevOps, or similar tools. In reality, they have tracking systems, not visibility systems. Alex described modern project management tools as "glorified Excel sheets." That description lands because many engineering teams recognize the pattern immediately. Endless ticket hierarchies, fields, statuses, and sprint rituals often create administrative complexity without improving confidence. The core issue is simple: status updates depend on human behavior. Developers forget to update tickets. Teams delay reporting problems. Managers discover schedule risks only when deadlines are already compromised. The tooling creates an illusion of control while actual delivery risk remains hidden. That creates a dangerous operating environment for leadership. A founder or executive can solve a delivery problem early. They can reduce scope, renegotiate timelines, allocate additional staff, or re-sequence priorities. But once a team waits until the final week to communicate delays, most strategic options disappear. Visibility is not the same thing as documentation. Visibility means understanding delivery risk early enough to respond. Software Delivery Clarity Requires Behavioral Design One of the most interesting concepts from the discussion was the idea that project management is partly behavioral science. Most tools allow teams to skip critical disciplines. Teams can start work before decomposition. They can mark tasks complete without validating outcomes. They can carry partially defined requirements into implementation. Alex's approach flips that model entirely. Instead of giving teams unlimited flexibility, the system enforces operational readiness. Work cannot begin without decomposition. Timelines cannot exist without estimates. Completion cannot happen without verifying a definition of done. This is important because software organizations often assume process problems are communication problems. In reality, many are workflow design problems. If a system permits ambiguity, ambiguity becomes normalized. If a system requires clarity, clarity becomes operational behavior. Why AI Makes Software Delivery Clarity More Important AI-assisted development changes the economics of software delivery. Implementation cycles are shrinking dramatically. Tasks that previously required days may now take hours. Boilerplate code generation, scaffolding, testing support, and architectural suggestions accelerate execution speed. That acceleration creates a new challenge. If implementation becomes faster, bottlenecks move upstream and downstream. Requirements gathering, coordination, prioritization, testing, and validation suddenly become the limiting factors. This means organizations can no longer rely on heavyweight process management structures built for slower delivery cycles. When implementation speeds increase but operational visibility stays static, delivery chaos accelerates instead of improving. The transcript discussion highlighted a critical reality many organizations are only beginning to recognize: AI amplifies existing operational weaknesses. A disorganized engineering team using AI becomes a faster disorganized engineering team. That is why delivery clarity matters more now than it did during earlier Agile transformations. The Simplicity Principle Behind Better Delivery Alex outlined several operational principles that simplify software execution dramatically. Software Delivery Clarity Starts with Prioritization Teams should know exactly what matters most. Priority order should not be vague or political. If only one item can ship, teams must know which item wins. That sounds obvious, but many organizations operate with dozens of simultaneous "critical" initiatives. Clear sequencing eliminates organizational confusion. Software Delivery Clarity Depends on Finishable Work Teams should not start work that they cannot complete. This principle directly attacks excessive work in progress — one of the most common hidden inefficiencies in software organizations. Partially completed work creates coordination overhead, testing delays, context switching, and reporting confusion. Smaller, decomposed work creates measurable progress. Software Delivery Clarity Improves Team Accountability Alex also challenged pre-assigned work structures. When work is individually distributed too early, collaboration weakens. Teams lose shared ownership. Visibility becomes fragmented across individuals instead of remaining centralized around delivery goals. That perspective aligns closely with modern product-oriented engineering cultures where collaboration and flow matter more than rigid task ownership. Before adding new process layers, evaluate whether your current workflow already contains unnecessary coordination overhead. Why Simpler Engineering Systems Scale Better Many organizations assume maturity means adding process. The conversation suggested the opposite. Mature engineering organizations often remove unnecessary friction instead of introducing more operational complexity. Simplicity improves adoption, consistency, and decision-making speed. This becomes especially important in high-growth environments. As teams scale, communication overhead compounds rapidly. Every unnecessary workflow step multiplies across developers, product managers, QA engineers, architects, and leadership stakeholders. Simple systems reduce cognitive load. That reduction creates operational focus. The goal of project management is not to track work forever. The goal is to deliver valuable software predictably. Conclusion Software delivery clarity is not about more dashboards, more ceremonies, or more ticket customization. It is about creating operational confidence. Alex Polyakov's perspective challenges many assumptions that modern engineering organizations accept as normal. Teams do not necessarily need more process. They need better behavioral systems, clearer visibility, stronger prioritization, and simpler operational structures. As AI continues accelerating implementation speed, organizations that simplify coordination and improve transparency will gain a meaningful competitive advantage. The future of software delivery may not belong to the teams with the most process sophistication. It may belong to the teams with the clearest operational discipline. Stay Connected: Join the Developreneur Community

AI agents are reshaping enterprise workflows, increasing the importance of organizational context and connected data. Atlassian CEO and co-founder Mike Cannon-Brookes joins Bloomberg Intelligence senior software analyst Sunil Rajgopal to discuss how Atlassian is embedding AI across Jira, Confluence and service-management tools through its Rovo platform and Teamwork Graph. “The future is about human and agent collaboration,” Cannon-Brookes says. The discussion also covers enterprise AI adoption, developer productivity and API-driven software infrastructure.

Oren Michels is the founder and CEO of Barndoor.ai, the first and only Control Plane for the agentic enterprise. Previously, he co-founded Mashery in 2006 and served as CEO until Intel acquired the company in 2013. When it was acquired, Mashery-powered APIs were used by over 350,000 active developers in over 100,000 active applications, and counted among its customers many of the largest e-commerce, media, and data companies in the world. He is an entrepreneur, investor, board member, and advisor to technology startups in the US and Europe and has made angel investments in several successful companies including Uber, Pebble Post, Addy, Navdy, and eero.Highlight Bullets> Here's a glimpse of what you would learn…. Rapid evolution of AI agents in e-commerce and business operations.Definition and functionality of AI agents that perform actions on behalf of users.Importance of governance and trust in deploying AI agents to prevent errors and misuse.Introduction of Barndoor AI and its role in providing connectivity and governance for AI agents.Practical use cases of AI agents in managing tasks across various platforms (e.g., Shopify, JIRA, QuickBooks).The necessity of setting strict policies to control AI actions and ensure safety.Integration of AI tools with existing software systems and the potential for low-code/no-code solutions.The significance of problem-solving and process design skills in effectively utilizing AI agents.Recommendations for starting small with AI and learning through practical application.Continuous evolution of AI tools and the importance of staying informed and adaptable.In this episode of the Ecomm Breakthrough podcast, host Josh Hadley speaks with Oren Michels, founder and CEO of Barndoor AI, about the growing role of AI agents in business operations. Oren explains how AI agents can autonomously perform tasks within systems like Shopify, Amazon, and Slack, while emphasizing the critical need for governance and trust. He introduces Barndoor AI as a control plane that enables secure connectivity and policy-based guardrails, preventing unintended actions. Practical use cases include email management, JIRA ticket handling, and financial forecasting. Oren advises listeners to start small, experiment with multiple AI tools, and develop strong problem-solving skills.Here are the 3 action items that Josh identified from this episode:Start with low-risk automation Deploy AI agents on simple, non-critical workflows first (e.g., email summaries, reporting) to test value and build internal trust before scaling. Enforce strict governance from day one Define clear permissions, rules, and guardrails—never give blanket access. Every AI action should be controlled, logged, and auditable. Design processes before deploying AI Break workflows into clear steps and craft precise prompts. Strong process design + prompt clarity = better, safer AI performance.Timestamps:00:00:00 The Problem of AI GovernanceOren discusses lack of governance in current AI systems and the risks of AI agents forgetting instructions.00:00:30 Podcast Introduction & Guest BackgroundPodcast is introduced, and Oren Michels' background and achievements are highlighted.00:00:44 The Rise of AI Agents in E-commerceJosh frames the future of e-commerce as dominated by AI agents and introduces Oren as the guest.00:02:06 Oren's Perspective on AI Agent AdoptionOren explains the rapid and slow pace of AI agent adoption, especially beyond coding tasks.00:03:02 What is Barndoor AI?Oren introduces Barndoor AI, focusing on connectivity and trust for AI agents in business systems.00:03:40 How Barndoor AI WorksDetails on how Barndoor AI enables granular control and governance over AI agent actions.00:05:45 Security and Guardrails for AI AgentsDiscussion on security risks, both from bad actors and unintended consequences by legitimate users.00:06:33 Difference Between Barndoor and Other AI ToolsOren explains how Barndoor adds governance missing from tools like OpenClaw and Claude.00:09:24 Use Case: Email Management with AI AgentsOren shares how he uses AI agents to manage and triage his daily email load efficiently.00:12:04 Why Governance Matters in AI ActionsExplains the importance of restricting AI actions to prevent mistakes, especially in sensitive tasks.00:13:00 Custom Rules and Granular PoliciesBarndoor allows highly specific rules for AI actions, such as price-based restrictions in e-commerce.00:13:58 Use Case: JIRA and Finance AutomationExamples of using AI agents for JIRA ticket management and automated financial reporting via Slack.00:16:48 Enterprise Use Cases & E-commerce OptimizationBarndoor's enterprise clients use AI for handling sensitive data and optimizing Amazon listings seasonally.00:19:08 Customer Service and Contextual CommunicationAI agents help draft personalized emails by pulling context from Salesforce and previous communications.00:20:40 AI Agent Adoption is Still EarlyOren emphasizes that AI agent use is in its infancy and encourages experimentation in low-risk areas.00:22:40 Personal Use Cases for AI AgentsJosh and Oren discuss personal productivity applications, like sports team management and scheduling.00:24:14 The Evolving AI Tool LandscapeDiscussion on the rapid evolution of AI tools, the importance of using multiple models, and specialization.00:27:47 Future of AI in Business OperationsSpeculation on the future: specialized AI tools for each business function, governed by platforms like Barndoor.00:31:00 The Importance of Problem-Solving and Prompt EngineeringSuccess with AI depends on defining problems and giving clear instructions, akin to prompt engineering.00:33:46 Actionable Takeaways for ListenersJosh summarizes three action items: start experimenting, document processes, and stay flexible with tools.00:36:44 Book Recommendation: Why Computers ThinkOren recommends a book that explains the probabilistic nature of AI and why it sometimes fails.00:37:34 Favorite AI Tool and Personal UseOren shares his favorite AI tools and how he uses them for both work and personal learning.00:38:49 Who to Follow: Aaron LevieOren recommends following Aaron Levie for insightful commentary on AI and business.00:39:28 Where to Learn More About Barndoor AIOren directs listeners to Barndoor AI's website and their personal product, Zenni, for hands-on experience.00:39:45 Podcast Wrap-UpPodcast concludes with thanks and a call to subscribe and leave a review.Resources mentioned in this episode:Josh Hadley on LinkedIneComm Breakthrough ConsultingeComm Breakthrough PodcastEmail Josh Hadley: Josh@eCommBreakthrough.comTools and Websites"OpenClaw": "00:00:00""Barndoor AI": "00:03:14""

In this episode of Talos Takes, Amy Ciminnisi sits down with researcher Diana Brown to discuss the rise of "platform-as-a-proxy" (PAP) attacks. We explore how threat actors are weaponizing legitimate SaaS platforms like GitHub and Jira to deliver phishing campaigns that bypass traditional security filters. By leveraging the platforms' own infrastructure to send authenticated emails, attackers are exploiting the inherent trust employees place in these essential business tools. We break down the mechanics of these campaigns and provide actionable strategies for security teams to move beyond binary trust and implement contextual awareness to better protect their organizations.Blog: https://blog.talosintelligence.com/weaponizing-saas-notification-pipelines/

If your to-do list is 47 items long, your Slack won't shut up, and you ended the day thinking, "Cool… but what did I actually accomplish?"—welcome. You're among friends. In this episode, Kim and Kate take on the very real, very unsexy side of project management: figuring out how to manage your own work when everything (and everyone) is demanding your attention. This isn't about finding the perfect tool or building a prettier dashboard. It's about surviving—and actually functioning—in an interrupt-driven world where emails breed overnight, notifications multiply, and every task somehow feels urgent. They get into what actually works: setting a North Star for your week (yes, only a few priorities), getting tasks out of your brain before they haunt you at 10 PM, and why some tasks are secretly just traps that create even more work (looking at you, boomerang tasks). Also: a gentle reality check—you're not supposed to do everything. Grab a drink, ignore your inbox for a bit, and let's figure out how to organize the chaos without losing your mind.  

Boris Berenberg bootstrapped Atlas Authority, an Atlassian partner that resold Jira and Confluence to mid-market companies and built apps on top of the platform, to high seven figures in revenue with 18% net margins, then sold to private equity in May 2022.  A year later he wrote a blog post titled "I regret selling my startup" that went viral inside the exited founder community. 

Why I'm Not "Picking a Fight" on AI: A listener asked if I'm intentionally stoking a flame war by treating agentic coding as a foregone conclusion. The honest answer is that I've used it, the data points one direction, and a show built around pretending otherwise would slowly drift away from reality — and away from being useful to you. Respecting the Misgivings, Without Getting Stuck in Them: Ethical concerns, skill atrophy worries, and questions about long-term effects are all legitimate. But the goal of this show is practical applicability, so we focus on mental models you can use Monday morning rather than litigating every angle of the debate. The "Minecraft" Principle: If I ask you to "build Minecraft," I've handed you several chapters of specification in a single word. That's meaning-rich abstraction — language that points at a huge amount of shared context with very little token cost. Meaning-Rich AND Specific: "Human history" is meaning-rich but uselessly broad. "Block-building game" is specific but loses fidelity. The sweet spot is vocabulary that is both compact and unambiguous — sitting in the top right of the meaning-density / specificity graph. A Real Example — Strategy Pattern: When working on authorization rules, I didn't want a pipeline. Instead of describing base classes, shared interfaces, and parallel execution to the LLM, I used the words "strategy pattern." Three words did the work of three paragraphs, and the output landed where I wanted it. Vocabulary as Leverage: Named patterns, named algorithms (Monte Carlo, etc.), named architectural concepts — these act like compressed pointers. The more of them you genuinely understand, the higher the leverage of every prompt you write and every conversation you have with another engineer. How to Build This Vocabulary: Have conversations with senior engineers. Ask an LLM what patterns are at play in a codebase, which ones you're using incorrectly, and which ones you're tricked into thinking you're using. Learn the abstraction layer that sits one step above your day-to-day implementation work. The Asterisk — Shared Context Required: This only works when both sides know the term. Public, well-documented concepts (patterns, papers, algorithms) translate immediately to LLMs. Private or organization-specific concepts need to be loaded into context — via CLAUDE.md, AGENTS.md, or skills — before that compression kicks in. Episode Homework: Pick one area of your current codebase. Ask an LLM to name the patterns in play, the patterns you're using incorrectly, and the ones you might be missing. Use that conversation to add at least one new piece of meaning-rich vocabulary to your working set.

The Coding-Is-My-Value Trap: For years, we've treated the ability to write code as the flagship skill of software engineering. It's concrete, it's teachable, it's the thing big box stores sell kits for. But conflating "what I enjoy about the job" with "what I'm actually valuable for" is dangerously reductive — and AI is now exposing that gap. The Skills You've Been Discounting: Domain expertise, systems thinking, risk and bottleneck analysis, organizational design, tech-lead-level sequencing of work, relational skills that unblock hard moments in a company's life. These have always been where a lot of your real value lived. You probably just weren't writing them down. The Three-Part Framework — Valuable, Durable, Transferable: A skill worth investing in hits as many of these as possible. Valuable means it meets a clear business need. Durable means it survives industry shifts. Transferable means it applies across domains and scales up as you grow more senior. What "Durable" Actually Means: Ask yourself: what would have to change for this skill to become obsolete? Coding, on its own, has a lower durability answer than it used to. Relationship building, architectural thinking, and the ability to reason about complexity require much bigger shifts before they stop mattering. Transferability Is Vertical, Not Just Lateral: Don't just ask whether a skill moves across industries. Ask whether it keeps paying off as you move into more senior, higher-leverage roles. Soft skills, systems thinking, and mental models like compound interest compound themselves the further up you go. Episode Homework: Make your own list. Which of your skills are valuable, durable, and transferable? Every engineer's list looks different — and the ones you've been quietly discounting are often the ones that matter most going forward.

BONUS: From 3,000 Scripts to 3 Tools - Building AI-Last Software With Conversational AI Pioneer Peter Swimm In this special BONUS episode, Peter Swimm—conversational AI veteran, creator of BotKit (the open-source chatbot framework that powered Slack and Teams bots), and former Principal Product Manager at Microsoft Copilot Studio—shares what 25+ years in tech taught him about working with AI. From his brutal experiment of running an entire business on voice-based AI for a week, to why he treats AI more like R2-D2 than C-3PO, Peter offers a grounded, practical perspective on where AI fits in software development teams. From BotKit to Copilot Studio: A Front-Row Seat to the AI Evolution "We had the number one bot in the Slack app store, because there were only 8 bots, and ours used regex. To show you how far we've come."   Peter's journey into conversational AI started with a newspaper ad and a creative writing background. When Slack launched its API, Peter and BotKit co-creator Ben Brown immediately saw that building bots wasn't just a technical challenge—it was a social and creative one, like writing scripts for plays that interface with people in their daily lives. That insight powered BotKit into becoming the backbone of Slack and Teams bots, and eventually led to Microsoft acquiring the company. Peter spent years inside Microsoft shaping Copilot Studio, working on connectors that bridge the gap between APIs and real-world work. But the experience also gave him a healthy dose of perspective: he can show you slide decks from 2016 that promise the same things today's AI pitches promise, always saying "within 5 years." That pattern recognition shapes his practical, no-hype approach. The 3,000 Scripts Experiment: Why AI-Last Beats AI-First "At the end of the day, if I've been prompting all day, I should have a computer program that works offline, that works without a subscription. Otherwise, I didn't really make anything."   Peter ran a week-long experiment trying to run his entire business using only voice-based conversational AI. The result: 3,000 generated scripts. After static code analysis, he discovered it was really only 5 programs made thousands of times—and those 5 programs were really just 2 or 3 core abilities. He deleted 36 gigabytes of generated code and kept 50 megabytes of what actually worked. This brutal compression led him to an "AI-last" philosophy: build reliable runtime software that works confidently in one click, then use AI only for exploration, connection-making, and creative riffing. The payoff is striking—within 3 weeks of a given application, his team sees a 90% reduction in AI usage in the first week, dropping to 0% within 13 days, because once a computer program does everything you need, you don't need AI anymore. R2-D2, Not C-3PO: How to Think About AI on Your Team "I think of our AI use more like R2-D2 than C-3PO. R2-D2 doesn't talk—bonus points. He doesn't interject his fear. He saves your butt. He's silent until you need him, and visible when you need him."   Peter's Star Wars analogy captures his team's philosophy on AI integration. AI should be like a smarter linter—a quiet, capable tool that handles the boring, repetitive tasks so humans can focus on creativity and shipping. His team treats AI as a "super junior" with infinite time: set it up as if it invented Python, have it write buy-the-book code with unit tests, and then a human reviews and accepts (or rejects) the output. The tooling isn't consistent enough to ship autonomously or commit directly into the codebase—even frontier providers don't fully understand what their models do. The practical benefit is enormous for setup and configuration: what used to be a painful, arcane process of tracking down dozens of AWS or Azure docs becomes a 20-minute "hello world" that's actually a working proof of concept. Your job isn't to become an expert at cloud services—it's to ship product. The Biggest Mistake: Automating Broken Processes at AI Speed "All it does is automate all the mistakes you made, all the way, at AI speed."   When asked about the most common mistake organizations make with AI, Peter is blunt: they port their existing infrastructure into AI-governed systems instead of rebuilding from the ground up. Companies with a self-inflated opinion of their processes think AI is just a million-person force multiplier—so they'll ship faster. But if your process was broken before AI, you'll just generate broken output at unprecedented scale. That 3,000-script experiment proved this firsthand. Peter's recommendation: rebuild from the bolts up. Start with AI-last architecture where reliable, offline-capable software handles the core, and AI is reserved for the edges—filling gaps, translating between systems, and making connections that don't exist yet. SaaS Is Bloated: The Case for AI Transformation Layers "The one thing AI is good at is transforming between boundaries."   Peter's team has been divesting from SaaS providers, replacing the patchwork of middleware subscription plans that forced everyone to copy and paste between CMS, Excel, meeting notes, and email. His approach: product people use Notion, developers use GitHub, and the two cross-sync without needing Jira as an arbitration layer. Everyone tracks work in the tool they already live in. AI's real superpower here is translation—between APIs, between languages, between formats. Peter sees a future where small translation layers between CRUD operations replace the bloated, one-size-fits-all SaaS tools that are "built for 99% of users with generalized features nobody uses." His team also freed themselves from tools like Figma: the designer works in their preferred graphics program, the developer in their preferred IDE, and AI arbitrates the differences. Teams, Velocity, and Reinvesting the AI Dividend "5 to 7 people is still good, because you need a diverse set of people who are intensely focused on certain areas. But they should be allotted that savings in time to ship all the things that get cut."   Peter pushes back on the idea that AI changes the ideal team size. The 5-to-7 person team still works—what should change is what those people do with the time they save. Instead of loading teams onto more projects or increasing portfolio velocity, reinvest the AI productivity dividend into quality: ship with unit tests from day one, ship WCAG-compliant from day one, and stop cutting features to hit deadlines. Version 1.0 should no longer need an immediate 1.1 follow-up. Peter also challenges the notion that AI eliminates the need for experienced practitioners—velocity metrics become meaningless when a 6-week coding plan finishes in 25 minutes. What matters is using the saved time to make software genuinely better. The Future: Demo-First Development and Solid Releases "I can show you a working demo of the thing at the first meeting, and you can pay for it. And then we can make it better than your dreams."   Peter sees AI transforming the consulting and product development lifecycle from "launch, listen, and learn" to "listen, iterate, and launch." As a consultant, he now brings working demos to first meetings instead of $20,000 six-week proposals. Clients see the product in motion and immediately identify improvements—before money changes hands. This shifts the power dynamic: products iterate toward quality before launch, not after. Peter envisions a future where we ship solid releases that iterate in quality, with interfaces that show users only what's relevant to them instead of "90,000 buttons that don't apply to me."   About Peter Swimm   Peter Swimm is a conversational AI veteran with 25+ years in tech — from managing data centers to building Botkit (the open-source chatbot framework that powered Slack and Teams bots), to serving as Principal Product Manager at Microsoft Copilot Studio. He's the founder of Toilville, a consultancy helping businesses build conversational AI solutions.   You can link with Peter Swimm on LinkedIn and visit his website at peterswimm.com.

Netflix beat on revenue and income but dropped 10%+ on weak Q2 guidance as Reed Hastings exits the board. Anthropic launches Claude Design, OpenAI overhauls Codex Desktop with computer control, and DeepSeek seeks its first outside funding at $10B+. Netflix reports Q1 revenue up 16% YoY to $12.25B, vs. $12.2B est., net income up 83% YoY to $5.28B, and forecasts Q2 EPS and revenue below est.; NFLX drops 10%+ (Bloomberg) Anthropic launches Claude Design, a new experimental product that lets users create visuals like prototypes, slides, one-pagers, and more using Claude (TechCrunch) Sources: Dario Amodei is set to meet with WH Chief of Staff Susie Wiles on Friday, a breakthrough in Anthropic's effort to resolve its fight with the Pentagon (Axios) OpenAI updates its Codex desktop app with features like computer control, an in-app browser, image generation, automation memory, plugin support, and more (ZDNet) Sources: DeepSeek is in talks to raise outside capital for the first time, seeking at least $300M at a valuation of at least $10B (The Information) Longreads India produces 1.5M+ CS graduates annually, but AI coding tools are forcing its $315B IT outsourcing industry into an existential reckoning (Bloomberg) Doug Liman's $70M movie Bitcoin: Killing Satoshi uses AI for sets, lighting, and more in post-production, cutting costs from an estimated $300M (The Wrap) Defunct startups are being liquidated for their Slack archives, Jira tickets, and email threads—operational exhaust that AI labs now treat as premium training data (Forbes) Learn more at liquid.trade/techbrew. Disclaimer: ● Initial 3 week subscription and 4 weeks of medication from $79 plus tax and $179 per month plus tax for 12 week subscription thereafter. Final pricing depends on program selection. ● Noom GLP-1Rx Program involves healthy diet, exercise and support. Individual results vary. Meds & personalization based on clinical need. Not reviewed by FDA for safety, efficacy, or quality. No affiliation with Novo Nordisk Inc., the only US source of FDA-approved semaglutide. Not available in all 50 US states ● Based on an analysis of self reported data from 1,254 engaged Noom users. Learn more about your ad choices. Visit megaphone.fm/adchoices