{
  "schemaVersion": 1,
  "articles": [
    {
      "id": "forward-deployed-engineer",
      "translations": {
        "en": {
          "slug": "what-makes-a-good-forward-deployed-engineer",
          "title": "What makes a good Forward Deployed Engineer?",
          "description": "Turning a customer problem into a working, measurable and maintainable solution: a sourced guide to FDE skills, assessment and development.",
          "intro": "When a maintenance manager says, “We need an AI assistant,” the engineering problem is still undefined. The real need might be finding historical records, avoiding equipment mismatches or reducing report preparation time. A good Forward Deployed Engineer works with the customer to turn that ambiguity into a problem the team can solve.",
          "takeaway": "A strong FDE chooses the right problem, builds the solution, measures its results in use and hands it over in a form the customer can sustain.",
          "editorialNote": "Adapted for the blog from the FDE competency report dated 3 November 2026. Employer listings describe their own expectations. The assessment and development suggestions here are proposals, not validated industry standards or claims of completed Watt2Work customer engagements.",
          "sourceNote": "Research cutoff and access date: 3 November 2026. An access date is not a publication date for an undated job listing; listings may subsequently change. Company announcements are not treated as independent evidence of success. The technical guides span several years and are not all presented as new 2026 publications.",
          "sections": [
            {
              "id": "role",
              "title": "Close to the customer’s work, responsible for delivery",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Forward deployed describes an engineer working close to a customer’s workflows and operating conditions. Some projects require time on site; others rely on regular joint development. The core responsibility is technical ownership across the problem, code, data, users and operation of the solution."
                },
                {
                  "type": "table",
                  "caption": "The typical focus of adjacent roles",
                  "headers": [
                    "Role",
                    "Primary responsibility"
                  ],
                  "rows": [
                    [
                      "Product software engineer",
                      "Technical quality and development of a product used by many customers"
                    ],
                    [
                      "Solutions architect",
                      "Translating needs and constraints into a defensible architecture"
                    ],
                    [
                      "Sales engineer",
                      "Establishing technical fit before a purchase"
                    ],
                    [
                      "Implementation engineer",
                      "Delivering an agreed installation and integration scope"
                    ],
                    [
                      "Customer success manager",
                      "Adoption, relationships and customer continuity"
                    ],
                    [
                      "Forward Deployed Engineer",
                      "Taking a customer problem through implementation, use, measurement and handover"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "These boundaries vary by company. Databricks’ June 2026 announcement places FDE work within its Professional Services approach, and Vercel’s listing also sits in that organization. When assessing a candidate, ask about actual implementation and delivery responsibility rather than relying on the team’s name.",
                  "sources": [
                    "databricks",
                    "vercel"
                  ]
                }
              ]
            },
            {
              "id": "expectations",
              "title": "The current expectation: production quality and customer outcomes",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "OpenAI’s role description connects development with production adoption and workflow impact. Anthropic’s Staff FDE listing emphasizes architectural direction and handing over systems that customers can operate. Palantir highlights breaking down open-ended problems and considering how technical decisions affect users.",
                  "sources": [
                    "openai",
                    "anthropic-fde",
                    "palantir"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Our interpretation is that a strong candidate needs depth in one area and enough breadth to work across a customer engagement. Expecting expertise in every technology is unrealistic. Knowing the limits of one’s expertise and bringing in the right specialist at the right time is a more useful requirement."
                },
                {
                  "type": "paragraph",
                  "text": "Anthropic’s Claude Frontier Academy announcement of 2 October 2026 combines a simulated enterprise application, practical assessment and a period of work on real projects. Its title, Frontier Deployed Engineer, should not be assumed to be a standardized equivalent of the general Forward Deployed Engineer role. These examples are qualitative employer signals, not research measuring industry compensation or growth.",
                  "sources": [
                    "academy"
                  ]
                }
              ]
            },
            {
              "id": "competencies",
              "title": "Eleven capabilities to look for in a strong FDE",
              "blocks": [
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Define the problem",
                      "text": "Observe who performs the work, how often and with which data. Write down the current process, baseline, data owner and exclusions. A request for a chatbot should lead to investigation before it becomes a feature list."
                    },
                    {
                      "title": "Learn the domain",
                      "text": "Learn terminology and exceptions with a subject matter expert. Distinguish measurement, calculation and interpretation. Explain which customer observation changed an initial assumption."
                    },
                    {
                      "title": "Write and debug software",
                      "text": "Explain code whether it was written directly or with an AI tool. Isolate failures across the client, application, data and external services. Present meaningful tests and a debugging example alongside the working application."
                    },
                    {
                      "title": "Own data and integration quality",
                      "text": "Handle missing, duplicate and delayed records, along with differences in units, time zones and identifiers. Test both the connection and the meaning of the data it carries."
                    },
                    {
                      "title": "Choose an appropriate architecture",
                      "text": "Compare rules, conventional software, models, retrieval-supported LLMs and tool-using agents. Make the choice through quality, latency, maintenance and cost considerations."
                    },
                    {
                      "title": "Evaluate quality",
                      "text": "Prepare representative tasks, failure cases and an acceptance set separate from development. Check for regressions when models or data change. Calibrate measurements against human judgment."
                    },
                    {
                      "title": "Make the system operable",
                      "text": "Design monitoring, versioning, retries, rollback and recovery. Make responsibilities during an incident explicit. Connect service objectives to what users need."
                    },
                    {
                      "title": "Enforce authorization and security",
                      "text": "Implement customer isolation, least privilege, secret management and logging in the application. Test that revoked access cannot be bypassed through a cached document."
                    },
                    {
                      "title": "Manage scope and cost",
                      "text": "Identify owners for data access, infrastructure, expert time and procurement dependencies. Include human review, failed attempts and operating effort in costs. Separate time saved from realized cash savings."
                    },
                    {
                      "title": "Communicate clearly and honestly",
                      "text": "Distinguish what is known, assumed and still unmeasured. Explain the effect of delays and the available options early. Record owners and dates in decision notes."
                    },
                    {
                      "title": "Build customer independence",
                      "text": "Show that someone else can install the system and perform routine changes. Turn recurring needs into appropriate shared components. Delivery should not depend on the same engineer always being present."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Useful evidence includes a problem brief, working code, data quality checks, a failure analysis, decision records and a handover rehearsal. Certifications and years of experience help interpret that evidence. For service objectives, Google’s SLO guidance provides an approach grounded in user needs.",
                  "sources": [
                    "slo"
                  ]
                }
              ]
            },
            {
              "id": "ai",
              "title": "Use AI tools and own the work they produce",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Developing quickly with AI tools is useful, but the FDE must still review the code, diagnose incorrect behavior and defend the design. Anthropic’s agent guide distinguishes predefined workflows from agents dynamically directed by a model. The simplest approach that meets the need is a useful starting point. Read this 2024 guide for its architectural principles rather than as a current inventory of tools.",
                  "sources": [
                    "agents"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Providing the model with the right sources, tool definitions and instructions is an engineering task in its own right. Context management belongs alongside source versions, conversation history, cost and access boundaries. The execution environment and task lifecycle also carry responsibilities beyond a model call.",
                  "sources": [
                    "context",
                    "managed"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Security cannot rest on a system prompt alone. A model’s request to call a tool does not establish permission to perform the action. OWASP’s LLM and agent guidance examines tool permissions, data leakage and excessive agency. With MCP, identity, consent and scope must be checked as well as connectivity.",
                  "sources": [
                    "owasp-llm",
                    "agency",
                    "owasp-agents",
                    "mcp"
                  ]
                }
              ]
            },
            {
              "id": "delivery",
              "title": "Track delivery through seven visible outputs",
              "blocks": [
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Discovery",
                      "text": "The problem, user, current process and baseline."
                    },
                    {
                      "title": "Data review",
                      "text": "Sources, a data dictionary, access rights and quality issues."
                    },
                    {
                      "title": "Scope and design",
                      "text": "Architecture, acceptance criteria, dependencies and the boundary of the first release."
                    },
                    {
                      "title": "First working version",
                      "text": "A narrow end-to-end workflow and user feedback."
                    },
                    {
                      "title": "Pilot evaluation",
                      "text": "Representative tasks, failure analysis, costs and conditions for moving forward."
                    },
                    {
                      "title": "Controlled use",
                      "text": "Monitoring, limited rollout, a recovery plan and evidence from use."
                    },
                    {
                      "title": "Handover",
                      "text": "An operating owner, training, an acceptance record and reusable knowledge."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "If a data owner, acceptance decision or operating owner is missing, record the remaining work explicitly. NIST’s Generative AI Profile is a voluntary framework for evaluation across the lifecycle. It is not, by itself, a certification or a finding of compliance.",
                  "sources": [
                    "nist-ai"
                  ]
                }
              ]
            },
            {
              "id": "measurement",
              "title": "Measure more than the number of demos",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "A useful assessment considers quality, actual use, cost and independence after handover together. Set targets after understanding the baseline and the risk of the work."
                },
                {
                  "type": "table",
                  "caption": "Select success measures together for each project",
                  "headers": [
                    "Measure",
                    "What to observe"
                  ],
                  "rows": [
                    [
                      "Time to first accepted value",
                      "Time from the start to the first useful output accepted by the user; access delays recorded separately"
                    ],
                    [
                      "Task success and critical failures",
                      "All in-scope attempts, with errors broken down by language, task type and risk"
                    ],
                    [
                      "Adoption",
                      "Eligible work completed through the system, rather than login counts alone"
                    ],
                    [
                      "Task duration",
                      "Comparable tasks before and after, including review and rework"
                    ],
                    [
                      "Cost per accepted output",
                      "Models, infrastructure, human review, operations and failed attempts"
                    ],
                    [
                      "Handover and reuse",
                      "Routine changes the customer can perform independently; components actually used in later work"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "A good average can hide a rare but serious failure. Evaluation should cover different task types, repeated runs and version changes. Staffing or process changes during the same period can also affect results: two measures moving together do not establish causation.",
                  "sources": [
                    "evals"
                  ]
                }
              ]
            },
            {
              "id": "assessment",
              "title": "Assess candidates through work that resembles the job",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "A proposed assessment has three parts: discovery around an incomplete problem, a small implementation and debugging exercise, and a discussion of architecture and handover. Roughly 40, 90 and 45 minutes can serve as a starting design. These durations are suggestions, not validated hiring benchmarks."
                },
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "How did the problem change?",
                      "text": "Ask which evidence led the candidate away from the customer’s original solution request."
                    },
                    {
                      "title": "How was the failure isolated?",
                      "text": "Examine the steps used to narrow down a production incident or a realistic failure example."
                    },
                    {
                      "title": "What happens when access is revoked?",
                      "text": "Ask the candidate to show the consequences for data, caches and tool access."
                    },
                    {
                      "title": "What can the customer do without them?",
                      "text": "Look beyond delivered documentation for evidence that someone else attempted installation and routine changes."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "AI tools may be used, but the candidate should explain the resulting work. Do not expect applicants to complete real customer work for free; longer exercises should be paid and clearly scoped. Missing evidence is not the same as demonstrated inability. Assessors should use shared behavioral criteria and set weights for the actual role. An overall FDE score should never hide a security or engineering gap."
                }
              ]
            },
            {
              "id": "seniority",
              "title": "Seniority grows with the scope of uncertainty handled",
              "blocks": [
                {
                  "type": "table",
                  "caption": "Suggested responsibility levels, not a company title standard",
                  "headers": [
                    "Level",
                    "Expected responsibility"
                  ],
                  "rows": [
                    [
                      "Developing FDE",
                      "Complete a defined integration or evaluation workflow with supervision"
                    ],
                    [
                      "Independent FDE",
                      "Own discovery, implementation, pilot evaluation and handover for one use case"
                    ],
                    [
                      "Senior FDE",
                      "Manage multiple dependencies, difficult scope decisions and stakeholders; mentor others"
                    ],
                    [
                      "Staff / Lead FDE",
                      "Guide architecture, reuse and quality across accounts or teams"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Years of experience provide context. The more useful question is which uncertainty the person can now resolve independently. Anthropic’s Staff listing offers one example through architectural responsibility spanning business lines and reviews of other FDEs’ designs.",
                  "sources": [
                    "anthropic-fde"
                  ]
                }
              ]
            },
            {
              "id": "first-90-days",
              "title": "Build a delivery story in the first 90 days",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "This development plan assumes an existing software foundation. It does not promise independent production competence in 90 days to someone starting from scratch. Customer availability and data permissions can change the schedule."
                },
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Days 1–30: define the problem and build a first version",
                      "text": "Choose a domain and narrow workflow. Observe the process, establish a baseline, prepare a data dictionary and build a small end-to-end version. If real data is unavailable, identify the use of public or synthetic data explicitly."
                    },
                    {
                      "title": "Days 31–60: make failures visible",
                      "text": "Test exceptions, access boundaries, monitoring and version changes. Compare an alternative on the same tasks. Measure quality, latency and cost, and rehearse rollback or recovery."
                    },
                    {
                      "title": "Days 61–90: evaluate and hand over",
                      "text": "Conduct an authorized user evaluation. Have another engineer attempt installation and a routine change. Document limits and outstanding dependencies. Without field permission, do not describe the work as field validation."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "A useful portfolio brings together the problem, a working example, an authorized technical review, measurements and a failure analysis. If illustrative examples replace confidential customer records, label them clearly."
                }
              ]
            },
            {
              "id": "industry",
              "title": "In energy and industry, understand the limits of evidence",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "An industrial FDE must learn equipment hierarchies, units, timestamps and the limits of maintenance records. Reading a signal does not establish a correct interpretation of its physical meaning. NIST SP 800-82 Rev. 3 addresses OT security alongside performance, reliability and physical safety. At the research cutoff, an initial public draft of Rev. 4 was also available; a draft is not a finalized revision.",
                  "sources": [
                    "nist-ot"
                  ]
                },
                {
                  "type": "callout",
                  "text": "Illustrative scenario: a maintenance engineer uses authorized historical records and technical documents to prepare a sourced review and draft report. This example contains no real plant data or completed pilot. The proposed starting scope is authorized read-only access; physical operating decisions remain with authorized people."
                },
                {
                  "type": "paragraph",
                  "text": "In such a workflow, equipment identities and source versions must be matched, while calculations remain in testable code. Missing records, conflicting notes, outdated documents and wrong equipment matches should be tested. Model-generated text must not become the authority for physical calculations or a definitive fault diagnosis."
                },
                {
                  "type": "table",
                  "caption": "Each form of evidence supports only the scope examined",
                  "headers": [
                    "Evidence",
                    "What it can demonstrate"
                  ],
                  "rows": [
                    [
                      "Synthetic test",
                      "Behavior in a defined software scenario"
                    ],
                    [
                      "Historical replay",
                      "Behavior under selected past conditions"
                    ],
                    [
                      "Expert review",
                      "Domain suitability of the output reviewed"
                    ],
                    [
                      "Authorized field pilot",
                      "Observations in a particular site, period and use case"
                    ],
                    [
                      "Operational acceptance",
                      "Acceptance of a defined scope by authorized parties"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Success on synthetic data is not evidence of success at a real plant. Acceptance at one site does not automatically generalize to others or grant control authority. For Watt2Work, that distinction underpins keeping measured values, calculated results and interpretation separate."
                }
              ]
            },
            {
              "id": "organization",
              "title": "Create the conditions in which an FDE can succeed",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "The organization must provide a business owner who can make decisions, a technical counterpart, data access and subject matter expert time. The FDE owns technical delivery; domain experts assess technical interpretation, data owners govern access and the business owner evaluates the outcome. One person should not be expected to hold every specialization and decision right."
                },
                {
                  "type": "paragraph",
                  "text": "Capacity planning includes development, customer meetings, documentation, travel and support. Recurring customer needs should reach the product team with reproducible examples and impact information. Not every request belongs in the shared product, but the reason for the decision should remain visible."
                },
                {
                  "type": "paragraph",
                  "text": "When considering an FDE, ask for an example from their last delivery: which problem did they choose, what did they build, how did they discover what was not working, and how does the customer sustain the system without them? Concrete answers make the quality of the work visible."
                }
              ]
            }
          ],
          "language": "en",
          "url": "https://watt2work.com/blog/what-makes-a-good-forward-deployed-engineer/",
          "markdown": "https://watt2work.com/blog/what-makes-a-good-forward-deployed-engineer/index.md",
          "blog": "https://watt2work.com/blog/",
          "datePublished": "2026-11-03",
          "dateModified": "2026-11-03",
          "author": "Watt2Work"
        },
        "tr": {
          "slug": "iyi-bir-forward-deployed-engineer",
          "title": "İyi bir Forward Deployed Engineer nasıl olmalı?",
          "description": "Müşteri problemini çalışan, ölçülen ve devredilebilen bir çözüme dönüştürmek: FDE yetkinlikleri, değerlendirme ve gelişim için kaynaklı bir rehber.",
          "intro": "Bir bakım yöneticisi “Bize bir yapay zekâ asistanı lazım” dediğinde mühendislik işi henüz tanımlanmış değildir. Asıl ihtiyaç geçmiş kayıtları bulmak, yanlış ekipman eşleşmesini önlemek veya rapor hazırlama süresini azaltmak olabilir. İyi bir Forward Deployed Engineer, bu belirsizliği müşterisiyle birlikte çalışılabilir bir probleme dönüştürür.",
          "takeaway": "Güçlü bir FDE’nin başarısı; doğru problemi seçmesi, çözümü geliştirmesi, gerçek kullanımda sonucunu ölçmesi ve müşterinin sürdürebileceği biçimde devretmesiyle görünür olur.",
          "editorialNote": "3 Kasım 2026 tarihli FDE yetkinlik raporundan blog için uyarlanmıştır. İşveren ilanları kurumların beklentilerini gösterir. Bu yazıdaki değerlendirme ve gelişim önerileri, doğrulanmış bir sektör standardı veya Watt2Work’ün tamamladığı müşteri işleri değildir.",
          "sourceNote": "Kaynak kesim ve erişim tarihi: 3 Kasım 2026. Tarihsiz ilanların erişim tarihi, yayın tarihi değildir; ilanlar sonradan değişebilir. Şirket duyuruları bağımsız başarı kanıtı sayılmamıştır. Teknik rehberler farklı tarihlere aittir; tümü yeni bir 2026 yayını olarak sunulmamaktadır.",
          "sections": [
            {
              "id": "role",
              "title": "Müşterinin işine yakın, teslimin tamamından sorumlu",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Forward deployed, mühendisin müşterinin iş akışına ve çalışma koşullarına yakın çalışmasını anlatır. Bu bazı projelerde sahada bulunmayı, bazılarında düzenli ortak geliştirmeyi gerektirir. Rolün özü; problem, kod, veri, kullanıcı ve işletim arasında teknik sahiplik kurmaktır."
                },
                {
                  "type": "table",
                  "caption": "Komşu rollerin tipik ağırlık merkezleri",
                  "headers": [
                    "Rol",
                    "Başlıca sorumluluk"
                  ],
                  "rows": [
                    [
                      "Ürün yazılım mühendisi",
                      "Birçok müşterinin kullandığı ürünün teknik kalitesi ve gelişimi"
                    ],
                    [
                      "Çözüm mimarı",
                      "İhtiyaç ve kısıtları savunulabilir bir mimariye çevirmek"
                    ],
                    [
                      "Satış mühendisi",
                      "Satın alma öncesi teknik uygunluğu göstermek"
                    ],
                    [
                      "Uygulama mühendisi",
                      "Tanımlı kurulum ve entegrasyon kapsamını teslim etmek"
                    ],
                    [
                      "Müşteri başarı yöneticisi",
                      "Benimsenme, ilişki ve müşteri sürekliliği"
                    ],
                    [
                      "Forward Deployed Engineer",
                      "Müşteri problemini çalışan, kullanılan, ölçülen ve devredilen çözüme taşımak"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Bu sınırlar şirketten şirkete değişir. Databricks’in Haziran 2026 duyurusu FDE yaklaşımını Professional Services içinde ele alır; Vercel’in ilanı da bu organizasyonda yer alır. Aday değerlendirmesinde ekip adından çok gerçek uygulama ve teslim sorumluluğu sorulmalıdır.",
                  "sources": [
                    "databricks",
                    "vercel"
                  ]
                }
              ]
            },
            {
              "id": "expectations",
              "title": "Güncel beklenti: üretim kalitesi ve müşteri sonucu",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "OpenAI’nin rol tanımı, geliştirmeyi üretimde benimsenme ve iş akışı etkisiyle birlikte ele alıyor. Anthropic’in Staff FDE ilanı, mimari yönlendirme ve müşterinin işletebileceği sistemlerin devrini vurguluyor. Palantir açık uçlu problemleri ayrıştırma ve teknik kararların kullanıcı üzerindeki etkisini düşünme beklentisini öne çıkarıyor.",
                  "sources": [
                    "openai",
                    "anthropic-fde",
                    "palantir"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Bu kaynaklardan çıkardığımız sonuç: güçlü aday bir alanda derinleşmeli, müşteri ortamında uçtan uca çalışabilecek kadar da geniş düşünmelidir. Her teknolojide uzmanlık beklemek yerine kendi sınırını bilmesi ve doğru uzmanı zamanında işe katması aranmalıdır."
                },
                {
                  "type": "paragraph",
                  "text": "Anthropic’in 2 Ekim 2026 tarihli Claude Frontier Academy duyurusu, simüle edilmiş kurumsal uygulama, uygulamalı sınama ve gerçek projeyle çalışma dönemini bir araya getiriyor. Programın kullandığı Frontier Deployed Engineer unvanı, genel Forward Deployed Engineer rolüyle birebir standart eşdeğerlik anlamına gelmez. Bu örnekler nitel işveren sinyalleridir; sektörün ücretini veya büyümesini ölçen bir araştırma değildir.",
                  "sources": [
                    "academy"
                  ]
                }
              ]
            },
            {
              "id": "competencies",
              "title": "Güçlü bir FDE’de aranacak 11 yetkinlik",
              "blocks": [
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Problemi tanımlamak",
                      "text": "İşi kimin, ne sıklıkta ve hangi veriyle yaptığını gözler. Mevcut süreç, başlangıç ölçümü, veri sahibi ve kapsam dışıyla birlikte bir problem tanımı yazar. “Chatbot yapalım” talebini doğrudan özellik listesine dönüştürmez."
                    },
                    {
                      "title": "Alanı öğrenmek",
                      "text": "Terimleri ve istisnaları konu uzmanıyla öğrenir. Ölçüm, hesaplama ve yorumu ayırır. İlk varsayımının hangi müşteri gözlemiyle değiştiğini açıklayabilir."
                    },
                    {
                      "title": "Kod yazmak ve hata ayıklamak",
                      "text": "Kendi yazdığı veya AI aracıyla ürettiği kodu açıklar. İstemci, uygulama, veri ve dış servis katmanlarını ayırarak hatayı daraltır. Çalışan örneğin yanında anlamlı test ve hata teşhisi kanıtı sunar."
                    },
                    {
                      "title": "Veri ve entegrasyonu sahiplenmek",
                      "text": "Eksik, yinelenmiş ve gecikmiş kayıtları; birim, zaman dilimi ve kimlik farklılıklarını yönetir. Bağlantının kurulmasıyla verinin doğru yorumlanmasını ayrı sınar."
                    },
                    {
                      "title": "Uygun mimariyi seçmek",
                      "text": "Kural tabanlı işlem, klasik yazılım, model, kaynak destekli LLM ve araç kullanan ajan seçeneklerini karşılaştırır. Kalite, gecikme, bakım ve maliyet gerekçesiyle karar verir."
                    },
                    {
                      "title": "Kaliteyi değerlendirmek",
                      "text": "Temsilî görevler, başarısızlık örnekleri ve geliştirmeden ayrı kabul kümesi hazırlar. Model veya veri değiştiğinde eski başarının korunduğunu sınar. İnsan değerlendirmesiyle ölçümün uyumunu kontrol eder."
                    },
                    {
                      "title": "Sistemi işletilebilir kılmak",
                      "text": "İzleme, sürümleme, yeniden deneme, geri alma ve kurtarmayı tasarlar. Kesinti sırasında kimin ne yapacağı bellidir. Hizmet hedefini kullanıcının ihtiyacıyla ilişkilendirir."
                    },
                    {
                      "title": "Yetki ve güvenliği uygulamak",
                      "text": "Müşteri ayrımı, en az yetki, sır yönetimi ve kayıtları uygulama katmanında kurar. Yetkisi kaldırılmış bir kullanıcının önbellekten belgeye erişemediğini de test eder."
                    },
                    {
                      "title": "Kapsamı ve maliyeti yönetmek",
                      "text": "Veri erişimi, altyapı, uzman zamanı ve satın alma bağımlılıklarının sahiplerini belirler. İnsan incelemesi, başarısız denemeler ve işletim emeği maliyete dahildir. Süre kazanımını gerçekleşen nakit tasarrufundan ayırır."
                    },
                    {
                      "title": "Anlaşılır ve dürüst iletişim kurmak",
                      "text": "Bildiğini, varsaydığını ve henüz ölçmediğini açıkça söyler. Gecikmenin etkisini ve seçenekleri zamanında paylaşır. Karar notlarına sorumlu ve tarih ekler."
                    },
                    {
                      "title": "Müşteriyi bağımsızlaştırmak",
                      "text": "Kurulum ve olağan değişiklikleri başka birinin yapabildiğini gösterir. Tekrarlanan ihtiyaçları uygun ortak bileşenlere dönüştürür. Teslim, aynı mühendisin sürekli yanında bulunmasına bağımlı kalmaz."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Bunları değerlendirmek için en yararlı kanıtlar; problem tanımı, çalışan kod, veri kalite kontrolü, başarısız örnek analizi, karar kaydı ve devir provasıdır. Sertifika ve deneyim yılı bu kanıtları yorumlamaya yardımcı olur. Hizmet hedefleri için Google’ın SLO rehberi, kullanıcı ihtiyacından hareket eden bir yaklaşım sunar.",
                  "sources": [
                    "slo"
                  ]
                }
              ]
            },
            {
              "id": "ai",
              "title": "AI araçlarını kullanmak, üretilen işin sorumluluğunu almak",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "AI araçlarıyla hızlı geliştirmek değerlidir; FDE yine de çıkan kodu incelemeli, yanlış davranışı teşhis etmeli ve tasarımını savunabilmelidir. Anthropic’in ajan rehberi, önceden tanımlanmış iş akışlarıyla modelin dinamik yönettiği ajanları ayırır. İhtiyacı karşılayan en basit yaklaşım iyi bir başlangıçtır; bu 2024 rehberi değişen araç listesinden çok mimari ilkeleri için kullanılmalıdır.",
                  "sources": [
                    "agents"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Doğru kaynakları, araç tanımlarını ve talimatları modele ulaştırmak ayrı bir mühendislik işidir. Bağlam yönetimi; kaynak sürümü, konuşma geçmişi, maliyet ve erişim sınırlarıyla birlikte düşünülmelidir. Çalıştırma ortamı ve yürütme yaşam döngüsü de model çağrısından ayrı sorumluluklar taşır.",
                  "sources": [
                    "context",
                    "managed"
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Güvenlik yalnızca sistem talimatına bırakılamaz. Modelin bir aracı çağırmak istemesi, o işlemi yapma yetkisi olduğu anlamına gelmez. OWASP’nin LLM ve ajan riskleri; araç izinleri, veri sızıntısı ve aşırı yetkiyi inceler. MCP kullanıldığında da bağlantının çalışmasının yanında kimlik, onay ve erişim kapsamı sınanmalıdır.",
                  "sources": [
                    "owasp-llm",
                    "agency",
                    "owasp-agents",
                    "mcp"
                  ]
                }
              ]
            },
            {
              "id": "delivery",
              "title": "Teslimi yedi görünür çıktıyla takip etmek",
              "blocks": [
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Keşif",
                      "text": "Problem, kullanıcı, mevcut süreç ve başlangıç ölçümü."
                    },
                    {
                      "title": "Veri incelemesi",
                      "text": "Kaynaklar, veri sözlüğü, erişim hakları ve kalite sorunları."
                    },
                    {
                      "title": "Kapsam ve tasarım",
                      "text": "Mimari, kabul ölçütleri, bağımlılıklar ve ilk teslim sınırı."
                    },
                    {
                      "title": "İlk çalışan sürüm",
                      "text": "Dar kapsamlı uçtan uca iş akışı ve kullanıcı geri bildirimi."
                    },
                    {
                      "title": "Pilot değerlendirme",
                      "text": "Temsilî görevler, hata analizi, maliyet ve ilerleme koşulları."
                    },
                    {
                      "title": "Kontrollü kullanım",
                      "text": "İzleme, sınırlı açılış, kurtarma planı ve kullanım kanıtı."
                    },
                    {
                      "title": "Devir",
                      "text": "İşletim sorumlusu, eğitim, kabul kaydı ve tekrar kullanılabilir bilgi."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Veri sahibi, kabul kararı veya işletim sorumlusu eksikse kalan iş açıkça yazılmalıdır. NIST’in Generative AI Profile belgesi, değerlendirmeyi yaşam döngüsü boyunca ele almak için gönüllü bir çerçevedir; tek başına sertifika ya da uygunluk sonucu değildir.",
                  "sources": [
                    "nist-ai"
                  ]
                }
              ]
            },
            {
              "id": "measurement",
              "title": "Başarıyı demo sayısıyla ölçmeyin",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Güçlü bir değerlendirme; kaliteyi, gerçek kullanımı, maliyeti ve devir sonrası bağımsızlığı birlikte görür. Hedefler, başlangıç düzeyi ve işin riski görüldükten sonra belirlenir."
                },
                {
                  "type": "table",
                  "caption": "Proje için birlikte seçilecek başarı göstergeleri",
                  "headers": [
                    "Gösterge",
                    "Ne ölçülmeli?"
                  ],
                  "rows": [
                    [
                      "İlk kabul edilen değere kadar süre",
                      "Başlangıçtan kullanıcının kabul ettiği ilk işe yarar çıktıya kadar süre; erişim gecikmeleri ayrıca"
                    ],
                    [
                      "Görev başarısı ve kritik hata",
                      "Kapsamdaki tüm denemeler; dil, görev türü ve risk düzeyine göre hata dağılımı"
                    ],
                    [
                      "Benimsenme",
                      "Sistemle tamamlanan uygun işler; yalnızca giriş yapan kullanıcı sayısı değil"
                    ],
                    [
                      "İşlem süresi",
                      "İnceleme ve düzeltme dahil, benzer görevlerin önceki ve yeni süreleri"
                    ],
                    [
                      "Kabul edilmiş çıktı başına maliyet",
                      "Model, altyapı, insan incelemesi, işletim ve başarısız denemeler"
                    ],
                    [
                      "Devir ve tekrar kullanım",
                      "Müşterinin bağımsız yaptığı olağan değişiklikler; sonraki işte gerçekten kullanılan bileşenler"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "İyi bir ortalama, nadir fakat önemli bir hatayı gizleyebilir. Değerlendirme farklı görev türlerini, tekrar çalıştırmaları ve sürüm değişikliklerini içermelidir. Aynı dönemdeki personel veya süreç değişikliği de sonucu etkileyebilir; birlikte değişen iki ölçü tek başına nedensellik göstermez.",
                  "sources": [
                    "evals"
                  ]
                }
              ]
            },
            {
              "id": "assessment",
              "title": "Adayı işin kendisine benzeyen örneklerle değerlendirmek",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Önerilen değerlendirme üç parçalıdır: eksik tanımlı bir problemle keşif görüşmesi, küçük bir uygulama ve hata incelemesi, ardından mimari ve devir tartışması. Başlangıç tasarımı olarak yaklaşık 40, 90 ve 45 dakika düşünülebilir. Bunlar doğrulanmış işe alım süreleri değildir."
                },
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "Problemi nasıl değiştirdi?",
                      "text": "Müşterinin ilk istediği çözümden hangi kanıt üzerine vazgeçtiğini sorun."
                    },
                    {
                      "title": "Hatanın nedenini nasıl buldu?",
                      "text": "Üretimdeki veya gerçekçi bir örnekteki arızayı hangi adımlarla daralttığını inceleyin."
                    },
                    {
                      "title": "Yetki geri alınınca ne olur?",
                      "text": "Veri, önbellek ve araç erişiminin nasıl etkilendiğini göstermesini isteyin."
                    },
                    {
                      "title": "Müşteri onsuz ne yapabilir?",
                      "text": "Doküman tesliminin yanında kurulumu ve olağan değişikliği başka birinin denediğine bakın."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "AI araçları kullanılabilir; aday üretilen işi açıklamalıdır. Şirketin gerçek müşteri işini ücretsiz tamamlaması beklenmemeli, uzun uygulamalar ücretli ve açık kapsamlı olmalıdır. Kanıt bulunmayan alanı yetersizlikle karıştırmayın. Değerlendiriciler aynı davranış ölçütlerini kullanmalı; ağırlıklar göreve göre belirlenmelidir. Tek bir genel FDE puanı, güvenlik veya mühendislik açığını gizlememelidir."
                }
              ]
            },
            {
              "id": "seniority",
              "title": "Kıdem, çözülebilen belirsizliğin kapsamıyla artar",
              "blocks": [
                {
                  "type": "table",
                  "caption": "Önerilen sorumluluk düzeyleri; şirket unvan standardı değildir",
                  "headers": [
                    "Düzey",
                    "Beklenen sorumluluk"
                  ],
                  "rows": [
                    [
                      "Gelişen FDE",
                      "Gözetimle tanımlı bir entegrasyon veya değerlendirme akışını tamamlama"
                    ],
                    [
                      "Bağımsız FDE",
                      "Tek kullanım senaryosunun keşif, uygulama, pilot ve devrini yürütme"
                    ],
                    [
                      "Senior FDE",
                      "Birden çok bağımlılığı, zor kapsam kararlarını ve paydaşları yönetme; mentorluk"
                    ],
                    [
                      "Staff / Lead FDE",
                      "Hesap veya ekipler arasında mimari yön, tekrar kullanım ve kalite sorumluluğu"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Deneyim yılı bağlam sağlar; belirleyici soru kişinin hangi belirsizliği artık bağımsız çözebildiğidir. Anthropic’in Staff ilanında birden çok iş kolu ve diğer FDE’lerin tasarımları üzerinde mimari sorumluluk tarif edilmesi bu ayrımın bir örneğidir.",
                  "sources": [
                    "anthropic-fde"
                  ]
                }
              ]
            },
            {
              "id": "first-90-days",
              "title": "İlk 90 günde bir teslim hikâyesi oluşturmak",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Bu gelişim planı yazılım temeli bulunan biri içindir. Sıfırdan başlayan bir kişinin 90 günde bağımsız üretim yetkinliği kazanacağını vaat etmez. Müşteri ve veri izinleri takvimi değiştirebilir."
                },
                {
                  "type": "list",
                  "items": [
                    {
                      "title": "İlk 30 gün: problemi ve ilk sürümü kur",
                      "text": "Bir alan ve dar iş akışı seç. Süreci gözle, başlangıcı ölç, veri sözlüğünü hazırla ve uçtan uca küçük bir sürüm geliştir. Gerçek veri yoksa açık veya sentetik veri kullandığını belirt."
                    },
                    {
                      "title": "31–60. gün: başarısızlığı görünür yap",
                      "text": "İstisnaları, yetki sınırlarını, izlemeyi ve sürüm değişimini test et. Alternatif yaklaşımı aynı görevlerde karşılaştır. Kalite, gecikme ve maliyeti ölç; geri alma veya kurtarma provası yap."
                    },
                    {
                      "title": "61–90. gün: değerlendir ve devret",
                      "text": "İzinli kullanıcı değerlendirmesi yap. Başka bir mühendis kurulumu ve olağan değişikliği denesin. Bilinen sınırları ve kalan bağımlılıkları yaz. Gerçek saha izni yoksa bunu saha doğrulaması olarak anlatma."
                    }
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Portföyde problem, çalışan örnek, izin verilen teknik inceleme, ölçüm ve bir başarısızlık analizi birlikte bulunmalıdır. Gizli müşteri kaydı yerine temsilî örnek kullanıldığında bu durum açıkça etiketlenmelidir."
                }
              ]
            },
            {
              "id": "industry",
              "title": "Enerji ve endüstride kanıtın sınırını bilmek",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Endüstriyel FDE, ekipman hiyerarşisini, birimleri, zaman damgalarını ve bakım kayıtlarının sınırlarını öğrenmelidir. Bir sinyali okuyabilmek, fiziksel anlamını doğru yorumlamak değildir. NIST SP 800-82 Rev. 3, OT güvenliğini performans, güvenilirlik ve fiziksel güvenlikle birlikte ele alır. Kaynak kesim tarihinde Rev. 4 ilk kamu taslağı da bulunuyordu; taslak kesinleşmiş sürüm değildir.",
                  "sources": [
                    "nist-ot"
                  ]
                },
                {
                  "type": "callout",
                  "text": "Örnek senaryo: bakım mühendisi, izinli geçmiş kayıtları ve teknik dokümanları kullanarak kaynaklı bir inceleme ve rapor taslağı hazırlar. Bu açıklayıcı örnek gerçek tesis verisi veya tamamlanmış pilot içermez. Önerilen başlangıç yalnızca izinli okumadır; fiziksel işletme kararı yetkili insanlarda kalır."
                },
                {
                  "type": "paragraph",
                  "text": "Böyle bir işte ekipman kimliği ve kaynak sürümü eşleştirilir; hesaplamalar test edilebilir kodda tutulur. Eksik kayıt, çelişkili not, eski doküman ve yanlış ekipman gibi durumlar sınanır. Model metni fiziksel hesaplama otoritesine veya kesin arıza teşhisine dönüşmemelidir."
                },
                {
                  "type": "table",
                  "caption": "Her kanıt, yalnızca sınandığı kapsamı destekler",
                  "headers": [
                    "Kanıt",
                    "Gösterebileceği şey"
                  ],
                  "rows": [
                    [
                      "Sentetik test",
                      "Tanımlanmış yazılım senaryosundaki davranış"
                    ],
                    [
                      "Geçmiş kaydın yeniden oynatılması",
                      "Seçilen tarihsel koşullardaki davranış"
                    ],
                    [
                      "Uzman incelemesi",
                      "İncelenen çıktının alan açısından uygunluğu"
                    ],
                    [
                      "İzinli saha pilotu",
                      "Belirli saha, süre ve kullanım kapsamındaki gözlem"
                    ],
                    [
                      "Operasyonel kabul",
                      "Yetkili tarafların tanımlı kapsamı kabul etmesi"
                    ]
                  ]
                },
                {
                  "type": "paragraph",
                  "text": "Sentetik başarı gerçek tesis başarısı değildir. Bir sahadaki kabul başka tesislere otomatik genelleme sağlamaz; kontrol yetkisi de vermez. Watt2Work açısından bu ayrım, ölçülen değer, hesaplanan sonuç ve yorumu ayrı göstermenin temelidir."
                }
              ]
            },
            {
              "id": "organization",
              "title": "İyi FDE’nin çalışabileceği koşulları kurmak",
              "blocks": [
                {
                  "type": "paragraph",
                  "text": "Kurum; karar verebilen iş sahibini, teknik muhatabı, veri erişimini ve konu uzmanı zamanını sağlamalıdır. FDE teknik teslimi sahiplenir; alan uzmanı teknik yorumları, veri sorumlusu erişimi, iş sahibi ise iş kabulünü değerlendirir. Aynı kişiden bütün uzmanlıkları ve karar yetkilerini üstlenmesi beklenmemelidir."
                },
                {
                  "type": "paragraph",
                  "text": "Kapasite planına geliştirme, müşteri görüşmesi, dokümantasyon, seyahat ve destek birlikte girer. Tekrarlanan müşteri ihtiyaçları, yeniden üretilebilir örnek ve etki bilgisiyle ürün ekibine taşınmalıdır. Her müşteri isteğinin ortak ürüne girmesi gerekmez; kararın gerekçesi görünür kalmalıdır."
                },
                {
                  "type": "paragraph",
                  "text": "Bir FDE’yle çalışmayı değerlendirirken son tesliminden bir örnek isteyin: hangi problemi seçti, ne geliştirdi, neyin çalışmadığını nasıl gördü ve müşteri sistemi onsuz nasıl sürdürüyor? Bu sorulara verilen somut yanıtlar, rolün niteliğini görünür kılar."
                }
              ]
            }
          ],
          "language": "tr",
          "url": "https://watt2work.com/tr/blog/iyi-bir-forward-deployed-engineer/",
          "markdown": "https://watt2work.com/tr/blog/iyi-bir-forward-deployed-engineer/index.md",
          "blog": "https://watt2work.com/tr/blog/",
          "datePublished": "2026-11-03",
          "dateModified": "2026-11-03",
          "author": "Watt2Work"
        }
      },
      "sources": [
        {
          "id": "palantir",
          "label": "Palantir · Forward Deployed Software Engineer",
          "url": "https://jobs.lever.co/palantir/a2e9ab0f-4dd1-4744-92b9-edc7ae393c58"
        },
        {
          "id": "openai",
          "label": "OpenAI · Forward Deployed Engineer",
          "url": "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/"
        },
        {
          "id": "anthropic-fde",
          "label": "Anthropic · Staff Forward Deployed Engineer",
          "url": "https://job-boards.greenhouse.io/anthropic/jobs/5449229008"
        },
        {
          "id": "vercel",
          "label": "Vercel · Forward Deployed Engineer",
          "url": "https://job-boards.greenhouse.io/vercel/jobs/5752684004"
        },
        {
          "id": "databricks",
          "label": "Databricks · Forward Deployed Engineering: Delivering Business Outcomes with AI",
          "url": "https://www.databricks.com/blog/forward-deployed-engineering-delivering-business-outcomes-ai"
        },
        {
          "id": "academy",
          "label": "Anthropic · Claude Frontier Academy",
          "url": "https://www.anthropic.com/news/claude-frontier-academy"
        },
        {
          "id": "agents",
          "label": "Anthropic · Building effective agents",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        },
        {
          "id": "evals",
          "label": "Anthropic · Demystifying evals for AI agents",
          "url": "https://www.anthropic.com/research/demystifying-evals-for-ai-agents"
        },
        {
          "id": "context",
          "label": "Anthropic · Effective context engineering for AI agents",
          "url": "https://www.anthropic.com/research/effective-context-engineering-for-ai-agents"
        },
        {
          "id": "managed",
          "label": "Anthropic · Scaling Managed Agents",
          "url": "https://www.anthropic.com/research/managed-agents"
        },
        {
          "id": "owasp-llm",
          "label": "OWASP · Top 10 for LLM Applications",
          "url": "https://genai.owasp.org/llm-top-10/"
        },
        {
          "id": "agency",
          "label": "OWASP · Excessive Agency",
          "url": "https://genai.owasp.org/llmrisk/llm062025-excessive-agency/"
        },
        {
          "id": "owasp-agents",
          "label": "OWASP · Top 10 for Agentic Applications for 2026",
          "url": "https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/"
        },
        {
          "id": "mcp",
          "label": "Model Context Protocol · Security Best Practices",
          "url": "https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices"
        },
        {
          "id": "nist-ai",
          "label": "NIST AI 600-1 · Generative Artificial Intelligence Profile",
          "url": "https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence"
        },
        {
          "id": "slo",
          "label": "Google SRE · Implementing SLOs",
          "url": "https://sre.google/workbook/implementing-slos/"
        },
        {
          "id": "nist-ot",
          "label": "NIST SP 800-82 Rev. 3 · Guide to Operational Technology Security",
          "url": "https://csrc.nist.gov/pubs/sp/800/82/r3/final"
        }
      ]
    }
  ]
}