Thoughts on working together, and supporting organizations

View the Project on GitHub NewAlexandria/leadership_readme


I like to aim for a lightweight workflow for Overarching planning documents (Charters / Charters / etc) as they move from an idea until they’re ready to be implemented. Usually this process is managed in an ad hoc fashion, and as a result often lacks visibility and consistency. Here is what we are aiming to avoid.



Non Goal:


Most of these will have already been implemented. For more, see the section on teams and meetings

⚠️ Only prototype-in-isolation what you are willing to throw away once cross-functional input comes, from Agile Planning.

( spikes, and gold spikes )


The idea of reviewing and leaving comments on a completed Charter is well-established in the tech organization, and the subsequent epic process is mostly standardized. However the process of actually developing a Charter has largely been left as exercise for the reader. This worked fine when the vast majority of the work on Charters was done by 2-3 people, but as the Engineering and Product teams grow, we need some process to better coordinate everyone involved.

As well, the Charter process in Engineering generally occurs after some Business planning. Afterward, a release or launch planification helps the company own the success. These major stages needed a place in the big picture. Here we’ll proposes to outline and detail all of that, in a way that can translate to input from stakeholders org-wide.

Stages of Planning, Delivery, and Operationalization

We will consider a few models for how cross-team interaction can look. These will expand and build upon one another.

This doc does not include specific guidance on ratios of types-of-staff within the team, but for related reading see this article. This may fall under the topic of ‘org planning’, ‘scaling teams’, and other cost-to-value ratios. Engineering / Technology leaders will not set these purely on their own, and instead work with financial, ops, or other P&L staff (even if the engineering leader / role fully owns their P&L).

Product and Engineering

The concise chartering process focuses on Product p. anning, Engineering, and Release:


Charter Types stand as the granular versions of broader phases of work that go on within the whole lifecycle of corporate planning. These phases can overlap. The current consideration of these looks like this:


For detailed handling of configuring systems to hold all of these practices, you should maintain docs on how to repeatably do setups. Eventually, these can be automated.


Every Charter should have the following checkpoints:

Requirements Review

The stakeholders must agree on the requirements once they are gathered. If they do, product and engineering should agree about how to proceed with writing the Charter and schedule incremental check ins. If they cannot agree, the requirements must be reworked.

Incremental Charter Check In

The product and technical designs should be informed by each other and should be iterative, so check ins among the people working on producing the Charter are really important. They’re also a good way to keep momentum.

Final Review

Once the Charter is complete, all stakeholders must agree on the scope of work. Ideally stakeholders should be involved in prior checkpoints so there aren’t any huge surprises at this point.

Stakeholders vary depending on the type of Charter. The stakeholders for a product Charter would include a product manager, the lead engineer and a business sponsor. For an eng Charter, the stakeholders might be a group of engineers.

For eng Charters, the tasks handled by a product manager would be either handled by the lead engineer (e.g., gathering requirements) or skipped (e.g., producing a product design).

Agile Ritual

I find that much of the literature on Agile practices involves the use of euphemistic phrases. You may have seen these in examples like ‘pop the happy-bubble’, etc. It appears that all of these are rooted in the narrative process of mind. Examples of pattern languages underscore this, such as for

The theoretical roots of this extend from the concept of Literary Topos, which are akin to Jung’s archetypes but potentially set in a more rich semantic ecosystem. Literary Topos may be the granule of character archetypes, in the sense of Joseph Campbell’s work.

Such narrative topoi certainly evolve with the changes of culture, at the macro level and within professions. When used skillfully they should lubricate the system of communication. In contrast, when the macro-org is dysfunctional, a narrative topos will be experienced more like trope, and often create the opposite effect.

In a later article, we can look at how this psychological schema graph intersects with the operational schema. Indeed, both are roadmaps. Doubtless that excessive lag between certain elements of each feel like real drag in the experience of team flowstate.

Agile Anti-pattern

These anti-patterns are a mix of cross-team situations, and inter-team dynamics. They have been source from Steve McConnell’s “Rapid Development,”. Despite the book being more than 25yr old, these factors have largely not disappeared. Such shows that the issues are human conditions, and require interpersonal strategies (management) instead of just commitment-to-principle.

  1. Undermined motivation
  2. Weak personnel
  3. Uncontrolled problem employees
  4. Heroics
  5. Adding people to a late project
  6. Noisy, crowded offices
  7. Friction between developers and customers
  8. Unrealistic expectations
  9. Lack of effective project sponsorship
  10. Lack of stakeholder buy-in
  11. Lack of user input
  12. Politics placed over substance
  13. Wishful thinking
  14. Overly optimistic schedules
  15. Insufficient risk management
  16. Contractor failure
  17. Insufficient planning
  18. Abandonment of planning under pressure
  19. Wasted time during the fuzzy front end
  20. Shortchanged upstream activities
  21. Inadequate design
  22. Shortchanged quality assurance
  23. Insufficient management controls
  24. Premature or overly frequent convergence
  25. Omitting necessary tasks from estimates
  26. Planning to catch up later
  27. Code-like-hell programming
  28. Requirements gold-plating
  29. Feature creep
  30. Developer gold-plating
  31. Push-me, pull-me negotiation
  32. Research-oriented development
  33. Silver-bullet syndrome
  34. Overestimated savings from new tools or methods
  35. Switching tools in the middle of a project