Develpreneur: Become a Better Developer and Entrepreneur

There's a big difference between being busy and building something that lasts. Many entrepreneurs don't realize they're stuck in that gap. They're working hard, juggling responsibilities, hustling nights and weekends — but the business isn't really moving forward. In this episode of Building Better Developers, Army veteran and founder of Skillful Brands, Antwon Person, breaks down what actually creates forward momentum in a business. And it's not hype, hacks, or grinding harder. It's mindset, structure, and knowing when to leverage. The Entrepreneurial Mindset Isn't About Hustle — It's About Structure When Antwon left a 22-year military career and stepped into entrepreneurship, he brought discipline and leadership with him. What he discovered quickly, though, was that discipline alone doesn't build a company. Like many new entrepreneurs, he was busy. Very busy. But busy didn't mean structured. He realized something that most founders eventually learn the hard way: being busy in your business does not build a business. You can answer emails all day. You can tweak branding, post on social media, and chase opportunities. But without structure underneath those actions, you're just reacting — not building. That realization changed everything. Instead of chasing more tactics, he looked for clarity — and found it by connecting with someone who already had a blueprint. Momentum without structure leads to burnout. Structure without momentum leads to stagnation. The entrepreneurial mindset requires both — in the right order. Why Your First Mentor Doesn't Need to Be in Your Industry There's a common mistake new entrepreneurs make: assuming they need a mentor who does exactly what they do. Antwon disagrees — at least in the beginning. When you're building the foundation of a business, the fundamentals are universal. Every business needs clear goals, defined processes, the right mindset, and repeatable systems. At the early stage, what you need most isn't industry secrets — it's business fundamentals. He sees too many entrepreneurs jumping into advanced marketing tactics before they've validated their structure. They're polishing something that hasn't been built properly yet. It's like trying to optimize a machine that hasn't been assembled. Don't work on Phase 3 problems while you're still in Phase 1. Build proof of principle first. Everything else comes after. Once your foundation is solid and revenue is predictable, niche-specific coaching becomes powerful. But without a base, advanced tactics won't stick. The $10K Rule and the Leverage Phase One of the most practical insights from this conversation is Antwon's revenue-based approach to scaling. Up to around $10K per month, many entrepreneurs can manage operations solo — if they have structure. Beyond that point, things change. The workload compounds, communication increases, tasks multiply. Growth creates friction. That's where leverage becomes necessary. Instead of calling it "growth mode," Antwon frames it as entering the leverage phase — and that shift in language matters. Leverage means delegation, systems that support scale, clear onboarding, and defined ownership. Without it, revenue growth just creates exhaustion. With it, growth becomes sustainable. Hiring help isn't about spending money. It's about buying back focus and multiplying capacity. Why Hiring a VA Feels Hard — and How to Fix It For many entrepreneurs, hiring a virtual assistant feels overwhelming. There's hesitation: Will they understand what I need? Is it worth the cost? Will this just create more work for me? Antwon has lived through that. In the early stages, bringing on VAs felt like adding another job to his plate — confusion, repetition, miscommunication. The problem wasn't the VA. It was the lack of onboarding and structure. So he built a system. Now,...

If you've ever hit that point where you're "still functioning," but everything feels heavier—this episode is for you. In Building Better Developers, the hosts frame this season around getting unstuck and building forward momentum—even when life is busy, messy, and your energy is running low. In this conversation with Andrew Stevens, the throughline is practical: communicate early when you're behind, shrink work into achievable chunks, and put real AI guardrails in place so "helpful tooling" doesn't turn into a trust incident. Forward Momentum starts with honesty: communicate early When you're overloaded, the easiest mistake is to go silent and hope the schedule will magically work out. Andrew's advice is the opposite: you can be busy and even behind, but it has to be communicated—early and clearly—so stakeholders can react while there's still room to maneuver. This ties directly into the season's theme. Rob literally describes the season as "getting unstuck," "moving forward," and "getting out of the starting blocks." Forward momentum isn't a sprint; it's a consistent start. Forward momentum is often a communication problem before it's a productivity problem. If you're slipping, say it early—while you still have options. Small wins beat big intentions when you're overloaded One of the most useful tactics in the episode is deceptively simple: pick something small enough that you can finish it. When burnout (or just relentless busyness) sets in, big tasks become motivation killers. Breaking work into smaller, clearly finishable steps creates traction. A small win gives you proof you can still move, which is sometimes the only thing that gets you back into a productive rhythm. The hosts even joke about needing a "bigger notebook" because there are so many ideas—then explicitly connect the dots to their seasonal goal: keep the forward momentum going into the new year. If everything feels too big, shrink the scope until it's impossible to fail. One completed task restores momentum faster than ten "important" tasks you never start. AI guardrails: use AI for leverage, not liability The most grounded part of the discussion is how Andrew thinks about AI: not as magic, but as a tool that needs clear boundaries. He talks about using enterprise tools (like Gemini Enterprise) because they integrate with the systems he already works in, and because the risk profile matters when you're dealing with real work. He's also blunt about avoiding consumer/free models for anything involving real names or data. And then there's the deeper "guardrails" layer: deterministic wrappers, an AI control plane, monitoring tokens to prevent runaway spend, and protecting PII end-to-end. The stories land because they're not hypothetical—like the example of a customer accidentally creating massive costs, or how a single recording mistake can crush trust. A few practical takeaways that came through clearly: Treat AI output as fallible. Separate trust domains. Guardrails aren't "policy." They're architecture. "AI guardrails" isn't a slogan. It's a design constraint: deterministic steps where you can, visibility into cost and access, and a hard line around customer data. Forward Momentum as a career skill: tech is about people (and data) The episode doesn't stay purely tactical—it also connects forward momentum to long-term career growth. Andrew describes a common "fork in the road" for technical people: stay deeply technical (tech lead/architect), move into people leadership (SDM), or blend both in an entrepreneurial path. But the bigger point is what changed for him over time: early-career focus is "know the tech inside out," and later-career realization is "technology is all about people." That means connecting with customers, peers, and management—and understanding incentives (KPIs, value, how the business makes...

