Lesson 1.3: A week in the life of an FDE
There is no typical week for a forward deployed engineer, but there is a rhythm. See what a week looks like, how it changes, and how to protect time to build.
By the end of this lesson you will be able to describe what a forward deployed engineer actually does with a week, why no two weeks look alike, and which habits keep the work from taking over. You will walk through a sample week day by day, compare three different kinds of week with real hour counts, see how the week changes as a project moves from discovery to handover, and use a simulator to find out how much time for focused building is left once meetings, travel, incidents and several customers are counted. This lesson builds on Lessons 1.1 and 1.2, and you need no coding background to follow it.
Most descriptions of a job are written as lists of responsibilities. That tells you what the job is for but not what it feels like. The feel comes from the calendar: how often you are interrupted, how much time goes to people and how much to code, and what happens when something breaks. For this role the calendar matters more than for most, because the work sits between a customer's world and your own company's, and both send you requests. This lesson tries to make the calendar visible.
Why there is no typical week
Forward deployed engineers who describe their work often say the same thing: it changes. In a 2019 post on Palantir's engineering blog, one engineer who holds the role says the days change from month to month. Some weeks go mostly to writing and reviewing the team's code, like a typical software engineer. In other weeks most of the time goes to scoping the future of a project with a client, or working with users to check that what has been built meets their needs. Another describes spending a couple of days most weeks at the customer's premises, in meetings with technical and business people, plus time monitoring, debugging, deploying and configuring the software. The rest goes to small code changes, reviews, planning and messages to colleagues at home.
Two things follow. First, the phrase "a day in the life" can mislead, because the better unit is a week or even a project phase. Second, the variety is part of the job, not a flaw in how it is organised. The role exists to cover the gap between a general product and a specific customer, and the size and shape of that gap changes constantly.
Still, the variation has a shape. If you look at many weeks, the same four kinds of activity keep appearing, and what changes is only how they are balanced.
The four blocks under every week
Think of the week as four kinds of time.
1. Customer time. Meetings, workshops, calls, site visits, watching users work, and informal conversations in corridors and chats. This is where you learn what is real. It can be energising and also tiring, because you are listening carefully and often managing expectations at the same moment.
2. Build time. Writing, testing and deploying software: data pipelines, integrations, configuration, dashboards, scripts. This needs long unbroken stretches. A two-hour block of focus produces far more than four half-hours scattered between meetings.
3. Communication time. Written updates, messages to your own team, escalations, notes after meetings, planning, and the short conversations with the product team that turn a customer's problem into a clear request.
4. Upkeep time. Fixing things that broke, answering support questions, handling access requests, waiting on approvals, and the paperwork of working inside someone else's organisation: security forms, change requests, user accounts.
The first block fills the calendar most visibly. The second block is what most engineers think they will do all day. The third and fourth are the ones newcomers underestimate. A useful rule of thumb is that the less technical the activity looks, the more likely it is to be underestimated when you plan a week.
A sample week, day by day
What follows is an invented composite, written for teaching. It describes one engineer in the middle of a pilot for a lender, working partly on the customer's premises and partly remotely. The hours are illustrative.
Monday: planning and customer time. The week begins with a short plan. The engineer lists the three results that must exist by Friday, for example "nightly file loads without errors, first account groups visible to the collections team, security review questions answered". Then two hours in a stand-up and review with the customer's head of collections and a data analyst. The meeting uncovers a new fact: accounts that paid last month should be moved out of the first group. The engineer writes it down as a change to the plan. The afternoon is for build time: adjusting the logic, a first test on real data.
Tuesday: on site. A day at the customer's office. Two hours sitting beside collections callers, watching how they pick the next account. One hour with the security team about where data may be stored. Two hours of build time in a borrowed meeting room, interrupted twice by callers with questions. A short written note in the evening to the engineer's own team, listing what was learned.
Wednesday: build and fix. A mostly quiet day, which is rare. Four hours of focused build time: finishing the account grouping and writing tests. One hour on a call with the product team about a missing feature, sending an example of the problem. At 4 p.m. the nightly file arrives late and malformed. The engineer spends two hours working out why, then writes to the customer's data analyst explaining what was found, what is being done and when it will be fixed.
Thursday: demo preparation. Half the day goes to preparing a short demonstration for the customer's executive on Friday: choosing the three screens that matter, rehearsing the explanation, fixing two visual problems. The other half goes to answering the customer's questions and filing the access requests that will take days to approve.
Friday: demo and update. The demo takes thirty minutes, with half the time for questions. The engineer then writes a one-page weekly update: what was done, what the numbers show, what is blocked and what the customer needs to decide. The afternoon is for cleaning up, reviewing code, and writing the plan for next week.
Here is how the hours in that week might divide. The figures are rounded and illustrative. A real week varies by project phase and company.
In this picture, building is the largest block but still only about a third of the week. Customer time and upkeep together are almost half. Anyone who joins the role expecting to code most of the day will find the balance surprising, and some will find it disappointing. Others will find that the combination is exactly what they wanted.
Predict first: it is Wednesday at 4 p.m. and the customer's nightly data file has arrived late and broken, three days before an important demo. You have a plan for how to fix it, which will take about two hours. What do you do first, before you start fixing? Think of the one action that matters most.
The answer is to tell the customer early. A short message such as "the nightly file arrived late and with a formatting error; I am investigating and will confirm the cause and the time of the fix by 7 p.m." takes two minutes and changes the situation entirely. It turns a surprise into a managed problem, and it gives the customer a chance to warn their own team. Hiding the problem while you fix it feels efficient, but if the fix takes longer than hoped, the customer finds out late and trust suffers. This habit, early and short bad news, is among the most important in the role, and a later module gives it a full lesson.
Worked example 1: the building week
Some weeks are mostly building. This usually happens after a clear plan exists and before the next demo. Suppose an engineer works a 45-hour week like this, with illustrative numbers.
Customer time: 6 hours (two check-ins and one review).
Build time: 24 hours.
Communication: 7 hours (updates, planning, a product-team discussion).
Upkeep: 8 hours (access requests, a minor data issue).
Build time is 24 of 45 hours, or about 53 per cent. This is as close to a core software engineer's week as the role gets. The danger of a building week is not the work. It is the silence. If the engineer disappears into code for a week without showing anything, the customer starts to wonder what is happening, and the first thing they see after a week of silence may not be what they imagined. The good habit is to keep the customer touch points even in a building week: a short update midweek and a small visible result every few days, even if it is only a screenshot of a rough screen.
Worked example 2: the incident week
Now a bad week. A production system that the engineer deployed three weeks ago fails on Monday morning, because the customer changed a field in their source system without telling anyone. The engineer's plan for the week disappears. A realistic split, again illustrative, over a 55-hour week:
Customer time: 12 hours, much of it calls about the failure and its effect.
Build time: 14 hours, mostly fixing and testing the repair.
Communication: 12 hours, including frequent updates, a written explanation of the cause and a plan to prevent a repeat.
Upkeep: 17 hours, including digging through logs, checking affected records and emergency access requests.
Build time fell from 24 hours to 14, upkeep more than doubled and the week stretched to 55 hours. Most of the planned results for the week did not happen. This is normal. A good engineer does not treat it as failure. They treat the incident as the week's real project, communicate clearly, and use the aftermath to improve things: a check that detects the changed field the next time, an alert, and a short note in the runbook. Over a project, the habit of turning each incident into a safeguard is what makes weeks calmer over time.
Worked example 3: the on-site discovery week
The third kind of week comes at the beginning of a project. The engineer travels to the customer for five days to understand how the work is done. A 45-hour week might split like this:
Customer time: 26 hours, much of it sitting beside users, interviewing and reading records.
Build time: 4 hours, a small test to check an assumption.
Communication: 8 hours, daily notes and a summary at the end.
Upkeep: 7 hours, including travel arrangements and getting access.
Customer time is more than half the week. Almost no software is written. Newcomers often feel uneasy about such a week, because it looks unproductive. It is the most productive kind of week if done well, because it prevents the expensive mistake of building the wrong thing. By Friday the engineer should have a written description of the real problem, a list of data and access that must be arranged, and a first version of the plan. That page will shape the next six weeks.
Compare the three weeks. In the building week, the engineer builds. In the incident week, they respond. In the discovery week, they learn. The role consists of moving between the three at the right moments, and the skill lies in recognising which kind of week you are in and acting accordingly.
Put the four kinds of week side by side and the main difference is how much time is left to build. The chart takes the build hours from the sample week and the three examples above.
An incident can empty a plan quickly, and a few extra hours worked only partly make up for it. Try the sliders: set the unplanned incident hours and the overtime you are willing to work, and see what is left for building.
At the defaults, a 45-hour week with 21 hours of normal non-build time leaves 24 for building. An incident that takes 20 more hours, with 10 hours of overtime, leaves 14, which is the incident week in the example. Without the overtime it would be 4.
How the week changes across a project
Projects have phases, and the week follows them. A useful simplification is four phases.
Phase · Typical focus · Where time goes · Main riskDiscovery · Understand the problem, the data and the people · Mostly customer time · Accepting the first description of the problem
First build · Make a rough working version · Mostly build time, with frequent customer check-ins · Building before understanding, or hiding in code
Deployment · Put it into the customer's real systems · Upkeep and customer time rise sharply · Surprises about security, data and access
Handover · Make the customer able to run it · Communication and training rise · Becoming the permanent operator
Seeing the phases helps you plan. In discovery, protect customer time and resist the urge to start building too soon. In first build, protect focus and show progress regularly. In deployment, expect upkeep to expand and leave room for it in the plan. In handover, shift effort from doing to teaching, so that the customer's people can run the system without you.
It also explains why advice on "how to spend your week" varies so much. Someone describing the deployment phase and someone describing the build phase are both honest, and both will sound as if they hold different jobs.
The calendar problem: protecting time to build
Of the four kinds of time, build time is the one that disappears first, and it is also the one that most depends on being protected. Programming and data work need concentration. An interruption costs more than its length, because it takes time to rebuild your mental picture afterwards. A calendar with one meeting every hour may total only a few meeting hours but leaves no usable block for work.
Three things eat build time.
Meetings and travel. These are necessary, and often the whole point, but they come in fixed slots.
Incidents and support. These arrive unannounced and are urgent.
Several customers at once. Every customer you add brings a share of fixed overhead: another set of systems to remember, another set of people to update, another set of access rules. A person who handles four customers does not have four times the work of a person with one, but the overhead is real, and it falls on the same hours.
The simulator below lets you try the arithmetic. Set the hours in your week, the hours of meetings and travel, the hours of incidents and support, and the number of customers with the overhead each one adds. The result is the number of hours left for focused building, shown beside how that number falls as the number of customers grows.
The numbers are illustrative defaults, so change them to match your own week. A good experiment is to start at one customer and add one at a time, watching how much time to build disappears. Then raise the incident hours from five to fifteen to see what a bad week does.
Try it with the sliders. Set the number of customers to one, and the week leaves twenty-one hours for building (the defaults start at two customers, which leaves eighteen). With four customers, the extra overhead alone takes nine hours, and the focused time falls to twelve. Nothing about the individual customers changed. The only change was how many were held at once. This is why experienced forward deployed engineers push back, politely, on being spread across too many accounts, and why managers who understand the role cap the number.
Habits that keep a week from running away
People who do well in the role tend to rely on a handful of habits. Each is simple. The difficulty is doing them consistently.
A written plan on Monday. List the two or three results that must exist by Friday. Everything else is secondary. When an incident arrives, the plan tells you what to give up.
Block time to build. Put long blocks in the calendar and treat them like meetings. Where possible, group customer meetings on certain days, so that other days stay free.
Short written updates. A weekly note with what was done, what the numbers show, what is blocked and what you need from the customer. People read short notes. The note also protects you, because it creates a record.
A log of what you learn. Keep a running file of facts about the customer's systems, people and rules. Your future self, and whoever takes over, will thank you.
Escalate early and plainly. When something is blocked by someone you cannot influence, say who, what and by when it is needed. Do not wait until it is a crisis.
Turn each incident into a safeguard. Add a check, an alert or a runbook line so that the same failure is caught or fixed faster next time.
Rest and boundaries. Urgent issues will not respect the calendar. Because of that, protect the time that is genuinely yours. Tired engineers make mistakes in production systems, which are the mistakes that cost customers the most.
Common mistakes
These mistakes come up often in the first months of the role.
Expecting a week of coding. The role has a large share of customer, communication and upkeep time. Plan for it, or you will feel behind all the time.
Disappearing into code. A week of silence, however productive, makes customers anxious. Show something small every few days.
Underestimating upkeep. Access requests, approvals and incidents take time and are rarely on the plan. Leave a margin of 20 to 30 per cent in any weekly plan.
Saying yes to every customer. Each extra customer costs overhead. Raise the load early with your manager, with numbers.
Hiding bad news until it is fixed. An early short message costs two minutes. A late surprise costs trust.
Not recording what you learn. Facts about a customer's systems live in your head, and then they leave with you.
Treating an incident as a personal failure. Incidents happen in real systems. What matters is how you respond and what you change afterwards.
Key takeaways
There is no typical week, but the same four kinds of time keep appearing: customer time, build time, communication and upkeep.
Building is often only about a third of the week. Customer time, communication and upkeep make up the rest, and newcomers underestimate the last two.
Weeks fall into kinds: a building week, an incident week and a discovery week. The skill is recognising which one you are in.
A project moves through discovery, first build, deployment and handover, and the week changes shape with each phase.
Build time needs long unbroken blocks, and several customers at once shrink it quickly through fixed overhead.
Good habits are simple: a Monday plan, protected focus blocks, short written updates, a knowledge log, early escalation and a safeguard after every incident.
Check yourself
1. Name the four kinds of time that fill a forward deployed engineer's week.
Customer time, build time, communication time and upkeep time.
2. In the sample week, what is the right first action when the nightly file arrives broken on Wednesday afternoon?
Tell the customer early, in a short message saying what is wrong, that you are investigating and when you will update them. Then fix it.
3. Why does an incident week usually leave less building time than a building week?
Because upkeep, customer calls and communication expand to deal with the failure, and the plan for the week is replaced by the incident.
4. With a 50-hour week, 14 hours of meetings, 8 of upkeep, 7 of writing and 3 hours of overhead per extra customer, how many focused hours are left with one customer and with four?
Twenty-one hours with one customer (50 − 14 − 8 − 7). With four customers, the overhead is 9 hours, so 12 hours remain.
5. Why is a week of on-site discovery, with almost no coding, still productive?
Because it prevents building the wrong thing. It produces a written description of the real problem, a list of data and access needed and a first plan.
Try this
This exercise takes about forty minutes and gives you a realistic feel for the balance of time in a role like this. Use your own current work, whatever it is.
1. Take last week's calendar, or your best memory of your week. Sort every activity into four groups: time with other people about your work (customer time), time making or building something (build time), time writing updates and planning (communication) and time handling surprises and paperwork (upkeep).
2. Add up the hours in each group and write the percentages next to them.
3. Compare your numbers with the sample chart above. Which block is larger than you expected, and which is smaller?
4. Use the simulator above with your own hours. Set the number of customers to the number of different groups or people whose requests you handle. How many focused hours are left?
5. Pick one habit from the list (Monday plan, protected block, written update, log, early escalation or safeguard) and plan how you will do it next week. Write down the day and time.
6. At the end of next week, repeat step 1 and see whether the balance moved.
A good result is a one-page table with four numbers for each of two weeks, a note on which block surprised you and the one habit you tried. People who do this honestly often find that the time they thought they lost to "interruptions" is really upkeep and communication that they never planned for, which is exactly the lesson of the role.
Sources
[Dev versus Delta: Demystifying engineering roles at Palantir](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87), Palantir engineering blog, 8 April 2019. Used for the engineers' own descriptions of how their weeks vary: weeks mostly spent on code, weeks mostly spent scoping with clients, and a couple of days a week at the customer's premises. These are company staff describing their own jobs.
The sample week, the three kinds of week, the hour counts and all figures are the author's illustrations for teaching, not data from real companies or surveys.
Tags: Forward Deployed Engineer Time management Careers Customer engineering Beginner