MLOps Zoomcamp: Free MLOps course. Register here!

DataTalks.Club

Home Articles Slack Events Podcast Books

Effective Communication with Business for Data Professionals

Season 3, episode 4 of the DataTalks.Club podcast with Lior Barak

Links:

Hummus places in Berlin:

Did you like this episode? Check other episodes of the podcast, and register for new events.

Transcript

Alexey: This week we will talk about the disconnection between data folks and the management, and how to bridge the gap between the two. We have a special guest today — Lior. Lior has experience of over 12 years in building data teams, leveraging data for growth. He learned a lot from that, he experienced a lot of pains and he even has written a book about this. He also hosts a podcast — “What the Data?!” and — full disclosure — I was a guest on this podcast once, so go and check it out. Welcome to our event! (1:31)

Lior: I am so happy to be here. Actually one of my happiest moments is when I am talking to data scientists and data engineers. We can do so many cool things together. I am happy to be here! (2:15)

Lior’s background

Alexey: Welcome. Before we go into our main topic of communicating with business, let’s talk a bit about your background. With 12 years of experience you probably saw a lot of things. Can you tell us a bit about your career journey so far? (2:30)

Lior: I am a dinosaur as we call it. I started my data career even before there was any Google analytics on board. We used analytics tools that were installed locally by us. In the last couple of years, I was working for Zalando. There basically I did the entire transformation of the data for the marketing department. I was working for Lovoo, a dating app. To the ones who do not know it, it’s a quite cool company. There I was a project manager / product manager to help constructing data. (2:49)

Lior: Now lately I am running the podcast “WHAT the Data?!” where I am interviewing data and business people. I’m trying to bridge the communication between these two functions to leverage the data for growth. Then also I am managing director of “Tale about Data”, which is a company that we started as an agency. Now we are moving more towards a product approach. We help companies to set up their data infrastructure in a quick way, so they can focus on hiring good data engineers and not being under pressure to run around.

Who is a data strategist?

Alexey: I checked your LinkedIn profile and it says that your title now is a “data strategist”. This makes me wonder what does a data strategist do? (4:08)

Lior: A data strategist is the person who sits between the data engineering, the data science and the business, trying to find the right approach to use the data. One of the biggest pains that I suffered as a product manager for data for a very long time was that I need a dashboard. I need it now. I need it tomorrow, the calculation is wrong, I do not trust it. It is supposed to be eight, why is it four? What a data strategist needs to do? It needs to balance between the two functions of the tech and the business, ensure that both of them are speaking the right language. (4:21)

Lior: The second part: they also have the right strategy. They are actually understanding when we are talking about installs — what do we mean when we are saying “install”? What do we mean when we are talking about sessions. When we are running a model for forecasting the revenue, how is it being calculated?

Lior: The business is not going to go into the details of “is it a random forest or a linear regression”? They will ask, but they are not really understanding what is behind it. What they care about is how accurate it is. This is where you need to come in and actually make sure that the understanding level is correct between everybody.

Lior: There is also a trust to the data. A lot of business people do not trust the data. This is something I always suffered from. I know it cannot be the data is correct, check it again, I am missing something here. This is where that strategist should come in and support the organization in understanding better how to use it.

Alexey: As understood, you do two things. One: you are the bridge between the technical people and the business people. You help communicate, you translate the requirements maybe and develop trust for business. Business people do not trust the data. You help them to have this trust. You help them understand what is going on behind the hood. Then, at the same time, you also probably do that the other way around? You help the technical people to understand what business wants from them, right? (5:55)

Lior: Yeah. I like to say that I am the idiot in the room that asks all the idiotic questions that everybody else is afraid to ask. That is how I see it myself — if I need to sum it up. (6:36)

Alexey: As I understood, you are coming from the product management background. So you are more from the business side coming into tech rather than from tech to the business side? (6:48)

Lior: Actually I started my way in the tech. I was in the path of being a developer. Then I decided that life is too short for me to sit down and debug code. This was always one of my biggest frustrations. Then I moved more towards product, but I am still coding. I am still writing Python. I know SQL is not a code, but I am still writing SQL queries. I am still running R-queries, sometimes using R for different parts. So, I am still connected to the code. But I am trying not to develop because I know I am bad at it. But I understand enough code to be able to translate it into something that people can understand. Or I can at least look at it and see what is going on in there. (6:59)

Improving communication between business and tech

Alexey: So, you have the background of a technical person, you also have a background of a product manager which puts you in this unique position of being able to understand both — be able to translate from one world to another, from one function to another. From your point of view, how can we improve communication between the technical side and the business side? What are the things we can do to make it better, smoother? (7:46)

