What a dedicated-developer engagement looks like week to week
The hire page describes the four steps that start an engagement. This is what happens after them: who talks to whom, where the plan lives, and what a developer on a dedicated team is actually accountable for.
Most of the work here is project work: a brief, a scope, a date, a handover. A dedicated engagement is a different shape, and candidates who end up on one sometimes find the difference bigger than they expected. The client is not buying a deliverable. They are buying a defined slice of the team, typically two to five people, for a monthly block, and the roadmap is allowed to move inside it.
That one change, scope that moves while the team stays, sets almost everything else about how the week runs.
Before the first week
An engagement starts with a scoping call with someone who will be on the build, then team assembly, then onboarding. Team assembly is the step that matters most to a developer, because the client is told the people rather than the roles: who is assigned, what else they carry, and how many hours a week the client has them for. If you are named on an engagement, the client knows your name before you have written a line of their code.
Onboarding is the first week. Access, environments and a written way of working. The team works in the client's tools where the client has them and ours where they do not, which means a developer here learns to be useful inside someone else's tracker, someone else's repository conventions and someone else's standup format without asking for them to change.
The shape of a normal week
- Mornings in Islamabad are build time, before the Dubai day is fully underway.
- Standups and written updates go out from Islamabad. If the client runs their own standup, the team joins it rather than running a parallel one.
- The overlap hours carry the calls, the reviews and anything that needs a decision.
- Commercial questions, priorities and anything that changes the shape of the engagement go through one account contact in Dubai, so the client is not managing five relationships and the developers are not negotiating scope mid-task.
- There is one place where the plan lives. If a decision was made on a call, it is written there the same day.
For clients in the UAE, Europe and the UK the working day overlaps almost entirely. For North American clients the overlap is the morning, so the written handover at the end of the Islamabad day carries more weight. It has to be readable by someone who was asleep when the work happened.
What changes for the developer
On a fixed-scope project, the scope document protects everyone. On a dedicated engagement it does not exist in the same form, and the protection has to come from somewhere else. Here it comes from writing things down. A priority that changed on Tuesday is a message that says it changed, and that message is what the work follows.
The other change is continuity. The people who start a client's product are the people who finish it and maintain it afterwards. That is the point of the model for the client, and it means the code you write in month one is code you will be reading in month six. Shortcuts that would survive a handover to somebody else do not survive a handover to yourself.
On a dedicated team, the person who inherits your shortcut is usually you.
Where the judgement is
- Telling the difference between a moved priority and a new project. A roadmap that shifts is the model working. A request that quietly doubles what the team is carrying is a conversation for the account contact, not something to absorb by working later.
- Raising a slip before it is a slip. The client hears about a moving date from us first, with the revised date attached. On a monthly engagement that habit is what keeps the next month's renewal from being a difficult call.
- Keeping the client's codebase theirs. Handover notes, credentials in the right place, a readme for whoever picks it up next. Engagements run monthly with a notice period, and the work has to stand up if the engagement ends.
Why this is on a careers site
Because a candidate placed on a dedicated engagement is closer to a member of the client's own team than to an agency developer working through a queue. Some people want exactly that: one product, a long run at it, and a client who knows them by name. Others prefer the variety of project work. Both exist here, and it is worth knowing which you would rather be doing before the interview.