The setting
's keep code in Git repositories and run automated pipelines, written in YAML, that build, test, and deploy software. Teams run it as a hosted service, on their own servers, or as a managed service for one customer.
A complete intake form does not settle who should take the work.
Planning needs comparable requests, while engineering and security need their competing dependency claims preserved.
Who you’d be doing this for
“I filled in every field, then got asked who owned the security prerequisite again.”
Bhavna Sethi · DevOps Engineer · a character in this brief
Submits infrastructure requests that need engineering and security coordination before pipeline changes can proceed.
What is at stake
Program managers reopened 17 of 46 infrastructure requests despite completed intake fields. You decide whether conflicting owner claims should halt enrichment or enter planning as competing proposals.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- comparable fields vs preserved nuance
- single owner name vs split engineering and security claims
- dependency context vs restricted access
- requester effort vs inferred context
Why Gitlab
GitLab issues, epics, and handbook-first coordination carry infrastructure requests across an all-remote R&D organization.
Written with these in mind
Not your kind of problem? 30 more at Gitlab, or browse every organization.
Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.
The organization context comes from public information. The situation and characters are written for the brief.
Job postings it was written from
Public descriptions of the work at Gitlab. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.
- Principal Technical Program Manager (opens in a new tab)
- Driving infrastructure modernization and scalability programs that support our growing customer base
- Lead end-to-end technical programs across product, engineering, data, and security, from initial scope through launch and continuous improvement
- Technical Program Manager (opens in a new tab)
- Facilitate working group meetings and async discussions to support decision-making, surface tradeoffs, and keep programs on track.
- Lead 1–3 strategic technical programs at a time spanning multiple engineering teams and product stages, ensuring clear scope, priorities, and outcomes.
- Senior Manager, Technical Program Management (opens in a new tab)
- Manager, Technical Program Management will work closely with Product and Engineering leadership to ensure that TPMs are assigned to high priority programs and that they are successfully delivering results for customers.
- Staff Program Manager, CCO Programs (opens in a new tab)
- Recommend scope changes, re-sequencing, or ending a program when it is not delivering value.
- Customer Experience Enablement Lead (opens in a new tab)
- Scope and build new enablement content, including programs focused on product knowledge, skill development, onboarding, leadership development, and many other areas, specifically for the CX organization.
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.
Where similar work appears
Other live briefs connected to this one, and what connects them.
Similar problems at other organizations
Like this one, each of these turns on moving faster inside a system others depend on.
Readiness records stay stale even after owners discuss changes in Slack and email.
You choose what the agent writes into a readiness record from a thread, and what waits for the owner and program manager to confirm.
Agent-created issues are entering intake faster than product managers can judge their planning value.
You have to weigh a faster path into work against a review moment people will actually use.
Program managers are rebuilding engineering status because milestone reviews cannot show live dependency risk.
You must weigh a useful shared view against the engineering team’s need to keep its existing workflow intact.
The same setting, from another role
Each is set around Gitlab’s Integrated source control and CI/CD, written for a different role. They’re separate briefs, not the same scenario.
Repository investigations are consuming critical release time because the first plausible cause is hard to verify.
You must decide what AI assembles, what engineers confirm, and how the pilot proves the difference.
Required approvals are appearing after merge requests enter review, creating avoidable rework.
You have to weigh a clear preview against the performance and fidelity of repository rule evaluation.
Agent-written CI/CD changes are creating unexpected runner demand after they merge.
You must weigh early cost guidance against estimates that could overstate risk and slow useful changes.
Other problems with a similar purpose
In each of these, as in this one, the aim is making daily workflows and product experiences feel coherent, calm, and dependable rather than effortful.
Thirty-one percent of captured tasks still have no owner after 24 hours.
You need to weigh faster capture against the accountability project managers need to move work forward.
Promising discovery calls are losing momentum while sellers rebuild notes and account research by hand.
You decide at which point between the call record and the account plan a drafted next step passes to the seller who has to stand behind it.
Project managers are rebuilding fields and types for recurring work, leaving portfolio reports inconsistent.
You have to weigh fast reuse against the flexibility enterprise workflows need.