Building forward momentum isn't about moving fast. Rather, it's about moving intentionally — especially when transitioning from developer to entrepreneur. In Season 27 of the Building Better Developers podcast, we explore what it truly means to keep progressing when challenges, distractions, and new responsibilities threaten to slow you down. In this episode, Andrew Stevens — software engineer, multi-time founder, CTO, and board member — shares how building forward momentum has shaped his multi-decade journey through technology and startups. Instead of focusing on overnight success, his story emphasizes sustained curiosity, disciplined execution, and constant recalibration. Over time, momentum is built layer by layer, not in dramatic bursts. Building Forward Momentum Through Collaboration At first, Andrew's entrepreneurial journey didn't begin alone. It started with collaboration. During the early dial-up internet era, local ISPs were emerging everywhere. At that point, Andrew joined forces with two complementary partners. While he focused on writing software, one partner handled infrastructure, and another concentrated on sales and commercialization. Because each person owned a specific strength, the venture gained traction quickly. This alignment created confidence. No single individual carried the entire burden, which reduced risk and accelerated learning. Building forward momentum often begins with the right partnerships, not total independence. In other words, developers don't need to master every business function before launching something new. Clarity about strengths — and awareness of gaps — is far more powerful. Building Forward Momentum During the Engineer-to-Founder Shift Eventually, Andrew transitioned into more solo ventures. At that stage, the dynamic shifted dramatically. Coding was no longer the only priority. Sales conversations, tax planning, customer communication, and financial oversight became daily responsibilities. As complexity increased, the temptation to retreat into technical work grew stronger. Many developers stall at this point. Technical tasks feel comfortable, whereas business responsibilities feel ambiguous. Meanwhile, operational issues quietly accumulate. Andrew openly discusses early financial mistakes and process failures. Nevertheless, those moments didn't stop progress. Instead, they forced adjustments that strengthened the foundation. Building forward momentum requires correction, not perfection. Entrepreneurship rarely follows a straight line. Each misstep generates feedback, and each adjustment reinforces resilience. Building Forward Momentum with AI as Leverage Alongside structured execution, Andrew emphasizes the strategic use of AI. One approach treats AI as a tool. He leverages it for rapid prototyping, static analysis, architecture critiques, and test case generation. In addition, AI significantly shortens debugging cycles, particularly when configuration issues arise. That said, production code still demands human judgment. AI accelerates iteration, but discernment remains essential. A second perspective positions AI as a channel. Increasingly, users ask AI systems for recommendations before making purchasing decisions. Consequently, products must be structured for discoverability within AI-driven ecosystems. Unlike traditional SEO, this requires thinking about how AI systems reference and surface information. AI doesn't replace disciplined builders — it amplifies their capacity. By reducing research time and accelerating experimentation, AI expands a founder's ability to test ideas. More testing leads to stronger building forward momentum. Building Forward Momentum Through Structured Execution Rather than relying on vague annual goals, Andrew breaks execution into focused horizons: This framework creates clarity without...

Most developers believe their biggest career challenges are technical. They're usually wrong. The real blockers tend to be invisible — habits, assumptions, and internal narratives that quietly control decisions, communication, and confidence. In this episode of the Building Better Developers Podcast, we talk with coach Kim Miller-Hershon about why talented developers get stuck and how a developer mindset shift creates real forward motion. Progress doesn't start when you learn a new framework. It starts when you change how you think. About Kim Miller-Hershon Kim Miller-Hershon is an international business coach, corporate trainer, and speaker who helps leaders and entrepreneurs get unstuck by thinking differently and taking action faster. She works with executives and business owners on essential leadership skills, including communication, management, and time management—always with a focus on authenticity. Kim also hosts the Unconventional Wisdom About Conventional Wisdom podcast, where clichés are challenged, and fresh thinking takes center stage. Follow Kim on Instagram, LinkedIn, and her website. The Developer Mindset Shift Starts With Seeing Your Patterns Many career frustrations repeat themselves: the same conflicts, the same hesitation to lead, the same communication breakdowns. That's not bad luck — it's a loop. We all carry internal stories about who we are and what we're capable of. Until you recognize those stories, you unconsciously act them out again and again. The moment you notice the pattern, you gain the ability to choose differently. The Awareness Rule You can't move around an obstacle you refuse to see. Coaching isn't about digging through your past — it's about identifying the behavior you're repeating today and deciding what to do next. Forward motion starts with awareness. Changes How You View Selling Many developers avoid self-promotion because it feels dishonest or pushy. But that discomfort comes from framing it incorrectly. You may dislike selling — but you enjoy buying. Think about the last time someone helped you choose the right tool, product, or service. That interaction didn't feel manipulative. It felt helpful. That's the difference. Reframing Sales Selling isn't convincing people to want something. It's helping the right person solve the right problem. When you focus on value instead of yourself, self-promotion stops feeling uncomfortable and starts feeling professional. The Developer Mindset Shift That Fixes Communication One of the most common workplace misunderstandings looks like this: "I need you to do XYZ." "Got it." Later — ABC is delivered. Both people believe communication happened. It didn't. The fix is surprisingly simple. The Repeat-Back Technique Don't ask: Do you understand? Ask: Tell me what you heard. Until both sides say it and hear it, agreement doesn't exist — only assumptions. Clear communication is less about talking and more about confirmation. The Developer Mindset Shift From Taking Work to Choosing Work Early in a career, you accept every opportunity available. That's normal — survival requires it. Growth requires a different behavior: saying no. The wrong project, wrong role, or wrong client can stall your progress longer than having no work at all. A developer mindset shift means understanding that movement and progress are not the same thing. Career Filter The goal isn't more work. The goal is the right work. Clarity about what you do — and who you help — eventually attracts better opportunities automatically. Why a Developer Mindset Shift Beats the Overnight Success Myth Tech culture celebrates sudden success stories. A tiny idea becomes massive overnight. Those cases exist — but they are rare. Most careers grow through...

If you've ever felt stuck despite having experience, skills, and a plan, the problem usually isn't effort. Most developers and technical leaders don't stall because they're lazy or unmotivated—they stall because their beliefs, motivation, and execution are misaligned. A strong getting unstuck isn't about pushing harder. It's about creating alignment so forward momentum becomes sustainable instead of exhausting. When progress slows, people often default to adding more tools, tighter schedules, or bigger goals. But without clarity underneath, those fixes rarely stick. Real movement starts when you trust the process, understand what's driving you, and design actions that actually fit how you work. About Kim Miller-Hershon Kim Miller-Hershon is an international business coach, corporate trainer, and speaker who helps leaders and entrepreneurs get unstuck by thinking differently and taking action faster. She works with executives and business owners on essential leadership skills, including communication, management, and time management—always with a focus on authenticity. Kim also hosts the Unconventional Wisdom About Conventional Wisdom podcast, where clichés are challenged, and fresh thinking takes center stage. Follow Kim on Instagram, LinkedIn, and her website. Getting unstuck starts with trust and clarity Before any plan can work, trust has to exist—trust in the process, trust in support systems, and trust in your ability to navigate discomfort. Growth almost always involves friction. If everything feels comfortable, you're probably not changing anything meaningful. A healthy getting unstuck doesn't avoid discomfort; it reframes it. Feeling uneasy doesn't mean you're failing—it often means you're stretching. That shift alone can prevent the avoidance and second-guessing that quietly derail progress. Just as important is clarity. Vague intentions create fragile momentum. When goals are fuzzy, decisions become reactive instead of intentional, and it's easy to drift back into familiar patterns. Getting unstuck requires a "juicy why." Motivation doesn't come from ambition alone. It comes from having a reason that's compelling enough to carry you through the parts of the work you don't enjoy. Your "why" needs to be clear, personal, and vivid—not aspirational fluff. Getting unstuck depends on this kind of clarity. When your reason for moving forward is strong, you don't need constant external motivation. You have something internal to anchor to when energy dips or obstacles show up. The "Juicy Why" Check Getting unstuck fails when plans ignore behavior Many solid plans fail because they assume ideal behavior. They don't account for procrastination, avoidance, or the realities of working with other people. A perfect strategy that ignores how you actually operate won't survive contact with deadlines and dependencies. A practical getting unstuck adapts plans to real behavior. That means designing systems that work even when motivation drops, interruptions happen, or other people don't deliver on time. Progress comes from plans that flex—not plans that look good on paper. Getting unstuck when scaling your role One of the hardest moments in growth happens when success requires letting go of work you're good at—or even love doing. For developers and technical leaders, staying close to execution feels productive, but it can quietly cap growth. Getting unstuck recognizes that scaling isn't about abandoning strengths. It's about repositioning them so others can step in, teams can grow, and the organization isn't dependent on a single person. Letting go isn't failure—it's evolution. Getting unstuck depends on psychological safety Momentum collapses when mistakes feel personal. Progress accelerates when mistakes are treated as information. Getting unstuck replaces self-judgment with curiosity. Instead...

