Embedded Engineer Add-on

The Embedded Engineer is an add-on to DevOps-as-a-Service that makes dedicated time of one of our engineers available to your team. Where DevOps-as-a-Service runs and safeguards your platform, the Embedded Engineer reaches further: it takes on challenges and pains that normally sit on your side of the shared responsibility model, and adds dedicated engineering capacity you can direct at your own priorities.

It is meant for teams who want more than platform management: someone who knows your business and workloads, works inside your processes, and helps close the gap between application and platform work, without becoming a single point of contact or a substitute for your own engineering.

What the Embedded Engineer does

The add-on works in two ways:

It takes on selected application-level responsibilities. Under standard DevOps-as-a-Service these stay with you (you build it, you ship it). With the Embedded Engineer you can hand over the ones that drain your team, or have the engineer make them self-serve for your developers. Some examples:

• Secrets management for your applications, including migrations to managed secret stores
• CI/CD pipeline development for your applications
• Deployment management: rollouts, releases and deployment processes
• Container & Kubernetes support: container optimisation and manifest management
• Developer tooling: building the tools, workflows and automation your developers rely on
• Application observability: monitoring, logging and alerting for your workloads
• Performance tuning and application scaling

You choose what the engineer focuses on and which responsibilities to hand over, and you can take them back at any time: your team stays the owner and decision-maker, the engineer is capacity you direct, not a replacement for your platform ownership. The full picture is in the shared responsibility model, where the applicable responsibilities flip to Skyscrapers while the add-on is active. The rest stays with your team.

It gives you dedicated capacity. Beyond taking over responsibilities, the Embedded Engineer is reserved time you can point at whatever matters most, scoped projects, recurring improvement work, or unblocking your developers. Because the engineer already knows your context, that work starts faster and carries less hand-over overhead.

Compared with hiring, you skip the recruiting and the multi-month ramp, you scale the commitment up or down as your needs change instead of making a hire-or-fire decision, and the one person you work with is backed by the full Skyscrapers team’s expertise through the same retainer.

How we engage

The Embedded Engineer is delivered as a retainer: a set number of days per week, on fixed, pre-agreed times, with the engineer working remotely. Your reserved time is dedicated to you; any deviation is agreed with you rather than assumed. We propose the engineer who will provide the service. The engagement runs in three steps, and all three are part of the service.

Onboarding

The engineer already knows the infrastructure Skyscrapers runs for you. The engagement starts with a lightweight onboarding to learn the rest: your processes, the tools you use, and the parts of your environment we are not already aware of but the engineer needs during the assignment. It also covers an access and tooling checklist and an agreed starting backlog, including which responsibilities you are handing over and how interaction will work. It is deliberately a focused orientation to make the engineer effective quickly; deeper understanding of your applications builds over the course of the assignment.

Ongoing cooperation

Who works with the engineer is agreed at the start of the engagement and can adapt as the work changes: depending on what needs doing, that can be a single point of contact, your team leads, or the teams directly, including pairing and working sessions. You integrate the engineer into your own processes and tooling (backlogs, stand-ups and planning) as far as you want to.

A push/pull model works best: you bring work to the engineer, and the engineer proactively flags improvements and pain points. Day-to-day cooperation runs through a shared Slack channel and sync calls when needed; the engineer self-directs within the agreed scope when unblocked and keeps you informed through your preferred methods. All changes go through pull requests and respect your existing branch protection and review rules: changes in your repositories stay subject to your team’s approval, and platform-area changes are reviewed on the Skyscrapers side, including on responsibilities you have handed over. The engineer works inside your change process rather than around it. Strategic direction and quality stay with your Customer Lead through the regular status calls, and the engineer shares a regular report internally at Skyscrapers on the work performed. If a task needs skills the engineer does not have, the engineer can pull in other Skyscrapers experts through the same retainer.

You set the scope of the assignment anywhere on a spectrum, from open-ended (“help us improve our delivery and tooling”, with priorities that shift over time) to goal-specific (a defined outcome such as “migrate us to a new CI/CD system” or “prepare a new region launch”).

The Embedded Engineer does delivery and improvement work, not operations. Taking on a responsibility means doing the work behind it, not standing on-call for it: on-call, incident response and other operational duties stay out of scope. Production incidents always follow the standard DevOps-as-a-Service support and on-call path, whatever work the engineer has taken on.

Handover and offboarding

Handover is part of how the engineer works, not only something that happens at the end. Whenever a task or project is delivered, or the scope changes, we do a handover and provide documentation where needed, so your team can take the work further. The same applies when the engagement ends, a goal-specific assignment winds down, or you reclaim a single responsibility mid-engagement: any responsibilities the engineer took on are handed back with the same documentation and walkthrough as onboarding, so nothing is left orphaned and your team can pick the work up cleanly.

Continuity

The Embedded Engineer is not a single point of contact or a single point of failure, and the service is designed to keep it that way:

• Work and decisions are documented, with runbooks and documentation kept in your own repositories rather than living only in the engineer’s head.
• Knowledge is shared back into your team and into Skyscrapers, so context is never trapped with one person.
• Should the assigned engineer be absent or need to be replaced, we inform you as early as possible and ensure a proper hand-over of context to a suitable replacement.
• All work the engineer produces (pipelines, tooling, automation, runbooks) is your work product, kept in your own repositories from day one.

What’s not included

• The Embedded Engineer does not do operations. On-call, incident response and other operational duties are out of scope. Support requests and incidents continue to go through the standard support process, including 24/7 on-call for production. The engineer is dedicated, planned capacity for delivery work, not an operations, on-call or support resource.
• It does not replace DevOps-as-a-Service. The add-on is additive: it never takes over platform responsibilities that Skyscrapers already holds under DevOps-as-a-Service.
• It does not take over your application development. The line is the code itself: the engineer works on everything around your application (delivery, tooling, scaling, observability), but changes to your business logic stay pull requests your team authors and owns.

Engagement & terms

The Embedded Engineer is a payable add-on and requires an active DevOps-as-a-Service agreement. It runs as a monthly retainer that renews after an initial term, with a notice period for changes or termination.