Lior: One of the most idiotic things that I noticed when improving communication. When something goes wrong with the data or with the formula, send a small email and say “Guys do not use it. We are checking what went wrong”. Even if it was triggered automatically. Try to trigger it automatically before people even start using the data. In today's world, we are trying to finish processes before people arrive to the office. We do not have any office anymore, we are all sitting at home, but we are trying to make it available for people from around 8:00 a.m., 9:00 a.m., 10:00 a.m. — whatever. You are setting it up, people are expecting to have the data at this point. One of the key components here — especially when we are talking about creating trust — is to trigger this small email saying “Everything was working fine. You can use the data” or “There was an issue. Do not use the data. It may cause you to make the wrong decisions”. Once somebody starts to suspect your data, you lost this trust. To buy it again, it will take you a long time. Longer than what you even expect. It is just creating more frustration, it is just causing more backlogs on you as a developer. (8:22)

Lior: In the long run you are going to find yourself running into an issue of “They do not trust me”. I do my job. I am frustrated with my job. The data scientist and all the data engineers become very frustrated. This is something I noticed and I was not aware of it. Because for me, at the beginning when I started, I was like “Okay, there is a request. You need to make it happen. I do not care how it happens. It needs to happen”. But very quickly I realized that a lot of these requests are coming from frustration — from the business person who is transferring it now to the technical guy, who could have solved it just by sending an email saying “Listen, dude. I checked the data, everything is looking good. If you have complaints we can check it, but there is no reason for you, because I did the QA for you. I checked that the data is correct. Is to the best of my knowledge. If you spotted something, I would be more than happy to have a conversation about it”. It is going to reduce 60 percent of the wasting of the time back and forth between the tech and the business in many cases.

Building trust

Alexey: So the main thing here is building trust. Business people need to have trust in the work of data engineers, data analysts, and data scientists. One of the ways of doing this is to be upfront, be transparent. If something happens, inform immediately. “Hey our job failed, so today expect some inconsistency in the data, we are working on fixing this. Sorry about that.” (10:48)

Lior: Think about something else. You have a forecast model. You are running it on a database that is supposed to forecast revenues. You need to forecast 30 days ahead or even 360 days ahead. If you are showing a certain number there, people do not trust the number you give them. How can you make them trust? Either you are creating some graph that is showing them what your confidence level in the information is. Either you telling them “This is based on the most accurate data I have right now. This is what I am predicting”. In many cases, when I worked on forecasting models, suddenly a model was crashing. It used to be very stable on a certain level. And then one day it crashed. Sometimes marketing changed their campaigns or stopped them. And the entire model went to the garbage — because it was counting on a certain traffic that is going to happen. (11:18)

Lior: In some other cases, the model is not relevant anymore. Because somehow the users that arrive completely changed the picture of how it is observing the operation. Or some features were changing. They are not relevant anymore, they are not available anymore. This is the way for the data scientist to create a small dashboard and put it somewhere. Whenever people are suspecting that the number is wrong, they can go there. They can QA it quickly and see immediately if there is a problem or not. This is really small stuff that will take us half an hour, one hour, and two hours to do. And it can increase the trust of people — just because they have access to the data now, to the back end. They know how the calculation is going. They will be able to already see if something went wrong or not. Your job is to build a model but also to create in a certain way.

Alexey: You mentioned that to build good communication, we need to build trust. Building trust is informing and being transparent. The second thing is showing small things like confidence intervals. Being upfront that our model might be wrong and these are potential boundaries and all that. Is there something else that we should do? I think for good communication there should be somebody who can speak the language. In addition to tools, in addition to all this alerting, we need to have somebody who can do this — you can call it “the data strategist or” I think. Usually it can be a product manager who was previously technical. Or maybe a data scientist who is doing more the product way. But somebody needs to be this translator. (13:15)

Putting data and business people together

Lior: Not necessarily. You can have this translator in the middle. But you, as somebody who is touching the data — and basically most of us — most of the data engineers, data scientists are looking at themselves as an enabler's functions. I am enabling somebody to do his job, so he can do something better. The reality is that without you understanding what the product manager, or the marketing, or the finance team, or any other team out there wants to achieve, you would not be able to do your job as good as you want. That’s one of the things that I noticed many times — the communication is always going either above somebody's head or is going around it. And we are trying to avoid it because I am talking tech and I will explain the tech side, and he is talking business, he is going to explain the business side. But this is not true. (14:20)

Lior: When I was working with data people, I put the data people — the data engineers, the analysts or even the data scientists — to sit with the business for a day or two. So they can see what they are doing. If you are looking for transparency in how you are writing the code, and how you are creating it, notifying people, it is a great thing that saves a lot of time for everybody and increases the trust. QAing the data is a great thing that is also creating an advantage. But sitting with the people that are going to use your data at the end, understand their problems and what they do — it’s going to help you to communicate with them better. You can tell them “Listen, I was sitting with you, I saw that you are doing X, Y and Z. This is why I change my process to adapt it better to what you do”. Or maybe something is wrong. Let’s try a different approach. It doesn’t always go through a third party.

