July flash sale
Engineering managers and tech leads often inherit a queue nobody can see: production support, architecture decisions, technical debt, platform requests, security changes, reviews and delivery work. Individuals appear busy while important items age between specialists. KMP 1 helps when the leadership problem is managing the system of work rather than increasing personal utilisation.
The KMP 1 Kanban System Design course provides a way to understand services before selecting visualisation, WIP, pull, risk and feedback policies. It does not prescribe one engineering board. A platform service, product team and architecture review service can need different boundaries and policies.
High utilisation can damage engineering flow
When every specialist is fully allocated, new work waits for the exact skill it needs. Review queues grow, context switching increases and urgent requests displace planned work invisibly. A system view shifts the conversation from whether each person is busy to whether valuable work flows predictably.
| Engineering demand | Risk to expose | Design question |
|---|---|---|
| Production incident | Customer harm and urgency | How is expedite limited and reviewed? |
| Feature delivery | Delay and market learning | Where is commitment made? |
| Technical debt | Future failure or delivery drag | How is capacity or selection policy explicit? |
| Architecture review | Specialist queue and dependency | Can review begin earlier or capability spread? |
| Platform request | Cross-team waiting | What service expectation can evidence support? |
Visualise knowledge work without policing people
The board should show work and relevant workflow, not become a public activity monitor. Avoid columns for every person's status, WIP limits used as individual quotas, or metrics used to rank engineers. Those choices encourage gaming and hide collaboration. Design around service delivery and use metrics for system learning.
Leadership policies KSD can make discussable
- Who can interrupt the team and under what conditions.
- How reviews are pulled and how old review work escalates.
- What evidence supports starting another item.
- How blocked work changes replenishment decisions.
- When technical-risk work competes with product demand.
Do not solve a capability gap with a board
If one specialist is the only person able to deploy or review a critical component, visualising the queue will not remove the constraint. The system may need pairing, automation, architecture change, hiring or altered ownership. Kanban makes the economic effect visible so leaders can choose; it does not manufacture capacity.
Bring one engineering service to training
Use a service with enough repetition to inspect, such as platform requests or production changes. Gather arrival rate, completed items, age, blocked reasons and common demand types if the data is available. If it is not, bring the workflow and uncertainty without fabricating precision.
Know what KMP 1 will not teach
KSD is not an engineering-management, DevOps or architecture course. It will not teach technical coaching, reliability engineering, code review technique or cloud operations. It helps leaders design how knowledge work is selected, visualised, pulled and reviewed. Choose it when the management gap is the work system; choose technical development when the constraint is engineering practice itself.
Read blocked-work policy for KSD and Kanban dependency management for two common engineering constraints.
