Added Dusseault

content/interviews/dusseault-interoperability.md

@@ -0,0 +1,262 @@
+---
+narrator: Lisa Dusseault
+subject: Interoperability standards
+facilitator: Nathan Schneider
+date: 2025-10-10
+approved: 2025-10-13
+summary: "Reflections on a career trying to make software systems work together for users, across competing companies and standards bodies."
+location: "Palo Alto, CA USA"
+headshot: "lisa_dusseault.jpg"
+topics: [gender, open source, organizations, software, standards]
+#links:
+#  - text: "LINK 1"
+#    url: "https://..."
+---
+
+*Could tell me how you like to introduce yourself?*
+
+Lisa Dusseault, she/her. I'm the CTO of Data Transfer Initiative these days.
+
+*What is Data Transfer Initiative?*
+
+The Data Transfer Initiative is a nonprofit founded to help facilitate conversations between policymakers and implementers around data portability. We not only want to allow users to move their data off a platform if they want to try another service, but also to improve the ecosystem for competition and for add-on services. Users have more choice, and it's easier to enter. We think a lot of benefit can be had by standardizing and improving trust, letting users have more options about how they use their data online or in personal storage.
+
+*I know you've worked for big tech companies and startups. Why is this organization a nonprofit? How did its design come about to be that way?*
+
+There were three policy folks from Google, Apple, and Meta who decided that the open source project they were all working on to improve data portability among them and with other partners would benefit from a neutral nonprofit sponsor. They wanted policy conversations to be assisted with a neutral third party. They founded the Data Transfer Initiative to be that neutral third party and gave it a lot of independence. They hired Chris Riley as executive director, who is fantastic. He's not easily pressured or swayed. He will formulate a plan and work toward it if he thinks it's a good plan. Chris recruited me.
+
+I'm pretty senior in my career, so I asked and hoped that it would be a partnership between us, which it absolutely has been---a fantastic partnership in the last couple years where I get to shepherd an open source project. But I also work on additional projects when I think a specification would help make things better, or when a library---an open source library---might improve interoperability and access. We've been building systems that aren't run by a large platform or by a small startup who can ill afford to. We're hoping these systems boost interoperability and security.
+
+*Let's go back to your earliest encounter with standards and standardization. How did you first encounter this as a challenge or a need or something worthy of your attention?*
+
+I was right out of university, although I had several work terms under my belt, including several at Microsoft. I joined Microsoft full-time on a team that was working on internet servers, which was interesting to me because I'd already been exposed to the web in university---not everybody had been in 1996. I worked with some of the Microsoft managers who were very forward-thinking about the internet, and being able to talk to them about what the internet could be meant I got to do some cool things as an intern and then as a full-time employee.
+
+I joined a team that was building, among other things, an IRC server, an early directory server, and some early web tools. It was code-named Normandy, this project. I was made a program manager for this team that had seven or eight engineers and was working on five or six small services or servers that Microsoft could run. Then the senior program manager quit the team, so it was just me.
+
+When it came to the IRC server, it didn't meet Microsoft's enterprise requirements around authentication and internationalization. I thought this was an opportunity to talk to people about how the protocol works. I investigated who defines IRC and how it can be changed, and I discovered that it was an IETF RFC.
+
+I got the budget and approval to travel to the IETF and email people around the world, saying, "Hey, IRC is a great protocol, but it doesn't have internationalization and authorization. How about it?"
+
+My reception in standards was crazy. People would recoil physically from a Microsoft person. Yet clearly, I was naive, sincere, energetic---it was hard for people to be put off by me for very long.
+
+I didn't make progress on IRC because doing standards work always requires other people to collaborate. You can't single-handedly push a standard out into the world and make it happen.
+
+*There wasn't a will to solve those problems in the community?*
+
+The founders of IRC wanted it to be anarchic. They were explicit that internationalization was not a feature they wanted because they wanted a channel in Japanese to just be opaque to non-Japanese speakers. That was part of their anarchic, federated vision---anybody can run a server, anybody can do connections between servers, use whatever character set you like, and they also wanted it to be anonymous.
+
+It was a philosophical viewpoint that was very strongly held. Without the founders of IRC supporting the project at all, it didn't go anywhere. But I did meet lots of other interesting people and was exposed to a lot of interesting open source philosophies very early in my career. I also got to meet the other Microsoft people who were working in standards, which was key for then starting to work on WebDAV.
+
+When my team was imploding, I got recruited over to work on a team in the Exchange server that was working on WebDAV, a whole platform for Exchange data to be accessible through an internet standard.
+
+*Before we get into that, I wonder if you could say a bit about the positionality of Microsoft in these processes at that time. You mentioned that people were put off by Microsoft. The company has had an evolving relationship with open source and open standards. Can you say a bit about where it was at that point and any tensions within the company about its relationship to these standards processes?*
+
+I assumed that the negative attitude toward Microsoft was around the things that were in the news. The Federal Trade Commission was investigating Microsoft for predatory pricing because it would give significant discounts to computer companies if all of their computers went out the door with Windows. Once a computer manufacturer was being charged for Windows for one hundred percent of its PCs, why would it then spend extra for any other operating system?
+
+The stance of "embrace, extend, extinguish" was beginning to take hold. The idea that if Microsoft wanted to plow its way into a market, it could do so by embracing open standards. But then, as it was successful, it could use those standards in ways that actually prevented the next entrant. Every large company looks at its market position and makes its strategies similarly. Some are more cutthroat than others in certain kinds of competition.
+
+One of the interesting things with the FTC stuff at Microsoft and with the standards stuff was that it's a bubble. It's drinking the Kool-Aid. Most of the Microsoft people I ever talked to about the FTC could not see that Microsoft could possibly have done anything wrong. It's legal, it's good for customers, it's good for these machine vendors, it's good for us---what's wrong with that?
+
+There's a Mark Twain quote about how a man's opinions are remarkably formed by what is to his benefit. That was absolutely true for the bulk of Microsoft employees. There are very few Machiavellian people that I ever worked with inside Microsoft, but if a Machiavellian purpose was needed to adopt an open standard, sometimes somebody would say, "I think we should adopt this open standard for instant messaging, and an open standard would be great for the world and the internet and users." But you had to justify it to VPs. Because at Microsoft internally, the management had a reputation for being cutthroat, I think people would sometimes pitch their stuff in a Machiavellian way, even if what they really wanted was for the whole internet to interoperate, and they wanted to be part of it.
+
+*Let's turn to the WebDAV process. Talk about what was going on with Exchange and why standards became part of the development of this core piece of the Microsoft Office product offering.* TKTK
+
+I was recruited to the Exchange team internally at Microsoft because it was doing amazing things. The vision, the architectural vision---Alex Hoffman was one of the people holding this vision, Joel Soderberg was another. Several people were on board with this vision of having a standardized access protocol to the massive amounts of data in an enterprise email, calendaring, task, and notes server.
+
+The benefits to this standard interface could be large. One was that third-party clients could interoperate with an Exchange server, which they already could for email, but not at the time for calendaring or for tasks. Another benefit was that enterprise customers could write enterprise tools to interact with the Exchange server and manage the data in it, or add more data in it and get more value out of the platform. Another benefit was that---this is the early days of web UIs---the Exchange team was building a web UI.
+
+The Exchange Web UI could use---it wasn't JavaScript at the time. It was AJAX before AJAX, before all the components of AJAX really existed. It was Microsoft's dynamic web scripting language, whatever it was using at the time, ActiveScript maybe, calling WebDAV interfaces over the internet to fetch data, put it into a web page, get the answers in XML, and interpolate those into the webpage. This is what AJAX became, but it was independently thought of and worked on and formalized within the Exchange team at the time. I could see how powerful that would be.
+
+That vision absolutely attracted me to the Exchange team, and I worked on that there for two years.
+
+*What was the relationship between the development of those internal projects and products and the standards processes?*
+
+Rather than invent a new protocol, which there's always a temptation, one of the wisest things that this team did was say we think this can be part of this emerging web distributed authoring and versioning effort. We already know that making this HTTP-based will make it so much easier to do this web UI stuff. We think that's easy for third-party clients to implement and enterprise access. Making all of that be an HTTP API was already, obviously, a good idea, even back then.
+
+What companies came to do in Web 2.0---using JSON and just defining their own APIs and publishing them and being done with it---that wasn't very common at the time. The idea that you just publish your API and move on quickly had not dominated, so the idea that we should join the standards process that was already working on making the web editable was pretty attractive.
+
+It's really interesting to me that although the working group and the very early energy around WebDAV was around making websites remotely editable, that never really paid off in a big way. All kinds of Web editors continue to use completely different protocols that are not web. They used FTP for fifteen years to edit a website, which is crazy because then you're trying to manage two namespaces.
+
+*I think this is an interesting story because Tim Berners-Lee's original vision for the web was an editable protocol, and the editable side wasn't implemented in the early browsers like Mosaic. Was this tied to that earlier vision?*
+
+Yes, because one of the main pieces you need in order to make the web editable in Tim Berners-Lee's vision was a way of seeing and affecting what's in a collection. You can't edit the resources if you can't find them. Discovering which resources you have in your web server so that you can then send them PUT requests to change their content is a prerequisite. The WebDAV collection model and PROPFIND for getting the metadata, the properties of a resource that aren't visible when you just get it, was the key piece to making the web editable.
+
+But also, once you have a collection and an extensible set of properties, the very earliest proposals for PROPFIND and getting a collection listing were so generic and extensible that it was obvious how you could even use it to get a database table. That was what led these visionaries on the Exchange team to realize---Yaron Goland was another of the Microsofties who saw this vision really early---that WebDAV PROPFIND gave them a standardized basis for a common data access protocol.
+
+*What kinds of things does it end up being used for, if not editing web pages? What kinds of user-facing experiences are made possible by that standard?*
+
+It's turned into a little-known but still widespread document sharing and collaboration basis. There are research organizations around the world and universities that agree to use WebDAV-based shares so that they can each access each other's research datasets, research papers in progress and other materials, presentations, and things that they're working on across these boundaries and with their different tools. File sharing, file sync, network file access, that kind of thing is definitely ongoing.
+
+As I know you know, calendaring---we built calendaring on top of WebDAV. When WebDAV is used to access a calendar, you can do that with multiple different clients against multiple different implementation servers, thanks to CalDAV. I think CardDAV (similar concept but for address books) has some uptake and interoperability as well.
+
+*I use all three of them constantly in my life, mainly because I live on several Nextcloud servers. Can we zero in on the calendaring piece? You mentioned earlier that at this time calendars across different services were not necessarily interoperable. Can you say about the ecosystem as you found it and how standardization started to change it?*
+
+It became forgotten very quickly, but it was obvious at the time that Exchange was not necessarily going to win the personal data enterprise space. Lotus Notes was the market leader. IBM was a very powerful company. Exchange had a lot of problems. At the start of my career inside Microsoft, Exchange wasn't even widely used inside Microsoft for email. There had to be a push inside Microsoft to use Exchange for email, and a lot of people inside Microsoft were very unhappy when they were forced to use Exchange. But it also forced Exchange to develop.
+
+As the second mover in the market, maybe the third or fourth but definitely not the first, it's more likely to be to the second mover's advantage to promote standards. Lotus was not particularly supporting standards. They sent people to the standards meetings, but their contributions did not frequently move things forward.
+
+There was a very complicated protocol being endlessly worked on for calendaring when I showed up at the IETF. I would sit in those rooms meeting after meeting every four months, finding that basically no forward progress had been made because it was a complicated protocol and they were inventing too many things from scratch.
+
+*Was this the iCal process?*
+
+iCal, the iCal proposal, and the iCalendar working group, probably. The IETF had successfully made several interchange formats standards. You could put a calendar item in an email and send it to somebody, and their software could open up the email, open up the attachment, and say, do you want to put this on your calendar? Do you want to accept? That was working very nicely, but the server access requires more of a level of the servers being able to handle an outside data model and just a lot more stuff is involved to standardize an access protocol than an interchange format you can send as an attachment.
+
+That was the level of calendar interoperability at the time. Everybody supported these attachments. Nobody supported a protocol that you could use to use a third-party client.
+
+*How did this process develop, and how did it also relate to the iCal process? Was it an ongoing dialogue, or did they get the job done and then you built another piece of functionality on top of it?*
+
+I was in yet another meeting where barely any progress had been made on iCal, and the sense of the room was exhaustion. People were exhausted---the authors were exhausted, the spectators, the occasional participants were exhausted. I can't remember if it was officially in the notes or loudly in the break or something, but I said we should just explain how to exchange the events over WebDAV and be done with this. Larry Greenfield turned around to me and said, well, why don't you write that up, Lisa? That's almost like being dared.
+
+I didn't want to write it up alone, so I quickly recruited two people who were invaluable coauthors, Bernard Desruisseaux and Cyrus Daboo. Cyrus and I even flew to Montreal to have a meeting with Bernard and work out some of the details. With me from Microsoft and Bernard working on a lesser-known calendaring server and Cyrus working on related projects, we had three implementers, three authors, and it was just a lot easier to make things happen. Not only because we were building on top of a higher level of functionality to begin with by building on both vCard and vEvent and WebDAV and building on top of both of those. It still was a substantial spec, but it made a lot more things inarguable. There's a lot less to argue about, which is one of the big time savings in internet standards.
+
+*Because you were building on primitives that were already established, and so you're able to work with those.*
+
+Primitives that---because we said we have a dependency on WebDAV, the architectural assumptions of WebDAV were not part of the debate. We'd moved those off the debating stage and said, no, those are good.
+
+*Did the design process mainly reside with the three of you, or did it get more complex as it proceeded through the IETF?*
+
+I'm a big believer in editor independence. When I'm a chair or offering notes on something, I believe that a good author, an editor team can hold the overall system in their mind and should be opinionated about what it should be. They shouldn't just take every comment given to them but should say, okay, I see the text you suggested, but I think it'll be better over here and explained in this way.
+
+One of the reasons to prefer that is practical. You can have a meeting with just three people to hash something out, me and Cyrus and Bernard. It's a lot more pleasant to be the author than it is to just be the secretary. People don't agree to do this job unless they have a vision and a goal in mind, and you want to give authors of these complicated specs the tools they need to get them done. I think this was common at the time. Now a lot of authors operate more off of pull requests, and they have to decide whether to accept somebody else's pull request.
+
+There are standards organizations that believe that every meeting about the protocol needs to be done transparently with open participation. In ActivityPub, Evan Prodromou has triage sessions that he announces to the public. But we had the ability to iterate on this, just the three of us, and then bring our work when it was ready for a new chunk to be digested to the working group. Then we'd take people's high-level comments. You also get a whole lot less nits this way. A whole lot less, oh, there's an extra space over here, or you've changed your tense in the middle of this sentence. Those are such an annoyance when you're trying to get the overall structure right.
+
+*As you're proceeding with this, how did the spec development interact with the running code, as they say in the IETF? Were the companies that you were involved in already engaged in implementing these specs, or were they waiting for the specs, or were they indifferent to this process? How did the design interact with adoption?*
+
+By this time, I was working in a nonprofit. I had recently joined the Open Source Application Foundation, working for Mitch Kapor, another amazing organization I've worked for. Mitch was fully supportive, and the goals of OSAF and the tools it was building really supported an interoperable open exchange protocol. We wanted it to work for contacts and notes. The idea was to build a seamless experience for contacts, notes, email. I love this idea---the idea that you don't know when you're starting to work on something what it's going to be.
+
+If you start with a note, you need to put down your thoughts on how you're going to make progress on defining a process that you can then have people to come and do. Wait, first thing I need to do is I need to meet with so-and-so, and then you turn what you just started out as your notes into an event. But your notes could just as easily turn into an email. You need to email that person your thoughts, or turn into a task, or not necessarily a meeting with somebody else but also time on your own calendar---book out time on your own calendar to think about something you want to make progress on.
+
+The idea that all of these personal productivity tools should be blended rather than siloed was the inspirational idea under OSAF. Having interoperable protocols for the pieces in there was also a good part of the vision because collaboration was also part of the vision, because the idea that not only would you have your own notes and tasks, but you'd be able to share your notes and tasks with your team or with somebody you were collaborating with in another organization.
+
+*You said in passing earlier that in a lot of ways, these tools are still pretty siloed from each other. What were the challenges of seeing that vision translate into actual products?*
+
+One thing is it's hard to be excellent at all of those things. I use Gmail, and although I have my complaints about it, it's honestly excellent at several things, including massive scale. But I've never liked Gmail's associated task thing, and it's not even that integrated. You can't turn a task into an event or turn an event into a task or link them together in any way that I've found. It's possible that you can do this, but it was also built as separable features, clearly.
+
+Maybe it's just too hard to be excellent at all of them. I use Bear for notes and tasks, and it's absolutely better than the things that are built into email because email sells first on email for features. You only have so much attention.
+
+*It seems like you were in developing this set of standards articulating not just an attempt to connect things that already existed but actually dreaming up a different way of having workflows and relating to the tools in our lives.*
+
+It wasn't that different from what I'd been doing at Microsoft or from what I wanted to be doing at Microsoft.
+
+*How did that process change when you left Microsoft? You've got a sequence of different jobs here. How does standardizing change when you're not in the behemoth?*
+
+As soon as I left Microsoft, pretty much, people were saying, hey, Lisa, you should chair this working group. Hey, Lisa, you should author this document. The openness to my contributions increased dramatically because people already knew me, and now I was no longer Microsoft.
+
+*They felt like they could trust you.*
+
+Larry Masinter suggested I cochair the WebDAV working group pretty soon after that. I did so gladly. The suggestion to author CalDAV was shortly after I left Microsoft too.
+
+*But doesn't not working for the big company also mean that it's harder to see these things be implemented?*
+
+Many people in open standards are currently very afraid of participation from large company employees, and there is reason to worry about what they'll do. But I think, on balance, on average, there's even more reason to invite them in to open standards because it allows that person to make the standard work for their big company. They have a seat at the table. They have commitment consistency. By having a representative who's an author or a chair or a major contributor, the company has this commitment to the open standard, which then they are pressured to be consistent with.
+
+I think people, when they are worried about something bad, are more afraid of something bad than they are happy about something good coming out of it, if that makes sense. People are risk-averse when it comes to, oh, a big company could do something bad if we don't always keep our guard up and be nasty to them when they come into open standard spaces. It's not like being nasty to big company representatives when they're on a mailing list or in a forum talking about open standards solves anything. It doesn't make them more likely to implement the standard well or be honest about their plans or their license terms. It's just pointless.
+
+*I'm curious if you could reflect on how that standards process has shaped the way you use these technologies today. Do you see them differently than you think other people might who were not part of the processes of working on these standards? Do you notice things that you think maybe most people don't notice because of these experiences?*
+
+Probably, but I'm also very pragmatic. You said you use a bunch of Nextcloud services, which I love. I just do what most people do, and I use Gmail for mail and Apple Photos for photos. It's a very pragmatic, or you could call it lazy, decision. Then I whine about them, and I could see how they could be so much better because of the dreams we had.
+
+*I recall reading in an earlier interview you gave that you took a hiatus from standards, that you had enough and you stepped back. Can you say about that experience?*
+
+There were so many reasons to step back, and I was clearly, in retrospect, somewhat burned out. It helped me to get some distance and develop different skills and then come back. I feel like I have superpowers now from both having experience doing standards committees over the long term and having startup experience shipping software on the daily.
+
+I stepped back because I was trying to make progress on some things that I thought were important to the IETF, and people objected to for reasons that really infuriated me. Sometimes it was opposition to change, sometimes it was the interests of their employer, and these were things that I didn't think should need to be blocked. The idea of having images in standards---does that really hurt some big company? The stop energy was enormous. I watched some people change companies, and somehow their opinions changed without them noticing or at least admitting to noticing that their opinions had changed. They'd have a philosophical position, change companies, and a year later they'd be stating something that was opposite to their philosophical position they'd stated a year ago.
+
+I had young kids. It was getting harder and harder to travel. You can travel with a baby, actually, pretty easily if you're willing to put them in a carrier---babies can be happy in a lot of different places, but a toddler is hard.
+
+I was getting sick of the ten-year time horizon in standards. Everything I worked on, would I have to wait ten or twelve years to show my mom, who's a great supporter of me and my work? See, this is the end result we were working toward.
+
+Chartering a working group---I was an area director, so I was even farther removed from anything practical or immediate. I was recruiting people to come to the IETF, I was helping them charter working groups, I was choosing chairs, I was helping them write a charter so that then the chairs could choose the editors to write the drafts to meet the charter to then be approved by the working group to then be sent to the IETF to then become RFCs, and then implementers really start thinking about them. You can see why this becomes a ten-year time horizon before it ends up in something mass market.
+
+*How does that experience make you reflect on the openness of the IETF? In some respects, it's an incredibly open organization and process, in the sense that discussions are on email lists and there isn't a closed membership logic that some standards bodies have. But at the same time, there are these bureaucracy of its own and the kinds of social norms and so forth that some have found off-putting. How do you end up understanding the idea of openness in that organization?*
+
+First, have you read Kaliya Young's paper on IETF culture? It's very good. It's very hard to be open and be technical and make progress. There's some triangle of---you can't have all three, it sometimes seems.
+
+One of the things that I think saves the IETF in its extreme openness---because I've been a member of CalConnect, I've been a member of Trust over IP, I've been a member of the W3C, I've certainly looked at other standards organizations. Sometimes standards organizations just pop up, like the ones under the umbrella of the Linux Foundation now. ITU, IEEE, none of these is as open to participation as the IETF.
+
+Many of them look at it and say it's impossible, it's impossible to be that open, it's impossible to do that well. Kaliya has dug into the history of how Tim Berners-Lee came to the IETF, saw utter chaos because the IETF was in the middle of a transition, and said, this is crazy, this is impossible to make any progress in this environment, and went off and founded the W3C with a closed membership model so that you can make progress. But then the IETF recovered from its existential overturn and continued to make progress, although slowly.
+
+I think what saves the IETF is, when it works on very technical things, the technical things themselves are somewhat of a barrier to entry. Then there are cultural norms around, did you read the documents before you start commenting on them, which help. We're not just asking for opinion on policy or ideas or vision statements. We're asking for---we're opening up to public opinion on technical specifications. Did you read the forty pages before you comment? That makes open participation a lot more manageable.
+
+I'm part of a process right now in which the IETF is advancing its participation models to have more effective moderation. When the open participation allows harmful participation, there's a lot of concern about silencing when you talk about moderation in these forums. But there's a whole suite of voices, there's a whole population of voices that are silenced because they are turned off so early. They may even be invited, come to an IETF, IETF has outreach, but then they try to participate and they're treated badly, like I was at first, and leave. You never get that voice.
+
+There are---I've talked to many people individually who feel that they'd like to participate in the IETF, but it's just not worth the stress, the emotional stress, the aggravation.
+
+*What kinds of things are you working on to address that issue?*
+
+The instigators of this work were Roman Danyliw, the IETF chair currently, Lars Eggert, a past IETF chair, Elliot Lear, one of the long-standing contributing members of the IETF community. They were the real instigators of some work to revise the IETF's moderation procedures. I got invited, just as I was reentering standards from my hiatus, to chair this working group, which I agreed to do despite it being---a working group on moderation procedures attracts every troll, and every person who's most worried that their interactions might get moderated.
+
+It's hard. They're not bad people, and they're often not wrong. With my co-chair, Jon Peterson, also amazing, we've steered a very careful course of allowing lots of things to be said, even the things that we don't think should be allowed to be said and repeated if we had proper moderation  in place, because we have to allow an unusual amount of free speech and open participation in the very procedures that might shut that down in the future to legitimize them and make sure we get it right.
+
+*It sounds like an immense challenge to adjust that plane while it's flying.*
+
+*After your hiatus, you got back into standards processes. Can you say about what drew you back?*
+
+My last startup was wrapping up after seven years and a pretty good run. Up until that point, that had been the best job I'd ever had, so I enjoyed those seven years, but they were coming to a close, clearly. Chris Riley reached out to me at just the right time with an irresistible offer.
+
+As soon as I looked at how do we make data portability work better, standards was one of my first thoughts, and Chris was like, oh, this person has done startups and standards, has done open source as well as worked at a big company. Chris and I had a lot of the same ideas about what could be done. He did ask me in our early conversations---I hesitate to even call them interviews, they were more proving to each other that we could have a great working relationship---what's the silver bullet for making data portability better? I laughed and said there's no silver bullet. None of this is easy. If it were easy, you could have done it already. Building standards and demand for standards is hard. Doing things securely and openly at the same time is a notably hard trade-off.
+
+*How do you approach this standards work now, maybe differently than you did before? Do you have a different orientation to it after the hiatus?*
+
+When I said I joined Microsoft as a program manager right out of university, that means I was in a non-full-time programming role. From program manager, I became a manager, and then I joined the nonprofit and became a manager. For many years, I wasn't coding enough full-time to become what I considered to be a good enough senior engineer. I hired great senior engineers and trusted them and had them teach me. But sometime in that last startup, in the ten or twelve years hiatus from standards, I became a senior engineer. I could no longer rely on my senior engineers to do better than I could do. I was having to say can we think about this architecture because I don't think it's great, or why did you write the code like that, or that library was not worth integrating? When you're the first engineer in a startup, even if you intend to hire a team, you start writing code. I had written enough code by that time to get Malcolm Gladwell's ten thousand hours of practice. I'd accumulated ten thousand hours of programming, so in this case, that feels about right.
+
+I came back to standards with even more confidence about my technical abilities. I always knew I was capable of understanding, but more confidence in my opinions. It's harder to convince me that an idea that I don't like---something in my now well-trained gut is giving me a little bit---experience really builds pattern recognition, and the pattern recognition I was starting to trust and say, I see what they're saying, but something's niggling, and I have to work with this problem. If I have time, I'll work with the problem to analyze what's making me feel a little bit off about it. That confidence.
+
+But also, some of the amazing people I worked with---my cofounder at that last startup is just a terrific individual. She taught me so much about being a manager, being a leader, listening to people. I've come back simultaneously very confident in my management and leadership skills compared to my hubris, my less-founded confidence of a younger me. But now I also have a confidence in my technical skills, which the younger me didn't have to the same extent. I no longer have imposter syndrome, whether it was imposter syndrome in the beginning.
+
+I remember being very defensive about my technical skills back then. After a year of working together with an IETF colleague, he said, Lisa, let's talk to each other about how we're doing and give each other feedback. I said okay.
+
+One of his bits of feedback was, I feel sometimes you don't know as much about a technical subject as you should because there are things you should know, and yet you're asking questions about it. I said -- have you heard about the Socratic method? His mind was blown.
+
+But I was also defensive about it. From my first year at Microsoft as an intern, can you get things done as an intern by walking into offices and telling people what to do? No. Can you ask questions until you either understand or have convinced them to change their mind? Yes. Nobody expects the twenty-five-year-old who looks twenty to have all the answers, so people have such patience for asking questions. I honed that skill at Microsoft and brought it to the IETF. I will continue asking questions for as long as I can until we get something better than what was making me start to ask questions.
+
+*It's a very powerful skill.*
+
+But I was definitely defensive about it, and I felt I had to do things to prove my technical skill, and now I don't feel like that. I have decided, also, coming back to standards, to prioritize technical contributions because organizational contributions just---I have a limited budget for that. If I use up all my organizational energy, I don't have energy to organize my friends knitting night or my kids' baseball season and schedule. I just turn into a blank face checked-out person halfway through the day because if everything involves organizing, planning, coordinating, asking people, looking at schedules, it's important work and I can do it, but I just run out of capacity for it. I have to maintain those technical, those solo contributions, the things that get you in flow, and combining together, then I can use up both reserves of energy every day and get a lot more done.
+
+*I think it's interesting that you've moved more toward the technical side as your career has progressed. It seems to me it's more common in the industry for people to begin with a high level of technical emphasis, as engineers building with particular new technologies, and then over time they grow into management and they become less in touch with the most current frameworks or whatever people are using right now. Do you feel like you've gone in some ways in an opposite direction from people around you?*
+
+I mentor people pretty regularly, and I'm often asking women who I mentor, do you want to get management tracked? Because if you get management tracked too early, your opportunities cap out. If you stay in the individual contributor, technical contributor for longer, somehow manage to combine that with a management role, then you're planning for five years in the future being a CTO, being the VP of engineering, instead of being the director of the project management team or something like that. Where do you want to end up? As a woman, how do you protect your---how do people see you so that you can get there?
+
+*Can you say about the contributions you're making now and the standards that you've been focusing on?*
+
+Chairing the Moderation Procedures Working Group is one contribution. With Alexey Melnikov and another coauthor, we're proposing an email and personal productivity data archive format. One that, if you export all your personal data from a system, can you synchronize it or some of it to another system? Can you do a backup and restore? Can you move your stuff to another system? This perfectly fits into our Data Transfer Initiative goals. The moderation procedures stuff, I consider almost a personal volunteer contribution, but the PDP archive, the Personal Data and Productivity Archive, is absolutely work.
+
+I've got a proposal to the ActivityPub working group, possibly. The Social Web Community Group is trying to form a Social Web Working Group within the W3C, and I've proposed a mechanism specifically to move your account from one server in the Fediverse to another server in the Fediverse. I think it's pretty solid, and I think that also supports other work in data transfer because it establishes use the access protocol to access the data, so you don't have to write a whole data access protocol, and use OAuth to provide authorization for a third party to access the data. Now the third party can do it to help you moderate your inbox or help you move to a different service or provide additional value adds or just be able to back up and restore your stuff if you need to. Fediverse servers sometimes shut down suddenly.
+
+I've just agreed to chair a new working group as it's getting formed. The IESG just approved the charter, which means it's going for IETF-wide review. I was asked because of my WebDAV background and because this is a protocol that builds on top of WebDAV as well as other file sharing protocols. It's the work of CERN and some other research organizations to be able to securely share private collections of resources across organizational boundaries, where you don't---if you're a CERN researcher and you want to invite somebody from Stanford, you don't have to create an account for them and for every other external contributor and make them remember a login and all of that. Instead, it follows a federated model similar to the Fediverse, where the CERN document server can allow the Stanford documents server to clone the shared collection, and now it's available in theory to whoever the Stanford server wants to share it with. But in practice, these organizations trust each other to honor the access control models of the originator of the collection. I'm going to chair that working group, assuming it gets approved by the wider community.
+
+I think that's the major standards contributions right now. I also show up in things like HTTP API and OAuth to say when I approve of a draft or I think this work should go forward, I think it should be adopted by the working group.
+
+*I have an OAuth coauthor and ActivityPub originator in the oral history project as well, so it's nice to see the interaction.*
+
+*One thing that I saw in an earlier interview you gave was a reflection on the way in which sometimes people become cold and bitter after a long career in standards and this image of the bitter elder saying no to everything and only seeing the problems. I'm curious whether you have any insights about how to avoid that trap and in general any advice for people who are getting into the work of standards building.*
+
+What you're not saying now is that I'm clearly now an elder. I'm fifty-three. I'm sure when I was twenty-six, some of the people I met who were forty seemed old.
+
+What's the live fast and die young ethos? That never made sense to me. Yet, ironically, when I was in my twenties and early thirties, my participation in standards was---I often would grumble to myself, I never want to be old and doing standards. Look at what's going on here. It's so frustrating. I was also bitter and burned out when I went on hiatus, so that absolutely colored that worldview. Obviously, I now don't have as negative an opinion of institutional elders. How convenient. At least when I have a conveniently held position, I'm aware---I try to be aware of a conveniently held position.
+
+One of the things I realized is there's purely selection bias. New people are there to work on new ideas because that's why they're new. It's entangled in why they're new. People who've been around for a while aren't necessarily working on the new ideas just because time passes, but it doesn't mean that they can't. Of course, a person who's worked on one thing for twenty years can pick up a different thing and work on it, which I think is extremely healthy. I think working on the same thing for twenty years is bad for the intellect, if not the soul.
+
+*I wonder if that direction that you've moved from more organizational work to more technical work could insulate you from some of those dynamics you observed.*
+
+I hope so. I also---I'm going to psychoanalyze people a little bit and say that I think---this is one thing that my last cofounder really helped me to see. She's amazing. She helped me to see people's trauma expressed in how they work. Sounds fluffy, but it's actually extremely specific.
+
+I think we all know it by the time we're in our late twenties. We've all seen that friend who got badly hurt in a breakup or something, and they say I'm never going to date X again or make some statement about how they can't handle that risk, they can't take the risk of putting their hopes and love into that kind of situation ever again.
+
+I've also met founders who had a terrible cofounder experience and will say I can never found a company again, it's just terrible, it's a terrible experience, it hurts so much. Or people who take venture capital from the large number of, frankly, toxic investors and say I can never do that again, I've been---it hurt too much.
+
+It would have been easy to look at failures in my own past and say, well, that failed, and if we can't have that, then I can't believe in anything else. But I'm fundamentally a person who loves again, who trusts in another person. I was badly burned by a cofounder in one startup, but I put my trust in the next one.
+
+One of the things that people who have been traumatized in this way try to do is they deal with disappointment by trying to put rules and boundaries and structure or promises around the situation so that it doesn't happen again. You see this when somebody---I got the advice, when you're starting a startup with somebody, you have to get everything in stone with your cofounder because if you don't, then they can hurt you. I look at that and say, you could put everything in stone around your relationship with your cofounder, and they can still hurt you. In the meantime, it's distrustful, it's stop energy. You have to have the right amount of structure and rules and setting in stone with your cofounder, and then take a deep breath and take a leap of faith.
+
+I think the same thing is true with technical projects. I think there are a lot of people who've been burned, and so they want to avoid possibly being---there are lovely people who want to avoid other people being burned. But they're putting too much of the risk management up front too early, even in cases that only rhyme with the time that they got hurt.
+
+I feel like I can see this often very specifically, and it's so nontechnical of me to use words like love and hurt. But I think using those words is necessary to understand how enduring it is and how it can even become part of somebody's personality. When somebody gets pushback for being who they are, sometimes they double down.
+
+*I think that's very wise, and sometimes hurt and love are the best way to understand why one standard was created and adopted and another wasn't. These kinds of dynamics shape our technical world. That is a wonderful way to end, I think.*
+
+On the fuzziest things I've said so far!
+
+*You said a lot of non-fuzzy things, so don't worry.*