# Rob Byrne's blog: full text > Notes on AI agents, developer tooling, delivery and engineering culture from Rob Byrne, a software craftsman in Vancouver, BC. --- URL: https://blog.leanrob.com/posts/how-i-plan-my-week-on-sunday/ # How I Plan My Week on Sunday > Friday closes the week. Sunday sets up the next one. Here's how I turn leftovers and a few big goals into a calendar my agents can work from. - URL: https://blog.leanrob.com/posts/how-i-plan-my-week-on-sunday/ - Published: 2026-11-08 - Tags: productivity, planning, ai - Reading time: 3 min - Author: Robert Byrne A week doesn't go well by accident. It goes well because someone decided what it was for. On Friday I [close out the week](/posts/how-i-close-out-my-week/). Sunday is the other half of that loop: I take what Friday told me and turn it into a plan for the week ahead. Here's the routine, in order. **1. Start from the Friday review.** I don't plan from a blank page. I open Friday's notes and check what's left over from last week. Some of it still matters and comes along. Some of it quietly doesn't, and that's worth noticing too. **2. Pick the top three.** Before any detail, I decide the three things that would make this week a good one. Just three. If everything is a priority, nothing is. **3. Break them down.** I think about the week in boulders, small rocks, pebbles and sand. Boulders are the big goals, the top three. Small rocks are the pieces that keep a boulder moving from one day to the next. Pebbles and sand are the messages and world-facing items: replies, follow-ups, small things other people are waiting on. They aren't really tasks, but they fill every gap if I let them, so I name them up front.
**4. Review the overall plan.** Then I step back and look at the whole thing at once. Does it hang together? Is there an obvious gap, or something that doesn't belong? **5. Let the agents put it on the calendar.** My agents break the plan into events with start times and add them to my calendar app, under a calendar used only for planning. That keeps the plan separate from meetings, and makes it easy to see what I meant to do against what actually happened.
**6. Write the prompts for later in the week.** While the plan is fresh, I write the prompts I'll hand to agents over the coming days. I also flag anything that can run overnight as background work, so the week starts with some of the prep already done. **7. Put it all in the notebook.** Everything goes into the notebook my scheduling and planning agent works from. If it isn't written down there, the agent can't plan around it. **8. Evaluate the plan against Friday.** This is the step that keeps the plan honest. I ask one question: if I did all of this, how would Friday's review compare to now? And how does that compare to where I actually want to be? If the answer is "a bit busier, but not much further along," the plan needs another pass. **9. Leave space.** A week packed edge to edge breaks on the first surprise. I leave room on purpose for learning, for socializing, and for one-on-ones. Those are easy to squeeze out, and expensive to lose. **10. Decide who to meet.** I go through the people I should see this week, for work or personal reasons, and prep those meetings from Monday onward. A meeting that's prepped on Sunday is a conversation. One that isn't is a status update. **11. Decide what I'm not doing.** Everything that didn't make the plan gets an explicit answer. For each item, I either defer it to a later week or delegate it to someone else. Nothing just sits there making me feel behind. None of these steps takes long on their own. Together they mean Monday starts with a plan I've already argued with, instead of an inbox. Sometimes, if I have the time, I get agents to build me a single page application that shows each day of the week with all of my tasks. As I finish each one, it grows a little bonsai, one branch per finished task, until it's fully grown by the end of the day.
Then Friday comes, and I find out how honest the plan was. --- URL: https://blog.leanrob.com/posts/how-i-close-out-my-week/ # The weekly close out > Most weeks don't end, they just stop. Here's the Friday routine I use to close the week on purpose, including a career lens and handing work to AI agents for the weekend. - URL: https://blog.leanrob.com/posts/how-i-close-out-my-week/ - Published: 2026-11-06 - Tags: productivity, planning, ai - Reading time: 3 min - Author: Robert Byrne The week isn't over when you stop working. It's over when you've closed it, both externally and internally. Most weeks don't end, they just stop. The last task gets done, the laptop closes, and the loose ends come along for the weekend. So on Fridays I close the week on purpose. Here's the routine, in order. **1. Check the calendar against what actually happened.** I planned the week on Sunday. Friday is where I hold that plan up against reality. Where did the hours go? What got pushed? What showed up that wasn't planned? **2. Process the meeting notes.** Every project meeting leaves notes behind. I pull them together, pick out the decisions and action items, and put them where they belong, so nothing important lives only in a document I'll never open again. **3. Look at the rest of the team's work.** Not a deep review, just a high level pass. What shipped, what's stuck, and what might land on my desk next week. **4. Give the week a rough grade.** Done versus what I wanted done. It isn't precise, and it doesn't need to be. Next to the grade I write three wins and one miss, because a number on its own tells me nothing a month later. **5. Look at the week through a career lens.** This is the step that is easy to skip, and is critical not to miss. I ask two questions. How does this week's output look for someone at my current level? And how would the person I want to become have spent this same week? The gap between those two answers is usually the most useful thing I learn all week. **6. Do a final sweep of open work.** I go through everything still open. Most of it can wait for Monday. If something is genuinely critical, I handle it now rather than let it spill into Saturday. Then I clear the inbox and close the tabs.
**7. Hand work to remote agents.** Before I log off, I start remote containers to run research and proof of concept spikes over the weekend. The trick is briefing them well: what question to answer, what a good result looks like, and where the results should land. A good brief on Friday means Monday starts with reading results, not untangling them. **8. Leave a note for Monday.** A few lines: where I stopped, what comes first, and what the agents are working on. It makes Sunday's planning much easier. **9. Mark the stop.** Then the week is done. Sometimes I plan the weekend, sometimes it's already planned for me. Either way, there's a clear moment where work ends and the weekend begins. None of these steps are complicated. The value is in doing them in order, every Friday, so the week ends on a decision instead of fading out. Next up: the other side of the weekend, and how I plan the week ahead. --- URL: https://blog.leanrob.com/posts/show-me-your-calendar/ # Show me your calendar and I'll show you how productive you are > Learning used to come easy, until it didn't. Teaching myself how to learn was the first fix; as a professional the problem became where the hours go, and the calendar is the answer. - URL: https://blog.leanrob.com/posts/show-me-your-calendar/ - Published: 2026-11-03 - Tags: productivity, planning, learning - Reading time: 3 min - Author: Robert Byrne Show me your calendar and I'll show you how productive you are. For most people, anyway. This isn't about being busier. It's about getting your time back. ## When everything came easy In school, learning came easy, through memory or metaphor. The method, if you could call it one, was to show up and pay some minimum level of attention. That was it. ## The break Then came university, and calculus. Everything before had been built on something I already had a reference for. This didn't. It asked me to think in a way I had never been taught, and the intuition that had carried me for years hit a ceiling. I wasn't just lost on the material. I was lost on how to learn it. I had never had to learn how to learn. The subject doesn't really matter. What matters is that moment: the first time the thing that always worked stops working, and I realized I never had a method. I had a good foundation and a bit of luck. ## Teaching myself how to learn So I had to teach myself, and it was slower than I wanted. I tried things, dropped most of them, and kept the few that worked. The method that stuck was simple: be honest about what I didn't understand yet, break it into smaller pieces, and put in the hours on purpose instead of hoping it would stick on its own. This isn't a how-to. The point is that I had to build one. Learning how to learn is also what taught me to plan, because both start with being honest about what you don't know yet. ## Where the hours go Then you start working, and the problem changes again. You still need to learn, but now you also need to get things done, and the question shifts from "how do I learn this?" to "where do my hours go?" The good news is that this one is easier to plan for. At work, you usually have a decent idea of what needs doing. That's where the calendar comes in. Most calendars are just meetings. But a calendar of meetings says nothing about the time between them, and that's where the real work either happens or doesn't. Leave those gaps empty and they fill themselves with messages, small requests and whatever is loudest. So schedule the gaps too. Block off time for the work itself. Or keep a second calendar next to your real one: a planning calendar for what you hope to get done that day. The point is that the day has a shape before it starts. A planned day might look like this: focused work from 9 to 11, then standup. After lunch, a two hour block to build, and the last half hour to plan tomorrow.
That's why I think a calendar says so much. Show me one that's all meetings and white space, and I'll show you someone who is busy all day and still not sure what they got done. Show me one with the work blocked in, and I'll show you someone who gets the important work done. ## The payoff Here's the part I wish someone had told me earlier. If you don't have a plan, you can work endlessly. There is always one more thing, and you can work yourself to oblivion without ever feeling done. But if you have a plan for the day and you get it done early, you get a choice. You can get a head start on tomorrow. Or you can stop early and go enjoy your life.
--- URL: https://blog.leanrob.com/posts/choosing-the-right-ai-coding-harness-for-your-workflow/ # Choosing the right AI coding harness for your workflow > Claude Code, Codex and Cursor; Pi, Hermes, OpenCode and Kandev; and Grok Bot as a coordinator above them. How the main AI coding harnesses differ, and why I match the tool to the job instead of crowning one winner. - URL: https://blog.leanrob.com/posts/choosing-the-right-ai-coding-harness-for-your-workflow/ - Published: 2026-10-28 - Tags: ai, agentic-programming, tooling, developer-experience - Reading time: 14 min - Author: Robert Byrne A year or two ago the question was "which model is best for coding?" Now the model is only half the story. The other half is the **harness**: the program that wraps the model, gives it tools (read a file, run a command, edit code), manages context and sessions, and decides how much you see and approve along the way. Two people using the same model through different harnesses can have completely different days. So it's worth choosing deliberately. **Short version:** if you want frontier models with little setup, use Codex or Claude Code; if you want OpenRouter's range of models and control over the setup, use OpenCode. Beyond that, match the tool to the job. A quick fix, a home server repair and a multi-week project have different needs, and no single harness is best at all of them. This post walks through the proprietary harnesses most people start with, then the open-source ones I find most interesting, then Grok Bot, which sits above them as a coordinator. It ends with how I'd choose, for yourself or a small team. Things move fast in this space, so treat the details as a snapshot and check each project's docs before you commit. ## What a harness actually does Strip away the branding and most harnesses do the same loop: 1. Build a prompt from your message, the system instructions, project files and history. 2. Send it to a model. 3. Run the tool calls the model asks for (read, write, edit, shell), maybe after asking you. 4. Feed the results back and repeat until the task is done. Where they differ is everything around that loop: **which models** you can use, **where it runs** (terminal, IDE, web, a server), **how you extend it** (plugins, MCP servers, skills, scripts), **how many agents** run at once, and **what leaves your machine**. ## The proprietary harnesses ### Claude Code Anthropic's agentic coding tool. It started in the terminal and now also runs in IDE extensions, a desktop app and the browser. It's built around Claude models, supports MCP for connecting tools, and has features like sub-agents and project memory files. It also has a sibling for people who don't write code: [Claude Cowork](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile), the same kind of agent pointed at documents, files and connected apps instead of a repository. On Team and Enterprise plans an admin switches it on for the organisation, which makes it an easy way for non-developers at a company to start using AI on real work. Both can work on a schedule. Claude Code has [three options](https://code.claude.com/docs/en/scheduled-tasks): cloud scheduled tasks that run on Anthropic's infrastructure with your laptop closed (and can also fire from an API call or a GitHub event), Desktop scheduled tasks that run on your machine with access to local files, and `/loop` for quick polling inside an open session. Cowork has its own [scheduled tasks](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) for things like a daily briefing or a weekly report. You also choose how much Claude Code asks before acting, through [permission modes](https://code.claude.com/docs/en/permission-modes) you cycle with Shift+Tab: **Manual** (config value `default`, which asks before most actions), **acceptEdits** (file edits go through), **plan** (research and propose, no edits until you approve the plan) and **auto** (fewer prompts, with Claude Code deciding which actions still need your approval). There's also `dontAsk` for locked-down CI and `bypassPermissions`, which is meant for isolated containers only.
**Good for:** people who like a polished terminal workflow and are happy to centre on one model family. **Trade-off:** you're mostly tied to Anthropic's models and pricing, and the most hands-off permission modes only make sense once you've set up a safe place to run them. ### Codex OpenAI's coding agent, available through ChatGPT plans and the API. It comes in several shapes: the open-source (Apache-2.0) Codex CLI, an IDE extension, the Codex desktop app, and [Codex Cloud](https://help.openai.com/en/articles/6825453-chatgpt-release-notes), where each task gets its own isolated workspace and keeps going while your computer sleeps. You can start and steer those tasks from your desktop, the web or your phone. OpenAI's answer to Cowork is [ChatGPT Work](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex), an agent for longer, multi-step work like research, reports, spreadsheets and presentations, with Codex kept for software work. The newest piece is **dots**: always-on agents in ChatGPT that you give a goal and the apps they need, each with its own cloud computer, and that can now [start Codex tasks and follow up on Codex threads](https://community.openai.com/t/fresh-dots-updates-create-in-the-mobile-app-delegate-to-codex/1404834) for you. Dots are still rolling out, and I haven't used one enough yet to say how good they are.
**Good for:** people already in the ChatGPT ecosystem who want local and cloud runs from the same place. **Trade-off:** it's designed first and foremost around OpenAI's models, and the newest pieces (ChatGPT Work and dots) are still settling, so expect the shape to keep changing. ### Cursor An AI-first code editor with an agent built in. Since [Cursor 3](https://cursor.com/blog/cursor-3) it has two front ends you can keep open side by side: the classic IDE, a VS Code fork with full editing, and the [Agents Window](https://cursor.com/docs/agent/agents-window), an agent-first chat interface for running and reviewing many agents across repos. There's a CLI too. It offers models from several providers, and supports rules, skills, sub-agents and MCP. The other half is [cloud agents](https://cursor.com/docs/cloud-agent). Each one runs in its own isolated VM with your repo cloned, dependencies installed and secrets available, so it can build, run tests and even drive a desktop and browser to check its work, then open a PR with screenshots or a video. You can start them from the desktop app, the web, your phone, Slack, GitHub, Linear or the API, and move a session between local and cloud as you go.
**Good for:** people who want the agent inside a full editor, with diffs and review in the same window, and the option to hand longer work to the cloud. **Trade-off:** the full experience means adopting its editor, a VS Code fork, and cloud agents need a plan that includes them, with long or loosely specified tasks using more of your limits than quick local edits. ## The open-source harnesses ### Pi [Pi](https://github.com/earendil-works/pi), by Mario Zechner, is a deliberately **minimal** terminal harness ([MIT-licensed](https://github.com/earendil-works/pi/blob/main/LICENSE)). By default it gives the model four tools: read, write, edit and bash. It skips things like sub-agents, plan mode and built-in MCP on purpose. Instead, you extend it with TypeScript extensions, skills, prompt templates and shareable "Pi packages". It works with many providers and can run interactively, in a JSON/print mode, over RPC or embedded through an SDK.
**Good for:** tinkerers who want a small core they fully understand and can shape to their own workflow. **Trade-off:** you build (or install) what others ship out of the box. Extensions run with your user's permissions, so only load ones you trust. ### Hermes Agent [Hermes Agent](https://github.com/nousresearch/hermes-agent) is an open-source (MIT) agent from Nous Research, the lab behind the Hermes models. It can code, but it's really an always-on personal agent that gets better the more you use it. A built-in learning loop turns finished tasks into skills and refines them as you go, it keeps curated memory in plain files (`MEMORY.md` and `USER.md`), and it can search its own past sessions. It isn't tied to your laptop either: it runs locally, in Docker, over SSH or on serverless hosts like Modal and Daytona, and one gateway lets you talk to it from Telegram, Slack, Discord, WhatsApp or Signal. Add scheduled jobs that report back to any of those, isolated sub-agents, checkpoints you can `/rollback`, any model provider, and support for editors that speak the Agent Client Protocol (ACP).
**Good for:** people who want one long-lived agent that remembers them across sessions, runs on a server rather than a laptop, and is reachable from their phone. **Trade-off:** more moving parts, and a bigger surface to secure if you connect it to chat platforms and give it shell access. ### OpenCode [OpenCode](https://opencode.ai) is an open-source (MIT) coding agent from Anomaly, the team behind SST. Think of it as the open, model-agnostic take on the Claude Code experience. It connects to dozens of providers through [Models.dev](https://models.dev), including OpenRouter and local models, and comes with some free models. Its [provider docs](https://opencode.ai/docs/providers/) also cover signing in with some existing subscriptions, such as ChatGPT Plus/Pro and GitHub Copilot, though which ones are supported can change. Under the hood it's [client/server](https://opencode.ai/docs/server/): running it starts a local server, and the terminal UI is just one client. The desktop app, web UI, IDE extension and SDK talk to the same server, so you can run it on one machine and drive it from another. Tab switches between the full-access **build** agent and the read-only **plan** agent, with language servers, parallel sessions and `/undo`, `/redo` and `/share` on top. It's the open-source harness I've been connecting Grok Bot to on my own Mac.
**Good for:** people who want something close to the proprietary terminal experience without being tied to one model vendor, or who want to drive one agent from several devices. **Trade-off:** beyond the free models and supported subscriptions, you manage your own provider keys and costs, and it's a fast-moving project to keep up with. ### Kandev [Kandev](https://github.com/kdlbs/kandev) is a different kind of tool. It's an open-source ([AGPL-3.0](https://github.com/kdlbs/kandev/blob/main/LICENSE)), self-hostable **workbench for orchestrating other agents**. It gives you kanban and pipeline views, runs multiple tasks in parallel in isolated git worktrees, Docker containers or remote machines over SSH, and gives you an integrated place to review diffs and open PRs. It supports many agent CLIs, including Claude Code, Codex, OpenCode, Pi and Hermes, and advertises no telemetry.
**Good for:** people running several agents at once who want a control plane and review gates rather than a dozen terminal tabs. **Trade-off:** it's another service to run, and it sits on top of the harnesses rather than replacing them. ## Side by side | | Licence | Where it runs | Models | Extending it | Many agents at once | | --- | --- | --- | --- | --- | --- | | **Claude Code** | Proprietary | Terminal, IDE, desktop, web | Mostly Claude | MCP, plugins, sub-agents | Yes | | **Codex** | CLI open source; service proprietary | Terminal, IDE, desktop, cloud | Mostly OpenAI | MCP, config | Yes (cloud tasks) | | **Cursor** | Proprietary | Editor, Agents Window, CLI, cloud VMs | Several providers | Rules, skills, MCP | Yes (cloud agents) | | **Pi** | MIT | Terminal, RPC, SDK | Many providers | TypeScript extensions, packages | Build your own | | **Hermes Agent** | MIT | Terminal, desktop, server, chat apps, ACP editors | Any provider | Skills, toolsets, MCP | Sub-agents | | **OpenCode** | MIT | Terminal, desktop, web, IDE, SDK | Many providers, incl. local | Config, MCP, custom agents | Parallel sessions | | **Kandev** | AGPL-3.0 | Self-hosted web UI | Whatever the agents use | Workflows, MCP | Yes, it's the point | Grok Bot isn't in the table on purpose: it sits above these harnesses rather than being one of them. ## Above the harness: Grok Bot [Grok Bot](https://cursor.com/docs/grok-bot) is the assistant I use day to day, and it works at a different layer from everything above. It's proprietary, and it's included with every paid individual Cursor plan and the Cursor Teams plan. You message Bots from a desktop or phone app, and each Bot works on a persistent cloud computer with a browser, files and a terminal. It uses connectors for apps like email, calendar, Linear and GitHub, falls back to the browser for sites without one, can hand pieces of work to other Bots, and runs saved skills as routines on a schedule. It keeps working with my laptop closed and comes back to me when something needs my approval. It isn't just a connector between other tools, though. Grok Bot is powerful in its own right and runs on its own models under the hood, so it does real work itself on its own computer. I think of it as a coordinator: it runs things, and when a task gets bigger it hands it to an agent built for that job. For repository work, that usually means a Cursor cloud agent. Grok Bot launches one, hands it the brief, follows its progress and reports back with the PR. I describe the outcome in a chat and review the result, and the cloud agent does the repo work in its own VM. It doesn't have to stop at Cursor, either. You can build your own connections so Grok Bot can drive open-source harnesses too. I've been building a small bridge, a CLI called `orb`, that lets Grok Bot start and steer OpenCode sessions on my own Mac. That deserves a post of its own, so more on it soon. **Good for:** people who want one assistant that handles work across apps itself and hands bigger coding tasks to agents built for them. **Trade-off:** it can act on your accounts, so the real work is deciding which connectors it gets and what it may do without asking. ## What I actually use, and why I use Cursor, Grok Bot, OpenCode and Codex, and Claude at work. Grok Bot runs things and hands bigger tasks to agents. People sometimes ask which one wins on a real task, and I don't think that question has a useful answer. My tasks vary too much. Some are small tasks, some are fixes on my home server, some are complex projects that run for weeks, and plenty are something else again. They all have different needs, and forcing one tool onto all of them is a square peg in a round hole. So rather than a benchmark, I pick the tool that fits the job in front of me. ## How I'd choose I find it helps to start from **how you work**, not from feature lists. **"I want frontier models and as little setup as possible."** Codex or Claude Code. **"I want OpenRouter's models and control over the whole setup."** OpenCode. **"I live in my editor."** Cursor, or an editor that speaks ACP with Hermes or another ACP agent behind it. Reviewing diffs where you already read code is a big quality-of-life win. **"I want to own every piece."** Pi. You'll spend time shaping it, but you end up with exactly the tool you want and understand all of it. **"I want a long-running assistant, not just a coding session."** Hermes Agent, ideally on a server with tightly scoped permissions. **"I run lots of agents in parallel and the bottleneck is review."** Kandev on top of whichever harnesses you already like. A few questions cut through most decisions: * **Lock-in:** if your preferred model changes next quarter, how painful is the switch? * **Cost:** do you pay a flat subscription, per token, or both? Open-source harnesses are free, but the model calls usually aren't. * **Privacy:** what code and context leave your machine, and to whom? Read the privacy docs rather than assuming. * **Safety:** what can the agent do without asking? The checklist below matters more as you hand over more. ### A short safety checklist * Run agents in git worktrees or containers, so a bad run is easy to throw away. * Keep bypass-style modes, like Claude Code's `bypassPermissions`, for throwaway environments only. * Scope connectors to what the task needs, and prefer read access until write access is clearly needed. * Never give a long-running agent production credentials. ### For a small team The same split works for a team: frontier models only points to Codex or Claude Code, and OpenRouter models with full control points to OpenCode. A few things matter more once more than one person is involved: * **Standardise on a default.** Pick one tool everyone gets, and let people add others for the jobs that need them. * **Keep shared instructions in the repo,** so every agent starts from the same conventions (more on that below). * **Agent PRs go through normal review.** Same checks, same reviewers, same bar as any other PR. * **Know how the costs behave.** Some tools charge per seat, some by usage, many both. Cloud agents and long-running tasks spend more than quick local edits, and open-source harnesses are free but you still pay per token for the models behind them. Then governance. Before rolling anything out, check each vendor's data retention and training settings, turn on the admin and SSO controls your plan offers, and give connectors the narrowest access that does the job. An agent that can read every inbox and repo in the company is a bigger decision than which editor people use. ## Portable setup The cheapest insurance against lock-in is keeping your project instructions in plain files in the repo. Most harnesses read some version of them: * **`AGENTS.md`** is the shared convention many tools read, including Codex, Cursor, OpenCode and Pi. * **`CLAUDE.md`** is Claude Code's equivalent. * **Cursor rules** live in `.cursor/rules`. * **Skills folders** hold reusable instructions and scripts, and several harnesses now load them. The content carries over well: build and test commands, code style, architecture notes, what not to touch. What doesn't carry over is the wiring around it, like permission settings, hooks, MCP configs and tool-specific frontmatter, so keep that layer thin. One easy trick is to write everything once in `AGENTS.md` and have `CLAUDE.md` point to it. ## Wrapping up There's no single best harness. The proprietary ones are polished and quick to start with, but they pull you towards one vendor. The open-source ones trade some polish for control over models, hosting and extensions, and they're improving fast. My advice: match the tool to the job rather than crowning one winner, keep your project instructions in plain files that any harness can read, and stay ready to switch. The harness should fit your workflow, not the other way round. --- URL: https://blog.leanrob.com/posts/strategic-overcommitment/ # Strategic overcommitment: when going all-in can build your career base > My personal take on when it can be worth going all-in for a while as an engineer, how to tell real creative momentum from pressure, and how to keep the push from tipping into burnout. - URL: https://blog.leanrob.com/posts/strategic-overcommitment/ - Published: 2026-10-21 - Tags: career, productivity, focus, opinion - Reading time: 8 min - Author: Robert Byrne Most career advice about effort points one way: slow down, protect your evenings, don't let work eat your life. I agree with nearly all of it. Burnout is real, it's common in our industry, and nobody gets a prize for running themselves into the ground. But I also think there's a quieter truth that doesn't get said much. Every so often, if you're lucky, you hit a stretch where you're *genuinely* fired up: a problem you can't stop thinking about, a skill that's finally clicking, a project that feels like yours. In those moments, I think it can be worth leaning in harder than usual, on purpose, for a limited time. This is my personal opinion, not a prescription. It's what has worked for me, and the "on purpose" and "limited time" parts are doing a lot of work. ## A caveat before anything else If you're already tired, anxious, or dreading the work, this post isn't for right now. The World Health Organization describes burnout as a syndrome resulting from chronic workplace stress that hasn't been successfully managed, marked by exhaustion, growing mental distance or cynicism about your job, and reduced effectiveness. If that sounds familiar, the right move is usually less, not more, and talking to someone you trust or a health professional is a sign of good judgement, not weakness. Everything below assumes you're starting from a healthy place and the energy is real. ## Why I think a deliberate push can be worth it Some things compound. If you spend a focused few months going deep on a new language, a hard problem or a side project, you often come out with: * **A skill base** you keep drawing on for years. * **A body of work** you can point to: a project, a portfolio, some writing, a talk. * **Confidence** that you can learn hard things quickly, which changes how you approach the next one. Those things are much harder to build in scattered half-hours. Momentum matters. When you're in it, an extra evening can do more than a week of distracted effort later on. And it's a privilege. Being in a situation, with the health, time and circumstances, where something lights you up like that isn't a given. When it happens, I think it's worth making the most of it. ## Momentum or pressure? Telling them apart This is the most important part, because the two can feel similar from the inside. **Real creative momentum usually looks like:** * you *want* to come back to it, even after a break; * time passes quickly and you finish tired but satisfied; * you're curious, not just anxious about falling behind; * you'd keep going even if nobody was watching. **Pressure or guilt usually looks like:** * you're pushing because you feel you *should*, or you're scared of what happens if you don't; * the work feels heavy before you start; * you feel worse after each session, not better; * it's driven mostly by someone else's expectations. If it's the second list, overcommitting won't build a base. It'll just drain you. ## How I'd structure a push ### Time-box it Decide up front how long the push lasts: a few weeks, a quarter, until a specific milestone. An end date turns "I'm always on" into "I'm doing a sprint". Put it in your calendar. ### Decide what base you're building Write down, in one or two sentences, what you want to have at the end. "I can build and deploy a small service in a new language." "A portfolio site with three real case studies." "A working prototype of the idea I keep sketching." If you can't name it, you're likely just working more, not building something. ### Protect the non-negotiables The things that keep you functioning aren't optional extras during a push. They're what make it possible: * **Sleep.** This is the first thing to go and the last thing you should trade. * **Movement and food.** Boring, essential. * **People.** Tell the people close to you what you're doing and for how long. Keep the time with them that matters most. ### Keep a light log A few lines at the end of each session: what you did, how you felt. It's a progress record and an early-warning system at the same time. ## Warning signs it's tipping over Watch for these, and take them seriously: * you're sleeping badly or relying on caffeine just to start; * the work you were excited about starts to feel like a chore; * you're snapping at people, or withdrawing from them; * you've stopped doing the things that recharge you; * you're extending the time box again and again. When you notice them, step back. Take a few days off completely. Cut the scope. End the push early. Stopping isn't failing; it's the "managed" part of strategic overcommitment. If the signs don't lift with rest, talk to a doctor or another professional. For me, the clearest version of "you've stopped doing the things that recharge you" is golf. When I catch myself thinking "I can't go this week, I've got too much to do", I've learned to treat that thought as a signal, not a fact. If I look back and realise I haven't played in a few weeks, that settles it: I make the time and go, on purpose. A round takes about four hours, and for those four hours I do my best to switch off from work completely. The work is still there when I get back, and I'm usually in better shape to deal with it.
## When you're stuck, do something completely different During a push it's tempting to treat being stuck as a reason to grind harder. In my experience that often makes it worse. When I've been going around in circles on a problem, what works surprisingly often is to stop and do something completely different. Then, later, on a walk, in the shower or halfway through a round of golf, the answer shows up out of nowhere. This has a name: the incubation effect. Graham Wallas described it back in 1926 in [*The Art of Thought*](https://archive.org/details/theartofthought), where he split the creative process into four stages: preparation, incubation, illumination and verification. Preparation is the hard, conscious work on the problem. Incubation is the time when you're not consciously thinking about it at all. Illumination is the "happy idea" arriving, and verification is checking that it actually works. It isn't just folklore. A [2009 meta-analysis by Sio and Ormerod](https://doi.org/10.1037/a0014212) pooled 117 studies and found a real, positive incubation effect. The effect was bigger when people had spent longer working on the problem first, and smaller when they filled the break with another demanding task. A [2012 study by Baird and colleagues](https://doi.org/10.1177/0956797612446024) found something similar: people who spent a break on an easy, undemanding task, the kind that lets your mind wander, did noticeably better when they came back to a creative problem they'd already seen. People who rested, did a demanding task or took no break didn't get that boost.
What I take from that: * **Do the preparation first.** Incubation isn't a shortcut. It works on a problem you've already loaded into your head. * **Pick something light.** A walk, the dishes, a round of golf. Swapping one hard problem for another isn't a break. * **Actually let go.** It only works if you stop working the problem on purpose. * **Then verify.** The idea that shows up out of nowhere still has to be checked like any other. ### Calm a racing brain Meditation helps me with the other kind of stuck: when my brain is racing. When I'm jumping between the problem, the deadline and everything else on the list, I'm at my worst at solving anything. Taking a few minutes to meditate and let that settle is often what lets me see the problem clearly again. There's some evidence for both halves of that. A [2014 meta-analysis in JAMA Internal Medicine by Goyal and colleagues](https://doi.org/10.1001/jamainternmed.2013.13018) looked at 47 randomised trials and found moderate evidence that mindfulness meditation programs reduce anxiety, and low-strength evidence that they reduce stress. And in a [2012 study by Ostafin and Kassman](https://doi.org/10.1016/j.concog.2012.02.014), people given brief mindfulness training did better on insight problems, the kind where you have to drop your first framing of the problem to see the answer, though not on ordinary step-by-step problems. These are modest effects, and meditation isn't a treatment for burnout. But as a way to get my head out of a loop, I've found it really useful. ## Coming down deliberately The end of a push deserves as much intention as the start. * **Actually stop.** Take real rest afterwards, without guilt. Recovery is part of the plan. * **Take stock.** What did you build? What did you learn? Write it down while it's fresh. * **Package it.** Turn the work into something durable: a write-up, a repo with a good README, a short demo. * **Reflect honestly.** Was it worth it? What would you do differently? This tells you whether, and how, to do it again. ## Wrapping up I don't think anyone should live in permanent overdrive. But I do think that when real, creative momentum shows up, it can be worth leaning in for a while, as long as you set an end date, know what you're building, protect your sleep, health and relationships, and stop the moment it starts to cost more than it gives. Used carefully, a push like that can lay down a base you build on for years. Used carelessly, it's just burnout with better branding. The difference is whether you're managing it, or it's managing you. --- URL: https://blog.leanrob.com/posts/animation-with-intent/ # Animation with intent: using motion well without overdoing it > What animation is actually for (feedback, continuity, orientation and a little delight), how to do it well with CSS and the View Transitions API, and a checklist for spotting motion that should be cut. - URL: https://blog.leanrob.com/posts/animation-with-intent/ - Published: 2026-10-14 - Tags: design, animation, frontend, accessibility - Reading time: 6 min - Author: Robert Byrne I love good animation. A button that responds the instant you press it, a panel that slides in from where you tapped, a page that hands off smoothly to the next one: when it's right, you don't notice it. You just feel like the interface is paying attention. I've also sat through plenty of motion that made things worse: hero sections that make you wait before you can read, lists that bounce on every scroll, page transitions that turn a fast site into a slow one. Let's discuss what animation is for, how to build it well, and a checklist for when to cut it. ## What animation is for I think every animation should have a job. If I can't name the job, it probably shouldn't ship. The jobs I keep coming back to: * **Feedback.** "I heard you." A button press, a toggle flipping, a field shaking gently on an invalid value. * **Continuity.** "This is the same thing, it just moved." A card expanding into a detail view, or an item sliding into its new place when a list re-sorts. * **Orientation.** "Here's where you are now." A drawer coming in from the side tells you where it lives and how to put it away. * **Delight.** A small, occasional flourish that gives a product personality. Used sparingly, this is great. Used everywhere, it becomes noise. Notice that three of those four are about **understanding**, not decoration. ## Getting the basics right ### Duration Shorter than you think. Nielsen Norman Group's guidance is that most UI animations sit somewhere between 100 and 500 ms, with simple feedback (a checkbox, a toggle) around 100 ms, and anything approaching 500 ms starting to feel like a drag. My own defaults: * small feedback: about 100–150 ms; * elements entering or leaving: about 200–300 ms; * big, full-screen changes: rarely more than about 400 ms. ### Easing Real things don't move at constant speed. As a rule of thumb: * **ease-out** (fast start, gentle stop) for things entering: they respond immediately and settle; * **ease-in** for things leaving: they gather speed and get out of the way; * **ease-in-out** for things moving from one place to another on screen. Avoid `linear` for UI movement. It's fine for spinners and progress bars. ### Animate the cheap properties Browsers can animate `transform` and `opacity` without recalculating layout or repainting, so they stay smooth even on modest devices. Animating `width`, `height`, `top` or `margin` forces layout work on every frame and is where jank comes from. ```css /* Prefer this */ .panel { transform: translateX(100%); opacity: 0; transition: transform 250ms ease-out, opacity 250ms ease-out; } .panel.is-open { transform: translateX(0); opacity: 1; } /* Rather than animating `right` or `width` */ ``` ## Respect reduced motion Some people get dizzy, nauseous or distracted by motion, and operating systems let them say so. The `prefers-reduced-motion` media query passes that setting to your CSS and JavaScript. WCAG 2.3.3 (Animation from Interactions) asks that motion triggered by interaction can be turned off unless it's essential. "Reduced" doesn't have to mean "none". Swapping a big slide for a quick fade often keeps the meaning without the movement. ```css @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } ``` That blanket rule is a decent safety net. Better still is designing a reduced variant for the animations that carry meaning. ## View Transitions: continuity without the plumbing The View Transitions API lets the browser snapshot the page before and after a change and animate between them. For years, smooth page-to-page or state-to-state transitions meant a lot of manual DOM juggling. Now the browser does the heavy lifting. On my own site I use it in two places, which make nice examples. **A theme-switch wipe.** When you pick a new theme, the page doesn't just flash to the new colours. A slanted gap opens from the middle of the screen and spreads outwards, revealing the new theme underneath the old one in about a fifth of a second. It's continuity: you see the change happen rather than wondering what just blinked. Here's a simplified, generic version of the pattern: ```js function switchTheme(apply) { const root = document.documentElement; const reduce = window.matchMedia("(prefers-reduced-motion: reduce)").matches; if (reduce || !document.startViewTransition) { apply(); return; } root.classList.add("theme-switching"); const transition = document.startViewTransition(apply); transition.finished.finally(() => root.classList.remove("theme-switching")); } ``` ```css /* An animatable custom property for the width of the gap */ @property --wipe { syntax: ""; inherits: false; initial-value: 0px; } @keyframes split-wipe { to { --wipe: 80%; } } /* The old snapshot sits on top; a slanted gap opens from the centre */ html.theme-switching::view-transition-old(root) { z-index: 1; mix-blend-mode: normal; mask-image: linear-gradient( 100deg, #000 calc(50% - var(--wipe)), transparent calc(50% - var(--wipe)), transparent calc(50% + var(--wipe)), #000 calc(50% + var(--wipe)) ); animation: split-wipe 200ms cubic-bezier(0.7, 0, 1, 1) both; } html.theme-switching::view-transition-new(root) { animation: none; mix-blend-mode: normal; } ``` Scoping everything under a `theme-switching` class keeps the wipe separate from the page-navigation transitions. It's also worth handling impatience: if someone clicks through several themes quickly, skip the running transition (`transition.skipTransition()`) and jump straight to their latest pick rather than queueing up wipes. Notice the guard at the top: browsers without the API just switch instantly, and so do people who've asked for reduced motion.
**Page transitions.** Moving between pages gets a short (roughly a third of a second), subtle transition so the site feels continuous rather than flashing white between routes. For multi-page sites, cross-document view transitions can be enabled in CSS with `@view-transition { navigation: auto; }` in browsers that support it. The key with both: they're **quick**, they **don't block** anything, and they **disappear** for people who don't want them. ## Scroll-driven effects, done right CSS scroll-driven animations let you tie an animation's progress to scroll position without JavaScript scroll listeners. That's a real performance win. It's also an easy way to make a page exhausting. What I think works: * a reading-progress bar; * subtle reveal of content as it enters the viewport, done once; * sticky headers that compress gently. What I'd avoid: * scroll-jacking, where the page stops scrolling like a page; * heavy parallax on text you're trying to read; * anything that makes content unreadable until an animation finishes. ## How animation gets abused The failure modes are predictable: * **Making people wait.** Content that fades in over a second, or an intro that plays before you can click. Every repeat visit pays that tax. * **Motion for its own sake.** Everything bounces, nothing means anything, and the one important animation gets lost. * **Layout jank.** Animating layout properties, or content shifting around as things load and animate in. * **Ignoring preferences.** No reduced-motion path at all. * **Inconsistency.** Five different durations and easings across one product, so nothing feels like it belongs together.
## A checklist for cutting an animation Before shipping, I ask: 1. **What's its job?** Feedback, continuity, orientation or delight. If none, cut it. 2. **Does it block the user?** If someone can't act until it finishes, shorten it or remove it. 3. **Would I still like it on the twentieth view?** Delight fades fast; irritation doesn't. 4. **Is it only transform and opacity?** If not, can it be? 5. **What happens with reduced motion?** There should be a deliberate answer. 6. **Does it match the rest of the product?** Same family of durations and easings. ## Wrapping up Good animation helps people understand what just happened and where they are. It's fast, it's cheap for the browser, and it respects people who'd rather not have it. Bad animation makes people wait, wobbles for no reason and ignores their settings. Give every animation a job, keep it short, stick to transform and opacity, honour `prefers-reduced-motion`, and lean on the View Transitions API for continuity. And when in doubt, cut it. Nobody has ever complained that an interface felt too responsive. ## Further reading * [MDN: prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion) * [W3C: Understanding WCAG 2.3.3 Animation from Interactions](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html) * [Nielsen Norman Group: Executing UX Animations: Duration and Motion Characteristics](https://www.nngroup.com/articles/animation-duration/): the 100–500 ms range and ~100 ms for simple feedback. * [web.dev: How to create high-performance CSS animations](https://web.dev/articles/animations-guide): why transform and opacity are cheap. * [MDN: View Transition API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API) * [MDN: Document.startViewTransition()](https://developer.mozilla.org/en-US/docs/Web/API/Document/startViewTransition) * [MDN: @view-transition](https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition): cross-document transitions. * [Chrome for Developers: Smooth transitions with the View Transition API](https://developer.chrome.com/docs/web-platform/view-transitions) * [MDN: ViewTransition.skipTransition()](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition/skipTransition) * [MDN: @property](https://developer.mozilla.org/en-US/docs/Web/CSS/@property): animatable custom properties used in the wipe. * [MDN: CSS scroll-driven animations](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations) --- URL: https://blog.leanrob.com/posts/meta-planning-from-baseline-to-phased-agent-workspaces/ # Meta-planning: from baseline to phased agent workspaces > A layered workflow for high-stakes delivery with AI agents: a human-gated meta-plan, testable phases with focused prompts, isolated workspaces, a staff-level readiness pass, then deliberate execution one phase at a time. - URL: https://blog.leanrob.com/posts/meta-planning-from-baseline-to-phased-agent-workspaces/ - Published: 2026-02-13 - Tags: ai, engineering, tooling, agentic-programming - Reading time: 10 min - Author: Robert Byrne When you are trying to bring a **new app or service** to something like **production readiness** (deployable, observable, reversible, and aligned with how your org actually ships), one long chat with an agent is not a strategy. It is a lottery. The useful move is to step up one level of abstraction and treat the work as **meta-planning**: you are not only writing code; you are designing a **stack of plans** that turn a fuzzy baseline into ordered, checkable work, with humans holding the line where mistakes cost the most. This post is for **tech leads, staff engineers, and senior ICs** who already use tools like Cursor and want a repeatable shape for **large surface** changes. You will get a concrete pipeline: meta-plan → human confirmation → testable chunks and **phase prompts** → **one workspace per phase** (with ops context) → another human review → a **staff-level readiness pass** with an agent → **execution in order** with verification. Nothing here replaces your organization’s real approvals or on-call judgment; it gives you a way to keep agent assistance from quietly amplifying a wrong early assumption. --- ## Why a single agent thread does not scale to a baseline Production readiness is a **system** problem. It includes the repo, the pipeline, secrets and config, data migrations, metrics and alerts, access controls, rollback story, and the manual checks your team trusts. A single prompt thread tends to **interleave** those concerns, lose track of global constraints, and optimize for whatever looks like progress in the moment. You get merges that are hard to review and a story that is even harder to **audit** later. **Meta-planning** means naming the **baseline** first (what “done” means for this initiative) and then decomposing everything that must become true to reach it. Examples of baselines: - The service runs in the production environment with the right **routing and auth**. - **Observability** exists at a level you would defend in an incident. - **Data** paths are safe to run twice (idempotency) or safe to roll back. - **Operational** runbooks and ownership are clear enough that on-call is not guessing. AI agents (like Cursor or Claude Code) are good at **drafting** inventories, suggesting sequencing, and surfacing forgotten steps. They are not good at **owning** the truth about your environment. That split is the backbone of the rest of this workflow. --- ## Layer 1: Generate and refine the meta-plan, and put humans on the record Start by using an agent (or several short sessions) to build a **meta-plan** anchored to your baseline. Good meta-plans usually include: - A crisp **definition of done** for the baseline, in language your team would actually use in a review. - A **dependency map**: what must exist before what, including external systems and human gates (security review, data classification, etc.). - **Workstreams** that can progress in parallel versus steps that are strictly serial. - **Risk and rollback** notes: what breaks if you ship this increment, and how you would know quickly. Refine the meta-plan iteratively. Ask for gaps, ask for “what would a skeptic ask,” and ask for **failure modes**, not because the model is always right, but because those questions produce a better draft. Here is the part to internalize: **errors at this layer compound.** A wrong assumption in week-one sequencing does not stay in week one. It becomes the premise for phase prompts, branch strategy, and test plans. Every downstream workspace inherits it. So before you treat the meta-plan as real, **stop and put humans on it**: owners who know the system confirm that the scope, sequencing, and definition of done match reality. This is not a courtesy review. It is where you buy down **multiplicative** risk.
--- ## Layer 2: Break the meta-plan into testable chunks and phase prompts Once the meta-plan is human-approved at the level of “this is the work,” translate it into **chunks** that are **testable** on their own. A chunk should have a clear **falsifiable** outcome: you can demonstrate completion without debating the entire program. Examples: - “CI builds and deploys to staging with the new config shape.” - “Read path hits the database with the new schema; write path is still behind a flag.” - “Dashboards and alerts exist for the golden signals we agreed on.” Map those chunks to **phases**. For each phase, write a **phase prompt**: instructions that load **codebase context** and spell out what this slice must do, but **do not** paste the entire meta-plan every time. The phase prompt should include: - **Objective** for this phase only. - **Constraints** (compatibility, flags, “do not touch X yet”). - **Verification**: commands, checks, or manual steps that prove the phase is done. - **Interfaces** with other phases: contracts, file paths, or APIs that must stay stable. If the prompt repeats the whole master narrative, agents will **re-plan** instead of **execute**, and you will fight drift. If the prompt is too narrow without the right repo context, they will miss implicit invariants. The balance is the craft. The block below is a **real shape** we have used: it names the phase, ties it to a larger plan without dumping the whole document, and asks for exploration plus an implementation plan that includes git mechanics and prerequisites. > This is one slice of our **production-readiness** work for **Golf Round Finder**. A fuller breakdown lives in a separate planning doc; your job here is to go deeper **only for this phase**. > > **Phase name:** “Phase J: Provision production resources (real accounts and infrastructure)” > > Do a **detailed exploration of this codebase** and produce a **concrete implementation plan** for this phase: what to build, what to touch, and in what order. > > The plan must include **how we will use git**: branching, commits, and PRs that match the steps (small, reviewable changes where possible). > > It must also list **everything we need before we start**: environment variables, keys, cloud accounts, services, quotas, DNS, or access, anything that could block provisioning or deployment. > > Attach the **excerpt from our meta-plan** that defines scope for this phase (goals, constraints, dependencies on other phases, “done” criteria). Treat that text as authoritative for boundaries; push back in the plan if the repo contradicts it. When you run this prompt, paste the real excerpt after the quoted instructions (or inline in the same message). A placeholder might look like: ```text title="phase-excerpt.txt" Phase J — goals: … Out of scope: … Depends on: … Done means: … ``` You would replace that stub with text copied from your approved meta-plan. The phase name in the prompt doubles as the **workspace label** when you split work across directories or Cursor roots. --- ## Layer 3: One workspace per phase (prompt plus operations) Give each phase its **own workspace** (or an equivalent isolation pattern). The goal is bounded context: the agent should not “helpfully” refactor adjacent areas or blur two phases into one diff. Each workspace should carry not only the phase prompt but the **operational glue** your team already relies on: - **Git** conventions: branch naming, commit granularity, when to rebase versus merge, PR size expectations. - **Migrations and flags**: how you roll forward safely, and what “off” looks like. - **Tophatting**: exploratory manual validation (clicking the path, sending the request, reading the trace), whatever your culture calls proving it in a real environment. - **Org-specific gates**: security scans, change windows, approvals.
Then another **human gate**, at detail level: someone reads the phase plan the way they would read a design doc. What files move? What could break in production? How would we notice? Agents are fast; **review** is still O(human attention), and that is appropriate for the layer where execution starts to touch users and data. ```mermaid title="pipeline.mmd" figure="fig-pipeline.svg" alt="Hand-drawn chalk flowchart of the pipeline in order: meta-plan, human approved; testable chunks; phase prompts, codebase scoped; one workspace per phase plus ops context; human review per phase; staff-level readiness pass; execute phases in order and verify." caption="The pipeline in order. Every arrow is a place to stop and check." %%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart TB MP[Meta_plan human approved] CH[Testable chunks] PP[Phase prompts codebase scoped] WS[Workspace per phase plus ops context] HR[Human review per phase] SR[Staff_level readiness pass] EX[Execute phases in order verify] MP --> CH --> PP --> WS --> HR --> SR --> EX ``` --- ## Layer 4: A staff- or principal-level readiness pass (still an agent, still not infallible) Even with good phase prompts, blind spots cluster around **integration seams**: partial deploys, two services’ assumptions about timeouts, the difference between “works in staging” and “safe in prod,” and the boring steps nobody wants to put in a ticket. That is where a **staff-engineer persona** prompt helps. Use an agent session structured to **challenge** the combined plan: missing failure modes, unclear ownership, places where observability or rollback is weak, ordering risks, and anything that assumes perfect humans on the other side of a handoff. Ask it to **improve** the meta-plan and phase prompts until the critique stabilizes: fewer **new** gaps each pass. This is not a rubber stamp. It is **compression**: you are hiring pattern-matching against a large slice of “how big systems fail,” with the understanding that the model can still hallucinate confidence. Treat the output as a **review artifact** to fold back into human-owned plans, not as authority. A **staff-style readiness prompt** we have used looks like this (edited for clarity). You attach the **current** meta-plan or phase bundle as context; the model’s job is to score readiness and **revise the plan text**, not only to compliment it. > Review the attached plan as if you were a **principal or staff engineer** who knows this system and cares about shipping the **best** code and architecture we can: maintainability, operability, and correct sequencing included. > > **First**, give an explicit **readiness assessment** for implementation: what is solid, what is ambiguous, what is missing or risky, and whether you would let the team execute as written. > > **Then** update the plan itself: add, remove, reorder, or sharpen sections so the document is fit to execute. Prefer concrete edits over generic advice. Run this **after** humans have done a first pass, not instead of one. The rating is a forcing function; it is still a model, not a staff engineer’s sign-off. --- ## Execution: press “build” one phase at a time When the layers above are in place, execution should feel almost boring. You have **context-bound** workspaces, **scoped** prompts, and **explicit** verification. Run phases **in order**. After each phase, run the checks you wrote when you were thinking clearly, not the checks the agent suggested at 11pm. If something fails, fix **forward** in the smallest responsible step, and update the plan when reality diverges. ### Plans and prompts are not set in stone Meta-plans and phase prompts are **hypotheses**, not tablets. They should **change** as you put work into the world: each phase teaches you something about the codebase, the platform, and the seams between services. When what you ship diverges from what you wrote down, **fix the document**; otherwise the next agent session starts from a map everyone quietly knows is wrong, and compound error shows up again. Treat updates as normal. A phase finishing is a good moment to **reconcile** the meta-plan and any phase prompts: what did we learn, what is no longer in scope, what new risk appeared, what order should shift? The staff-style pass (Layer 4) is not only for day one; you can run a lighter version after major milestones if the program is still large. ### Version history belongs in Git The easiest way to keep that history **honest and inspectable** is to keep plans in a **Git repository**. That might be the same repo as the product (many teams use a `docs/`, `planning/`, or `runbooks/` tree) or a separate internal repo if that matches how you manage design docs. What matters is that changes are **committed**, not pasted into chat and lost. Git gives you **diffs and blame**: you can see how the plan evolved, recover earlier wording when someone asks “why did we decide that?”, and open **pull requests** for substantive edits so plan changes get a second pair of eyes, similar to code. Linking plan commits to phase completions or merge commits is cheap traceability: future you (or a new teammate) can walk from “what we thought” to “what we shipped” without archaeology in Slack. That is the practical meaning of **meta-planning** here: humans anchor truth at the top, agents accelerate drafting and iteration in the middle, and **discipline** at the bottom (one phase, one verification, one merge at a time, with **documents that stay tied to reality**) is what keeps the system honest. --- ## Further reading - Barbara Minto, *The Pyramid Principle*: conclusion-led structure and MECE thinking for plans, not just slides. - *The DevOps Handbook* (Kim, Humble, Willis, Debois): why flow and feedback loops reward small, verifiable batches (a useful mental match for phased execution). --- URL: https://blog.leanrob.com/posts/multi-cadence-delivery-partial-validation-enterprise-boundaries/ # Multi-cadence delivery: partial validation when the UI outruns the API > When app and platform teams ship at different speeds, POs and QA get squeezed between partial surfaces and full acceptance. Here is how to name the failure modes, shrink the gap where you can, and handle the enterprise seam honestly. - URL: https://blog.leanrob.com/posts/multi-cadence-delivery-partial-validation-enterprise-boundaries/ - Published: 2025-07-15 - Tags: engineering, delivery, architecture, quality - Reading time: 7 min - Author: Robert Byrne You have seen the ticket: the screen needs filters, pagination, or a new field today, but the “Enterprise Services” API will not return that shape until next quarter. Or the reverse: the platform shipped a capability nobody can reach yet. Different parts of the system **do** get built at different cadences. That is not a people problem first; it is a **queue and ownership** problem. It becomes a people problem when nobody names what can be validated at each step, and POs and QA are asked to pretend a mock is the product. This post is written for **IC engineers and tech leads** who own sequencing across UI, services, and shared platforms. You already like **full-stack, same-team** delivery because it shortens feedback loops and shrinks the gap between “we agreed” and “it runs.” Many organizations still split **product engineering** from **platform or enterprise services**. The playbook below assumes that seam exists: you will see how misaligned cadences show up, what breaks, and what to do about it, technically and in conversation with POs and QA. --- ## The tension in one sentence **Vertical slices** are the comfortable story: one team ships a thin, end-to-end increment that is testable and demoable. **Staggered layers** are the common reality: the UI team, the API team, and the platform team each have their own backlog, velocity, and release train. When those timelines do not line up, someone is asked to accept **partial validation**, and that is where conflict shows up. --- ## Why cadences diverge Split cadences are rarely mysterious. - **Different owners and backlogs.** The mobile or web squad plans sprints around UX milestones; the integration or platform group plans around contract stability, data migrations, and operational risk. - **Different risk profiles.** Shipping a UI change is cheap to roll back; changing a canonical enterprise schema is not. - **Dependency chains that do not respect org charts.** The product needs a query parameter before the platform exposes the matching filter semantics. The platform shipped an event nobody consumes yet. None of that requires bad intent. It does require **explicit** handling of the gaps. ```mermaid %%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart TB subgraph app [Product_app] UI[UI] BFF[App_API_or_BFF] end subgraph platform [Enterprise_services] ES[Platform_APIs] Data[(Data_stores)] end UI --> BFF BFF --> ES ES --> Data ``` The diagram is the easy part. The hard part is the **calendar**: three teams, three burndowns, three definitions of “done.” ```mermaid %%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart LR subgraph t1 [Team_A_UI] U1[Milestone_U1] end subgraph t2 [Team_B_app_API] U2[Milestone_U2] end subgraph t3 [Team_C_platform] U3[Milestone_U3] end U1 -.->|desired_order| U2 U2 -.->|desired_order| U3 ``` Solid sequencing is rare. More often, **U1** lands before **U3** exists, or **U3** lands while **U1** is still in design. --- ## Failure modes when things ship out of order ### UI before the API (or before the real contract) The product adds parameters, screens, and empty states against a **future** contract. Engineering proves behavior with mocks or a stub. Risk: the team **confuses** “green in CI” with “safe in production.” QA may correctly refuse to sign off because the integrated path does not exist yet. Staggered delivery often **doubles QA’s calendar** for the same feature: one pass when only the client path exists (mocks or partial data), and a **second** pass when the real API or contract finally lands, plus any regression work in the gap. The gantt below is schematic; the point is two validation windows where a vertical slice would have been one. ```mermaid %%{init: {"gantt": {"useWidth": 900}, "themeVariables": {"fontFamily": "inherit"}}}%% gantt title UI ahead of API: two QA passes for one feature dateFormat YYYY-MM-DD axisFormat %b %d section Delivery UI in staging :ui, 2026-03-02, 5d Real API in shared env :api, 2026-03-23, 4d section QA same feature Pass A partial mock_or_stub :qa1, 2026-03-02, 5d Pass B full integration :qa2, after api, 5d ``` ### API or platform before the UI Backend capacity ships ahead of the experience. Nothing is wrong with the service in isolation, but **value is stranded** until something calls it, and integration tests may not cover the real client. Here the same **two-pass** pattern appears with the order flipped: QA can exercise the service or contract early (Postman, contract tests, synthetic clients), then must **re-validate** the full journey once the UI or app wires the behavior; again, roughly **twice the touch** for one capability. ```mermaid %%{init: {"gantt": {"useWidth": 900}, "themeVariables": {"fontFamily": "inherit"}}}%% gantt title API ahead of UI: two QA passes for one feature dateFormat YYYY-MM-DD axisFormat %b %d section Delivery Platform or API live :api, 2026-03-02, 5d Client UI wired :ui, 2026-03-18, 5d section QA same feature Pass A service_or_contract_only :qa1, 2026-03-02, 4d Pass B end_to_end journey :qa2, after ui, 5d ``` ### QA in the middle Test plans assume a stable environment where the full path works. With staggered delivery, QA is asked to test **A** while **B** is still a ticket on another board. Without a named policy, every bug becomes a **routing** argument: app versus platform versus environment. ### PO and acceptance pressure POs are scored on outcomes customers can use. **Partial validation** feels like shipping debt. If the team never translates “phase A” into explicit acceptance criteria, POs fall back to binary “feature done,” and engineers hide behind “blocked by platform.” --- ## Full-stack, same-team delivery: the smaller gap When one team owns UI and API for a product slice, you get: - **One backlog** and fewer handoffs. - **Shared mental model** of the contract as it evolves. - **Faster correction** when the wrong abstraction was chosen on day one. Treat that as the **comparative ideal**, not a moral lecture. In large enterprises, platform consolidation and compliance often **require** a separate services org. Your job is not to win an org-design debate in a blog-shaped box; it is to **reduce coupling pain** where you sit. --- ## Enterprise reality: name the seam If data flows through a platform you do not own: 1. **Name the boundary.** Who owns incidents when the contract drifts? Where do tickets land when latency or schema breaks a downstream client? 2. **Prefer written contracts** over hallway agreements. OpenAPI specs, async schemas, or explicit versioning policy beat “we will add that field when we can.” 3. **Clarify who proposes a change.** The app team often discovers the need; the platform team owns the blast radius. Consumer-driven expectations (the app team publishes the shape it needs) reduce thrash. --- ## Playbook: avoid, mitigate, handle ### Avoid: slice work so something is end-to-end testable, even if narrow Prefer a **thin vertical slice** over a broad horizontal layer. A small feature that hits real wire (even with limited scope) beats a large UI that only ever saw mocks. ```mermaid %%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart TB subgraph thin [Thin_vertical_slice] v1[One_user_path] v2[Real_API_call] v3[One_platform_field] end subgraph wide [Wide_horizontal_slice] h1[Many_UI_screens] h2[Mocks_only] end ``` If you cannot get the full filter set, ship **one** filter against a real endpoint and grow from there. ### Mitigate: stubs, contracts, environments, flags - **Stub servers or contract tests** so the client team can pin behavior **before** the platform is ready, without pretending the stub is production. - **Feature flags** (see also release and rollout thinking elsewhere on this site) to separate “merged” from “visible,” so partially integrated code does not become a surprise launch. - **Dedicated integration or staging paths** where both sides meet on a **known** build. “Works on my machine” is not a policy; “works in env X with builds A and B” is. ### Handle: make partial validation explicit for PO and QA Write down, per increment: - **What is validated** (which path, which environment, which data). - **What is explicitly not validated yet** (which calls still hit mocks or return empty). - **What “done for this phase” means** versus “done for the customer promise.” That turns a stressful ambiguity into a **schedule and risk conversation**. QA can sign what is signable; POs can align stakeholders on phased value. Engineers stop treating “blocked” as a personality trait. --- ## Honesty as a system property Partial validation is not shameful; **undiscussed** partial validation is how trust erodes. The fix is not only technical; it is **legibility**: who owns what, which environment is the contract of record, and what “green” means at each step. If you take one line into your next planning meeting, try this: **“Here is what we can demonstrate end-to-end this sprint; here is what remains on another team’s timeline; here is how we prevent false confidence in between.”** That is the kind of sentence that keeps QAs and POs in the loop without asking them to bless fiction. --- ## Further reading (light touch) - Team and platform dynamics are a whole literature; for a starting mental model, *Team Topologies* (Team of Teams style) pairs well with hard platform boundaries. - For incremental replacement of large systems, Martin Fowler’s **Strangler Fig** pattern describes how to grow capability without a single big bang. These are pointers, not prerequisites; the concrete moves here are **contracts**, **thin slices**, **named environments**, and **explicit validation phases**. --- URL: https://blog.leanrob.com/posts/beyond-the-build-adoption/ # Beyond the build: adoption and developer culture > A practical guide to driving organization-wide engineering change, from planning and consensus to implementation, evangelism, and what breaks when you skip a step. - URL: https://blog.leanrob.com/posts/beyond-the-build-adoption/ - Published: 2025-06-04 - Tags: culture, engineering, adoption, leadership - Reading time: 9 min - Author: Robert Byrne Some changes stay inside a Pull Request; others reshape how your organization decides, tests, and ships. The “something” might be Architecture Decision Records (ADRs), a shared platform, reliability or security norms, release policy, or anything that changes the default path for many teams, not one service in isolation. If you’re a tech lead, a staff-plus engineer, or a program lead driving standards across teams, treat this as a working map: you can **audit** an active initiative against the three stages below and see where you’re under-invested before you declare success. That’s a slow, political class of problem, and it’s easy to underestimate. Nobody hands you a clean RACI spelling out who’s responsible, accountable, consulted, and informed for “change how we engineer”; you earn alignment in hallways, docs, and incident reviews as much as in roadmaps. At staff scope especially, “done” often means **other teams’ behavior** and **durability**: the initiative still holds when you’re not in the room, not only that your own squad shipped. This is a map of the work, not a promise of outcomes: three stages, what “done” tends to feel like, and how things fail when you skip or rush a step. --- ## The three stages of wide-scale change **Plan and align** so the change is bounded, understood, and owned before it spreads. **Implement** in real systems, or coordinate owners so it lands consistently. **Evangelize** so the change survives contact with real teams and doesn’t die in a folder nobody opens. Skipping planning feels fast until you’re re-explaining the same decision in every retro; skipping implementation leaves you with philosophy; skipping evangelism leaves you with a wiki and a prayer. The sections below unpack each stage. --- ## Change implementation in detail Organization change is messy in practice; the sections below unpack the same sequence in detail. ### 1. Make a plan, get consensus, and collaborate #### How to approach it Name the problem plainly: what hurts, for whom, and what would feel different if this worked. Scope a first version on purpose: what’s in, what’s explicitly out, and what you intend to learn next. Talk to someone who has walked a similar path before[^staff-path]. Buy-in rarely lands in one meeting: **first draft**, **iterate with collaborators until you’re confident**, **bring in leadership and broader stakeholders until you’re ready to execute**, then **define the execution timeline**. Sketch: ```mermaid %%{init: {"flowchart": {"curve": "basis", "padding": 8}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart LR A[First draft] --> B[Iterate with collaborators] B --> C{Confident?} C -->|No| B C -->|Yes| D[Leadership and broader stakeholders] D --> E{Execution ready?} E -->|No| D E -->|Yes| F[Define execution timeline] ``` **Takeaway:** iterate until you’re confident before you widen to leadership and stakeholders; lock an execution timeline only once execution is actually ready. Write for the audiences you have; staff, leads, and managers rarely need the same document. Build consensus with the people who will live with the consequences: service owners, on-call, release, hiring. Collaboration here isn’t one permission meeting; it’s shared trade-offs, including ugly ones. Before you move on, agree on success criteria you can observe: fewer incidents, faster feedback, fewer exceptions, whatever fits the change. #### What you can expect when this step is done You’ll have a shared _why_, not only a _what_. Teams that matter had room to push back, and you folded that in or wrote down why not. You’ll have a credible sequence: who goes first, what depends on what, and what “first” means. The plan should cover pain and cost, the agreed direction, stakeholders, measurable success, and named owners and affected teams. #### What can go wrong **Consensus theater**: meetings where everyone nods but nobody commits. Mitigate with real buy-in, including from leadership when you can: short, prepared sessions with a concrete proposal and evidence, not a vague ask. **Analysis paralysis**: the plan never gets small enough to ship. A shared breakdown (tickets or a sheet) with a couple of devs for a day or two often unsticks it. **Silent veto**: people who weren’t in the room block you later. You can’t always avoid it; sometimes the org quietly shelves the work and you regroup. Showing value over time keeps you credible for the next attempt. **Over-promising**: the plan assumes every team has the same capacity and skill. Smaller tickets and less ambiguity surface that early; don’t pretend one size fits all. --- ### 2. Implement: in code or through coordination #### Implementation: put your money where your mouth is It has to land in real systems: templates, linters, CI defaults, scaffolding, libraries, golden paths, not only a wiki under pressure. Make the right path easier than the old one; where you must, raise the cost of the wrong path with lint, reviews, or gates, but with empathy for migration; shame isn’t a rollout strategy. If teams can’t tell whether they’re “done” adopting, they’ll optimize for whatever is easiest this sprint, which is often the old way. Instrument enough to see adoption and failure modes: who’s on the new path, what breaks, whether rollbacks are exercised. Pair **adoption** (coverage over time) with **friction** (exceptions, workarounds, noisy tickets). If friction climbs while adoption looks flat, you may be measuring theater. Loop in owners and on-call before production behavior changes; bring platform and security in early if pipelines or risk posture shift. Surprise them after the fact and you pay for it in pages and politics. Two patterns both work; what fails is mixing them without admitting it. ##### Path 1: Your team implements You drive the change across the repos that matter, mostly inside your group. You still don’t own every line in the company: treat code owners as partners (interfaces, timelines, review load) before you flood them with diffs. Carry clear milestones and a definition of done per place that people can repeat without improvising, or you get “we shipped in our repo” while the org stays on the old path. ##### Path 2: You farm work to other teams You delegate to owners. That only works if they bought in early enough to _schedule_ the work, not just nod. Roadmaps clash; “we agree in principle” isn’t capacity. Negotiate dates and document who owes what by when. Start where momentum is easiest: teams that feel **real pain**, have a **bounded blast radius** if you misstep, and **opted in**, not groups you “volunteer” by surprise. That lines up with starting with sympathetic, innovative cohorts[^devops-handbook]. When someone asks “why them first?”, answer with **criteria** (pain, readiness, capacity) and a rough **order of march** for who’s next, so it doesn’t look like favoritism. Often the **main team** carries the foundation first; **once that track is far enough along**, the other two teams **pick up their slices in parallel** while the main team finishes. The shape is common: ```mermaid gantt dateFormat YYYY-MM-DD title Illustrative rollout across teams section Main team Foundation and core :a1, 2026-01-06, 33d Conclusion :a4, 2026-03-20, 10d section Team B Feature slice B :a2, 2026-02-01, 28d section Team C Feature slice C :a3, 2026-02-15, 35d ``` **Takeaway:** the main team carries foundation and wrap-up; other teams start their slices once the foundation is far enough along. Your calendar will differ. Tickets aren’t fire-and-forget. You’re still accountable for landing the change: unblock, keep the rollout alive, and sign off on completion against agreed criteria, not an endless “almost done.” If you’re always the one explaining the program, you don’t yet have a **program**; you have a **personal tour**. Get peers and sponsors carrying the story too. Partial work and silent drops are what you get when you walk away too early. #### How to know your change has been fully implemented There’s working code or infrastructure, not only slides. Teams can apply the pattern with examples they can copy; edge cases are handled or explicitly deferred with a visible plan. If you led implementation, evidence spans the repos you owned and owners aren’t left with surprise debt. If you delegated, each team met its slice _and_ the org-wide picture matches the plan: bounded scope, real exit, so the program doesn’t drift forever. #### Possible implementation pitfalls **Partial implementation**: one team moves; others don’t; two incompatible worlds. **Big-bang failure**: a huge switch with no rehearsal or rollback story. **Coordination debt**: “someone else was supposed to,” but nobody owns the outcome. **Tooling without teaching**: CI fails people with no path to green, and frustration is all they remember. --- ### 3. Evangelize and foster adoption #### Communication and hope Meet people where they are: demos, office hours, posts in channels where team leads actually read. Repeat the _why_ over and over, it may be boring to you but newcomers weren’t in the room when the decisions were made. You need a **sponsor** who can clear priority and a **champion** in each pocket of the org who can answer without you; otherwise you’re always the bottleneck. Map the **shadow org chart** once: who can quietly block exceptions, which forum actually moves decisions. Make feedback easy and close the loop; black holes kill trust. Celebrate real wins (migrations, metrics) so it feels shared, not mandated. The goal isn’t applause; it’s that asking for help on the new path is easier than routing around it. #### When you’re done spreading the word New hires and existing teams should hit the new default without a private tour from you. Questions get predictable enough to document; surprises shrink. The old way should feel deprecated, not equally valid forever. #### Adoption is hard; don’t beat yourself up Talk isn’t enough; you may need to **review** work over time so adoption stays real. Mandates produce paper compliance and workarounds. **Premature victory** is declaring success when only friendly teams moved. **Burnout** is a tiny group policing everyone; senior allies have to share the load. **Scope creep after “go live”** erodes trust; if you’re constantly re-litigating in PRs, pause and reset the message. It’s also OK to **pause, narrow, or stop** when the same objections loop without new learning, no sponsor will own capacity, or teams keep routing around the standard: exit cleanly, document what you learned, and don’t poison the next attempt. The old way will defend itself in review; expect friction that isn’t always technical. --- ## If you get it wrong: risks and common confusions ### Risks Done badly, this **wastes time**: big builds nobody uses, or shadow processes that pretend alignment while teams do something else. **Cynicism** follows when “we tried that initiative” becomes shorthand for “don’t bother me with change.” **Uneven quality** widens when easy adopters pull ahead and stragglers fall behind, sometimes by skill, sometimes by incentives you didn’t mean to create. **Security and compliance** suffer when auditors see one story and production sees another, because people optimize for what actually hurts when it breaks. ### Confusions worth clearing up **“We shipped it” ≠ “it’s adopted.”** Shipping is a milestone; adoption is behavior over time. **Process isn’t culture**: slides don’t change habits; **systems and incentives** do. **Consensus isn’t unanimity**: you need enough alignment to move and a clear dissent path, not infinite meetings. **This isn’t a hero arc**: sponsors, champions, and durable ownership matter when the ADR author is on vacation. --- Driving change is **build, implement, and adopt**; skip a leg and good ideas die quietly. Get the rhythm right and you’ll still have hard days, but fewer where you wonder why nobody uses what you built. The point isn’t perfection; it’s that each stage gets a deliberate slice of your attention before you call the program a win. **Next step:** pick one initiative you own and score each stage honestly; schedule the smallest concrete fix for the weakest leg, then revisit after the next milestone. --- [^devops-handbook]: Gene Kim, Jez Humble, Patrick Debois, and John Willis, _The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations_ (IT Revolution, 2016). Part II (“Where to Start”) focuses on choosing a value stream and shaping the organization so change lands, **starting with the teams and environments where you can build momentum** before you scale. [Goodreads](https://www.goodreads.com/book/show/26083308-the-devops-handbook). [^staff-path]: Tanya Reilly, _The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change_ (O’Reilly, 2022). The book is explicit that staff-level impact leans heavily on **relationships, judgment, and learning how others navigated comparable situations**, including when you’re charting unfamiliar organizational or technical terrain. [Goodreads](https://www.goodreads.com/book/show/61058107-the-staff-engineer-s-path). --- URL: https://blog.leanrob.com/posts/the-quiet-win-of-regular-syncs-outside-your-usual-lane/ # The quiet win of regular syncs outside your usual lane > Why a small recurring cadence with product, design, or peers in another part of engineering (and with mentors or mentees) beats hoping alignment happens in Slack, and how to show up as a person, not only a role. - URL: https://blog.leanrob.com/posts/the-quiet-win-of-regular-syncs-outside-your-usual-lane/ - Published: 2025-05-19 - Tags: career, communication, culture - Reading time: 8 min - Author: Robert Byrne If you spend most of your day in code reviews and standups, your picture of the org can get narrow. Product, design, customer success, sales, and operations see different pressures than your squad does, but so can **another engineering team**, a **tech lead** you rarely ship with, or a **mentor** or **mentee** who is not on your calendar by default. A **regular sync** with one of those people is a quiet win: not a dashboard metric, but fewer surprises, less rework, and trust that compounds when you are not in the same Slack channel or retro. This is not a pitch for more meetings for their own sake. It is a case for a **small, predictable rhythm** with someone **outside your usual lane** (cross-functional partners, engineering peers you depend on but do not sit next to, or someone you are learning from or investing in), plus a little prep, a little calibration, and a few notes afterward so the next conversation starts warmer and clearer than the last. --- ## What counts as a sync Think **short and recurring**: fifteen or thirty minutes on the calendar, often weekly or biweekly, with a clear counterpart. Examples: - **Cross-functional**: A PM you ship with, a designer on your surface, a CS lead who sees customer pain. - **Inside engineering**: A senior or staff engineer whose judgment you want in the loop, a platform or infra owner, a lead on a team your work touches, someone you pair with rarely but whose constraints affect your roadmap. - **Mentorship**: Someone you want to **learn from** (formally or not) or someone you are **helping grow**; the sync is where growth and feedback get airtime, not only ticket chatter. The point is **continuity**, not a status parade. You are not trying to replace the backlog or the design file; you are making space for what does not fit cleanly into tickets: priorities, risk tolerance, how rough a prototype can be, career direction, or what “good” looks like for a skill you are building. Treat them as a **partner**, not a ticket source (or a box to check for HR). When that framing lands, the sync stops feeling like surveillance and starts feeling like shared work. --- ## Same habit, different conversations The **rhythm** is the same; the **content** shifts with who you are sitting with. **Cross-functional** syncs skew toward **context you do not get in standup**: customer language, commercial pressure, how success is measured outside engineering, and what would make their job easier when you push back on scope. You are translating between worlds. **Engineering peers** (different team, stack, or level) skew toward **technical and organizational reality**: who actually decides, where the bodies are buried in the codebase, how incidents get handled, what “done” means for that service, or how promotion and impact are visible from another chair. You are widening your map of the engineering org, not only your squad. **Mentorship** syncs skew toward **growth and feedback**: goals, gaps, stories from their path, specific skills to practice, and sometimes harder truths that need a dedicated slot, not a drive-by in the hallway. Whether you are the mentor or the mentee, a little structure helps: one standing question (“What felt stuck?” / “What do you want feedback on?”) keeps it from dissolving into vague cheerleading. You can calibrate rapport the same way in all three: some people want zero fluff; others want a real minute before you dive in. The next section still applies. --- ## Before and during: read the room, read the person **Before** the slot, spend a minute on intent. What do you need from this conversation? What is one thing worth surfacing early? If you have been taking light notes (see below), skim them so you are not reinventing the relationship from zero every time. **During** the sync, match the **person**, not a generic idea of “professional.” The list below is a **loose map**, not a personality test. People are **complex**: someone can be direct on Tuesday and chatty on Thursday, or sharp in a crisis and soft in a one-on-one. Use it as a set of **hypotheses to test with your eyes and ears**, not labels to pin on anyone. ### A loose map of styles (heuristics, not types) | What you might notice | One way to respond | | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Short answers, fast pivot to work**, little appetite for preamble | Lead with the ask or decision; keep context tight; skip “how was your weekend” unless they open the door. | | **Warm-up time**: asks how you are, shares a bit of life first | Offer a genuine minute back, then **transition** clearly into the work so the sync does not dissolve into chat. | | **Wants data, edge cases, and “what happens if…”** | Bring options with tradeoffs; say what you do not know yet; avoid hand-wavy reassurance. | | **Thinks in stories and “why”** before tactics | Match the altitude: connect to purpose or customer, **then** narrow to the next step. | | **Softens hard news** or hedges a lot | Listen for what is **not** being said; ask one direct, kind question rather than filling the silence with your own anxiety. | | **Clearly overloaded**: late, distracted, jumping topics | Shrink scope to **one** outcome; offer to follow up async; do not treat scattered attention as disinterest. | | **Formal or cautious** in mixed company | Mirror their register; keep jokes and hot takes in check until you have shared norms. | | **Playful or blunt** when they trust the room | You can loosen up **if** it is reciprocal; still keep commitments and respect explicit. | Treat rows as **overlapping tendencies**, not boxes. Someone can be analytical _and_ relational; a stressed week can look like “direct” when it is really “overloaded.” Update your read when evidence changes. Over time, notice **favorite topics** or recurring threads. You are not building a dossier; you are remembering that they care about running, or sourdough, or a side project, so you can pick up a thread naturally next time instead of forcing rapport from a blank slate. “Appropriate” depends on context. Remote and in-person feel different; so do cultures and team norms. The goal is the same: **use your judgment**, read cues, and stay bounded. Rapport serves the working relationship. Forced intimacy does not. --- ## After: post-sync notes and forward planning When the meeting ends, capture a few things while memory is fresh. Keep it **lightweight**: a note in your docs, a private page in your notes app, whatever you already use. The habit matters more than the tool. Useful categories: - **How they work.** Do they want bullets or narrative? Do they like detail up front or a headline first? What tends to stress them? Write what helps you **collaborate better**, not gossip. - **Threads they enjoy.** Topics they light up about, so you can reconnect without awkwardness when there is space. - **Your own reminders.** What you promised, follow-ups you own, risks, and half-finished debates worth revisiting. - **Next time.** A line or two: open questions, themes to return to, or “pick up X when we meet.” That is your **forward plan** so the rhythm compounds. For mentorship, you might add **growth threads**: what they are working on, what you committed to watch or review, or what feedback you owe next time. Memory can be a kindness when it is respectful and proportionate. If a note would feel wrong if they read it over your shoulder, it does not belong in the file. --- ## What you get (when it works) These are **observations**, not guarantees. Organizations differ. You tend to get a **shared mental model** of what matters this month, not only what the board says in a deck. You hear **weak signals earlier** (customer tone, sales pressure, a design constraint, or an org shift in another part of engineering) before they become a fire drill. Handoffs get **cleaner** because names and expectations line up. With mentors or mentees, you get **progress you can point to** instead of hoping growth happens in the gaps between tickets. Escalations often shrink because fewer problems are surprises. None of that requires you to become best friends with everyone. It requires a steady beat and enough humanity that people will tell you the messy parts. --- ## Objections you might have **“I do not have time.”** A short recurring slot often **replaces** ad hoc pings, thrash, and emergency meetings. If it does not, shorten the cadence or merge topics, but try the rhythm before you dismiss it. **“Slack is enough.”** Slack is great for speed and terrible for nuance, tone, and the kind of trust where someone tells you what they are actually worried about. Async has its place; it does not replace a focused conversation. **“My counterpart is hard to work with.”** A sync will not fix a broken relationship by itself. It can still reduce ambiguity. If the dynamic is toxic, that is a different problem: document, escalate, or get help; do not treat coffee chat as therapy. --- ## How to start (and when to stop) Pick **one** high-leverage person. Propose something small: “Can we put twenty minutes on the calendar every other week?” Bring a short agenda the first time so the intent is clear. Iterate: if weekly is too much, go biweekly; if you only need monthly, do that. Stop or change the cadence when the sync **stops earning its keep**: same information could be an email, or the relationship is healthy enough that you have other channels. There is no medal for keeping a useless meeting alive. --- ## A next step If this resonates, book **one** recurring slot with someone **outside your usual lane**: a PM, a designer, an engineering peer you depend on but rarely talk to, or a mentor or mentee if you have been meaning to make that real. Before you go in, write down three bullets: what you need, what you owe them, and one human detail you remember. Afterward, add three lines to your notes. That is the whole system: small rhythm, calibrated rapport, and a little memory so the next sync starts better than the last. --- URL: https://blog.leanrob.com/posts/welcome/ # Why this blog > What this site is for, what I’ve learned along the way, and what you can expect to read here. - URL: https://blog.leanrob.com/posts/welcome/ - Published: 2025-04-20 - Tags: welcome - Reading time: 2 min - Author: Robert Byrne This site exists for a simple reason: I’ve picked up a lot of lessons over the years, some the hard way, some the easy way, and plenty by watching other people’s mistakes so I didn’t have to repeat them. I’m writing here to share that in one place, in public, where it might help someone else the way other people’s writing has helped me. Software engineering rarely moves in a straight line: you ship, reality pushes back, and you learn from both what breaks and what holds. The loop looks roughly like this: ```mermaid %%{init: {"flowchart": {"curve": "basis", "padding": 12}, "themeVariables": {"fontFamily": "inherit"}}}%% flowchart LR A["🚀 Build & ship"] B["📡 Real-world feedback"] C["⚠️ Mistakes & friction"] D["✅ Successes & validation"] E["🧠 Learn & refine"] A --> B B --> C B --> D C --> E D --> E E --> A classDef stepBuild fill:transparent,stroke:#5a7a96,color:#5a7a96,stroke-width:1.5px classDef stepSense fill:transparent,stroke:#6f7783,color:#6f7783,stroke-width:1.5px classDef stepHard fill:transparent,stroke:#8f5f6a,color:#8f5f6a,stroke-width:1.5px classDef stepWin fill:transparent,stroke:#5f7a5f,color:#5f7a5f,stroke-width:1.5px classDef stepGrow fill:transparent,stroke:#6e5f8a,color:#6e5f8a,stroke-width:1.5px class A stepBuild class B stepSense class C stepHard class D stepWin class E stepGrow linkStyle 0,1,2,3,4,5 stroke:#7c8794,stroke-width:1.5px ``` ## What “experience” means here I’ve worked in a lot of contexts: a small room with teammates figuring everything out together, growing product teams, and large organizations with all the process and scale that comes with them. The problems change with size, but the themes rhyme: shipping, quality, people, trade-offs, and how you learn when you’re wrong. I’m **not** claiming to be an expert in everything (or anything) you’ll read about here. These posts are lessons and notes from the path, not pronouncements from a mountaintop. When I’m sure about something, I’ll say so; when I’m thinking out loud, I’ll try to make that obvious too. ## What you’ll find (for now) For the foreseeable future, most posts will sit somewhere in the overlap of **entrepreneurship**, **technology**, and **software engineering**: how we build things, how teams work, and what I’ve seen work or fail in practice. I might write about other parts of life eventually; I’m not committing to that yet. If it happens, it’ll be because it felt worth sharing, not because the blog needs filler. ## Why bother saying this in the first post A first post like this is easy to skip, but it matters to me that you know what you’re walking into: an honest record of what I’ve learned, offered in good faith, with room to revise my mind as I learn more. Thanks for reading, and here’s to the posts that come next.