Measuring AI marketing ROI has become one of the most uncomfortable conversations in tech and marketing teams. Everyone knows AI is "important." Fewer teams can explain what success actually looks like. Even fewer can tie adoption to real outcomes rather than experimentation for its own sake. For developers and technical leaders, this isn't a tooling problem — it's a decision-making problem. The teams that win are the ones that slow down just enough to define value before they ship. About Meeky Hwang Meeky Hwang's journey resonates with entrepreneurs, technical leaders, and anyone navigating the intersection of technology and business. As CEO and Co-Founder of Ndevr, a digital solutions development agency, Meeky brings over 20 years of experience building resilient, scalable platforms for organizations including Johnson & Johnson, Pfizer, Forbes, PMC, and Bloomberg. Her work goes beyond website development—she focuses on long-term digital solutions that improve performance, streamline workflows, and align technology with business strategy. Equally important is Meeky's perspective as a woman leading in a male-dominated industry. She has navigated the challenges of technical leadership, entrepreneurship, and scaling a services business while building credibility and strong teams along the way. Her experience offers an honest look at what it takes to grow as a leader without losing sight of innovation, people, or purpose. Follow on LinkedIn and her Website. Measuring AI marketing ROI when the hype is louder than the data AI adoption today often starts with pressure instead of purpose. Tools arrive before goals. Budgets get approved before success criteria exist. That's the first red flag. If you can't articulate what improvement AI is supposed to create — conversion lift, content velocity, operational savings, personalization accuracy — you're not measuring ROI. You're chasing momentum. Measuring AI marketing ROI by defining outcomes before tools The most effective teams reverse the typical process. They define outcomes first, then ask which capabilities might support those outcomes. That discipline alone filters out most bad investments. Before selecting tools, answer three questions: If those answers feel vague, that's your signal to pause. Measuring AI marketing ROI with clear baselines and success metrics ROI requires comparison. Without a baseline, every result looks impressive — or disappointing — depending on expectations. Establish: This turns AI from a belief system into an experiment with guardrails. Measuring AI marketing ROI without wasting budget on "maybe" features Not every feature deserves implementation just because it exists. Time and money are always the real constraints. Teams that succeed evaluate AI features the same way they evaluate architecture decisions: cost, risk, effort, and impact. When those tradeoffs are visible, priorities clarify quickly. Measuring AI marketing ROI while Google, SEO, and platforms keep shifting AI doesn't exist in isolation. SEO changes, platform updates, and algorithm shifts constantly reshape the playing field. That makes flexibility more valuable than novelty. Incremental improvements that survive change often outperform bold implementations that lock teams into fragile solutions. Measuring AI marketing ROI alongside compliance requirements and regional rules Global websites introduce real constraints — privacy, consent, accessibility, and regulatory differences. AI features that ignore compliance increase risk faster than they increase value. Measuring AI marketing ROI with a repeatable compliance checklist A checklist-driven approach ensures new features don't break trust or regulation: This protects ROI by preventing costly rework. Measuring AI marketing...

The Developer to CEO transition rarely starts with a bold declaration like, "I'm going to run a company." More often, it begins quietly—by taking on one more responsibility, saying yes to a new opportunity, or stepping into a role that stretches just a little beyond your comfort zone. In this episode of the Building Better Developers podcast, part of our Forward Momentum season, we talk with Meeky Hwang about how that transition unfolds in real life. Her path—from developer to agency founder and CEO—reflects a pattern many experienced engineers recognize only in hindsight. Over time, those small decisions add up. You stop thinking only about code and start thinking about people, clients, sustainability, and direction. At some point, you realize you're no longer just building software—you're building a business. About Meeky Hwang Meeky Hwang's journey resonates with entrepreneurs, technical leaders, and anyone navigating the intersection of technology and business. As CEO and Co-Founder of Ndevr, a digital solutions development agency, Meeky brings over 20 years of experience building resilient, scalable platforms for organizations including Johnson & Johnson, Pfizer, Forbes, PMC, and Bloomberg. Her work goes beyond website development—she focuses on long-term digital solutions that improve performance, streamline workflows, and align technology with business strategy. Equally important is Meeky's perspective as a woman leading in a male-dominated industry. She has navigated the challenges of technical leadership, entrepreneurship, and scaling a services business while building credibility and strong teams along the way. Her experience offers an honest look at what it takes to grow as a leader without losing sight of innovation, people, or purpose. Follow on LinkedIn and her Website. Developer to CEO transition starts with "accidental" opportunities For many engineers, this transition begins almost by accident. A consulting role exposes you to different industries. A startup forces you to wear multiple hats. An agency environment teaches you how delivery, relationships, and trust intersect. None of these roles comes with a "future CEO" label. But they do build instincts—how to prioritize, how to adapt, and how to make tradeoffs when perfect solutions aren't possible. Those instincts matter far more than a perfectly mapped career plan. Developer to CEO transition lessons from consulting, startups, and agencies Each environment contributes something different to the Developer to CEO transition. Consulting sharpens communication and expectation-setting. Startups teach ownership and resilience. Agencies reveal what it takes to scale work without burning people out. Individually, these roles can feel chaotic. Together, they form a foundation that prepares developers for leadership long before they realize that's where they're headed. Developer to CEO transition and the mindset shift to full responsibility There's a moment in the transition when responsibility feels heavier. Decisions don't stop at your team or your sprint—they ripple outward. Hiring, pricing, client relationships, and long-term viability all land on your plate. Problems are no longer theoretical. They're personal. This shift changes how leaders think. It forces clarity, prioritization, and the ability to move forward without perfect information. Developer to CEO transition accelerators: mastermind and founder groups One of the most impactful accelerators in the Developer to CEO transition is joining founder communities earlier than you think you need them. Mastermind ROI for New Owners Founder groups shorten the learning curve by replacing isolation with shared experience. Instead of guessing, you learn from people who've already been there. Developer to CEO transition accountability: learning faster...

