A common complaint among teams working with the conception, design and development of software, self-service, ecommerce and services is that they "don't have a seat at the table".

Behind these seven words we find a threefold complaint of not having enough influence in:

A. Choosing what to work on\ B. Deciding what the solution should be\ C. Shaping how the work is done

Let's have a look at these might look like:

• A team sets out to improve a small detail in a solution, but soon uncovers a much more important underlying issue that they do not have the mandate to work on.
• A new feature launches and the team is ready to start optimizing it based on user feedback, but are called to work on another new feature instead

• A team has the best available information, but a less-involved higher-up decides what they should make or do
• A highly specific output is envisioned before the team begins its work, and their task is to "just make it work"
• A team builds a solution around a best-in-class component, but is made to replace it with a less-capable component that the organization has standardized around
• A team develops a high-performing solution but support for a vital, required component is pulled, and they must launch a sub-standard solution
• A team learns that their solution works well for customers, but that it causes issues internally, but they don't have a mandate to work on this
• A team creates touchpoints for a new service. Along the way, they identify several a number of discoordinations and contradictions in how the service itself has been conceived of. Unfortunately, the design of the service is encased in law, and there is nothing they can do to change it.

• The team must follow the same workflow as all other teams, and has little power to shape how they work
• The team gets caught in feature factory mode, and is prevented from focusing on outcomes
• The team is pressured to start pushing code into production as quickly as possible, leaving little time to come up with a coherent, well-architected solution.

So: to enable optimum outcomes, teams must have sufficient influence in:

A. Choosing what to work on\ B. Deciding what the solution should be\ C. Shaping how the work is done

For the purposes of our discussion, I'm going to call these working conditions the Ideal Frame.

How can we help make sure that teams working with the conception, design and development of software, self-service, ecommerce and services do so within the Ideal Frame?

Sidenote: I apologize for using the long-winded phrase conception, design and development of software, self-service, ecommerce and services to describe what we do, but our field has been plagued by pointless infighting at least since Vannevar Bush wrote the essay that perhaps best conceived of our field, "As we may think" in 1945.

You might also have noticed that I didn't include "management" in the phrase. This is not due to any umbrage against product managers, I am simply fully including their work within "conception, design and development" and not treating it as something exterior or separate.

The team operating within the Ideal Frame:

A. Chooses what to work on\ B. Decides what the solution should be\ C. Shapes how the work is done

