What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

When should you start with process and architecture in a startup?That was the question that we've asked ourselves (as if there is a real-life example currently happening :-) and then we thought, “Why not ask someone who is living in this space?”Vidar co-founded his first tech startup at 19 because he didn't know enough to know how hard it would be. 30 years on, he has gone mostly from startup to startup, usually as the first technical hire or a co-founder. He has both bootstrapped and raised VC capital and recently spent 3 years working at a VC fund. He now runs a tech consultancy focusing on the intersection of DevOps and AI while working on his next big thing.In this episode of the podcast, we talk about:A startup is defined by pre-revenue or pre-profit status combined with rapid growth ambition — a chip shop is operational from day one, not a startup. Once you're profitable and growing modestly, you're a lifestyle business.Early-stage capital is the most expensive capital you'll ever spend, because you're paying in equity. The earlier you are, the larger the slice of the company you trade away for the same dollar amount.VC investors expect most of their portfolio to fail and are only looking for the 10x–100x outlier. If you can't raise your next round within about 18 months, their interest moves on — so failing fast and validating quickly is the entire game.AI has dramatically lowered the barrier to building a working prototype, letting founders show investors something tangible and compelling much faster than ever before.But the industry is swinging back hard toward upfront specs and documentation, because AI coding agents can't infer your unique business context. Writing a truly good spec turns out to be one of the hardest parts of the entire software development process — and most teams have been skimping on it for 25 years.Your truly proprietary assets are your ideas, processes, use cases, and customer segments. The generated code is a commodity — everyone building on the same AI tools has access to the same output.Lightweight processes pay off quickly once a startup begins to scale. The absence of basic QA, project management, and clearly written tickets is almost always what causes delivery to break down first — not the process itself.A common and costly mistake is over-engineering: developers building for 10 million users when the total addressable market is 10,000. This happens when engineering teams are never told what the product actually is or who it's actually for.Process and architecture function as a communication layer — aligning engineering, sales, and leadership around a shared vision, the customer they're serving, and the strategy connecting the two. It builds buy-in, and buy-in produces better work than a paycheck alone.Vision must be communicated continuously from the hiring process onward, not just stated once and assumed to stick. Developers detach from the "why" quickly when daily work becomes purely tactical.Both one-on-one check-ins and group meetings are essential to a healthy team. People rarely surface real blockers, interpersonal tensions, or technical concerns in group settings — individual conversations build the trust that makes those things visible before they become crises.Vidar can be reached on LinkedIn here and also has a website: hockstadconsultng.com.Reach out by emailing ⁠[email protected]⁠ or subscribe to our newsletter and articles on Substack at whatsyourbaseline.substack.com.

Roland and J-M go solo to pull back the curtain on something that's been years in the making: BPM OS, a purpose-built, local-first tool stack designed to help small, talented process and architecture teams stand up a real BPM practice — without the vendor dependency, IT overhead, or 12-month procurement nightmare.In this episode of the podcast we talk about: Most BPM programs fail not because of bad content, but because organizations treat it as a pure IT exercise — buy a platform, check the box, and wonder why nothing sticks.The three pillars every BPM capability needs are content, governance, and adoption — yet most organizations only address the first one.Knowledge rented from consultants or SaaS vendors disappears the moment you stop paying; BPM OS is built on the principle that you own it outright, forever.BPM OS targets three groups: small internal teams doing more with less, consulting organizations that want baked-in methodology for client delivery, and vendors looking to bundle a white-labeled practice layer with their platforms.Groundwork is the brainstorming and planning app — dump ideas onto a canvas, sort them into zones, and shift into structured planning mode with priorities and rough timelines.Playbook is a lightweight wiki for capturing structured knowledge, course profiles, stakeholder analyses, and methodology documentation — with templates so you never start from a blank page.Atlas generates visual subway maps of your learning curriculum or capability landscape, complete with time-sensitive station states, deprecation indicators, and links back to Playbook pages.Outline lets you define the detailed content structure of a course or deliverable in a hierarchical, mind-map-style view — moving from “What do we need to teach?” to "Exactly what are the chapters and items?”Course Flow is a Kanban-based project management tool for developing and iterating on courses, complete with a built-in feedback form, an inbox for triage, and a status dashboard across all active projects.Cadence is a personal (and optionally team) task planner organized by day and category — with recurring daily items, carry-forward of incomplete tasks, and a simple velocity metric to spot overload before it becomes a crisis.The entire stack runs on Node.js, saves files as Markdown and JSON (no database required), plays nicely with Google Drive or OneDrive for backup, and optionally connects to GitHub or GitLab for full version history.Apps interoperate through lightweight linking and import/export — cards from Groundwork flow into Atlas, tasks from CourseFlow export into Cadence, and every Playbook page carries a permanent link that works anywhere in the stack.Find out more and download your free personal copy of Cadence at whatsyourbaseline.com/bpm-os—and check the episode show notes for a PDF overview of all six apps.Reach out by emailing ⁠[email protected]⁠ or subscribe to our newsletter and articles on Substack at whatsyourbaseline.substack.com.