Lior: There is one function as I see it — that is the grow function. It’s built with the tech side and the business side. Both of them should enrich each other and give the ability to grow and learn new stuff. The business can come with new ideas of automation or how to improve the models. The data side should come to the business and tell them “Listen, I see that you are doing this in these operations usually. Why don’t we change it? Why don’t we do it better?” For example, the most stupid thing that I saw was — somebody was having five to six clicks to change his bidding on a certain platform. The data engineer who was sitting with them was like “Hold on, but why do you do this? There is an API. I can write it for you. I can throw you a front end, it is going to take me a week to build an MVP for you. You don’t need to do all of these clicks around. You just can optimize it from one place.” It came only from the fact that they were sitting one next to each other and communicated on a level “I showed you what I am doing and I will show you what I can do for you afterwards.”

Alexey: I can totally relate to this as a data scientist. I remember that once I worked in a team that was creating tools for moderators. Moderators are people who look at… In my case, I work at OLX. This is a company where you can sell things. There are people who actually look at the content that users produce — at the listings that people produce. They see “Okay, this is something that should not go live on the platform”. They reject it, they remove it from the platform. We were building things for these moderators. I remember for me the most enlightening experience was actually talking to the moderators, watching them how they work, working with them together and using the system together with them to moderate content. So, just sitting with the users, with those people who are going to consume the data products, consume the machine learning services. I can totally agree that it brings understanding on the next level. And this experience that you see, what kind of problems they have, it gives you a different perspective. (17:33)

Lior: And to remember that data is not an enabling function, it’s a leading function. Without having the right data, having the right outcome of the data, nobody will be able to do anything. It is not only enabling, it is also growing. It’s part of the growth of the organization. I was working as a freelancer for a while for cisco in the recruitment team. one of the most important parts for the recruitment team was the recruitment process. To analyze it and to understand which positions were issues or not, or which positions can be improved with the candidate. Maybe we are missing something that we do not see today? (18:50)

Lior: You can only drive this stuff when you are sitting with the recruiter together, you are understanding how he is working. The same thing goes to marketing and the same thing goes to every place. A lot of these recruiters are also frustrated many times with their job — there is a hiring manager that is stuck in the process. Maybe you can create some panel of some dashboard for them that they can go and say “Okay, you are stuck in my process. Let’s see how we can move faster, how we can improve the process and bring better candidates”. Or if candidates feel that they are suffering, how can you actually improve it? I think that this is one of the points that only by sitting together and combining forces, you can try this growth.

Dealing with pushbacks

Alexey: I was thinking about the example you gave — when somebody was taking six clicks, the data engineer approached and said “Hey, we can make it easier for you”. But I imagine that there are some cases when the data engineer would have a pushback. Maybe in cases when there is not enough trust between the technical part and the business part. Then they think “This is somebody coming from outside who is telling us how to do things. No. We will keep doing things the old way” How to deal with these pushbacks? When you say “I want to help you do your job better” but not everyone gets immediately excited about this idea. (20:25)

Lior: Do it on hackathons, and use a hackathon as an opportunity to present it to a larger crowd. Or if you think that this is something that really is not going to take you that long, work on it as a side hustle, when you have some free time. And then present it and tell him “You can keep doing your own stuff, but let’s give this one a try for a week or week and half and see what happens”. If you trust enough that what you constructed and what you created is actually something that is going to serve them to the better. (21:20)

Lior: You are going to give it to them, then I am like “Let’s try for a week. What can go wrong?” Nothing can go wrong if you are going to try it for a week. There is no chance that they are going to push it back. I think yes, there are a lot of pushbacks for tech people. “No, don’t do that. I have a bigger strategy that I need you to work on.” But right now I see that there is a problem that I can solve quite quickly, so why don’t you let me work on it for a week? We are going to have a setback of a week. A lot of companies are working with OKRs and stuff like this. Okay, so you are going to reach 0.5 instead of 0.7 because you had an extra week working on something else. But it saved you the amount of time that you saved. This is what actually counts.

Lior: If you are thinking about an organization that has 14 people, and all their job is just to download reports from different platforms. They do copy-paste of them into excel sheet. This does not make any sense. It’s a waste of time. It’s 14 employees that work an entire month or half of the month just on downloading data. No organization is going to come and tell you “What? No, that is a stupid idea to automate it. Why would we do it?” On the contrary, the organization wants to automate this process. Then these employees can do their actual job which is not sitting there and downloading reports, but going over the data, make the right decision, change the biddings, change the right approach for growth. Their job is not to download the data and just copy paste it into excel. This is where we are coming into the picture. We should push quite hard and find our right way to present stuff.

