DRAFT - Technology in Context Praxis - Thinking
Draft For Feedback
Welcome to the first in a series of posts describing the praxis - the working method - behind Time & Space Studios :) This one's about thinking. The next is about doing.
The five statements below are frames and questions for structuring conversations about technology decisions. What they do, in summary, is shift conversational focus away from any particular type of technology, to focus instead on the people, systems, and political dynamics around the technology. This is where the power lies.
It's our belief that having better conversations about technology will lead to better decision-making about technology. Our approach will be helpful for leaders that believe in collaborative decision-making, and don't need to be sold on why. It will not be productive for command-and-control leadership.
These statements are in no particular order and can be used in whole or in part.
Technology Decisions are Operations Decisions. Think about technology and where it is being used in your organization, or is being proposed for use, in specific. Think about it on the shop floor, so to speak. Avoid speaking about it as an abstract product or technology type. Talk instead about what the tech is doing, or is proposing to do, with proper nouns, in narrow contexts, to people and relationships. By reframing technology decisions as operations decisions, we return to familiar ground that fits into existing organizational design, staffing, and management methods. Create an accessible and repeatable narrative about proposed technological change to bring the wider organization into tech conversations from a place of confidence, using institutional knowledge, norms, and memory. Refuse tech exceptionalism.
Excavating the Past. Revisit the mandate of the organization and its values, all the way back to its beginning. Ask if and how any technology changes to operations do or don't align with them. Understand, in detail, the intentions and rationales behind current technology systems, including their constraints. Celebrate successful technology implementations of days past, and also consider the missteps of past decisions that were made too quickly and without adequate internal collaboration. Excavate the past of potential vendors and suppliers as part of due diligence.
Exposing the Seams. Map the ways that people in your organization are interconnected and how their current relationships would be impacted by new technology implementations. This means mapping physical workplaces, the people within them, and outside of them. This also means exploring digital supply chains. What are you in control of as an organization, in the technological parts of your systems design and operations? Reviewing workflows is one method for doing this. What aren’t you in control of within these systems because a vendor holds the power for how the system functions? Where does internal IT have too much or too little power, given the many broad consequences of how technology is part of service delivery? Where have you given away or delegated important authority internally or externally, in the shape of technical systems, that needs to be reclaimed? What are the current impacts of these dependencies, and if/how will they change with the new technology in question?
Building Operational Scaffolding for Adaptation. Change is the only constant for technology (and the world writ large). What does it look like when technology works exactly as sold – what does that to do organizational design and staffing? What about when it doesn’t work, or if it breaks? Who suffers the consequences, and how are these people connected (or not) to the power to adapt to and address the problem? Technology will always break. Look at the tech life cycle and think about planning from purchase to maintenance to sunset. How can you set your organization up to steward technology well, especially when you don’t own and directly control it?
Prioritizing the Worker Perspective. Maximize the agency that each employee retains over their use of technology in standard operations. How can you bring the expertise of front-line staff into discussions early enough to have them shape technology choices in a range of contexts: buy vs. build decisions, procurement, contract terms, and maintenance plans? How can you use training to inform ongoing maintenance plans for technology, and have that training be the start of a feedback loop for maintenance, contract renewal negotiations, product feature requests, etc.
Gratitude and thanks to Melanie Kapogines, Zaid Khan, Shiva Sankar, and Gabe Sawhney for early feedback.
Should you have any feedback, suggestions, or would like to join a small number of beta readers of the handbook that I'm writing about our working methods, please let me know by sending me an email - hello [at] timeandspacestudios.com :)
This is an unfinished working document. As such, it's too long, repetitive, inconsistent in style, construct, and tone. It's also being offered out of context and without any design support. Such is working in draft :/ Given this state of affairs, the feedback that would be the most helpful and desired is about the content, rather than style or formatting. Or any questions that reading these five statements dredges up for you - would be great to hear them. This means critique/roasting/shredding of what's here - critique is care! I don't take myself too seriously.
In writing this handbook, I’m following guidance from Rob Fitzpatrick's Write Useful Books. If you’re on a writing adventure too, you might want to take a look at his site, and the advice about having beta readers as part of your process, more at: https://www.usefulbooks.com/
Finally, this is all a synthesis of work experience. It's drawn from learnings from practice. It's an effort to share the kinds of thinking that I do and the kinds of questions that I ask myself and others when working on technology projects of many kinds, from new system deployments to advocacy to policy. In that work, I have learned from hundreds of people directly, and hundreds more indirectly. In addition, there are articles, books, and posts that I read and re-read. I will eventually construct a little reference library and bibliography for those curious and interested :)