# How do you work with an embedded consultant? **An embedded consultant** should accelerate a bounded outcome without becoming the only person who can operate the result. Whether they are a vendor, contractor, or specialist, give them an internal owner from the first week, apply the team's review bar, and treat access, knowledge transfer, and the end date as core engineering work rather than administrative details. ## What outcome should the consultant own? Define an outcome that can finish, such as migrating a service group to Kubernetes, establishing a security control, or proving a platform rollout pattern. Avoid contracts that say improve infrastructure without measurable boundaries. Vague scope makes activity easy to display and durable value hard to judge. Name what remains your team's responsibility. The consultant may lead discovery and implementation, but an internal engineering owner accepts the design, operating model, and remaining risk. If no internal person has time to learn or decide, the organization is not ready to buy acceleration. It is buying dependence. Write completion conditions early. Include working software, reviewed documentation, internal operation of the system, closed access, and a known list of residual risks. Delivery is not complete merely because the consultant's tasks are marked done or the vendor presents a green status slide. ## Why must an internal owner start in week one? The internal owner provides product context, makes tradeoffs, and carries the system after the engagement. Pairing from the first week lets that person understand why choices were made. A handover near the end can transfer documents, but it cannot recreate months of judgment. For a Kubernetes migration, the owner should join architecture decisions, review automation, and run early deployments. They do not need to perform every task beside the consultant. They do need enough direct practice to challenge assumptions and operate the result without a paid interpreter. Protect the owner's capacity explicitly. Managers sometimes assign an owner in a kickoff deck while leaving their full backlog unchanged. The consultant then works alone because pairing is always postponed. Remove work, reserve sessions, and track learning milestones with the same seriousness as migration milestones. ## How should the team review consultant work? Apply the same code, design, testing, and operational standards used for internal contributors. Expertise and time pressure do not justify a private path around review. If the usual process is too slow for the engagement, improve the process for everyone rather than creating an unexamined vendor lane. Give reviewers enough context to exercise judgment. A large delivery dropped at the end invites superficial approval because rejection feels too costly. Ask for small changes, decision records, and early design review. The consultant should explain alternatives and risks, not merely cite vendor best practice. Disagreement is not disrespect. Your engineers may know local failure modes that the specialist cannot see, while the specialist may challenge habits that no longer serve the team. Resolve the technical question with evidence and a named decision owner. Do not let contract status decide whose reasoning counts. ## What transfer sequence proves knowledge moved? - Name the internal owner and backup. - Pair during discovery and the first change. - Record decisions and failure cases. - Let the internal owner lead the next change. - Run an incident or rollback exercise. - Ask the backup to use the documentation. - Close gaps before the end date. This sequence tests capability rather than document volume. A polished runbook can still fail when credentials are missing, assumptions are unstated, or the only person who understands an alert is leaving. Practice reveals those gaps while the consultant can still repair them. Spread knowledge beyond one internal owner where operational risk demands it. The primary owner may leave or be unavailable during an incident. A backup does not need equal depth, but they should know how to diagnose, escalate, and find the relevant decisions. ## Which risks need a named owner? | Risk | Named owner | Evidence before exit | | --- | --- | --- | | Architecture choice | Internal engineering lead | Accepted decision record | | Production access | Security owner | Reviewed and removed | | Vendor relationship | Commercial owner | Internal contact map | | Operations | Service owner | Observed deployment and rollback | | Knowledge transfer | Host manager | Internal team leads the work | Do not let the consultant own the risk after their contract ends. The table should contain internal names even when the consultant performs much of the work. A vendor can advise, implement, and support, but your organization must consciously accept ongoing obligations. Review the owners when people change. An access approval assigned to a former manager or a service assigned to a team that never accepted it is unresolved risk. Use the engagement steering meeting to settle ownership, not only timeline. ## How should access and secrets be handled? Give the minimum access required, through named accounts with expiration and auditability. Avoid shared credentials, copied production secrets, or informal exceptions justified by the short engagement. Temporary people often need significant access, which makes disciplined ownership more important, not less. Name an internal security or system owner who approves each sensitive permission. Record where consultant generated credentials, automation tokens, and vendor portals live. The consultant should never be the sole person able to rotate a key or contact a critical provider. Plan access removal before the final day. Review accounts, repositories, devices, environments, and customer data. Confirm removal and test that internal owners can still operate. Offboarding is part of technical completion, not a later task for someone who missed the project. ## How can status theater hide team risk? Consultants often report to executives who want confidence, while engineers experience unresolved details. A polished weekly deck can show milestones green even when internal ownership, testing, or operability is weak. Ask for evidence tied to completion conditions rather than accepting activity and presentation quality as progress. Invite the internal owner to present status in their own words. Can they explain the design, demonstrate the system, and name remaining risks? If only the consultant can narrate progress, knowledge and authority have not moved far enough. That is a project risk even when delivery dates are holding. Make uncomfortable facts safe to report. The consultant may fear that exposing a flawed assumption threatens renewal, and internal engineers may fear appearing resistant. Ask directly what will fail after departure, what remains untested, and what work the timeline currently hides. ## How do you end the engagement well? Use the end date as a design constraint from kickoff. Work backward to internal leadership, access removal, documentation tests, and final risk acceptance. Do not spend the final week scheduling a ceremonial handover after all practical decisions are already fixed. Have the internal owner lead the last production change while the consultant observes. Resolve or explicitly accept gaps. Record vendor contacts and contract boundaries so ordinary questions do not keep flowing to one departed specialist through private messages. Evaluate the engagement on durable capability as well as immediate output. The migration may be complete, but can the team deploy, diagnose, and evolve it? Share specific feedback with the consultant and vendor. Then tell the team exactly who owns the system now. ## What should a migration steering meeting reveal? A useful steering meeting reveals decisions, capability, and risk rather than reciting completed tasks. For a Kubernetes migration, ask which workloads now run, which failure modes were tested, who inside the company can deploy them, and which design decisions remain reversible. The consultant can provide detail, but the internal owner should be able to explain the current state. Demonstrate one operation in each meeting. An internal engineer might deploy a service, inspect a failing health check, or restore a prior version while the consultant observes. This creates immediate evidence about tooling, permissions, and documentation. A dashboard that says training complete cannot show whether anyone can act under pressure. Review scope movement explicitly. Specialists often discover hidden platform work after starting. Decide whether new work is necessary for the bounded outcome, whether another owner should take it, or whether the end date changes. Do not allow every discovery to become an invisible contract expansion funded by exhausted internal engineers. Ask the consultant to name the assumption they are least confident about. Their answer may expose a local traffic pattern, compliance rule, or staffing constraint that standard migration guidance missed. Ask the internal owner the same question. Differences between the answers show where context has not transferred. Include access and commercial dependencies in technical status. If only the consultant can open a vendor case, renew a certificate, or view a production cluster, the migration is not operationally ready. Assign an internal owner and prove the route works before calling the milestone green. End with a forecast grounded in exit conditions. State which internal person will lead next, what evidence they must produce, and what risk could prevent completion. Executives can still receive a concise view, but confidence now comes from demonstrated ownership rather than presentation polish. ## How do you respond when the consultant becomes indispensable? Do not punish the consultant for being useful. Map the specific dependencies: technical knowledge, access, vendor relationships, decision history, or simply more available hours. Each dependency needs a different response. Pairing addresses knowledge, named accounts address access, and capacity planning addresses work that no internal person has time to absorb. Reduce the dependency in small tested steps. Have the internal owner lead a change, then a rollback, then an incident question. Ask another engineer to follow the runbook without private help. Track every point where the consultant must intervene and convert it into owned work before the end date. If leadership chooses an ongoing support contract, keep internal accountability. External expertise can remain valuable, but the company still needs someone who can judge advice, approve risk, and change providers. Renewal should be a conscious sourcing decision, not the only way to keep a system alive. ## What are common questions? ### Should a consultant own the system after leaving? No. A named internal owner must accept the design, operations, risks, and relationships before the engagement ends. ### Can consultants use a different review process? Their work should meet the same engineering bar, with early and small reviews that let internal engineers exercise real judgment. ### When should knowledge transfer begin? Begin in the first week through pairing, shared decisions, and internal practice rather than waiting for a final handover. ### Who owns consultant access? A named internal owner should approve, review, expire, and verify removal of every sensitive access path. ### How do you know the engagement is complete? Completion requires the outcome, internal operation, tested documentation, removed access, and explicit ownership of remaining risks. Related: [working with people who are not your reports](https://isilta.com/blog/how-to-work-with-people-who-are-not-your-reports/), [working with a forward deployed engineer](https://isilta.com/blog/how-to-work-with-a-forward-deployed-engineer/), [working with a people partner](https://isilta.com/blog/how-to-work-with-a-people-partner/).