Building things in the lean way (and growing tomatoes)

Lior: But we also need to always think, in an MVP way. This is another point that I will add here: don’t get complicated with stuff. Don’t go into development for three months or six months for a product. In the industry that we are working in, sometimes three or six months means the end cycle of a feature of a product. By the time you finish, it is not going to be relevant. You need to think about what can I achieve in a week, a week and a half or maximum two weeks. I can release it outside and showcase what it is used to. Then on top of it, start building it. Start with a lean approach, then move into an agile approach. This is what I always — using these OKRs or lean or agile… Because there is no one system that fits everybody. But we need to think about it as a cycle. You are starting with lean, you are moving to an agile. After you have agile for a while, you can move into OKRs, because it is already more stable. (23:54)

Lior: I look at it like a plant. I am starting seeding my tomatoes to put in the garden. I am starting it from the seed. It is slowly growing and I need to move it into a new pot. When it is in this pot, I need to let it grow there and I need to move it to another pot. I am starting in February and only in May or June, I am going to put it into the ground. It is going to catch with the roots into the soil itself. But until I am arriving at this point, I need to have different approaches to the plant. When I am seeding it, I need to make sure it is dark and moist for it. When it is opening up and the leaves are coming out, I already need to change my approach and start growing it in a different way.

Lior: This is also when I am talking about hummus in my book. I am talking exactly about that hummus is so simple. It’s just chickpeas, tahina, lemon, a little bit of salt and garlic. And that is it. There is no magic behind. It’s so simple and so fast. This is how data should be. This is how people should actually think about their approach to that. It should be simple but it is filling you up so much that you do not want to eat anything else afterwards. It is that simple.

Alexey: I am not sure if it makes sense for me to ask what your favorite food is. I think it's clear. (26:06)

Lior: I will go with hummus most likely. (26:14)

Starting with ugly code

Alexey: I thought so. We will talk a bit about hummus and your book later. But I like the metaphor about the plant. I am wondering how can we find the right balance between complexity and simplicity? I understand that this development MVP. Have this hackathon, create something quick and dirty — just to prove value. But then at some point it becomes a project that needs to be maintained. If I, as a data scientist, hack something together, then any sane engineer would look at this and say, “I don’t want to to touch this code”. On the other hand, this is something that I hacked in a week, but that works. It’s far from ideal but it does not fail all the time. So, how do we find the balance between moving fast and doing things simple versus something more complex. How do we make sure that we are not doing too much but doing just enough. (26:17)

Lior: It should be very simple at the beginning. Yes, it’s going to be bad. It’s not going to be beautiful. Code will never be beautiful. This is why I stopped coding as well — at some point I realized that my code is horrible. People did not want to deal with it. I did not want to have this feeling of “Oh shit! I did a really bad job”. (27:33)

Lior: You start with something ugly. You see that it works. If it works, then you are creating this approach of somebody taking over fixing the code, building it up, creating the system of how we are going to grow it, what is the end goal of it, and how it is going to become a better process for us in the future. I think that these are the points that are most relevant for us. Take it, the ugly as much as it is, check that it is actually working. I know that a lot of people say “Yeah, you are talking about tech. It needs work”. It’s going to be the same thing for the business. If business wants to have a dashboard or they want to have some calculation being done, they need to do it on an excel sheet and run with it several times. My philosophy is kill excel. There is no use of excel. But there are certain cases when you want to start something. Even if the tech do not trust it, you need to start it on an excel sheet, show that it is actually working, you are actually using it. And only then send it up for development. It goes both sides: on the code… You have disgusting code at the beginning, you are making better later. Or you are starting with an excel sheet. Horrible! I will kill somebody if I am going to see him using excel. But I have to accept it. And then it is going to move into automation. We need to convince each other and show that actually there is a purpose and there is use for what we do. And this is the only approach for us.

Convincing others to take our code

Alexey: As I understood, having ugly code is fine. We know that it’s going to be rewritten. Then, even before having any code, try simpler things. Try excel. Try to solve the problem without any code at all at first and see if it is valuable, if it is valid. I heard this expression, “Do things that do not scale first, and then try to automate them”. The other thing I am also wondering... It’s something I experienced in the past. You said: okay, there is some ugly code. Somebody will take this over and make it better. But how do we convince somebody to take this over? I usually have problems with that. This is my code. I know it is ugly. I know it is bad. But it also solves the problem. How do we convince people to take this over and make it better? (29:19)