Once you've sold the licenses you are done. Right? Well, not so fast, young Jedi. While the salesperson happily turns around and goes hunting elsewhere, the customer has high expectations about the treatment they get after the sale.Even today I see organizations who treat Customer Success teams as an afterthought and then wonder why they see churn or nastygrams from their customers. But it doesn't have to be this way. We discuss this topic with Chad Stephen.Chad has led cross-functional teams of 65, scaled Customer Success orgs through 4x ARR growth, cut renewal process complexity by two thirds, and reduced time-to-value by 50% — more than once, at different companies ranging from early-stage to scaled SaaS, across industries from FinTech to HealthTech to Restaurant & Hospitality.In this episode of the podcast, we talk about:What is customer success, really? — The most important definition centers on one thing: driving value for clients. Renewals, onboarding, and account management are elements of CS, not the definition of it.The buyer vs. the end user — The person who signs the contract is rarely the one logging in every day. A good CS function speaks to both audiences and translates value into something meaningful for each.CS as a function, not just a job title — Customer success can be owned by a team, a role, or — dangerously — "everyone," which usually means no one. The discipline matters regardless of what you call it.The QBR trap — Quarterly business reviews that run 80 slides and double as sales pitches miss the point entirely. The best QBRs focus on the customer's problems, not the vendor's product roadmap.Proactive vs. reactive CS — Waiting for a customer to come to you with a problem is reactive. True proactive CS means monitoring usage metrics, NPS surveys, and engagement signals before a crisis happens.The relay race handoff — The baton cannot hit the floor between sales, professional services, and customer success. There must always be a clear, singular point of contact at every stage of the journey.When to involve CS in the sales cycle — CS should never be absent from a deal entirely, but timing matters. Bringing them in too early creates confusion; the right moment builds the bridge between "excited to sign" and "ready to succeed."The hunter vs. farmer problem — When account executives are compensated only for net-new deals, they make poor customer success managers. Misaligned incentives produce misaligned behavior.Compensation drives behavior — If you want your CS team to own renewals and upsells, you have to pay them for renewals and upsells. Comp plans and job expectations must align, or you get animosity and dropped balls.Start CS early — even at Series A — Smaller organizations often default to the AE managing the account post-sale. The sooner a dedicated CS function exists, the better. Stickiness in SaaS is decreasing, making the long-term relationship even more critical.Onboarding is the most critical phase — Getting a customer up and running quickly, with a clear understanding of the value they bought, sets the tone for the entire relationship. A poor start rarely fully recovers.Keep it simple — Over-engineered CS motions with 12 segmentation layers and elaborate playbooks often collapse under their own weight. Always ask: How does this actually drive more value for the customer?You can find Chad on LinkedIn: https://www.linkedin.com/in/chadstephen/. And he has a website at https://www.doublewindconsulting.com/.Reach out by emailing [email protected] or subscribe to our newsletter and articles on Substack at whatsyourbaseline.substack.com.

