# Forward-deployed teams > A forward-deployed engineer is a senior engineer from TechFabric who works on your problem for the length of the engagement, either embedded in your team or as part of a pod that owns delivery outright. They scope and build in the same motion, and the engineer in the first conversation is the one who writes the code. For: CTOs and chief data officers with a problem nobody has scoped yet Canonical: https://www.techfabric.com/services/forward-deployed --- The people in the room are the people who build it. Product engineers decide what is worth building, design engineers make it usable, and they work alongside the people writing the code. Embed them in your team, or hand us the whole programme and we will run it as a full team from our own offices. Either way there are no account managers and no handoff to a delivery team you have never met. ## What it includes - Product, design and engineering on one team - Embedded with your team, or a full team delivering from our offices - Scoping and building happen together - On AI work, the first deliverable is the goal and how it will be scored - Continuity. The same people stay with the engagement ## Questions ### How is this different from staff augmentation? Both are available, and they're priced differently. A contractor takes a ticket on work your team already owns, and we place engineers that way when it's what you need. A forward-deployed engineer takes the problem and stays with it until it's gone: they sit with the people who have it, work out what's actually wrong, and build the fix. With that you're buying judgment about what to build, not hours against a specification someone else wrote. ### We're already talking to Databricks about their forward-deployed engineers. How is this different? Databricks runs its own forward-deployed practice, and its page for it says the team co-delivers with Databricks partners where that helps. We're one of those, with 80 Databricks-certified engineers. The useful split is scope rather than skill. A Databricks FDE is there to make the platform succeed, which is the right person to want when the question is Databricks-shaped. Ours stay with the product around it: the application, the integrations, and the argument about what is worth building at all. Plenty of programmes want both, and they work alongside each other. ### How long before they are productive on our codebase? Days, not months. Our engineers average fifteen years of experience and have worked in unfamiliar enterprise codebases many times. The two-to-three week discovery exists so that ramp happens against a scoped piece of real work. ### Do we get the same people for the whole engagement? Yes, because continuity is most of what makes the arrangement worth anything. The team assigned to your project stays on your project and learns your systems, your data and your business context. We do not rotate people between accounts to balance utilisation. ### Do they join our team, or run the work themselves? Either, and the choice is yours. Our people can embed in your team, joining your standups, using your tools and reviewing your pull requests. Or we take the whole programme and run it as a full team from our own offices, delivering against outcomes while your team stays on its current roadmap. That second model is how we take on the larger builds, and plenty of engagements start as one and become the other. ### What does a forward-deployed engineer actually produce on an AI project? The permissions boundary gets drawn in the first conversation, because giving an agent reach into production data before that line exists is an incident with a date on it. What comes out of that conversation, in order: a business problem stated precisely enough to argue with, that problem turned into a scoring rubric and an environment that can run it, then the agent or workflow that scores well against it. Tooling now writes a great deal of the third. The first two still require sitting with the people who own the problem and knowing what a right answer looks like to them. ### If AI writes more of the code, why do we need your engineers? Because the constraint moved rather than disappeared. When implementation was expensive, the scarce skill was building the thing. When implementation gets cheap, the scarce skill is deciding what should be built and being able to tell whether the result is right. A wrong goal now gets implemented faster than it used to. Our engagements have gone from ten people to three on exactly this basis: the three are the ones who can define the problem, write the rubric, and judge the output. ### Is this only engineers, or do you bring product and design too? Both. Alongside software engineers we field product engineers, who decide what is worth building and cut the scope that is not, and design engineers, who make the thing usable. All three work as one team, and AI has made that team considerably smaller and faster than the equivalent staffing three years ago. Andrew Ripley runs product and Sam Salima runs design, both in house. Sam puts the design case as arriving while the engineering decisions are still open, since coming in after them leaves you decorating whatever was already decided badly. ### What size engagement makes sense? Most start with a two-to-three week discovery, which gives you a scope, an architecture and a realistic cost before you commit to anything larger. From there we put the right team on it to get things done, with daily demos so you see working software every day. That might be a single embedded engineer or a pod that owns the programme outright. If the work is Databricks-shaped there are smaller fixed-fee engagements to start from instead, and they end in a written deliverable whether or not you continue: the two-week Health Check at /databricks/health-check, the Migration Readiness Sprint at /databricks/migration-readiness, and the six-week Lakehouse Launchpad at /databricks/launchpad.