Lior: Look at it as an Excel sheet. At the end of the day, it will go to the garbage, because we are going to automate it. You wrote the code just to prove a point. The point was proven. There is now a use case for it. There is a business that is standing behind it that can actually push for it. Then start rebuilding it from scratch. Or take the old code and try to improve it. But do not get insulted if somebody tells you “Listen. I don’t like your code. I want to rebuild it”. It’s completely fine. He’s taking ownership and when he owns it, it’s his responsibility to make sure that the code is looking better. It's his responsibility to understand and be able to explain to others what it’s doing. (30:30)

Lior: This is something that I learned quite heavily when I am running my company. We are using a lot of external resources for different parts of our code. We cannot always run all over it and ensure that we can cover everything. Sometimes this code is not the best but at least it’s doing the function. It’s creating the idea, it is creating the concept and the demand. Then, from there, we are going to take it and we are going to streamline it. We are going to fix it. We are going to create something that can be used in the future. But we need to start somewhere. From the moment that there is enough clear use case and ownership, everything can run smoothly. Nobody is going to come and tell you “Nah, I don’t think I want to use this tool”. If there is a used case, this is the reason why you are developing code. You are not developing code just to say “I am sitting here and I am writing Python”. No, you are sitting here because you want to solve a problem that is going to help your company to grow. This is exactly the reason why you are there in this, exactly the reason why you should take this now and start working on it and fix it.

Alexey: Basically do not get attached to the code. If somebody wants to rewrite and it is a reasonable time frame… It’s not going to take six months then it is fine, right? (32:20)

Lior: You know how many times people were telling me that something I was doing looked disgusting. Many times I used to be the first one to build dashboards. My color picking is horrible. When I was 18 years old, I was requested to do a presentation for somebody. The only reaction that I received was “The colors you picked were the most horrible colors I ever seen in my life. I do not know how somebody can survive with such a color pallet”. I did not care. I told him “it doesn’t matter. Did you understand the message I tried to transfer to you through the presentation?” He was like “Yes”. And I was like “Great!” (32:42)

Lior: Now you can take it, you can create the right color schema for that, you can add whatever images you want and cut them whatever way you want. The most important part is that the message and the use case here are transferred. Since then, every time I am building a dashboard, I know already it is not going to be beautiful. Somebody is going to come and make it much more beautiful than what I do. And I accept it. I do not fight against it.

MVP vs development and Hummus

Alexey: Going back to this ugly code. When we move fast, it creates this reaction from engineers “This is a bad code. We want to rewrite.” But the other thing — it might cause business to think that this speed is the usual speed. This is the speed you can expect things to happen in the future. So next time the new thing, the new feature added to this raw prototype, it will also be added in a week, after a couple of days. I think it creates this false sense of moving very fast. Do you have some tips how to handle expectations from business when it comes to MVP versus development. (35:54)

Lior: One of the things that I am talking about a lot is hummus. You can do it in the quick way or you can do it in the slow way. The quick way: you are just going to go and buy chickpeas in a can. You are going to wash them a little bit, ground them in some tahina. And here you go, you have hummus. And it is hummus. I am not going to fight with you. It’s hummus: you have chickpeas, you have the tahina. You have the basic ingredients. And it is great. (34:52)

Lior: But is it the taste you were after? No. If you really want to get this taste, you will need to soak the chickpeas for 24 hours. You will need to cook them for two to three hours until they are getting soft. You need to grind them. You need to cool them down. You need to mix them with tahini. There is a large process. And what I am always explaining is that — yes this one is my hummus from a can. This is just to give you a taste of what hummus can be. Now let’s move and work on the hummus itself.

Lior: If I am going outside of this metaphor of hummus, the reality is that yes, the beginning is always fast. You are doing the minimal things that you need to do. But now every feature that you need to develop on top of it, going to take time. It’s going to take much more thinking, because now we made sure that it’s relevant and it’s needed and required. Now let’s figure out how we are making it — not only needed and required but also used and loved. And this is two different stories. It’s a chickpeas from a can, a chickpeas you cook yourself — they will have two different tastes. This is completely different. And this is exactly how I am looking at development of code.

Talking to people who can’t code

Alexey: I know what I will use next time when I explain why it takes so long. Great! I really loved the metaphor, I even forgot what I wanted to talk about. I think I wanted to also cover talking to people who don’t know how to code. Let’s say, we are talking to business but they don’t always understand the effort you put. Maybe they don’t care about the difference — between this fast hummus and proper hummus. Because they don’t see all these intricacies. They are not into hummus. They are not into coding. How do you talk to people who do not understand all these complexities about coding? How to structure the conversation with them? (36:33)

Lior: If they don’t understand coding — and a lot of people don’t understand coding. I think I am very lucky that I had a chance to understand how to write code and how to work with it. But, if we are looking at how we are creating a process that is meaningful. It’s to go and sit down with the people who don’t understand code, explain to them why you are doing it, what you do, why it is taking time. Speak to them in their language that they are going to understand. But, on the other side, also show them your code. Explain to them. Bring them into your process. Explain to them there is a certain way of how I am working. There is the definition of done, this is how my code looks. (37:36)