Regaining clarity at work is one of the biggest challenges developers face as responsibilities grow, distractions multiply, and expectations rise. Burnout rarely appears overnight. More often, it creeps in quietly—through constant context switching, mental fatigue, and the feeling that you're busy all day but not making real progress. For developers and technical leaders, clarity isn't a "nice to have." It's what allows you to make good decisions, focus deeply, and enjoy the work you're doing. Without it, even small tasks feel heavier than they should. About Andrew Hinkelman Andrew Hinkelman is a certified executive coach and former Chief Technology Officer who works with tech founders, CTOs, and engineering leaders to strengthen their leadership and people skills. With over 25 years of corporate experience, including 8 years as a CTO, Andrew understands firsthand the pressures technical leaders face as they move from hands-on execution to leading teams and organizations. His coaching focuses on helping leaders build trust, develop others, and stay strategic as responsibilities grow. Andrew's philosophy is simple: all professional development is personal improvement. After experiencing burnout in his own leadership journey—constantly stepping in to fix problems and being needed by everyone—he learned the value of trusting his team instead of controlling outcomes. Today, Andrew helps leaders avoid that same trap by building resilient teams, focusing on relationships, and creating environments where others can succeed. Follow Andrew on Instagram and LinkedIn. Why Regaining Clarity at Work Matters for Developers When regaining clarity at work starts to slip, the symptoms are subtle at first. Decisions take longer. You second-guess yourself more often. Work that once felt engaging starts to feel draining. This isn't a motivation problem. It's a clarity problem. Developers often push through this phase by working longer hours, assuming effort will fix it. In reality, the lack of clarity compounds the problem—leading to frustration, reduced quality, and eventually burnout. How Distractions Undermine Regaining Clarity at Work Modern work environments make regaining clarity at work especially difficult. Messages, emails, meetings, and notifications constantly pull attention away from focused thinking. Even well-intentioned tools can fragment your day into shallow work. The issue isn't that developers aren't capable of focus—it's that focus is constantly interrupted. Over time, this makes it harder to think clearly, prioritize effectively, or feel confident in decisions. The result is mental overload, not progress. Regaining Clarity at Work Through Better Daily Habits One of the most practical ways to regain clarity at work is by examining daily habits. Not in a rigid or extreme way, but by noticing patterns. What creates a good day? What leaves you feeling depleted? Sleep, movement, downtime, and boundaries play a much larger role in clarity than most developers expect. Clarity isn't created in moments of intensity—it's supported by consistency. Self-Discipline as a Foundation for Regaining Clarity at Work Self-discipline is often misunderstood as pushing harder. In reality, it's about protecting the habits that keep your energy stable. Waiting for weekends or vacations to reset burnout doesn't work if every weekday drains you. Regaining clarity at work means building routines that prevent depletion before it happens. Regaining Clarity at Work by Trusting Yourself When developers feel stuck, the instinct is often to search for more input—another article, another video, another framework. But more information rarely creates clarity. In many situations, you already know how to handle the challenge in front of you. Learning to pause, quiet your mind, and trust your experience can be...

For many developers and engineering leaders, executive coaching feels like something you turn to only when things go wrong. We're trained to solve problems, push through obstacles, and rely on our own expertise. So when progress slows, the default reaction is often to work harder—not to step back and reassess. That's exactly why executive coaching can be so valuable when used intentionally. At its best, coaching isn't about fixing weaknesses. It's about uncovering blind spots, challenging assumptions, and helping capable leaders see where their habits are limiting growth. When the fit is right, coaching brings clarity and momentum. When it's wrong, it simply adds noise. About Andrew Hinkelman Andrew Hinkelman is a certified executive coach and former Chief Technology Officer who works with tech founders, CTOs, and engineering leaders to strengthen their leadership and people skills. With over 25 years of corporate experience, including 8 years as a CTO, Andrew understands firsthand the pressures technical leaders face as they move from hands-on execution to leading teams and organizations. His coaching focuses on helping leaders build trust, develop others, and stay strategic as responsibilities grow. Andrew's philosophy is simple: all professional development is personal improvement. After experiencing burnout in his own leadership journey—constantly stepping in to fix problems and being needed by everyone—he learned the value of trusting his team instead of controlling outcomes. Today, Andrew helps leaders avoid that same trap by building resilient teams, focusing on relationships, and creating environments where others can succeed. Follow Andrew on Instagram and LinkedIn. What executive coaching actually does Leadership coaching is frequently misunderstood, especially in technical environments. It's not mentoring, consulting, or performance management. Rather than providing answers, a coach helps leaders examine how they think, make decisions, and show up—particularly under pressure. This kind of perspective is difficult to gain from inside your own day-to-day context. For technical leaders, this distinction matters. Many engineers advance by being exceptional problem solvers. Over time, that strength can become a constraint. Coaching helps leaders recognize when execution, control, or perfectionism starts to limit influence, trust, and scale. At its core, this work builds awareness—and awareness is what enables meaningful change. When executive coaching is the right move Coaching isn't necessary at every stage of a career. If progress feels steady and challenges are manageable, it may not add much value. However, it becomes especially useful during moments of transition or tension, such as: These moments often signal that your environment has changed—but your operating model hasn't. A strong coaching relationship helps leaders adapt intentionally instead of reacting out of habit. Executive coaching for leaders in new roles New leadership roles come with unspoken expectations. Success is no longer defined purely by output, and feedback becomes less direct or less frequent. Many leaders assume they need to "get everything under control" before working with a coach. In reality, coaching is most effective when things still feel unclear. That uncertainty highlights where growth is needed—whether in communication, prioritization, delegation, or decision-making at scale. You don't need to show up polished. You need to show up honestly. What a real coaching engagement looks like One common misconception is that leadership coaching is a one-time conversation or a motivational reset. In practice, effective coaching is an ongoing engagement built around clarity, feedback, and behavior change over time. It starts with defining what success actually looks like—not in abstract terms,...

If you've ever shipped fast only to realize no one wanted what you built, you've felt the tension behind balancing building and feedback. As developers, we're trained to execute against known requirements. As soon as you step into product ownership, consulting, or entrepreneurship, those guardrails disappear. Now you have to decide what to build, who it's for, and why it matters—while still making forward progress. Get it wrong, and you either drown in feedback or disappear into code. Get it right, and you create steady momentum without wasting effort. This interview continues our discussion with Tyler Dane as we break down a practical, repeatable system for balancing building and feedback so you can keep shipping and stay aligned with real customer needs. About Tyler Dane Tyler Dane has dedicated his career to helping people better manage—and truly appreciate—their time. After working as a full-time Software Engineer, Tyler recently stepped away from traditional employment to focus entirely on building Compass Calendar, a productivity app designed to help everyday users visualize and plan their day more intentionally. The tool is built from firsthand experience, not theory—shaped by years of experimenting with productivity systems, tools, and workflows. In a bold reset, Tyler sold most of his belongings and relocated to San Francisco to focus on growing the product, collaborating with partners, and pushing Compass forward. Outside of coding, Tyler creates YouTube videos and writes about time management and productivity. After consuming countless productivity books, tools, and frameworks, he realized a common trap: doing more without actually accomplishing what matters. That insight led him to break productivity down into its most practical, nuanced components—cutting through hustle culture noise to focus on systems that actually work. Tyler is unapologetically honest and independent. With no investors, no sponsors, and nothing to sell beyond the value of his work, his focus is simple: help people get more done—and appreciate the limited time they have to do it. Follow Tyler on LinkedIn, YouTube, and X. Balancing building and feedback starts with a clear v1 The biggest cause of wasted effort isn't bad code—it's unclear scope. A clear v1 isn't a long feature list; it's a decision about which problem you are solving first. When v1 is defined, feedback becomes directional instead of distracting. You can evaluate every request with a simple question: Does this help solve the v1 problem? If the answer is no, it goes into a parking lot—not the backlog. Without that clarity, every conversation feels urgent, and every idea feels equally important. Balancing building and feedback by timeboxing your week Unstructured time leads to extremes. One week becomes all coding. The next becomes all conversations. Neither works for long. Timeboxing forces balance by design. Decide when you build and when you listen—and protect those blocks like production systems. This removes decision fatigue and prevents emotional swings based on the latest conversation. The Weekly Balance Blueprint Consistency matters more than perfection. Balancing building and feedback with daily "business refocus" blocks Short check-ins keep you out of the weeds. Spend 10–15 minutes at the start and end of your day to reconnect with the business context. Ask yourself: These moments prevent scope creep and help you code with intent instead of habit. Balancing building and feedback using personal sprints Personal sprints introduce rhythm. Two- or three-week cycles work well because they're long enough to produce meaningful output and short enough to adjust course. Each sprint should include: This keeps learning and execution tightly coupled, rather than competing for attention. Balancing...

