PEP 8002: Add section describing an idealised version of the process used at Microsoft (#772)

pep-8002.rst

@@ -588,6 +588,151 @@ They retired (`Adrian's post
 9 years into the project's history.  Following the stepping down,
 the DEP process was defined.
 
+Microsoft
+=========
+
+Despite the selection process for "relevant projects" described above,
+it is worthwhile considering how companies that are held financially
+accountable for their decisions go about making them. This is not
+intended as a readily-usable model for Python, but as additional insight
+that may influence the final design or selection.
+
+This section is not taken from any official documentation, but has been
+abstracted by Steve Dower, a current Microsoft employee, to reflect the
+processes that are most applicable to individual projects in the
+engineering departments. Role titles are used (and defined) rather than
+identifying specific individuals, and all names are examples and should
+not be taken as a precise description of the company at any particular
+time in history.
+
+This is also highly simplified and idealised. There are plenty of
+unhealthy teams that do not look like this description, and those
+typically have high attrition (people leave the team more frequently
+than other teams). Teams that retain their people are usually closer to
+the model described here, but ultimately everything involving humans is
+imperfect and Microsoft is no exception.
+
+Key people and their functions
+------------------------------
+
+Microsoft has a hierarchy that ultimately reports to the CEO. Below the
+CEO are a number of organisations, some of which are focused on
+engineering projects (as opposed to sales, marketing or other functions).
+These engineering organisations roughly break down into significant
+product families - for example, there has been a "Windows group", an
+"Xbox group", and a "server and tools group". These are typically led by
+*Executive Vice Presidents* (EVPs), who report to the CEO.
+
+Below each EVP are many *Corporate Vice Presidents* (CVPs), each of which
+is responsible for one or more products. This level is where the hierarchy
+becomes relevant for the purposes of this PEP - the CEO and EVPs are
+rarely involved in most decision processes, but set the direction under
+which CVPs make decisions.
+
+Each product under a CVP has a team consisting of *Program Managers*
+(PMs) and *Engineering Managers*. Engineering Managers have teams of
+engineers who are largely uninvolved in decision making, though may be
+used as specialists in some cases. For the rest of this section,
+*Engineering* refers to anyone from the engineering team who is
+contributing with a technical-focus, and *PM* refers to anyone from the
+program management team contributing with a customer-focus. After
+decisions are made, Engineering does the implementation and testing work,
+and PM validates with users that their problem has been solved.
+
+(This is actually a huge simplification, to the point where some people
+in these roles are offended by this characterisation. In reality, most
+people in PM or Engineering do work that crosses the boundary between
+the two roles, and so they should be treated as a term describing the
+work that somebody is doing in the moment, rather than an identifier or
+restriction for a person.)
+
+Teams generally represent a feature, while the CVP represents a product.
+For example, Visual Studio Code has a CVP who is ultimately responsible
+for decisions about that product and its overall direction (in the context
+set by their EVP). But many teams contribute features into Visual Studio
+Code.
+
+For complete clarity, the CEO, EVPs, and CVPs do not ever directly
+modify source code. Their entire role is to provide direction for
+whoever is immediately below them and to adjudicate on controversial
+decisions.
+
+Regular decision process
+------------------------
+
+Changes to product code that are not visible to external users are made
+solely by Engineering. Individual engineers will be assigned tasks by a
+designated engineering manager, or may self-assign. Promotion to
+increasingly senior positions generally reflects trust in the
+individual's decision-making ability, and more senior engineers are
+trusted to make decisions with less validation from the rest of the team.
+Most bugs are covered by this process (that is, fixing a user-visible
+problem without changing the intended experience is an Engineering
+decision).
+
+Decisions affecting users of a particular feature are made by the PM
+team for that feature. They will use whatever data sources available to
+identify an issue, experiment with alternatives, and ultimately prepare
+a design document. Senior members from PM and Engineering will review
+designs to clarify the details, and ultimately an artifact is created
+that the feature team agrees on. Engineering will use this artifact to
+implement the work, and PM will later use this artifact to validate that
+the original issue has been resolved.
+
+Senior members of Engineering and PM teams for a feature are expected to
+make decisions in the spirit of the direction set by their CVP. Teams
+have regular meetings with their CVP to discuss recent decisions and
+ensure consistency. Decisions that are not obviously in line with CVP
+expectations are escalated to the controversial process.
+
+Controversial decision process
+------------------------------
+
+When decisions require cross-team coordination, or do not obviously
+align with previous CVP guidance, teams will escalate decision making.
+These often include decisions that involve changing direction,
+attempting to reach a new or different group of users, deprecating and
+removing significant features (or on a short timeframe), or changes that
+require quick releases.
+
+In general, CVPs are not intimately familiar with all aspects of the
+feature team's work. As a result, the feature team must provide both a
+recommendation and sufficient context for the decision that the CVP can
+decide *without additional knowledge*. Most of the time, the first
+attempt results in a series of questions from the CVP, which the team
+will research, answer and attempt the decision again at a later date.
+
+Common questions asked by CVPs are:
+
+* how many users are affected by this decision?
+* what is the plan for minimizing impact on current users?
+* how will the change be "sold"/described to potential users?
+
+CVPs are expected to have a strong understanding of the entire field, so
+that they can evaluate some questions for themselves, such as:
+
+* what similar decisions have been made by other projects within Microsoft?
+* what other projects have plans that may impact this decision?
+* what similar decisions have been made by projects outside Microsoft?
+* do users need it?
+* is it in line with the direction set by their EVP?
+
+Decisions made by CVPs are generally arbitrary and final, though they
+typically will provide their rationale.
+
+Planning a new release
+----------------------
+
+Releases involve coordinating a number of feature teams, and so rarely
+attempt to include input from all teams. A schedule will be determined
+based on broader ecosystem needs, such as planned events/conferences or
+opportunities to take advantage of media attention.
+
+Teams are informed of the release date, the theme of the release, and
+make their own plans around it following the above decision making
+process. Changing the release date is considered a controversial
+decision.
+
 
 Acknowledgements
 ================