Lior: When you see that you committed to something that is going to take you two weeks, and you don’t think you can make it in two weeks, come early enough to them. Tell them “Listen guys. I have this. And this right now is disturbing me. I have this issue that does not allow me to keep developing. I would not be able to deliver it on time.” They can understand it.

Lior: And not only that. I had a very non-technical director I was working with. Every time he saw a code, he started to have a rush. He could not sit in the room anymore once he saw the code. But when a developer came to him and said “Listen, I am blocked, because X and Y.” You could see him sitting there, not understanding one line of code, and asking questions in a very structured way. “Why doesn’t it work? What are the issues? Where is it blocked? What can I do to help you?” Then he was calling Facebook to talk to them about an issue that the developer had with an API. It’s because he had the right connection. He knew the right people to reach out to. Sometimes this can create this good communication, also between the business and the tech. Even if you don’t understand code, you are going to understand problems. You are going to understand blockers. You understand why this is not going to be ready in time. This, I think, what is important to make sure that we are doing.

Break down the silos

Alexey: Back to the point we discussed at the beginning — just sitting together, trying to build trust, trying to show, and trying to learn from each other. I am a data scientist and I’m willing to learn from you. I want to see what kind of problems you have. If I am a business person, I am willing to learn what kind of problems the data scientist has or data engineer. If we do that, if we sit together and try to understand what is on our mind, what is on the mind of the opposite… Not opposite, but for business — to understand tech, for tech — to understand business. “What kind of problems do we have?” Then it will develop this trust. It will develop this connection. It will develop a deeper understanding of the problems we have. (39:44)

Alexey: Then we will not need to explain why last time it took one hour to prepare something, but now it takes one month. Because we can show them these are the processes, this is what we need to do. This is the kind of code we need to write. They will believe us because there is trust between us.

Lior: Break down the silos. When I worked at Lovoo, when I worked in London, also when I worked at Cisco... If there are no silos between the different functions, if I am developing something in code, or when I need to deliver some dashboard, I am going to sit down with my consumers together. We are going to have conversations together. We are going to go for lunch together. It sounds a little bit stupid, but it’s working. Suddenly you have a common language because you have a common goal together to do. When you do not have these silos of “I am in the BI team and I am sitting in my corner”. It’s you all the time, you will never have good communication. (40:59)

Lior: Once you are going to go down from “I am sitting in my corner” to “I’m sitting with the marketing for one day. I am joining their chats. I am listening to what they are talking about”... Now, when we are working from home, one of the key components is to join or ask to join their chats. You can see what they are talking about, what is concerning them. Find your connection points to them through that. When you are working on something that is managed by them or needs to be delivered to them, try to also share it on their channels, not only in the BI channels. Great, we finish the sprint, will release it. No. Go to marketing or go to finance. Tell them “Hey guys, I finished it, I would love to get the feedback before I am announcing it to my team”. Think how it is suddenly changing the way that they are looking at you. You came to them before you even went to your team. You want to get their feedback, so you can actually release something you develop for them. It is showing them also that you value their feedback and you value their communication. It’s changing the game completely in many cases.

Alexey: Now it is a bit more difficult to have these lunches together. I remember at some point we had this donut in slack. This is an app that randomly connects people. Oftentimes what happened was that I am connected with somebody from marketing or advertisement or some other department that I usually do not interact with. But they use data science products in their work. Having this conversation with them, understanding what kind of things they worry about — even if it is remotely connected to my work — develops empathy and understanding. (42:55)

Lior: Empathy and deep thinking as well — it is sitting somewhere here in your brain thinking about it. (43:45)

Alexey: Since everything is remote now, one thing you suggested to do is, asking to take part in their meetings. Or maybe having random zoom calls at some point — or whatever we use for meetings — just have a conversation. Maybe a coffee chat or something. (43:52)

Lior: Do not waste too much of your time. Your time is important. You still need to work on other stuff. But at least sit in their chat room and see and then if you see something that is relevant. You can always ask them to jump on a call or jump on a conversation and then you have a trigger and you have a connection. Not joining meetings. I don’t believe that joining for every week or every second week meeting is going to give you any advantage. Most of the communication runs today through the chat rooms. (44:12)

Lior: When you arrive into the meeting, it’s either already solved or it is already in the process to get solved. It’s already too late or it’s not relevant. You are just going to sit there. You are going to be bored. You are going to start coding. Or you are going to do other stuff. You are not going to be focused. This is not what we want to create. We want to create a communication that is triggered based on important parts — something that happened is relevant right now.

