Your first 30 days as an embedded software technical lead

Days 1–5: map the real system and its people

Follow one change from requirement to a running device. Observe how it is specified, reviewed, built, flashed, tested, released and diagnosed. Note where evidence lives and where work depends on one person's memory. Run the build yourself from documented instructions. If it fails, preserve the failure as useful onboarding evidence rather than asking someone to make it work silently.

Spend time where the product is integrated and supported. A repository tour cannot show connector faults, timing variation, production programming or what service technicians can observe. Ask to see a real defect investigation and the evidence available from a returned or failing unit.

Draw a system context that includes processors, operating systems, boot chain, buses, CAN networks, external controllers, build infrastructure, hardware variants, update mechanisms and telemetry. Mark ownership and critical interfaces. Pair the diagram with a stakeholder map: product, hardware, software, test, safety or security, manufacturing, service and suppliers.

Ask what has hurt recently. Field defects, unstable tests, late hardware, integration surprises and long review queues reveal more than a generic backlog. Confirm which dates, safety constraints and customer promises are fixed and which are planning assumptions.

• Build and run one representative target from clean instructions.
• Trace one CAN message from sender to receiver and diagnostic evidence.
• Identify hardware variants, update paths and field recovery options.
• List critical interfaces with owners on both sides.
• Record single-person dependencies without blaming the person.

Days 6–10: establish the technical baseline

Create a short baseline with facts: supported toolchains, compiler warnings, dependency and kernel versions, static-analysis status, test levels, build reproducibility, known resource margins and open critical defects. Do not turn it into a maturity theatre. The purpose is to identify risks that can invalidate delivery, not to score the team.

Select a few health signals that can be refreshed. Useful examples include clean-build success, time to produce a release candidate, flaky-test rate, unresolved critical warnings, hardware-in-the-loop availability and time from field report to reproducible case. A signal without an owner or response is decoration.

Separate immediate containment from structural improvement. A release-blocking race condition may need a focused fix and additional logging now, while broader concurrency rules and architecture changes enter a later plan. Make both visible so emergency work does not erase the underlying lesson.

Days 11–20: make decisions and interfaces explicit

Introduce a lightweight decision record for choices that are costly to reverse: task scheduling, memory ownership, inter-process communication, CAN message semantics, compatibility, boot or update strategy and error recovery. Capture context, alternatives, decision, consequences and the evidence that would trigger review. A short record is better than a perfect template nobody maintains.

Focus reviews on risk. A low-level driver change may deserve hardware traces, boundary tests and a recovery scenario. A naming cleanup should not wait for the same meeting. Define which changes require architecture, safety, security or hardware input and set a response time. Delegate decisions to the closest capable people within clear boundaries.

Stabilise interface ownership. For every important hardware-software or component boundary, agree on versioning, data ranges, timing, error states, test responsibility and compatibility. CAN databases and generated artefacts should have an authoritative source and review path.

Days 21–30: deliver one improvement and a ninety-day path

Choose one improvement that reduces recurring friction and can be completed safely: a reproducible build, a deterministic interface test, a field-diagnostic trace, removal of a flaky release test or an automated compatibility check. Deliver it with the team, document the before-and-after evidence and make ownership durable.

Build the next ninety days around outcomes rather than a personal backlog. Group work into product risk, delivery flow, architecture and team capability. Limit simultaneous structural initiatives. Sequence experiments before commitments when hardware behaviour or timing remains uncertain.

Present the plan with trade-offs and decisions required from the client. Make dependencies on hardware, suppliers, environments and specialist availability explicit. A good consultant leaves leaders able to choose, not merely informed that the code is complicated.

Leave capability behind, not dependence

Share context continuously through pairing, concise records, diagrams that match reality and reviews that teach the reasoning. Rotate meeting and review ownership. Make sure more than one person can build, release, diagnose and modify each critical area. The consultant may temporarily carry a difficult responsibility, but should always have an explicit transfer path.

Use Nordkood's talent experience to find relevant assignments, express interest with a lightweight swipe and follow recruiting progress in one place. Once on assignment, your strongest signal is not how many decisions require you; it is how confidently the team can make sound decisions with the system you helped establish.

Keep a weekly transfer note: decisions others can now make, procedures another person has performed and risks that still depend on you. Review it with the internal counterpart. This turns knowledge transfer from a vague final deliverable into observable progress throughout the assignment.

First-month checklist

Use this list as a conversation with the team and client, not a private scorecard. Adapt the order to immediate safety and delivery needs while keeping the transfer of ownership visible.

• Can you build and run a representative target from documented steps?
• Is there a current system and ownership map?
• Are the highest product and delivery risks supported by evidence?
• Do costly technical choices have concise decision records?
• Are critical interfaces versioned, testable and jointly owned?
• Has one recurring source of friction been measurably improved?
• Does the ninety-day plan expose trade-offs and client decisions?
• Is knowledge transfer happening through daily work rather than a final handover?