Everyone says they hate compliance. But what they actually hate is being told the truth at the worst possible moment.The problem is not the regulation. It is the moment you involve the people who understand it. Too late, under pressure, with no room to course-correct.65 to 95% of digitization projects fail. The answer is not to run them faster. It is to slow down enough to get them right — and that starts with bringing the right people in before the damage is done. So we brought in an expert: Christof Layher.Christof is a digitalization and compliance specialist with over 20 years of experience in pharma and biotech, having worked with organizations including BioNTech. He operates at the intersection of IT, quality assurance, and business operations — precisely where those functions most often work against each other. His focus is structure, decision-making clarity, and clean execution in highly regulated environments. No slide-deck transformations, no tool evangelism — just repeatable, field-tested approaches that hold up in daily operations and under audit. He also hosts the ChaosHacker podcast.In this episode we talk about:Compliance is the messenger, not the cause. Compliance teams surface uncomfortable truths that organizations already sense but choose not to address.Non-compliance is rarely intentional. In roughly 95% of cases, organizations fail compliance through blind spots, ingrained habits, and the bias that “it's been working fine.”The “superhero fixer” problem masks systemic risk. When individuals compensate for broken processes to keep things running, the underlying issue becomes invisible — until it isn't.Compliance is sometimes weaponized to block change. People hide behind regulatory language rather than engaging honestly with initiatives they don't know how to handle.Gold-plating regulations create the real slowdown. Rules often require one signature; companies implement ten. The waste comes from over-interpretation, not the regulation itself.Shift left — bring compliance in early. Involving compliance at the requirements stage costs far less than failing the checklist at the end.Compliance is a competitive advantage. Used as an indicator of where your processes diverge from reality, it becomes a continuous improvement engine.Slow is smooth, and smooth is fast. Taking time upfront — including for compliance — produces better outcomes than more failed projects delivered faster.Process owners must own compliance. The person who operates a process is responsible for running it compliantly. That shift in ownership changes everything.Trust must be given before it can be earned. Leaders who model psychological safety unlock the early, honest conversations that prevent compliance crises.One bad actor spoils the basket. Building a culture of integrity requires leaders to live it visibly — and to remove those who exploit openness, regardless of their level.Check out Christof's LinkedIn here and his podcast here!Please reach out to us by either sending an email to ⁠[email protected]⁠ or signing up for our newsletter and reading articles about process and architecture on our Substack… Go and subscribe at ⁠whatsyourbaseline.substack.com⁠.And if you like to support “the little podcast that could,” become a Patron at ⁠https://www.patreon.com/c/whatsyourbaseline⁠. We appreciate you!

“Just go and show our tool in the best way possible.”I have heard this sentence wayyyy too often coming from a salesperson, and the solution engineer on the receiving end just died a little bit inside.Of course you want to make a good impression when showing your tools to your customer, but more importantly, you want to start building a relationship and engage with them. For that you have to get them to a point where they open up and tell you what they *really* think—and a “no” is a good indicator that this relationship has formed.And we are happy to have a pro in this field as the guest of this episode: Max Lüpertz. Max is a solution engineer who took over as account executive and grew until he led the whole sales organization of the UK for one of the companies he worked for. Now he helps fast-growing SaaS companies close more deals by making their sales demos (and their general presales) better. He provides hands-on coaching and sets up a simple, repeatable demo process with his firm, PreSales Rockstars.In this episode of the podcast, we talk about: Solution engineers are too often treated as “demo monkeys”—pulled in before proper discovery has happened because AEs need to show pipeline progress. There is no solution without a problem: if you don't understand what the customer is trying to solve, any demo you run risks being irrelevant or overwhelming.Once a prospect has seen the functionality and shortlisted vendors, their mindset shifts entirely—from “Can it do this?” to “What happens to me personally if this goes wrong?” Oversharing is one of the most common and costly demo mistakes. Bombarding a prospect with features increases cognitive load, raises perceived risk, and dilutes the message. Max's lesson from an 18-month stalled deal: FOMO caused him to show 50 features when the customer only needed three. The extra complexity made the project feel like a burden, and the prospect concluded they weren't ready. The “shotgun” method—showing everything and hoping something lands—is an AE-driven trap. Effective demos need a curated storyline built around confirmed needs, not a feature parade.Discovery is not a one-time AE activity. SEs need to run a secondary, deeper discovery to uncover the personal risks and motivations of individual stakeholders—not just the organizational problem.How you introduce yourself sets the ceiling on your influence. Being framed as the “technical conscience” boxes you into a narrow role. Instead, position yourself as someone who knows the industry, has seen implementations succeed and fail, and will proactively surface the risks the customer doesn't yet know about—the things they don't know they don't know.SEs act as a “human API” between customers and product management—translating vague feature requests into actionable feedback and pushing back on requests that turn out to be aspirational rather than genuine buying signals. POCs are high-cost investments—often two people for two to four weeks—and should never be offered just because it's “the next step.” Success criteria must be defined upfront, and the SE should use the POC as a “gift and get”.The value conversation must anchor every interaction. If a customer can't explain why they want to model processes beyond “so that we have modeled processes,” they aren't ready to buy. Every conversation needs to come back to outcomes, not features. Max is also on LinkedIn—check out his profile here: https://www.linkedin.com/in/max-luepertz/.Please reach out to us by either sending an email to [email protected] or signing up for our newsletter and reading articles about process and architecture on our Substack… Go and subscribe at whatsyourbaseline.substack.com.And if you like to support “the little podcast that could,” become a Patron at https://www.patreon.com/c/whatsyourbaseline. We appreciate you!