Hummus

Alexey: It’s more clear now. So it could be a slack channel. Just look what kind of problems they talk about. If something is broken, pay attention to these kinds of things. Clear! Now moving on to your favorite topic. which is you know what? (45:06)

Lior: Hummus. (45:29)

Alexey: Yes. One of the questions we have is “Why data specialists don’t like hummus but business people do?” I think you asked me to ask you this question. I am really curious to know what you have in mind. So, why data specialists don’t like hummus but business people do? (45:30)

Lior: Can you guess? (45:58)

Alexey: No. I am a data specialist, and I do like hummus. (46:03)

Lior: Do you? Business people most of the time look at the very end product — the very simple one. They do not care about all that goes around it. This is why they like hummus. Data engineers don’t like hummus. They want to see all the details around it. They want to understand how hummus was created. Otherwise they are not going to trust it. This is where we are going with code. You want to know how your hummus was created. You need to see the code that is happening behind me. This is why I said it. (46:08)

Lior: But we need to create this love for hummus for both sides. Each of us is looking at it in a different way. Me as a business person going to look only at the top of it: “The hummus looks really good. There are chickpeas. There is a lot of olive oil like I like. And there is some sumac that I really enjoy”. The engineer will look at it in a different way. They are going to start “What is the hummus made of? How can I make it better?”

Lior: This is the biggest difference when we are talking to each other. The view of the data engineer or the data scientist is very deep into the understanding of what stands behind it. The businessman, his goal is to understand what he sees in front of him, fitting to what he needs. He can start using it. He can eat it. He can start consuming it. It’s really important for all of us to remember this in every process that we are doing. Looking backwards on the code and understanding how it works. There are also people that look only at your end product. They do not see what happened behind it. They will never even understand the process. Why do you suck it for 24 hours or not for 12? But they also don't have the experience. This is what we need to explain to them. I did it for 24 hours because I was switching water in between them. I had 12 hours in with water that had baking powder inside it. Then I washed it. And I put it for another 12 hours without the baking powder. This is what causes the chickpeas to be softer when I am cooking them. We need to focus on both views and use hummus as the main way that we are looking at stuff. Always think about hummus when you are dealing with data. Simple as that.

Alexey: If our company is a kitchen, then the data engineer is the chief, the person who prepares and cooks the hummus, right? (48:37)

Lior: Exactly! (48:48)

Alexey: Then who are the business people? Are they the visitors, right? (48:49)

Lior: They are the consumers. (48:54)

Alexey: Consumers, yes. So, the data engineer produces a product — hummus. Then the business people, they are actually visitors, they go and eat hummus. They say “Oh, this is delicious hummus”. (48:55)

Lior: Or “Oh, it’s a shitty one”. You should be ready for that. Reviews on Google don’t lie. In Israel, in many places where you go to eat hummus, you are going to go into a place that looks really shitty. You are going to see dogs piss on the floor around the place. It’s not going to look the most attractive one. But when you are going to go inside, you are going to eat the best food for your life. This is because they have the same recipe for the last 50 or 60 years. They were working on it and they created an experience. They understood how each ingredient that they included is changing their end dish. Me, as a consumer, what I am after is an experience that I am going to remember. When I am using data, I need to remember this experience. It’s not just that I am using data. Don’t just create dashboards, don’t just create more KPIs, don’t not just create another forecasting. Think about what the client will want to eat. And be very precise in the way working for you. (49:11)

Hummus places in Berlin

Alexey: Yes which reminds me of my former manager from my previous company. He is Israeli and he suggested to me the best place to try hummus in Berlin. I went to that place and it looked super shady. I was not sure I want to be there in that place. (50:12)

Lior: Let me guess, Azam? (50:33)

Alexey: I don’t remember. It’s somewhere in Prenzlauer Berg, near Schönhauser Allee. That was a strange place, but hummus was delicious. (50:36)

Lior: If there are people in Berlin who want to go to a really good place, they should try either Akkawy if they want to have a good experience or Azam which for me is like the top of hummus. There is another nice place which is called The Eatery. It’s an Iranian guy. Strangely enough, he’s making really good hummus. He created the right experience for people. (50:50)

Alexey: We should add this to the show notes, I do not know how many people listen for it from Berlin. I see one, Ankush, he commented in chat. I know that he is from Berlin. So yeah, if you are into hummus, Ankush, now you know where to go. (51:18)

Lior’s book: Data is Like a Plate of Hummus

Alexey: Why did you call your book ”Data is Like a Plate of Hummus”? I think I am getting some ideas from our conversation. But maybe you have a short answer to that question? (51:36)