Customer feedback for developers is one of the fastest ways to improve a product—and one of the easiest ways to derail it. When you're building something you care about, every comment feels important. The challenge is learning how to listen without letting feedback pull you in ten different directions. This episode explores how developers can use customer feedback to sharpen focus, avoid scope creep, and move faster—without losing the original vision that made the product worth building in the first place. About Tyler Dane Tyler Dane has dedicated his career to helping people better manage—and truly appreciate—their time. After working as a full-time Software Engineer, Tyler recently stepped away from traditional employment to focus entirely on building Compass Calendar, a productivity app designed to help everyday users visualize and plan their day more intentionally. The tool is built from firsthand experience, not theory—shaped by years of experimenting with productivity systems, tools, and workflows. In a bold reset, Tyler sold most of his belongings and relocated to San Francisco to focus on growing the product, collaborating with partners, and pushing Compass forward. Outside of coding, Tyler creates YouTube videos and writes about time management and productivity. After consuming countless productivity books, tools, and frameworks, he realized a common trap: doing more without actually accomplishing what matters. That insight led him to break productivity down into its most practical, nuanced components—cutting through hustle culture noise to focus on systems that actually work. Tyler is unapologetically honest and independent. With no investors, no sponsors, and nothing to sell beyond the value of his work, his focus is simple: help people get more done—and appreciate the limited time they have to do it. Follow Tyler on LinkedIn, YouTube, and X. Customer feedback for developers: Why "this is great, but…" matters Most useful feedback doesn't sound negative at first. It usually starts with, "This is great, but…" That "but" is where the signal lives. For developers, the mistake isn't ignoring feedback—it's stopping at the compliment. The real value is understanding what's missing, confusing, or blocking progress. Teams that grow fastest learn to treat that follow-up as actionable data, not criticism. The "This Is Great, But…" Checklist Customer feedback for developers: how to find the right people to talk to Not all feedback is equal. Talking to the wrong audience can send you down expensive paths that don't actually improve your product. Customer feedback for developers works best when it comes from people who: Broad feedback feels productive but often leads to vague changes. Focused conversations lead to clarity. Customer feedback for developers: filtering input to prevent scope creep Scope creep rarely starts with bad intent. It starts with trying to please everyone. The fix isn't saying "no" to customers—it's filtering feedback through a clear lens: Avoid Scope Creep Without Ignoring Customers Customer feedback for developers: balancing vision with real user needs Strong products sit at the intersection of vision and reality. If you only follow feedback, you become reactive. If you ignore it, you risk building in isolation. Customer feedback for developers should challenge assumptions—not erase direction. The goal is refinement, not reinvention, with every conversation. Customer feedback for developers: building momentum with faster shipping One consistent theme is speed. Slow feedback loops kill momentum. Shipping faster—even in small increments—creates learning. Fast cycles: Build Momentum With Speed and Structure Customer feedback for developers: choosing a niche in a crowded market General...

If you've ever felt like you're busy but not progressing, you're not alone. The fix usually isn't a bigger plan—it's daily forward momentum. This episode kicks off a full season dedicated to getting unstuck by building a repeatable, low-friction way to move closer to your goals without burning out. The key shift: you're rarely "stuck." More often, you've plateaued—and plateaus are solvable with small, consistent action and smarter focus. Why Daily forward momentum matters Momentum is the difference between "I'm thinking about it" and "I'm shipping it." For developers and engineering leaders, it's easy to confuse activity with progress: meetings, tickets, firefighting, context switching, and endless "urgent" tasks. Daily forward momentum is how you reclaim control. It creates a stable rhythm that survives busy weeks and keeps your goals alive even when your calendar doesn't cooperate. Daily forward momentum starts by reframing "stuck" as a plateau "Stuck" can feel like a personal failure. A plateau is just a stage. You've grown, you've learned, you've pushed forward—and now the same tactics aren't producing the same results. That's normal in engineering careers, product development, and business growth. The point isn't to force the old approach harder. The point is to adjust. When you reframe stuck as a plateau, you stop spiraling and start experimenting. Daily forward momentum vs. repeating the same approach A plateau often comes from running the same playbook and expecting a different outcome. The move here is not "work more." It works differently. Try swapping: Daily forward momentum helps you test new approaches safely. You're not betting the week on a giant change. You're placing small, consistent bets that compound. Daily forward momentum and the "work in vs work on" trap This is the trap most technical leaders know too well: you can spend all your time building, coding, and delivering… and still feel like nothing is improving. Working in the work keeps things running. Working on the system—process, automation, positioning, strategy—keeps things growing. If you're a developer-founder or a tech lead, this matters because the "on" work is rarely urgent. It's just important. Daily forward momentum makes the important work non-negotiable without making it overwhelming. Keep your focus narrow Daily forward momentum in 15 minutes a day The most practical idea in this episode is almost boring—which is why it works: 15 minutes a day. This isn't a productivity hack. It's a commitment device. You're proving to yourself that forward motion can happen even on messy days. A good 15-minute target looks like: Daily forward momentum in 15 minutes Daily forward momentum through automation and time reclaimed One of the fastest ways to build momentum is to reclaim time. Automations—big or small—can turn recurring hour-long chores into quick workflows. That time savings becomes fuel. You reinvest it into the next constraint, the next improvement, the next deliverable. That's how momentum starts to snowball: less drag, more throughput, more clarity. Daily forward momentum challenge: pick one task for the week This episode brings back a challenge format that's simple and actionable: one Callout: The Weekly Focus Challenge Daily forward momentum rules: keep your focus narrow (1–2 items) If you're new to this, don't juggle seven initiatives. Start with one. If you've got a big backlog of half-finished ideas, cap yourself at two. The goal is visible progress. When you can point to real movement, motivation stops being fragile. Daily forward momentum becomes your default operating system. Final Thoughts If you want more progress without more pressure, commit to daily forward momentum this week. Pick...

Building better foundations isn't about chasing the newest framework, tool, or trend. Instead, it's about reinforcing the fundamentals that consistently support good software, healthy teams, and sustainable businesses. This episode closes out the Building Better Foundations series by stepping back and asking a practical question: are we still doing the things that matter most? Foundations rarely feel urgent. Because they're repetitive and often invisible, they're easy to deprioritize when deadlines tighten. However, when quality drops, focus slips, or growth stalls, the root cause is almost always the same—the foundations weren't maintained. Why Building Better Foundations Start With "Why" At the core of every strong foundation is clarity. Why does this work matter? Why does this business exist? Why are you building this product at all? Without clear answers, priorities blur and effort becomes reactive. As a result, teams stay busy without making meaningful progress. Re-centering on purpose provides a filter for decisions, helping teams choose what not to do just as much as what to pursue. The same principle applies to software and business. When purpose is clear, design decisions improve, roadmaps stabilize, and trade-offs become easier to justify. Building Better Foundations and Process Before Tools Tools are tempting—especially automation and AI. However, tools don't fix broken processes; they amplify them. If the underlying workflow is unclear or inefficient, adding technology only creates faster chaos. For that reason, building better foundations requires understanding the process first and then deciding where tools truly add value. This approach helps teams avoid constant tool churn and keeps attention focused on outcomes rather than novelty. Process Before Automation Building Better Foundations in Daily Developer Work Foundations show up in everyday habits. For example, designing before coding, writing meaningful comments, and committing code with intent all contribute to long-term stability. Although these practices may feel optional under pressure, they're what make systems maintainable and resilient. Skipping them might save minutes today, but it usually costs hours later. Over time, consistency in these habits separates fragile codebases from durable ones. Building Better Foundations for Business Growth For independent developers, consultants, and leaders, building better foundations also means working on the business—not just in it. While billable work feels productive, it doesn't scale by itself. Sustainable growth requires time spent on branding, marketing, process improvement, and planning. Although this work is often non-billable, it directly supports future stability. Working On vs. In the Business Building Better Foundations and Focused Execution Distraction is one of the biggest threats to strong foundations. New ideas, side projects, and constant context switching quietly erode momentum. Focused execution means regularly checking whether current work aligns with real priorities. Short work cycles, clear goals, and intentional pauses help prevent drift and keep effort aligned. Foundation Checkpoint Using AI to Strengthen Building Better Foundations AI can be a powerful accelerator when used intentionally. In practice, the most effective use cases target repetitive, low-value work and free up time for higher-impact thinking. Used thoughtfully, AI reinforces better foundations by supporting focus and experimentation. On the other hand, used carelessly, it becomes just another source of noise. Resetting Your Year With Building Better Foundations As this series wraps up, the takeaway is straightforward: revisit your foundations. Write down your goals. Clarify your priorities. Then build a roadmap and commit to...

