Embedding Into Agency Teams: Daily Standups, Their Tools, Their Brand

There's a word that gets thrown around a lot in agency circles: "embedded." As in, "we have an embedded developer." Most of the time, what they actually mean is "we have a freelancer we email tasks to." That's not embedded. That's outsourcing with a nicer label.

Real embedding is different. It means I'm part of your team in every way that matters, except the employment contract. Same tools, same meetings, same standards, same Slack channels. If your team doesn't know I'm not on the payroll, I'm doing it right.

What a Typical Day Looks Like

I'll use a real example. I worked embedded with a product consultancy for about two years. They built software products for startups — discovery, design, build, launch. Small team. Maybe eight people total, split across a couple of active projects.

Here's what my day looked like:

9:15 — Standup. Their standup, their format. We used a threaded async standup in Slack — what you did yesterday, what you're doing today, any blockers. Some teams do video standups. Some do walking standups. Whatever they do, I do.

9:30 — Check the board. They used Linear. Tickets were written by their product manager, refined in a weekly planning session I attended. I'd pick up the next prioritised ticket, same as anyone else on the team.

10:00-12:30 — Build. Heads-down coding. Their repo, their branch conventions (feature/PROJ-123-description), their PR template, their CI pipeline. I pushed to their GitHub org. My commits used my name but their conventions.

12:30 — Lunch. Sometimes I'd jump on a call with one of their designers to talk through an upcoming feature. Not because it was scheduled, but because that's what teammates do.

13:30-17:00 — More building. PRs reviewed by their lead dev. My PRs reviewed by me when their junior pushed code. Normal team dynamics.

Ad hoc — Client calls. Occasionally I'd join client calls as "part of the team." No special introduction, no "this is our external developer." Just another person in the meeting who happens to know why the API is returning 422s.

Adopting Their Everything

The hardest part of embedding isn't the code. It's the context switch.

Every team has its own culture, and I don't mean the ping-pong-table kind. I mean the thousands of tiny decisions that make a team function:

• How formal are Slack messages? Emoji reactions or written replies?
• Do people ask permission to refactor, or just do it?
• Are PRs reviewed line-by-line or just given a quick once-over?
• How do people handle disagreements about technical approaches?
• What time do people actually start working versus when they're "online"?

You can't ask about these things. You have to observe and adapt. In the first two weeks of any embedded engagement, I'm mostly watching. How does the senior dev write commit messages? What's the PR approval process? Who makes architecture decisions?

Then I match it. If their code uses early returns, I use early returns. If they favour long descriptive variable names, so do I. If they write tests for everything, great — me too. If they don't write any tests... well, I'll still write tests, but I'll have a quiet conversation about it rather than unilaterally changing the team's practices.

Tools I've Had to Learn

Over the years of embedded work, I've had to become competent in whatever the team uses. My personal preferences are irrelevant. Here's a non-exhaustive list of what various agencies have had me using:

Project management: Linear, Jira, Asana, Basecamp, Shortcut, Notion, Trello, Monday.com, and once — memorably — a shared Google Sheet.

Communication: Slack (mostly), Teams (occasionally), Discord (once, for a gaming client), and good old email for the old-school shops.

Design: Figma (almost always now), Sketch (less and less), Adobe XD (once, never again).

Code: GitHub, GitLab, Bitbucket. VS Code, PHPStorm. Docker, Sail, Valet, Herd. Laravel, WordPress, Next.js, Nuxt — whatever the project needs.

CI/CD: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines. Each one slightly different, each one someone's strong opinion about the Right Way to deploy.

I don't complain about tool choices. I don't suggest migrations to my preferred stack. If they're using Jira and it works for them, Jira is what we use. The moment you start pushing your own preferences, you've stopped being embedded and started being a consultant. Different role, different value proposition.

The Contractor vs Embedded Spectrum

Let me be blunt about the difference, because agencies often blur these lines:

A contractor gets a brief, disappears for two weeks, delivers some code, sends an invoice. Communication is formal and infrequent. They might not know the client's name. They definitely don't know the client's business goals.

An embedded developer knows the product roadmap. They know why feature X is prioritised over feature Y. They can anticipate what the client will want next because they've been in the planning meetings. They raise concerns proactively — "if we build it this way, the feature you're planning for Q3 will be much harder."

The embedded model costs more per hour but saves money overall. Fewer miscommunications. Fewer rewrites. Faster delivery. Less management overhead for the agency.

What Makes It Work

The embedded relationships that last years (not months) all share a few things:

Mutual respect. The agency respects my expertise and gives me autonomy. I respect their client relationships and don't overstep. Nobody's pulling rank because of an employment contract.

Transparent communication. If I'm stuck, I say so immediately. If there's a technical risk, I flag it in the channel, not in a retrospective two weeks later. If I think a deadline is unrealistic, I say it on day one, not day nine.

Consistent availability. Embedded means available. Not 24/7, but predictably. If the team knows I'm working Tuesday to Thursday, I'm reliably there on Tuesday to Thursday. I don't ghost for a day because a direct client had an emergency.

No ego. This is someone else's team. Someone else's product. Someone else's client. My job is to make them look good. If the lead dev makes a decision I disagree with, I'll voice my concern once, clearly, then commit to whatever they decide. It's their product.

The Emotional Side

I'll be honest — embedding can be weird. You're part of a team but also not. You're in the Christmas Slack thread but not at the Christmas party. You celebrate launches with people you've never met in person. You care deeply about a product that has nothing to do with you commercially.

There's a particular kind of loneliness to it that people don't talk about. You're close enough to feel like a team member but distant enough to know you're not really. When the team goes for Friday drinks, you're closing your laptop in a home office in Kent.

But the work is better for it. Being genuinely part of a team — even temporarily, even partially — produces better software than working in isolation. You understand the context. You care about the outcomes. You write code that other people on the team can maintain, because you know those people.

Why Agencies Should Want This

If you're an agency reading this, here's the pitch: an embedded developer gives you senior-level capacity without the full-time commitment. You get someone who understands your business, your clients, your codebase. Someone who can spin up fast on new projects because they already know how you work.

The alternative — briefing a new contractor every time you need dev work — is expensive in hidden ways. Every new person needs onboarding. Every new person writes code slightly differently. Every new person needs two weeks to understand your codebase.

An embedded developer who's been with you for a year can start a new project on Monday and have a PR up by Tuesday. That speed comes from context, and context comes from being embedded.

That's the whole point.

---

I've been embedded in agency teams for over a decade. If you're looking for senior development capacity you can trust, let's talk.