Eye on the Prize
Some principles & tactics on software engineering management
Eye on the Prize
A few engineers I previously managed asked me for some material on the changes I usually make with teams. It is hard to put together what ends up being my frequent rants about a few principles, but I’ll try.
These concepts are not new. I learned them over 10 years ago during my time at ThoughtWorks. For a broader perspective on software development principles, I recommend Evan’s ThoughtWorks post.
Managing software teams is about productivity and reliability. Agile simplified development, but three often-forgotten components matter: prioritization, iteration, and finishing work.
A tale of another team
Teams frequently operate in the following way:
Product defines work in cards from a business/user perspective, specifying what needs completion.
Engineering leads divide cards into technical tasks, analyzing cards and deciding technical approaches, explaining these in multiple technical subtasks.
Technical tasks are distributed among engineers for accountability, sorted by technical expertise. If Sara knows a section of the system, she receives related tasks.
Results deteriorate. Stand-ups become status reports about isolated tasks no one understands. Product visibility vanishes. Work supposedly converges at the end, but deadlines continuously slip.
Improving it with principles
During my time at ThoughtWorks, I recall a memorable meeting about non-software problems. When summarizing the situation to a colleague, their response stuck with me: we analyze problems, divide them into small independent pieces, finish and verify each.
This simplicity resonated — it represented standard problem-solving. The insight transformed an overwhelming question into manageable steps.
This thinking generated three core principles I have applied across teams:
Priority
Priorities must be clear. Maintain one backlog with entry/exit rules. All items must be business or customer-focused, deliverable, and independently verifiable.
Focus
Don’t abandon work. Assign one or more engineers to one piece of work simultaneously. Help or shuffle people if complications arise, but never drop pieces. Cycle time represents the optimization measure — not the only one, but the one that will make the most difference.
Get it done
Done means having a piece of work delivered and verified by who asked for it, hopefully in production. Teams work collaboratively, helping each other with complementary skills and expertise.
This isn’t everything needed for team success, but it represents a good chunk of it. Brian Guthrie captured this better:
The secret sauce of software development is incremental change, tight feedback loops, shared knowledge, and mutual respect.
Some common tactics
Achieving principles requires practical implementation. While non-exhaustive, these practices help teams reach the principles above:
Change stand-ups. Stop focusing on people (“what I did yesterday”), focus on work (“what’s happening with this card”). These walk the wall/board stand-ups aren’t new.
Priority is right to left, top to bottom. Make clear that engineers should prioritize finishing cards over starting new work. Adopt “stop starting, start finishing” as the selection mantra.
Don’t tell engineers what to do. Don’t create technical task lists for others. Provide guidance conversationally as work begins, not as advance to-do lists. Engineers make hundreds of daily decisions — more context improves those decisions.
Don’t assign work in advance. While teams do this for accountability, it pressures individual work over teamwork, making the system slower and reducing mutual support.
Work must be business-understandable. Don’t settle for engineer-written cards. Deliver work non-technical people understand and verify. Pair on testing and verification.
Triage defects and measure time spent. Context switching and distractions kill productivity. Establish urgent rules when bugs arise.
Track cycle time and time allocation. Monitor where teams spend time. Results will surprise you.
I think that’s all. Or at least most of it.