If you're building software in the AI era, speed is everywhere—and that's exactly why discipline matters more than ever. In Part 2 of our interview with Angelo Zanetti, one strategy keeps coming up as the smartest path for founders and product teams: go web first. You validate demand faster, avoid app-store friction, and you get a clearer signal before you spend real money on the mobile "tax." About Angelo Zanetti Angelo Zanetti is the co-founder and CEO of Elemental, a South African-based software development agency helping startups and scaleups worldwide bring digital products to life. Since 2005, his team has specialized in building scalable, high-performance web apps and software platforms that solve complex business problems. With deep technical knowledge and strategic thinking, Angelo has helped founders launch bespoke software products that are lean, user-focused, and future-ready. He's served on boards including BISA and Entrepreneurs' Organisation Cape Town, and he's a proud member of the global founder community OPUS. Go web first in the AI era AI is changing how teams build, but it doesn't change what makes a product succeed. Angelo's take is balanced: AI can absolutely make developers faster—but it can also make mistakes bigger if you don't have the experience to catch what's wrong. He shares a story that captures the risk perfectly: a developer using Cursor accidentally had the database dropped and recreated. The tool didn't intend harm—it simply took a destructive shortcut with confidence. Go web first and use AI like an amplifier. In the hands of an experienced developer, AI accelerates delivery. In the hands of someone guessing, it accelerates failure. Go web first when you're still validating demand If the goal is traction, the fastest route is often not a mobile app. Angelo points out that mobile adds overhead: submissions take time, changes can slow down release cycles, and testing requires compiles plus device/emulator workflows that can drag early iterations. When you go web first, you can ship faster, adjust faster, and learn faster. That matters when you're still figuring out what users actually value. Avoid app-store friction App stores introduce delays and rules. Even when you do everything right, you're waiting on review cycles and dealing with policies that can change. By starting on the web, you keep your feedback loop tight and your roadmap in your control. Shorten the feedback loop This is the hidden advantage: going web first makes iteration feel like steering instead of guessing. You can test onboarding, pricing pages, feature positioning, and workflows in days—not weeks—then respond to what real users do, not what you hope they do. Go web first, but use AI safely AI doesn't remove the need for senior judgment. Angelo's point is that experienced developers still matter because the hard part is translation—turning vision into structure, edge cases, and maintainable architecture. AI can accelerate progress—go web first with guardrails Go web first and set guardrails early: backups, version control, review practices, and clear boundaries for what AI can touch. Tools can generate code quickly, but your team still owns security, data safety, and reliability. Mistakes are cheaper to fix When you're validating, mistakes are inevitable. The goal is to make them inexpensive. A web-first approach keeps the cost of change lower, so you don't "lock in" bad assumptions behind a costly mobile release cycle. Go web first by planning like an architect Angelo uses a metaphor that founders immediately get: building software is like building a house—you don't start by putting up walls. You start with an architect. Planning is a real deliverable: scope, user journeys, exceptions, and specifications. It's often undervalued because it's not as tangible as code, but Angelo calls...

If you're building a new app or software product, your biggest risk usually isn't "bad code." It's building the wrong thing, shipping it with a shaky first impression, and then wondering why growth never shows up. In this episode of Building Better Developers, Angelo Zanetti breaks it down into a simple founder goal: prove your MVP—prove the problem is real, prove the solution is worth paying for, and prove you can deliver value without burning your runway. About Angelo Zanetti Angelo Zanetti is the co-founder and CEO of Elemental, a South African-based software development agency helping startups and scaleups worldwide bring digital products to life. Since 2005, his team has specialized in building scalable, high-performance web apps and software platforms. Angelo blends deep technical knowledge with strategic thinking, helping founders launch bespoke products that are lean, user-focused, and built for long-term value. He's also served on several boards (including BISA and Entrepreneurs' Organisation Cape Town) and is a proud member of the global founder community OPUS. Prove your MVP by solving a real problem Angelo's first checkpoint is direct: product-market fit is about whether you're solving a real pain—or building for a problem that "doesn't really exist." That's the trap founders fall into when the plan is "we'll launch, and the floodgates will open." In reality, traction comes from specificity: a specific user, a specific workflow, and a specific outcome that's better than the alternatives. If you can't describe your user's pain in one sentence, you're not ready to build features—you're ready to refine the problem. Keeping it simple To prove your MVP, you need a version you can ship and learn from. Angelo's advice: keep it MVP—keep it simple—make launch as easy as possible. This is where founders accidentally turn "minimal" into "massive." They stack features, add edge cases, and delay learning. A better approach is to ship the smallest version that delivers one clear win. A practical filter: directly Prove your MVP with a clean, bug-free first impression One of Angelo's strongest warnings: don't treat users like beta testers. He's not a fan of launching "full of bugs" and fixing things live, because you only get one chance at a strong first impression. That matters even more early on, when your users are deciding whether to trust you with their time, money, or data. Bugs don't just hurt quality—they kill momentum. A messy first experience can "blow your chances" to wow users. Market before development This is the founder's lesson that never feels "technical," but decides everything: marketing starts before you build. Angelo calls out the pattern he's seen repeatedly—founders who plan customer acquisition do well, and those who assume "launch to the world" will magically work usually don't. Marketing early doesn't mean ads on day one. It means clarity: Prove your MVP safely in the AI era AI tools can help you move faster—but they can also help you move faster into danger. Angelo raises a big concern: "vibe-coded" apps can become a playground for hackers, where API keys get exposed, and security gaps get exploited—especially when a non-technical founder doesn't know what to look for. He also frames planning with a great metaphor: building software is like building a house—you start with an architect. Scoping, specifications, and user journeys are often undervalued because they're not "tangible," but they're key to long-term success and scaling. Speed is great. But speed without planning and security is how you "prove" the wrong thing—painfully. Closing thoughts If you want to prove your MVP, don't chase perfection—and don't chase feature bloat either. Solve a real problem, keep it minimal, launch with quality, and start marketing earlier than feels...

Tiered pricing is becoming the simplest way to sell AI-powered SaaS without turning your pricing page into a technical explanation. In my interview with Dan Balcauski, founder and Chief Pricing Officer at Product Tranquility, we talked about why AI is forcing new pricing decisions earlier than ever—and why "good, better, best" packaging often works because it keeps buying decisions clear while helping companies manage real AI costs. The AI era is making pricing margin-aware again. Tiered pricing helps you protect margins without forcing buyers to learn your cost structure. About Dan Balcauski Dan Balcauski is the founder and Chief Pricing Officer at Product Tranquility, where he helps high-volume B2B SaaS CEOs define pricing and packaging for new products. He is a TopTal certified Top 3% Product Management Professional and helps teach Kellogg Executive Education course on Product Strategy. Over the last 15 years, Dan has managed products across the full lifecycle—from concept incubation to launch, platform transitions, maintenance, and end of life—across consumer and B2B companies ranging from startups to publicly traded enterprises. He previously served as Head of Product at LawnStarter and was a Principal Product Strategist at SolarWinds. Why Tiered Pricing Is Winning in the AI Era For years, SaaS companies could price mostly around value because marginal costs were relatively stable. AI changes the math. Dan points out that companies are now cutting meaningful monthly checks to model providers, and leadership teams can't pretend cost-to-serve is irrelevant anymore. That's a big reason tiered pricing is showing up everywhere right now. It gives teams a way to: and Most importantly, tiered pricing keeps you out of the weeds. The customer conversation stays focused on outcomes, not infrastructure. What Makes Tiered Pricing Actually Work Dan's point isn't "just shove AI into the top tier." Tiered pricing works when plan differences are easy to understand and tied to value drivers customers already recognize. Here are three practical patterns from the discussion that hold up well in the AI era. 1) Put AI in higher tiers when it boosts a user's output If an AI feature makes a person more effective—faster drafting, better triage, higher quality responses—tiering can be straightforward. The buyer already understands why a "Better" or "Best" plan costs more: it changes the capability of the team. This is also why seat-based pricing can still make sense for many AI-enhanced tools. If the value driver is still "help my team do better work," then users/seats remain an intuitive anchor. If AI increases team productivity, tiered pricing can stay aligned to seats—because seats still map to value. 2) Use add-ons when AI changes the value driver Sometimes AI doesn't just "help" the user—it replaces work entirely. When that happens, forcing it into the same tier structure can distort value and create confusion. Dan points to Intercom as a strong example of handling this well: per-resolution 3) Don't make buyers learn token math Dan's strongest warning is about token pricing. Customers don't want to learn what tokens are, and sales teams don't want to explain them—especially when you're selling a business outcome like faster support or better customer experience. Token-based pricing also shifts the conversation away from value and toward your vendor bill. As Dan puts it, customers don't care about your infrastructure costs, and pushing that complexity into the buying motion adds friction. If your tiered pricing requires a footnote explaining tokens, you're adding sand in the gears. A Tiered Pricing Checklist for AI Features Here's a simple way to apply this immediately: Good: Better: Best: Add-on: Stay Connected: Join the Developreneur Community We invite you to...

