The Purview Model of Organization

purview[ pur-vyoo ] noun:

From Latin prōvidēre “to see in advance, look ahead, take precautions, provide for, take measures.”

  1. the range or limit of responsibility, operation, concern, or intention
  2. range of vision, understanding, or cognizance

Context

This piece is about what I currently think of as the Purview Model of Organization. It is not a “new” model that replaces an “old” one or something you must transition to or anything like that. It is a model—a way of engaging with and discussing—current, existing realities inherent in human organizations. Being able to explicitly and clearly refer to and talk about stuff is useful, right?

The Purview Model is presented here in the context and language of contemporary digital product & service making organisations. The examples draw upon this framing. However, as a high-level concept, the Purview Model can be applied and explained in most any other setting and its language.

Intro

When making a product, lots of work needs to happen. That work exists across many different professional fields, but also at varying levels of more or less “here and now” versus “there and later.” In other words, what needs to be done now, by whom, and what will need to be done tomorrow, next month, in the next year.

We can make distinctions between “doing” and “planning”, and be tempted to ascribe a clichéd value judgement, but this is counter-productive. Work planning is also work; work which can require as much effort and experience as doing. Where this may not be so obvious — and with a wider discrepancy — is with physical labor. However, as modern software design and development is almost purely intellectual labor, the difference is difficult to measure. Once we accept that “planning for the doing” is as much work as the actual “doing”, we are freed to draw more useful distinctions, distinctions based on what we can call “purview.”

The word purview here means “the range of topics or concerns which are in one’s scope of activity and influence.” An easy way to think of one’s purview in an organization is as basically one’s “job description”: what are you responsible for, when and by what means?

Let’s take for example a startup scenario. A developer’s purview may be to write and commit code on the currently in-progress software project. A UX designer’s purview may be to conduct user tests, and prepare proposals for next week’s sprint. A Head of Product’s purview is to think about what products need to be delivered in 6 months to remain competitive and make sure the team has the resources to deliver that. The CEO’s purview is to maintain and evolve the organization’s vision, the relationships with the investors, etc… to make sure the lights stay on well into the future.

Without talking about hierarchy or professions, we can see here already a levelled structure of responsibilities based on how far ahead the role is required to think ahead, plan and act.

We might be tempted here to think the Purview Model is tied to hierarchical organization, but that’s not what it is about. The model may be applied that way, but it is neither implied, nor necessary. Again in the startup example, we find a small team of individuals who must “wear many hats” and need to operate at multiple levels of purview as part of their responsibilities. Even in a one person operation, that person needs to be able to move between and negotiate the levels of purview, and in fact many roles require us to do so.

It’s about how far ahead and abstract the nature of a given responsibility is.

That’s why this is called the Purview Model: it encompasses what is within one’s sphere of responsibility, how far does one need to look ahead — to view the terrain — and all which that entails — in terms of risk, contingency, preparation.

Of course, plans and “the future” are more abstract than actual code and UI assets in production; the further ahead one must look, the more abstract the materials and tools become. CEOs might talk in almost poetic visions, VPs in financial projections, Product Leads present slide decks of next month’s features, dev leads have thoughts about preparing the software architecture to handle future scale and minimize development debt.

So…

The Purview Model exists along two axes:

  • the level of abstraction, and
  • the distance of foresight.

Clearly understanding the “levels of abstraction” is already valuable and powerful on its own, so let’s begin with that. From there the time dimension becomes fairly obvious.

The Purview Levels

The Purview Model levels go from more tangible work to more abstract work. From the bottom up, they can — in our context — be referred to like this: Production, Product, Portfolio, Organization. (Note that larger organizations may have additional levels; for example a “Program” level between Portfolio and Product.)

The Purview Model Levels: Production, Product, Portfolio, Organization.

Production

Production is, well, production. It’s the coal face, where the sausage is made, and the rubber meets the road. The people involved in Production level work are focussed on what needs to be done right now and the immediate short term (e.g.: this week).

Product

At the Product Level, we might find a Product Manager, a Dev Lead and a UX Lead. They are responsible for figuring out a plan that might span a few months ahead to a major release, and to parcel that out into shorter term goals for the Production Level.

Portfolio

At Portfolio Level we find a Head of Product or a VP who is responsible for one or more Products and the activities necessary to bring them to market: setting goals and targets for a cohesive and successful reception in the market.

Organization

In our current context we may also call this the Company Level. At this level, we find the upper leadership team, crafting the organization’s vision, and establishing the relationships, acquiring the funding and fulfilling the staffing needed to bring that vision to reality.

(If we wanted to use more generic, and perhaps too militaristic terms, we could use Execution, Tactics, Strategy & Vision, for example.)

Why Levels of Abstraction

Why does the Purview Model refer to the level of abstraction, or “degree of abstractness”, of the work?

While some may snicker at this, CEOs do very concrete things like write emails, give presentations, participate in meetings — all of which are crucial for their success. They are not responsible for the writing of the email, but for, amongst other things, the perception, distillation and communication of the long and wide view of the future of their organization.

In a similar way, the programmer writing a feature’s functions is not responsible for the typing they are doing, but for the on-the-spot bringing together of their knowledge and experience, and applying it to a relatively localized, immediate need.

In both cases, we can argue that “the thing being handled” is abstract, certainly. But the line of code coming out of the programmer’s mind is one step away from being reified in a piece of executable, functioning software, whereas a CEO’s valuable contributions are far more general, far reaching and require a great deal more work and time to be refined down until they are translated into tangible results. They are abstract in that they are indirectly affecting the final product.

This is what we mean here by abstraction and why we couple it with “views into the future.”

Why Distances of Foresight

The Purview Model invokes foresight — the activity of looking forward, forming a view of what is likely coming up ahead, and planning for it — explicitly. It does because often it’s not clear what time scales colleagues with different purview are working in.

(Anyone who’s ever had an excited senior executive participate in a production planing session knows how catastrophic this can be. At best the dev team is confused; at worst they take the future visions as direction for priority planning the next sprint.)

Providing this clarity can save a lot of confusion, misunderstanding and thus wasted time and money. It may also provide insight into an aspect of people’s work that isn’t necessarily visible: abstraction and the future are not tangible physical things after all.

In Conclusion

The point of the Purview Model — here expressed as Production, Product, Portfolio & Organization — is to make explicitly clear the notion of the different time scales various organizational activities are engaged in. This clarity not only prevents unnecessary friction and confusion, but also provides visibility and understanding of what activities take place and responsibilities are at stake in different roles.

Postscript

There is a lot that can be said about the power dynamics inferred from being responsible for increasingly broad and future-making insight. Knowing something before others is inherently a powerful tool. Theoretically this lies at the root of the hierarchical social systems we humans have subjected ourselves to since we became more agrarian sedentary than hunter-gatherer nomadic.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.