What is an NDA and why do some projects need it?

[Valentine Vierne] An NDA is a non-disclosure agreement which you might have to sign informing you that you are on a restricted project with restricted information that you can not share with people that are not on this restricted list. It's a bit like an insider list but for a project and it's needed because sometimes projects have external dependencies which are still being negotiated and until the negotiation is closed we have to remain as quiet as possible about the potential outcome of the negotiation so as not to endanger it. It's usually linked to legal, antitrust, privacy or commercial matters, such as exclusive partnerships, acquisitions etc. that enforce participants to not disclose information about what is happening.

How do you know that you will be working on a project with an NDA?

[VV] You might be contacted by someone who wants to talk with you about a project they can't tell you much about, so they tell you that you will have to sign a NDA, and once this is done the person will be able to tell you more. Sometimes it's just roughly a small, very cryptic discussion that goes like "you know, we wanted to do something that would look like something that you could do but I can't say more". And then again, at some point you are made aware that you have been asked to sign an NDA and, when you have done so, the world opens up to you. And sometimes you just get to know that there is a project with an NDA and the question is, would you like to participate in it?

How does an NDA project affect a project manager's daily work?

[VV] The first thing is that you need to factor additional time to open a document to check if the person you want to talk to is on the list, if yes, that's perfect and you can talk openly and if not, you need to think twice. Do you really need to talk to this person? Could someone who is on the list step in? Should you place the person under the NDA? If you can't place the person under the NDA, you start having a conversation with a lot of uncertainty, imagination and creativity. The second aspect is that you have to be very creative in the way you communicate. You have to take on more points of view because the core team is usually smaller due to the fact that not everyone can be placed under the NDA, so you need to get your information from the limited number of people involved. You also need to make sure that all your documents have restricted access and are flagged with information about the existence of the NDA. And you need to repeat the message about not sharing information all the time. Also, all of your meetings are in private mode. It's actually additional administrative work and frustration because part of my job is to ensure everyone is on the same page and I can't do this to 100% under the NDA but at least, most projects under NDAs are challenging so there is something exciting to compensate for the additional burden.

How does an NDA project affect a Principal Engineer's daily work?

[Pete Barron] Typically as a Principal Engineer on a Digital Experience project what you're looking to do primarily is to find a solution that works for all the teams that are involved. This normally means that you are having conversations with the teams about what is the best solution and how to tackle particular requirements, what are the tradeoffs that we are looking to address. Normally, in projects you are default to transparency and you use the Technical Design Document (TDD) to align the teams on the approach to take. When a project is under NDA you don't have that luxury to talk to all the engineers, which means that the time to get to a solution can take a lot longer. Things slow down.

What are the techniques to facilitate progression in an NDA project?

[VV] It is frustrating for the stakeholders, they would like to help as much as they can. Some will be on the list because they are decision makers, some will not and you need to explain the situation from the start. Most of them are very helpful. You need to be either very vague when you talk or, on the contrary, very precise as if you were just solving a small piece of the puzzle and you don't say what the whole puzzle looks like. Some stakeholders don't even want to know more because a project under NDA sounds complicated and they are happy with the bare minimum.

[PB] There are 3 approaches, one is to get the people that are core to the project on the list, usually those are the ones where the risk is highest, still the solution slows down and the other aspect is that the solution may not be correct because you don't necessarily have the input to validate your assertions. Another approach is to go through the available documentation about the systems to build up an understanding of what the solution may be. In a regular project you don't have to do that as much because you can delegate those pieces of work to different teams and have it reflected in the TDD. In a regular project you are more the editor of the document rather than the author of the document. Finally, you can ask people without revealing the context behind the project: "what if we were to do this… how would you do it?" to try to understand how teams would implement particular features if they were to arrive at the doorstep, in other words, you extract the information from teams without revealing what the project is about or breaking the NDA and that's opportunistic at best. The challenge that you have is that most people live the OFMs and default to transparency and we haven't necessarily built an organization to understand that sometimes we can't talk about some things yet. Some people understand it, some don't. Some will simply ask, "oh, so this is an NDA project?" and then you can answer," yes, I can't tell much about it but could you tell me how this would work". Some teams will be wanting to ask more questions, such as "what is this NDA project and why can't you tell me more?" because in a way, the NDA conflicts with the organization's OFM principle. Fortunately, I haven't come across any adverse reactions and most people are fairly understanding. It's a nuance in our organization.

Is there a maximum for how long the NDA can last?

[VV] I've been in 2 projects under NDA so far we lifted the NDA in solution design. The first project was under a NDA which was lifted when there was a joint communication to the outside world. Sometimes it's a company decision at the high level, sometimes it's the legal team. It depends on the reason for the NDA. But, typically, at the end of the solution design you need to know from all the teams how long they will need to implement the solution. You need to plan for your execution and block resources or pause other projects and run this one if it's urgent. Especially for engineering teams, you want to discuss every single path which will be implemented, check the feasibility, we might not be aware of all the consequences of the designed solution. The people who will do the work need to know the details.

[PB] When you're at the point when you have to validate the solution design, and need to find how much it will cost to build, the project needs to be made visible to teams so that they understand how to bring it into execution, so at that stage the NDA is typically lifted. It's a balancing trick most of the time. You need the information to be able to progress and information can be incomplete, therefore there is risk and the whole project management aspect of how you deal with risks starts because if there is high risk, you want to do something about it and that again, comes down to the solution design and who needs to be involved to mitigate the risk.

What could potentially happen if the NDA is broken?

[VV] If the NDA is between Zalando and a Partner it would mean we lose the trust of our partners. That would be serious reputational damage. Partners can insist on an NDA because they don't want their competition to know that they are working with you, the breach could impact business decisions. If it's leaked inside Zalando, some people will feel uncertain and ask questions around how the project will impact them and their projects. With operational plans and roadmaps in place, how to make sense of this new thing coming in that we didn't know about? That is an unexpected/unplanned situation which could cause confusion.

Any tips for someone managing an NDA project for the 1st time?

[PB] Working in NDA projects is a burden but a necessary part of doing business and you work around it. Simple things, like ensuring your calendar is not visible, restricting access to documents, or that you don't inadvertently say something you shouldn't have said. From an engineering perspective being on a project that may cover multiple teams is a challenge that you have to figure out. But I don't see NDAs going away anytime soon so it's important to know how to balance the nuances of the default to transparency OFM and the business side. Talking to people who have done an NDA project before is definitely helpful.