You're debating database design choices with non-technical team members. How do you find common ground?

When talking with my team, I compare database with familiar things. I show the DB table with rows and columns. They can see that the data just like tables in Excel file where they often use. Visualization is important because it help them see exactly what they are talking about. They will trust and absorb easily what we say afterward. Then I can explain how a poorly DB design can lead to errors or inefficiencies. Show them how a good design makes tasks easier. Personally, in the long run, I think those people still need to have basic technology knowledge, because they are working with the dev team, so it will be better if they understand it. This is similar to the fact that the dev team needs to have a deep understanding of the business.

I've found that breaking down technical jargon into everyday language helps non-technical team members grasp the fundamentals. For instance, instead of saying "normalize the database," I explain it as "organizing the data to avoid duplicates and make updates easier."

When communicating concepts like Star Schema or Snowflake I use the example of shopping at your store of choice and what happens when scanning the item all the way you view your order the next day. How is the data ingested (OLTP) and what happens to the data after it is sent off to the data warehouse. Breaking down the flow of data into a relatable experience is key. I also try to explain how the data is related from one table to the other just like door keys, where certain keys match certain locks. Data in disparate tables can relate if the right key is present and matches the “lock” or as we know the same key in another table. We speak of relational database concepts without providing clarity to others as to what we are relating.

Start with a technology they are most likely familiar with like excel to explain how data is stored and extend with relationships in the data like how student mark results are related to a trainer although the details of both are not stored in the same table. If they are part of the design for the application it could help explain normalisation and take them step by step through the process. Indexing can be explained by liking it to a table of contents of a book whereas the indexing on relationships (Foreign keys) can be touched upon just to make them aware of additional indexes that are not the primary key.

Try to explain the impact in long-term, evaluate pros and cons of each choice for team-mate. When all have the same view, we can go to the most suitable solution.

Highlighting the real-world consequences of design choices can be very effective. For example, I once explained how a poorly designed database could lead to slow loading times and user frustration, directly impacting customer satisfaction.

In a recent project, we started by listing all the desired features and then worked together to prioritize them based on business impact. This ensured that the most critical needs were met first and everyone felt their input was valued.

Using diagrams and flowcharts to represent the database structure helped the team visualize how data flows and is organized. In one meeting, a simple ER diagram made it clear how different data points were related, facilitating better discussions.

Comparing database tables to filing cabinets, where each drawer (table) holds related files (records), has been particularly effective. This metaphor helps non-technical team members understand the concept of data organization and retrieval

Providing concrete examples from previous projects or well-known companies can illustrate the benefits of good database design. For instance, I shared how Amazon's efficient database structure supports their vast inventory and fast search capabilities.

Building trust and fostering a collaborative environment are key. Regularly seeking feedback, being transparent about the design process, and holding brief educational sessions can empower non-technical team members, ensuring their concerns are addressed and their ideas are included.

En cierta ocasión había hecho un buen trabajo para que los usuarios pudieran consultar con facilidad el contenido de un lago de datos, y me disponía a mandar un mail a todo el mundo para darlo a conocer. Como la comunicación entre gente de negocio y gente técnica es complicada, intenté explicarlo de la manera más simple posible. Además, pedí supervisión a mis compañeros, por si hubiera algún punto que no se entendiera bien. La repercusión del mail fue nula. Nadie se puso en contacto conmigo interesándose por el tema. Un compañero de negocio pasó junto a mi puesto y se sorprendió de lo que tenía en pantalla, y me dijo "justo eso es lo que necesitamos". El nuevo mail escrito junto con este compañero obtuvo el resultado deseado.