Lior: The idea behind the book was that I wanted to have a book that combines my passion for cooking and my passion for data. I think that data is like cooking. You need to cook it the right way and you need to serve the right dish. One day in the future maybe I will be able to create a very nice restaurant — instead of working in the startup world. If anybody wants to patron me, I am open, we can talk about that. (51:53)

Lior: But the idea of the book was to simplify it for people that do not deal with data. Business people don't understand SQL. They don’t understand data warehousing. They don’t understand AWS versus Google. These views for them are very banalic. “Okay, either these two or these two. Tell me how much it costs and we are going to make a decision.” What is the difference between Tableau and AWS QuickSight? They don’t have this feeling. In my book, what I want to say is “Guys, it’s really simple. If you are going to cook it correctly and you are going to follow the orders, you can create a great experience”. This where I am coming from, trying to bridge these two different worlds into something very easy to process.

Alexey: Your main target audience for the book is the business people or the tech people? Or both? (53:11)

Lior: It’s mostly for the business people. But also for tech people who want to understand a little bit better about how they should direct the business people to work. If you think about it — there is a business strategy that goes somewhere there. The tech is somehow involved. But the problem is that the business is creating a lot of pressure on the tech side. What I am trying to do in my book — I am talking about forming the data strategy. How do you actually understand what is important and what is not? Where should you put your emphasis on? As a data engineer, as a data scientist — is it on the models or is it on APIs, and cleaning the data and sorting it? The only way to achieve it is by getting the people into the understanding of “There is a process. Let’s try to create a flow where we all agree on what we are doing, what is important and what is not.” Then slowly we are going to increase it. But first, let’s feel comfortable with what we do. Let’s create the base. Then, on top of it, we can beat whatever we want. This is my main philosophy in life: start with something simple and stable and then build on top of it. Whatever. Models, breakouts, call it whatever you want. (53:20)

Lior: Buildings. You would not be able to build a building in the middle of the river. You need to have a ground that you can build it on. So, let’s start with creating this ground, cleaning the river from the water, drying it out and then creating the space for the building — before you started building it. That is one of the most important parts where I am trying to talk about in my book.

Alexey: Will I also learn how to cook hummus from the book? (55:01)

Lior: There is a recipe, my recipe there. You’re more than welcome to try it and let me know how it came out. Some people were complaining that it was good but not as good as they expected. But as I mentioned, it’s really about the taste of people. For example, for me, Azam is the top of the hummus place in Berlin. For others, they are going to say “it’s really bad hummus”. They don’t like it. They prefer to go someplace else. It’s completely fine. It’s our taste buds that control what we like and what not. It’s completely fine if we will decide to go in a different direction. (55:04)

Data chaos

Alexey: Thanks. That was great! Do you have any last words? Any tips and tricks that you want to share? (55:49)

Lior: I just want to say one thing. I think it’s really important to send it out there. We are living in a world that is controlled by data chaos. We’re all getting underwater with the amount of requests for data that we have. As data people, our job is to clear this mess for people. It’s to educate them on one side. And on the other side, it’s also to make them feel comfortable with data. A lot of people don’t use data or do not trust data. They go by their gut feeling just because of simple stuff that happened in the past. They don’t trust it. Or they are asking for 500 other requirements just to trust the number. (55:58)

Lior: Our job is not to be the sec that’s getting beaten every day. It’s to be the ones who are going there and showing people how it should be done. We should be the leaders of the company when it is coming to growth. Because we are the only one who can find the gems inside this entire surrounding of mud. Find it for them. Let them grow. Without us, nothing is going to happen. This is something we all need to remember. We are working in a world of chaos. Our job is to bring the light for people and make sure that they were going the right direction.

Alexey: Thanks a lot. One last thing I want to ask you. How can people find you on social media? (57:30)

Lior: You can reach out on LinkedIn, it’s Lior. You can find me on Twitter, LiorB. These are the most active places I am in. They can also check out the podcast. We always happy to have people on there, if anybody interested to come and talk about it. (57:40)

Alexey: Please send me the links. I will put them in the description. Thanks again for joining us today to share your experience, to share your passion for cooking and hummus. For sharing these wonderful metaphors. I am sure I am going to use them next time when somebody is asking “Why it takes so long?” That was my takeaway from this conversation. I took a note and I will use that. Thanks a lot for sharing all this with us. (58:01)

Alexey: That’s all for today. Thanks everyone for joining us and watching this stream today. I wish everyone great Friday, great rest of the day and a great weekend. We will see each other next week on Tuesday.

Lior: Thank you for having me, it has been a pleasure. Happy Friday! (58:49)

Alexey: Bye. (58:52)

Lior: Bye. (58:54)

Subscribe to our weekly newsletter and join our Slack.
We'll keep you informed about our events, articles, courses, and everything else happening in the Club.

DataTalks.Club. Hosted on GitHub Pages. We use cookies.