For teams already working within the Ideal Frame, these three describe how (or to what degree, nobody's perfect) things are done. For everyone else, they are goals. We must not make the mistake of thinking we can attain the directly.

Instead we must look at how to develop:

1. the internal working conditions – the team's character, capabilities and behavior – to name a few
2. the external working conditions – the operating environment, terrain, available resources, allies, adversaries, rate of evolution and more

Because the external conditions vary, the effort it takes to put in place the Ideal Frame will range from manageable, to extremely challenging. An important element here is that the level of difficulty hinges not just upon the external conditions, but also on the team's ability to successfully respond to and reshape those conditions.

Thus, we see that the degree to which the team:

A. itself chooses what to work on\ B. itself decides what the solution should be\ C. itself shapes how the work is done

… is not endemic to the environment or a function of the team's internal capacity. Instead the degree to which the team achieves all three is the result of the interaction between the team and its environment:

1. How the environment constrains or enables the team
2. How the team operates within the environment
3. How the team works to reshape the environment

Creating the Ideal Frame means reshaping the external conditions under which we do our work.

Did you notice that a key question is missing in all the lists above? Perhaps you wondered "How is the team supposed to be able to reshape the environment" or "How can the team get the mandate it needs to succeed?".

This is an interesting contradiction that presents itself often: a team actively working towards a goal, does not work to alter its own conditions in pursuit of that goal. Instead, it allows itself be bounded.

This isn't a critique of your team or mine, I am merely describing a trait I see across teams working with the conception, design and development of software, self-service, ecommerce and services: they do not actively reshape their environments with the aim of furthering the goals they have set. There are myriad reasons for this, but my aim (in spite of the boorish length of this piece) is action, not diagnosis.

I therefore propose that in the coming decade that:

Teams working with the conception, design and development of software, self-service, ecommerce and services must develop expertise in reshaping their environments to further the goals they have set.

Here are a few suggestions to get us started:

1. Begin investing in influencing policies that affect what you work on and how. Unlike physical products, most things digital have been lightly legislated, if at all governed by law. This is changing. Don't like the ISO standard for User Experience? Not happy with certain GDPR provisions? Not a fan of how WCAG contrasts requirements are calculated? Learn from other professions how to influence policy, and learn to work on these issues over years or decades, because that's how long it often takes.
2. Begin systematically addressing the skill shortage. "Everyone" has been complaining that there are too few skilled and experienced developers, design ethnographers, designers, product managers and so on available for at least a decade. But very few have organized or funded means of joining our field through mentorship, career transition offerings or trainee positions and new graduates are routinely met with demands of 3–5 years of experience. Start building a robust pipeline for skill development and recruiting in your company and your area. Also, remember that not everyone has to have a master's degree to do the work. In many cases, what we need is highly specific training in tools, methods and techniques.
3. Begin building strong professional organizations. Unlike medical professionals, lawyers or civil engineers, people working with the conception, design and development of software, self-service, ecommerce and services don't have strong professional organizations that create professional standards, sponsor research, shape policy, and so on. If we invested time and resources in creating analogous committees, organizations and networks on our respective fields, we would be able to improve the conditions for our work and enable better outcomes.
4. Begin importing useful practices from other fields. People with a background in interaction design and computer science will continue to have a unique disadvantage vis-à-vis political scientists, social scientists and lawyers who have a rich set of tools for understanding and shaping political, organizational, social and legal processes – the ones that people who with the conception, design and development of software, self-service, ecommerce and services labor under. Just as I think it's vital for more fields to become acquainted with designerly approaches, I believe it is essential that people in our fields understand and master the techniques by which economists, policy makers, legal theorists and others have reshaped the workings of the world.
5. Begin reading more widely. It seems that not a week goes by without someone in tech or design needlessly inventing something already well-established in Science and Technology Studies (STS) or making embarrassing assumptions about how things work in other countries, fields or industries. This is completely avoidable: read more widely.
6. Begin cross-pollinating early. One of the wonderful things about HfG Ulm, the template upon which many a design school has been built, was that they brought together operations researchers and cyberneticists with industrial designers and more. But in spite of high-performing product teams having found ways to help design anthropologists, product managers, front-end developers and designers work effectively together, all of these specialties are taught in different schools. I was fortunate enough to go on exchange to Aalto University in 1999 as an industrial design student, and in our industry projects we were put into teams with students from the Helsinki Business School and the Helsinki University of Technology. It was an amazing learning experience, and made everyone much more interested in each others' respective domains. Together, we formed incredible teams. I am of course generalizing through rosy retrospection, but I fervently believe that programs educating designers, technologists, strategists, marketers and more need to create arenas where students can work together and get to know each other and their respective specialties.
7. Take knowledge construction and diffusion seriously. There are many wonderful things about the low entry barriers (= no professional entrance examinations) in design, technology and product management. But the growth in our fields over the past decade has been so enormous that an the Eternal September effect of a steady influx of new entrants to the field who lack a common set concepts and terminologies has meant that professional discourse is either disconnected from practice or simply underdeveloped. An example: when you hear "Design Thinking", do you think of post-its and IDEO's five-step creative method, or do you think of design thinking as a cognitive style, a general theory of design, or as an organizational resource? Hint: almost everyone thinks it's the first. This lack of knowledge diffusion is actively harmful. It results in practitioners using inappropriate, ineffective, inefficient or outright harmful methods. It results in users being offered substandard services. It results in enormous and needless expenditures (I'm looking at you, failed billion-dollar IT projects). It results in misdirected efforts and negative impacts on human health and well-being, social cohesion, environmental health, resource use, economic growth, political freedom and the future of humanity – in aggretate from our various fields as a whole. For a more thorough investigation of of our field, see this article which uses van Gigch's Metamodeling approach show why we are stuck on the implementation level of our fields, and never reach the object or meta levels.

I began by dissecting a common grumble into its constituent part and flipped these over to reveal that a teams that works in an Ideal Frame:

A. Chooses what to work on\ B. Decides what the solution should be\ C. Shapes how the work is done

Then I looked briefly at the team itself, but since others have written extensively about high-performing and safe teams, I chose to focus on what I often find is missing: reshaping the external conditions under which we do our work. We do this so we can pick the right problem, make the right thing and make it in the right way. And then I offered a few suggestions of how we can get better at reshaping the external conditions under which we do our work.

I'm sure you have even better ideas on how this could be done: Team, take the wheel.