Chad Fowler

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

15

3 Comments

I love Rails. I've built my wealth on it. That's exactly why I think we need to have an honest conversation about its biggest blind spot. Eileen M. U. gave a brilliant talk at Rails World last year: "The Myth of the Modular Monolith." After 6 years of modularizing Shopify's monolith, she concluded: "You can't solve human and cultural problems by changing your architecture." She's right kinda of about the culture part. But stopped one step short. Rails doesn't just allow tight coupling. It incentivizes it. ActiveRecord makes every model globally accessible from anywhere. Any controller, any model, any job can reach into any table through any association chain. There's no boundary enforcement. No import restriction. No compilation step that says "this module shouldn't know about that one." When your framework makes coupling the path of least resistance, blaming developers for coupled code is like blaming water for flowing downhill. Shopify tried to fix this with Packwerk. It just give you a map not a real solution. Rails Engines? Been there, done that. They are miniature apps that provide functionality to their host applications. They don't enforce real isolation and they weren't designed for progressive extraction. But this isn't a Rails problem. It's a missing tool problem. Look at what Nx did for the Node/TypeScript ecosystem: → Module boundaries enforced at the import level, not via YAML to-do lists → Dependency graph visualization built in → Affected-only CI: only test what actually changed → Clear public API per module, everything else is private by default → A real path from monorepo module to extracted service Nx didn't replace Node. It gave Node developers the guardrails to build modular systems naturally. The right thing became the easy thing. By default. Rails deserves the same. Imagine a Rails-native tool that: • Enforces module boundaries through autoload paths, not opt-in linting • Gives each module a public API (explicit exports) while keeping internals private • Generates a live dependency graph from actual code usage, not manual YAML declarations • Runs affected-only CI based on that graph Not a replacement for Rails. A companion that makes Rails' conventions work at scale. Eileen is right: culture matters. Education matters. Leadership incentives matter. But culture alone didn't give us CI/CD. Tools did. Culture alone didn't give us code formatting standards. Linters did. Culture alone won't give us modular Rails applications. Rails gave us developer happiness for building products. Now we need the same philosophy applied to building organizations of code. The myth isn't the modular monolith. The myth is that we have the right tools for one. Who's building this? 🎥 Eileen Uchitelle — "The Myth of the Modular Monolith" (Rails World 2024) https://lnkd.in/dabvzHQm

13

I’ve come to believe that early experiences carry disproportionate weight - far more than we often acknowledge. For designers and builders, “minimum viable” may suffice for validating core functionality, but it rarely earns trust or sparks genuine delight. While velocity matters, I’ve always struggled with the notion that early versions should be merely viable, especially in a world where attention is scarce and emotional resonance is everything. This extends beyond product. Do you show up as the minimum viable version of yourself in your work, your relationships, your craft? I would encourage you to challenge the conventional MVP framework. Replace it with the Minimum Awesome Product. This doesn’t mean it’s fully-featured or pixel perfect. But it should be worthy of attention. Memorable, even evocative in the way it triggered emotion. The kind of product that prompts someone to say, “I didn’t know I needed this, but now I can’t live without it.” You can refine mechanics over time, but the emotional experience of a first interaction is singular and unrecoverable. Don’t settle for viability. Build something worth remembering… and make it awesome! ❤️‍🔥

148

26 Comments

The org chart that helped you get to 10 partnerships starts working against you at 50. Unclear ownership, reporting lines that bury the function, specialists brought in too late. Scaling a partner program requires making structural decisions that reflect where you're going, not just where you've been. On Thursday, March 26, Nelson Wang (Partner Principles), Jessica Baker(AchieveUnite), and Eleanor Thompson (Gravitee) are joining Denise Duest, MBA of HubSpot to talk through the real decisions behind building a partner team that scales:   ➡️ When to hire generalists vs. specialists ➡️ How to structure around different partner motions and how that changes as you grow ➡️ What reporting lines signal about whether your organization actually values partners Join us for a candid conversation from people who've built partner teams from startup mode through enterprise scale. Register here to attend live or get the recording:  https://lnkd.in/eFSf_g8v

39

1 Comment

