organizing-for-outcomes
Organizing for Outcomes
Use this skill when the management problem is structural: the team may understand outcomes conceptually, but the organization still runs on feature silos, handoffs, and backlog politics.
Boundaries
- Use
outcome-thinkingwhen the problem is conceptual clarity about outcomes, impacts, indicators, or OKRs. - Use
outcomes-based-planningwhen the main task is roadmap conversion or journey mapping. - Use
outcomes-driven-transformationwhen the focus is organizational adoption experiments or internal behavior change programs.
Default procedure
- Identify how the organization is currently grouped:
- by channel
- by platform
- by page or feature area
- by customer journey or outcome
- Determine which customer or user outcomes cut across those boundaries.
- Align intake, prioritization, and collaboration around those outcomes.
- Define how success will be reviewed over time instead of asking "is the feature done?"
- Rebuild trust with stakeholders through clearer prioritization and honest capacity management.
Defaults
- Organize around customer journeys or outcomes when cross-functional behavior change matters.
- Use early design-dev-user collaboration instead of design-to-dev handoff.
- Establish hypotheses and review windows before starting major outcome work.
- Reset impossible backlogs instead of maintaining false hope.
- Maintain a separate run-the-business lane for low-uncertainty operational work.
Signals that reorganization is needed
- teams compete for the same shared resources
- stakeholders negotiate for slots instead of aligning on outcomes
- large backlogs create false expectations
- teams can report feature completion but not value delivered
Gotchas
- A feature-centric structure will quietly de-prioritize cross-journey outcomes.
- Stakeholders often ask for certainty they cannot actually have; you need review logic, not fake precision.
- Throwing away backlog items can be correct if the backlog is already impossible.
- Without trust, outcome language sounds like an excuse for not delivering.
References
- Read references/organizing-for-outcomes.md when the task involves team structure, cross-functional workflow, backlog reset, or stakeholder trust.
More from jimnguyendev/jimmy-skills
backend-go-testing
Provides a comprehensive guide for writing production-ready Golang tests. Covers table-driven tests, test suites with testify, mocks, unit tests, integration tests, benchmarks, code coverage, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, memory leaks, CI with GitHub Actions, and idiomatic naming conventions. Use this whenever writing tests, asking about testing patterns or setting up CI for Go projects. Essential for ANY test-related conversation in Go.
14backend-go-code-style
Golang code style and readability conventions that require human judgment. Use when reviewing clarity, naming noise, file organization, package boundaries, comments, or maintainability tradeoffs in Go code. Do not use this for golangci-lint setup or lint output interpretation; use `jimmy-skills@backend-go-linter` for tooling.
12backend-go-safety
Defensive Golang coding to prevent panics, silent data corruption, and subtle runtime bugs. Use whenever writing or reviewing Go code that involves nil-prone types (pointers, interfaces, maps, slices, channels), numeric conversions, resource lifecycle (defer in loops), or defensive copying. Also triggers on questions about nil panics, append aliasing, map concurrent access, float comparison, or zero-value design.
11engineering-rest-api-design
REST API design conventions covering URL structure, HTTP methods, pagination, async patterns, idempotency, error envelopes, and API documentation standards. Use when designing new endpoints, reviewing API contracts, or establishing API guidelines before implementation in any language.
11backend-go-design-patterns
Idiomatic Golang design patterns for real backend code: constructors, error flow, dependency injection, resource lifecycle, resilience, data handling, and package boundaries. Apply when designing Go APIs, structuring packages, choosing between patterns, making architecture decisions, or hardening production behavior. Default to simple, feature-first designs unless complexity has clearly appeared.
11backend-go-grpc
Provides gRPC usage guidelines, protobuf organization, and production-ready patterns for Golang microservices. Use when implementing, reviewing, or debugging gRPC servers/clients, writing proto files, setting up interceptors, handling gRPC errors with status codes, configuring TLS/mTLS, testing with bufconn, or working with streaming RPCs.
11