Minimal viable pricing is the fastest way to stop debating what your product should cost and start learning what customers will actually pay for. In my interview with Dan Balcauski, founder and Chief Pricing Officer at Product Tranquility, we talked about how early-stage teams can set pricing that's "good enough" to sell, validate value, and iterate—without getting stuck chasing the perfect number. Pricing can feel risky because it shapes perception, positioning, and revenue. But Dan's message is practical: you don't need perfect pricing to move forward—you need minimal viable pricing that creates clear decisions and real feedback loops. Minimal viable pricing isn't "cheap pricing." It's "clear pricing" that helps you test value and drive decisions. About Dan Balcauski Dan Balcauski is the founder and Chief Pricing Officer at Product Tranquility, where he helps high-volume B2B SaaS CEOs define pricing and packaging for new products. A TopTal-certified Top 3% Product Management Professional, Dan also teaches in Kellogg Executive Education's Product Strategy coursework. Over the last 15 years, he has led products across the full lifecycle—from concept incubation to launch, platform transitions, maintenance, and end-of-life—across both consumer and B2B markets. Before Product Tranquility, he served as Head of Product at LawnStarter and as a Principal Product Strategist at SolarWinds following its $4B acquisition. What "minimal viable pricing" actually means Dan's approach starts with a mindset shift: early-stage companies rarely fail because their initial price was off by 10–20%. They fail because they haven't found a repeatable customer problem, a clear value promise, or a reliable way to acquire customers. Minimal viable pricing means: It's pricing as a learning tool—not a spreadsheet exercise. Minimal viable pricing starts with your "free option" One of the most actionable parts of the discussion was Dan's breakdown of freemium vs free trial—and why it matters so much for minimal viable pricing. A free trial creates urgency. There's a natural deadline, which forces customers to evaluate value and decide. A freemium model can work, but it often creates a huge pool of users who never engage deeply enough to convert. If your goal is to learn quickly, trials often generate clearer signals: Minimal viable pricing works best when your go-to-market motion creates real decisions—not endless "maybe later." Trial length: don't confuse "short" with "effective" There's a trend toward shorter trials (like 7 days), but Dan's point is simple: a short clock doesn't help if your customer can't realistically experience value in that window. In B2B especially, onboarding delays, competing priorities, and internal approvals can chew up days instantly. A minimal viable pricing approach asks: What's the shortest trial that still allows a motivated customer to succeed? If you're selling to teams, the answer is often longer than you think. Use minimal viable pricing to clarify positioning Dan also shared a framing that sticks: are you selling a Timex or a Rolex? In other words, are you competing on affordability and simplicity—or premium value and outcomes? Minimal viable pricing isn't just about the number. It's also about: You don't need a dozen plans to communicate this. You need clarity. If customers can't tell who your product is for from the pricing page, your "pricing problem" might actually be a positioning problem. The goal: learn faster, not argue longer Minimal viable pricing gives you a way to move forward without pretending you have perfect information. Start with something simple, sell it, listen hard, and iterate. If you want a practical takeaway from Dan's perspective, it's this: pricing is one of your best feedback loops. Use it early. Use it...

If you want real improvement—not just more dashboards—workflow efficiency metrics have to start with something most teams avoid: visibility. In Part 2 of our interview with Michael Toguchi, we move from "big ideas" into the operational reality leaders face every day: shadow tools, duplicate systems, fuzzy ROI, and the pricing pressure that shows up when AI makes work faster. This conversation is a reality check for ops leaders, engineering leaders, and consultants trying to scale without drowning in tool sprawl—or measuring productivity in ways that break trust. Workflow efficiency metrics only work when the workflow is visible. If work lives in shadows, your data will lie. About Michael Toguchi Michael Toguchi is the Chief Strategy Officer at eResources, where he leads strategy for technology that supports complex, high-stakes workflows across higher education and mission-driven organizations. With 25+ years in digital transformation, Michael helps teams reduce tool sprawl, eliminate manual bottlenecks, strengthen compliance, and measure improvements in ways that translate into real operational capacity and impact. Tool Sprawl Starts as "Helpful" (Until It Becomes Expensive) Every organization eventually meets the "skunk works" problem: someone builds a spreadsheet, a quick app, a mini database, or a side process that solves a real pain—fast. It's well-intentioned. It's also how silos form. Over time, those small fixes become a parallel organization: Michael's warning is simple: when every department solves problems in isolation, the organization pays for it later—usually in rework, compliance risk, and decision-making paralysis. Shadow tools don't just create tech debt—they create decision debt. Workflow Efficiency Metrics Start With Transparency, Not Control The fix isn't to ban spreadsheets or crush experimentation. Michael's approach is more practical: shine the light on the workflow, then standardize intentionally. That means asking better questions: Transparency isn't micromanagement. It's a shared map. And once everyone sees the same map, you can make changes that stick. "Shine the transparency light on the workflow." Then decide what to standardize and integrate. Workflow Efficiency Metrics That Matter: Time Saved → Capacity Gained A big takeaway from Part 2 is how Michael thinks about measurement. Leaders often struggle here because "value" feels subjective—until you translate it into something tangible. Instead of measuring activity ("tickets closed" or "hours logged"), focus on outcomes: Michael shares a practical framing: if you reclaim even a slice of time—say 15% of a team's capacity—that's not just a feel-good metric. It's a lever you can pull: In other words, the metric isn't "time saved." The metric is what the organization can now do because time was saved. Time saved is only "real" when it turns into capacity, quality, or revenue. When AI Shrinks Time, Time-and-Materials Pricing Breaks Then Michael hits the business-model shift that a lot of teams are quietly wrestling with: AI compresses time. Work that took weeks can take days. The value may be the same—or higher—but the hours shrink. If you sell hours, you're forced into a bad choice: Michael's answer is to move up the stack: value-based pricing, retainers, and partnership models—ways of charging for outcomes, access, and expertise instead of minutes on a clock. That shift requires maturity: you must be able to explain your value clearly and measure the results you're creating. Which brings us right back to the point of the episode… Workflow efficiency metrics aren't just internal tools. They're how you prove impact when "time spent" stops being the story. Value-priced work + retainers make sense when time shrinks—but outcomes still...