Most teams don’t have a delivery problem. They have a portfolio visibility problem. Your execs ask: “Where are we on the strategic initiatives?” “Why are 12 projects red?” “What did we actually commit to this quarter?” “Why didn’t we see this risk coming?” And suddenly everyone is scrambling through: ❌ 47 Jira boards ❌ 12 spreadsheets ❌ 3 disconnected roadmaps ❌ Slides built at midnight Jira works beautifully at the team level. But when you try to use it for portfolio project management without the right structure? It becomes noise. Initiatives don’t roll up correctly. Roadmaps aren’t trusted. Dependencies are invisible. Capacity is guesswork. Leadership loses confidence in the data. And here’s the hard truth: Most Jira admins and PMs were never actually taught how to design Jira for portfolio-level thinking. They were taught tickets. Not strategy alignment. Not funding models. Not cross-program visibility. Not executive reporting architecture. That’s exactly why I’m hosting a 1-Day Portfolio Project Management Workshop right before Team ’26. This is not: 🚫 “Here’s how to create an Epic” 🚫 “Here’s what a board does” This is: ✔ How to architect hierarchy for strategic initiatives ✔ How to structure Advanced Roadmaps for true portfolio visibility ✔ How to manage cross-team dependencies without chaos ✔ How to track planned vs. unplanned work at scale ✔ How to design executive-ready dashboards people actually trust ✔ How to govern portfolio data so it doesn’t decay in 3 months If you’re: • A Jira Admin being pulled into portfolio conversations • A PM expected to report at the initiative level • A Portfolio Lead struggling with visibility • A Leader tired of “slide engineering” every quarter This workshop will change how you think about Jira. Before Team ’26. One full day. Deep dive. Practical architecture. No fluff. If you want Jira to move from “task tracker” to “strategic system of record”, sign up for our conference -> https://lnkd.in/gK8FGx96 Let’s build systems executives can actually trust.

2

To be fair, sometimes it *is* the seed. Not all seeds are going to sprout, thrive, or survive to bear fruit. But you can't control the seed, you can only control the conditions. Sometimes seeds fail to thrive because they are in a poorly fitting environment, and sometimes the environment is just poor, and no one really thrives. Wow, you can ride that analogy all kinds of distance. A culture that is direct and kind can be a great asset to a business, but it does not guarantee success. If the culture does not serve the business and help ensure its survival, the culture is not achieving its most important job.

62

13 Comments

Decision modeling is key. Intent + decision traces created by agents need to be modeled to create self learning or ever improving decision quality ( measured via outcomes), while the criteria is non stop shifting. Process modeling - aka crud on system of records will also get eroded and merged with decisions models being stored. This is where Agebt plane and human plane converge.

6

We sat down with the co-founder of a $1B tech company. He shared with us how engineering teams can leverage AI in ways no one has been thinking about. Most engineering teams aren't struggling with whether to use AI. They're struggling with how to extract real value from it. In July, we co-hosted an event with Guy Gur-Ari (co-founder, Augment Code) and Tushar Jain (CTO, Docker) to discuss what they are seeing in engineering teams. Guy pointed out that building with AI agents requires a fundamental shift in how engineers think about their craft. It's no longer about reading code, reasoning through it, refining it line by line. Working effectively with AI introduces a new skill entirely. It's about breaking problems down so intelligent systems can actually help. This shift takes time because you're rewiring decade-old habits, current workflows, and expectations. This Thursday, January 15th, we're hosting a small, off-the-record dinner for CXOs to have an honest conversation about one question I’m hearing everywhere: How are engineering teams actually getting real leverage from AI in code today? I'll be joined by Guy and Igor Ostrovsky (co-founders of Augment Code) and peers from Enrich - our private members-only network of CTOs and VPs of Engineering from companies like OpenAI, Slack, and Reddit. We'll share what's working, what's not, and how teams are adapting in practice - not theory. Comment if you're interested in joining; priority given to Enrich members.

47

4 Comments

Reading Metronome’s Monetization Operating Model, I kept coming back to one idea: pricing has become product. Software now delivers outcomes, not access. Yet most companies still charge as if they’re selling seats or licenses. That disconnect creates friction: for customers, unpredictability; for companies, stalled growth. The paper’s argument is simple but sharp—monetization isn’t a late-stage decision. It’s strategic infrastructure. Pricing needs the same ownership and iteration as any feature. Treat it like a surface that customers touch, not a spreadsheet buried in finance. If value is continuous and dynamic, pricing must be as well. That means product, GTM, finance, and engineering working from one system of truth. How many of us still treat pricing as an afterthought—when it should be a growth engine? https://lnkd.in/gnH7WzYf #Monetization #ProductStrategy #AI

8