Processes - Embedded Software Development - Onboarding & Delivery Process

Overview

This process is for teams that already have an active product, backlog, or internal system and want experienced development capacity added quickly.

The goal is simple: reduce uncertainty early, make sure the engagement is a fit, then get useful work moving fast without adding management drag.

1 - Interest and intake

The process starts with the dedicated service intake form.

The intake captures:

• What product or system you need help with
• The team and stakeholders involved
• The current technical context
• What outcomes you need
• What constraints, urgency, and blockers exist
• The intro call slot that works for you from the currently available options

2 - Fit review, rate confirmation, and intro call

After the intake is submitted:

• I review the engagement for fit, timing, and likely delivery shape
• I confirm whether I have current capacity to support the work
• If it looks like a fit, I reply with the appropriate rate and confirm the intro call
• If it is not a fit, or the timing is wrong, I say that clearly and suggest the most useful next step

3 - Agreement and kickoff

If we both want to proceed, the next step is operational setup.

That usually includes:

• Confirming scope of responsibility for the first phase
• Agreeing the delivery rhythm and communication expectations
• Finalising the contract and any procurement steps
• Exchanging repo, hosting, tooling, or documentation access
• Defining the first batch of work to start with

4 - First delivery cycle

The first cycle is about becoming useful quickly.

Typical early work includes:

• Understanding the current architecture and delivery setup
• Identifying the highest-value near-term work
• Resolving obvious blockers or risks
• Taking ownership of implementation work that relieves pressure on the team

5 - Ongoing operating rhythm

Once delivery is underway, the engagement runs in a simple, reliable rhythm:

• Priorities stay visible
• Work is executed against the agreed focus
• Communication happens in the team channels and cadence we set up
• Risks, blockers, and changes are surfaced early
• The next slice of work stays clear so momentum does not stall

6 - Decision points during the engagement

As the work progresses, a few decisions tend to come up:

• Continue at the same level of capacity
• Increase or reduce time commitment
• Shift from one stream of work to another
• Expand into a rebuild or new-system-build engagement
• Wrap the engagement after the key delivery goal has been reached

7 - Offboarding or extension

At the end of a phase, we either continue with the next priority or close cleanly.

Closeout normally includes:

• Handover on current work and context
• Documentation or notes where needed
• Clear status of in-flight tasks
• Recommendations for what should happen next