Principal Software Engineer

Description

About CloudBees:

CloudBees helps organizations build, run, and govern software factories, giving enterprises the confidence to ship software better and safer.

Writing code is no longer the bottleneck. Governing what reaches production and validating its impact is. As enterprises adopt agentic coding, software gets created faster than most teams can review, secure, and validate it. Without consistent governance, organizations end up shipping code they can't explain, audit, or trust.

CloudBees Unify is a governance layer that works with the tools a customer already runs, instead of asking them to replace them. It makes every change, human or AI, visible and accountable before it reaches production, and enforces the same policy across every tool, team, and workflow.

Founded in 2010, CloudBees is backed by Goldman Sachs, Morgan Stanley, Bridgepoint Capital, HSBC, Golub Capital, Delta-v Capital, Matrix Partners, and Lightspeed Venture Partners.

Visit us at cloudbees.com (https://www.cloudbees.com).

About the team:

Our department, internally called "Faster, Safer Releases," has three areas: CDRO Classic (CloudBees CD/RO, our established, self-managed release orchestration product, still very much serving customers today), Unify Release Orchestration (Unify RO, its newer sibling, delivered as a SaaS), and Unify FM (feature management). You'd help shape the technical direction of Unify RO alongside the engineers already building it, who are rethinking what release orchestration can look like rather than porting CDRO Classic.

You'll join a core team of experienced engineers, and many more people contribute to the RO codebase beyond that: engineers from other teams across the department often land on it. You won't manage anyone. You'll be a go-to technical contact for RO work happening outside the core team, and you'll share accountability with the core team for the codebase's long-term health, including bridging to CDRO Classic customers curious about Unify RO and pushing internal dogfooding so CloudBees' own teams ship their own PRs faster and safer, alongside Unify FM.

What you'll do:

Help shape where Unify RO goes

• •Learn the current RO architecture from the people who built it, well enough to form an evidence-based view: what's solid, what's accumulating risk, and which ideas from CDRO Classic are worth carrying forward.
• •Help sequence the technical roadmap so the team ships value every few weeks, not a multi-quarter rewrite. You'll work closely with the RO product manager, as a conversation with the whole team rather than a two-person channel: product owns what and why, engineering owns how and in what order.
• •Stay hands-on with hard problems, especially ones that cross team boundaries and have no natural owner today.

Make the team stronger, not more dependent on you

• •Work as a peer with strong engineers, on the core team and on other teams when they're on RO, as ready to be persuaded as to persuade.
• •Bring context from across the department and from customers. Most technical calls stay with the engineers closest to the work: your job is to make those calls better informed, not to collect them.
• •Give candid, useful design and code review, and expect the same back.

Build the bridge to CDRO Classic and the business

• •Talk to CDRO Classic customers interested in Unify RO. Bring back what actually matters to them.
• •Drive adoption of RO pipelines inside CloudBees itself: help other teams ship PRs from dev to production faster and safer, combining progressive delivery with feature flagging, in partnership with Unify FM.

Make quality the default, not an afterthought

• •Keep testing, service boundaries, and release discipline strong as the team and roadmap evolve.
• •Pay down tech debt as you go instead of letting it pile up behind the next feature.
• •Push observability toward finding root causes fast.
• •Make it possible for other teams to move fast in the RO codebase without breaking it: through tooling, clear specs (including for AI-written changes), onboarding, and code review.
• •Write down architectural decisions and the reasoning behind them, so nobody has to rediscover it in six months.

Requirements

What we're looking for:

Must have

• •10+ years of experience, with principal or staff+ scope you can point to: you've joined a complex, live system and its team and measurably improved it together, including the sequencing and trade-off calls involved.
• •You lead through influence and technical credibility, not formal authority. If what attracts you to this role is the chance to "decide" things, this isn't the right fit: every engineer here, principal included, asks good questions and earns agreement rather than pulling rank.
• •Strong opinions, loosely held. Earning agreement means forming a real point of view and arguing for it, then dropping it fast when someone shows you better evidence.
• •The same goes outside the team: you're comfortable talking directly to customers about technical trade-offs.
• •Hands-on backend depth building and operating microservices on AWS, ideally in Go. Strong experience in a comparable backend language, with appetite to go deep in Go, also works.
• •The distributed-systems depth that goes with it: concurrency, event-driven architectures, message buses, and what actually breaks in each of them in production.
• •Hands-on use of AI coding agents (Claude Code, Cursor, Copilot, or similar) in your own work, not secondhand opinions. You know where they're good and bad, and that shapes how you think about architecture, review, and the governance problem Unify RO exists to solve.
• •A sense of humor. You'll need one some days, and it'll help on the good ones too.

Nice to have

• •Experience with CI/CD systems, workflow/pipeline engines, or developer platforms.
• •Experience with progressive delivery or feature flagging.
• •Java. CDRO Classic is written in Java, and knowing it shortens the ramp on deciding what to keep.

Who this is for:

You like joining a system that's already moving, built by people who know it better than you will on day one. You'd rather improve what's working than rewrite it from scratch, and you're energized by a role that's equal parts deep technical work, customer conversations, and getting other CloudBees teams to use what the team builds. Sharp and a little irreverent beats technically flawless but humorless, as long as you still ship.