If you've ever felt like your team is running on duct tape and good intentions, you're not alone. In this Building Better Developers interview, Michael Toguchi (Chief Strategy Officer at eResources) makes a simple point that changes how you approach growth: process before tools. Before you buy another platform, automate another workflow, or roll out a new system, you need clarity on how the work actually gets done—and who it's meant to serve. You can't tool your way out of chaos. The real fix starts upstream—before the migration, before the CRM, before the next sprint. It starts with people, leadership, and making the work visible enough to improve it. Process before tools isn't a slogan—it's the difference between scaling sustainably and scaling stress. If you want, I can also tighten the second sentence to include the phrase again without sounding repetitive, but this version should clear the Yoast check immediately. About Michael Toguchi Michael Toguchi is the Chief Strategy Officer at eResources, where he helps lead a platform that manages complex workflows for scholarships, grants, admissions, and accessibility services. With 25+ years supporting universities, nonprofits, and foundations through digital transformation, Michael focuses on making systems simpler, sustainable, and human-centered—so teams can scale without burnout and spend more time on mission-driven work. Process Before Tools: Why "Survival Mode" Becomes the Default Michael describes a pattern that mission-driven organizations (and plenty of startups) fall into: survival mode. Everyone is moving fast, reacting to urgent needs, and doing what it takes to keep the wheels turning. The downside is that the process gets postponed indefinitely. The team says things like: And it does work… until it doesn't. When the organization grows, the cracks grow with it: inconsistent outcomes, tribal knowledge, bottlenecks, and the quiet creep of burnout. Process Before Tools: Start Small, Make It Digestible One of the strongest points Michael makes is that meaningful change rarely comes from a dramatic, top-down overhaul. The most sustainable improvements begin with small, digestible steps. Instead of trying to "fix everything," identify a single pain point the team feels every week: Then improve that one piece, measure it, and repeat. Sustainable change isn't a magic wand. It's a series of small wins that teams can actually absorb. Process Before Tools: You Need Leadership Alignment (Not Just Agreement) A lot of teams confuse "buy-in" with "approval." Leadership might approve a new system or initiative, but that's not the same as aligning on why it matters, what success looks like, and what tradeoffs are acceptable. Michael emphasizes clarity: Without alignment, the organization drifts into mixed expectations—some people expect speed, others expect compliance, others expect perfect reporting. The result is frustration on all sides. Process Before Tools: Win With People, Not Platforms Michael's most practical warning is also the simplest: don't make it about tools. Tools can amplify a good process, but they can't create it. If you automate a messy workflow, you don't get a better workflow—you get a faster mess. The winning strategy is human-first: When teams feel heard, they participate. When they participate, the workflow becomes real. And once the workflow is real, the tool decision becomes obvious. Tools don't transform organizations—people do. Process Before Tools: A Practical Takeaway You Can Use This Week Here's a simple way to apply Part 1 immediately: only that That's how you move from survival mode to sustainable growth—without waiting for a budget cycle or a platform replacement. Closing Thoughts This interview is a reminder that building better...

You validated the idea. You built the page. Maybe you're even getting traffic. And yet… the conversions don't match the effort. In Part 2 of our interview with Samir ElKamouny, we shift from "prove the concept" to conversion rate optimization—the discipline of diagnosing what's actually limiting growth and improving the parts of your funnel that matter most. This isn't about chasing shiny marketing tactics. It's about execution: the kind that turns a funnel from "pretty good" into "predictable." About Samir ElKamouny Samir ElKamouny is an entrepreneur and marketing expert who believes execution is everything—an early lesson inspired by his father's legacy of big ideas. He has helped scale businesses by pairing strategic action with a commitment to impact, guided by values such as Freedom, Happiness, Health, Family, and Spirituality. In this episode, that philosophy becomes funnel execution: identify the bottleneck, prioritize the 80/20, and optimize what's already working. Conversion Rate Optimization Starts With One Question: Where's the Constraint? Many teams skip straight to A/B testing headlines or tweaking button colors. Samir takes a more surgical approach. Before you optimize anything, you need to know what kind of problem you have: Do you have a traffic problem? Or do you have a conversion problem? Because those are different fixes. If you're not getting enough visitors, obsessing over landing page micro-changes won't move the needle. But if you are getting traffic and still not getting demos, leads, or signups—then you've got a conversion bottleneck, and conversion rate optimization is exactly the right tool. Bottleneck First Traffic problem = distribution. Demo problem = messaging, offer, trust, friction, or flow. Diagnose the constraint before you "optimize." Use the 80/20 Rule to Avoid Busywork Samir's funnel advice lines up with how great engineers debug systems: don't touch everything—find the one thing causing most of the pain. That's the 80/20 rule applied to marketing and funnels: When you apply conversion rate optimization well, you're not "improving your funnel" in general. You're improving the one point that's limiting everything downstream. A practical example: if you're generating leads but no one books calls, the issue probably isn't your top-of-funnel content. It's the handoff—your booking experience, your follow-up, or the clarity of what the call is for. The "Two-Second Clarity Test" for Positioning Samir emphasizes something that's brutally simple—and incredibly effective: When someone lands on your page, they should understand what you do in about two seconds. Not "kind of." Not "after reading three paragraphs." Two seconds. That clarity acts like a conversion multiplier. If visitors are confused, they don't scroll. They don't click. They bounce. And no amount of A/B testing can fix a page that doesn't communicate the offer. Two-Second Clarity Test: Can a first-time visitor instantly answer: What is this? Who is it for? What outcome do I get? If not, start there. Don't Test What Nobody Sees One of the most actionable parts of Part 2 is Samir's reminder to test based on attention, not opinions. Teams often test sections that aren't getting seen or clicked because they "feel important." But if users never reach that section—or don't interact with it—optimizing it is wasted effort. Instead, focus on experiments where user engagement is highest: That's how you make conversion rate optimization practical: test the parts of the page that actually get traffic, eyeballs, and clicks. A Simple Conversion Rate Optimization Framework You Can Use This Week Here's a clean execution loop you can run without overcomplicating it: Pick one conversion goal Locate the biggest drop-off Form one hypothesis Make one...