Practice What You Preach

In the Datashare project we had been pushing for a participatory approach to technology' development. As we were by now all too aware of the practical difficulty of getting stakeholders interested—and willing to invest time and effort—in workshops, we now opted for a more top-down, theory-driven approach. In other words, we had very practical reasons to prefer a ‘theory-driven’ approach. To avoid re-inventing the wheel we planned to start by mapping the existing academic literature on democracy and digitalization. At a later stage we would then use the case workshops to establish more precisely what Current’s technologists needed and to check whether our proposals fitted their problems.

However, Current was suddenly, much to our surprise, pushing to increase stakeholder participation. They stressed that our project had to practice what it preached: while developing the framework we were to engage as many stakeholders as possible and to make them part of a deliberative process. The reason was that they saw the Democratic Digitalization project as a means to cultivate a larger network that would collaborate in democratizing the smart city. Of course, we wanted to take seriously the interests and demands of our collaborators and funders. More pragmatically, we also depended on Current to make the project a success and to have access to smart city innovators. So, to meet Current’s demands for stakeholder inclusion and network building, we agreed to organize ‘round-tables’ with academics, professionals from various disciplines and backgrounds, politicians, and citizens.

Despite our firm intention to move away from mediating between technologists and their stakeholders, we ended up being charged with exactly that task. Instead of first thinking things through on our own, we found ourselves brokering between different perspectives to come to some shared understanding of the problem and its possible solutions.

Stakeholder Engagement

The round-table sessions were not the success we had hoped. The commercial companies had little intrinsic motivation or incentive, as they did not regard ‘democratic digitalization’ as their priority or responsibility. Politicians and policymakers responded politely to our invitations, but stressed they had to divide their limited time between many initiatives. For citizens, the themes proved to be too abstract and removed from their daily concerns. The participants easiest to interest in a workshop were fellow academics. We had only three hours per session, as that was the maximum we could persuade participants to invest. The discussions in the round-table sessions remained very abstract—even when we invited everyone to focus on one concrete example— and it proved impossible to achieve closure on anything. The energy required to arduously enable translations between stakeholders, i.e., organizing the sessions and engaging stakeholders, came at the cost of actually doing the translating. As a result, the round tables provided us with few new insights, nor were they successful in terms of networking.

By contrast, the case workshops—co-organized with the DD project leader—were more helpful. The project leader concentrated the case workshops on projects and start-ups financed by Current, as their dependence on this company made them prone to collaborate with us. We explored how the technologies that these start-ups were developing raised issues regarding democratic decision-making. The case workshops provided valuable insights into the issues that technology developers were running into in practice. They gave us a deeper understanding of the complexity—in terms of technology, stakeholder relations, politics, legal concerns, etc.—these innovators were dealing with.

External Constraints

While collaborating with the Datashare team, we had felt that we were not given sufficient autonomy to develop a normative position of our own. In the DD project, we thought we had secured that autonomy. In reality, we spent so much time organizing round-table sessions, case workshops, project meetings, and giving presentations at various venues that we made only slow progress on the actual development of the framework.

Halfway through the project we noticed that the momentum was dropping. We were informed that Current had experienced some managerial upheavals and that the CEO who had supported reflective initiatives like ours had been replaced by someone more business-minded. The silver lining of Current’s declining interest was that we now had more time for our theoretical work. Using the existing literature, we developed a diagnostic tool. The tool operationalized ‘democracy’ by identifying core democratic functions and practices and offered a systematic overview of the ways in which digitalization threatens and vitalizes local democracy. It also identified instruments and strategies to meet those threats and to stimulate pro-democratic practices. In this way, the tool provides companies like Current with a vocabulary to discuss democracy in smart cities and what this implies for their technologies.

Our project manager at Current remained in touch with our work and was pleased with the results. However, when we finally presented our results to Current’s higher management, we met a lukewarm response. The corporate responsibility manager was interested, but much of what we proposed was too novel for him, as his work so far had to do with sustainability. The head of the strategy department, who had initially greenlighted our project, agreed we had delivered on our promise to devise a vocabulary to articulate new problems around digitalization and democracy. Unfortunately, she did not feel it was very relevant to Current’s strategy in the energy transition at that moment. Neither did she warm to the idea of follow-up or implementation plans, as Current’s strategic orientation had changed under the new CEO from long-term vision to short-term project returns. The world of digital technologies is rapidly changing, and Current is now less interested in theoretical vision than in quick, iterative, smaller projects that are regularly evaluated and adapted in order to keep abreast of the fast-moving developments. So, we had come full circle. Although we now had secured a space for slow philosophy and for a critical stance, both were more or less dismissed as incompatible with the demands of innovation practice.

Lessons Learned

The DD case confirmed some of the other lessons we learned at Datashare. Ironically, being in the position of having to find and interest stakeholders for our own (philosophical) product, we could better appreciate why Datashare’s management had been unwilling to completely stake the success of their platform on stakeholder deliberation. Collaborating with stakeholders really takes a lot of time and energy: it takes time to organize meetings and translate between the different stakeholders. One has to be aware of this and be prepared to invest the time. Otherwise the outcomes might not justify the effort.

Another lesson was the tension between the autonomy of the philosopher— in particular, when it comes to her normative agenda—and the ambition to contribute to a collaborative project. In this project, our ambitions and expectations sometimes conflicted with those of our partners. They had particular ideas about how to develop the platform that required us to change our approach. We adapted our plans to be responsive to their needs and to ensure that our eventual output would be useful to them. Moreover, we felt we were both obliged to our partners and dependent on them for getting access to their network. As a result, we had to temper our normative ideas about exploring other approaches to responsible research and innovation (RRI) than participatory approaches.

There is, however, an important difference between the two experiments. At the end of the DD experiment we had something to show for our time and energy, in the form of the diagnostic tool. This was because we managed, and circumstances allowed us, to create a semi-autonomous space for our theoretical research. Instead of performing as mediators for other parties’ views and values, it was clear to all involved that we were working on a product that not all our collaborators would have to agree on, or that they would have to feel represented by. The diagnostic tool was the outcome of our thinking, and we were taking responsibility for it. It was not, nor did it pretend to be, democratically designed by the stakeholders. We were trying to interest other parties in the tool but we were not staking its fate on their support; so, we felt free to use their contributions as we saw fit. As we were aiming for a more general theoretical framework, we were less subject to the frantic pace or the agile approach of a lean start-up. The price we paid was that in the end the Current management deemed the diagnostic tool not directly relevant to their ongoing concerns. On the other hand, the conclusion is not completely bleak. It is exactly because the framework is general in character that it can be transferred to spaces outside Current and is of interest to other stakeholders. Other stakeholders, such as municipalities, NGOs, scientists, and companies have since expressed interest in the framework.8

 
Source
< Prev   CONTENTS   Source   Next >