"You are an intelligent business analyst": how i learned to talk to business

Speaker 1 [00:00]

Welcome back everyone. We're gonna have two more talks here and we're gonna start with Daria Petrashka. She will be talking about you are an intelligent business analyst, how I learned to talk to business. So please take it away.

Speaker 2 [00:17]

Thank you. Thank you so much for a nice introduction. And to be honest, I'm surprised that you guys show up because it's like literally the, I think the, not the last one, but we still had a full day of talks. How's your PyCon going? Nice, nice, love it. So, okay, let's talk about some lessons I learned during my career. I wanted to share it with you guys. Take it with a little bit of a grain of salt, because it's my personal experience. But, you know, maybe you can avoid my mistakes. Okay, let me dive right into it and start with my personal story. back in 2021 I was a fresh data analyst and an outsourced company and because we had a few like new data analysts so it was a new department and my manager told me hey Daria you can actually choose you can be a business analyst or you can be a data scientist like slash data analyst what would you choose? Yeah, I was pretty junior, but even back in those days, I already knew some business analysts, like you can call them product manager. Yeah, product manager would be appropriate. And their calendar used to look like that. Yeah, you see? And I wanted to do a real technical job, so I can focus on real hands-on tasks, so my calendar should look like that. Okay, so I pictured business analyst or product manager is a poor guy stuck in back-to-back calls. Me, the opposite, would implement features, code, learn new technologies, so the choice was pretty obvious I need to avoid talking and focus on doing coding but it took me years to understand how wrong I was and with that preface it brings us to agenda and I wanted to share my insights how to identify key stakeholders how to understand those people how to navigate communication especially in mixed teams, how to fix if a communication is broken, how to find these pain points before they become blockers, and how to become a person that business can trust. This is me. My name is Daria. This is my LinkedIn. I would be happy to connect with you. Yeah, really send me a connection request. I like to connect to people, not just follow. yeah and as you can see from my title yeah I'm still a data scientist so I didn't switch I think I can do this presentation so but let's face the reality question for you what percentage of your work is dedicated to communication so I for simplicity I call it talking versus coding. Talking is in purple, and coding is in gray. So who is 80% coding, 20% talking? Okay. What about this? 40% talking, 60% coding. Other way around. 60% talking, 40% coding. Okay, see. And complete the opposite. Coding 20%, talking 80%. I think you guys are pretty important in your companies. Yeah, you do a lot of talking. Yeah. But what is happening overall, so you don't feel bad, in 2023, Microsoft subvert over 31,000 of its users, and according to their data, people on average spend 57% in communication, that includes calls, emails, chat, and only 43% on doing something, creative, being productive. So I know that Microsoft, not everyone uses Microsoft, but still 31,000 people, it tells something, it tells a part. So back to my story. So how did it go after this career fork? Luckily, I had a business analyst who was bridging this gap for me, gap between business and development. And it was fine because we had a big team, because we were an outsourcing company. And usually they're trying to sell like, I don't know, it depends. But if the client is big and project is big, they're trying to sell a big team of different people. like you engineers, back-end developers, front-end developers, data scientists, you name it. That's why the roles were split, and we can afford to have a business analyst. So, luckily for me, for some time, my calendar used to look like this. Yeah, but sometimes I had to do occasional sync-up with business analysts to understand what is going on. Then, after some time, I decided to move forward and went to another company, and that time it was a big corporate-like structure, but we typically work in small teams, meaning that in most cases we cannot afford to have business analysts. That was the time when I understood that this process between business and development is not about bridging, it's more about translation. And what does it mean? Let me refer here to a wonderful book that I read during that time, it's called Build a Career in Data Science, and this is a citation from this book. A core skill in data science is knowing how to translate a business situation into a data question, find the data answer, and finally deliver back the business answer. So, for example, a business person might ask, why are our customers leaving? But it's not like you have a package why customers are leaving, you can people install it, run it, and get an answer. Yeah, you need to figure out what's important, you need to figure out how to do the task technically, and decide how to answer this question back in business terms. so yeah again for some time I wasn't alone at the project and a senior data science help data scientist helped me in that translation and it was fine but time went and I wanted to become more senior and it got me into a question how to progress and then aha light bulb moment I need to learn how to talk to business so I can be more independent. So far I saw myself as a vending machine. This is a task, I execute the task, where is my new task? And over and over and over again I wanted to become like a Jack of all trades, of course without the second part, just to manage translation, communication, development, tests, everything, demos, so I can do it and be independent. Actually, I was pretty close to the industry definition. If we refer to the pragmatic engineer and his newsletter, he defines the seniority in different terms. For example, one is scope. This is y-axis. You can see the scope. Here we have like a tiny, tiny little box in the left. We have like a junior developer. And as far we go by the career, great. Yeah, it can depend on the company. Companies can have different names, they can have different positions, different time spent in the position but the pattern here is as far you grow and in the company your scope is getting bigger so instead of tasks and features you're already working on a project product or service level and here on the bottom you have influence instead of influencing yourself you are influencing peers and and then you're influencing the whole team. And another one, pretty close to it, we have, again, influence. So this orange circle, oval, represents senior specialist. They can influence some peers or entire team, and then can be really independent during the months, or like several months, comparing to junior specialists who cannot survive on themselves like a week. So again, it's all about independence and shifting from reactive to being more proactive. So with this long preface, let's dive into steps, what you can do to learn the business part and ultimately to become more visible and valuable. And disclaimer about this partition, I think it's approximate because I will touch different things in each chapter, but I just keep it to follow the agenda. So first we need to find the right people and try to understand them. Picture this situation. I think many of you were in this situation. You were introduced to a project, you had a call, all went well, hi everyone, yeah, and you ended the call and you're wondering, who are all these people? Yeah, indeed, roles, they can be scattered in various ways. And good news, that you are not assumed to guess, to know what is the exact role of people is. In fact, if you refer back to this book, one of the biggest things that can hold you back in your career is being afraid to ask questions or just say, I don't know. And I did this mistake. I assumed I should know. I assumed I should know the project structure. I assumed I should know who handles which part. But it's okay. if you don't know it's okay if you approach if you can approach your trusted person your manager or mentor or project manager what is the role division on the project or you can even ask directly who handles the business side and that would save you save you and let's suppose you found this person you can call it in a different way some someone call it business stakeholder subject matter expert it depends also whether you're developing something for external client or internal client next step is to make sure that you understand them to understand it's really important to ask right question because sometimes business people they cannot articulate questions well they they don't have the ability to understand your stuff and they can be very generic add some ai yeah i need some fancy stuff so it can be sold to customers yeah so it's kind of it it becomes a part of your job to actually figure out what they want to actually follow up and dig deeper what is required or maybe suggest some solution oh okay based on your business i see that this part and this part can be automated and by doing this digging and communicating loops communication loops you can understand their pain points and you can find a common language and sometimes uh i also heard about situations when a client or business was called like a difficult client Like, you know, this person is difficult. We tried multiple things and nothing. They rejected everything. This is a difficult client. But in reality, this client, this business person was misunderstood because, for example, they had some strict regulation requirements. And somehow it slipped away and it was totally, you know, ignored. And without this understanding, without this requirement, yeah, they had to. They had to reject every solution that didn't follow these requirements. So it's also about, like, finding a common language, and especially in international or cross-functional teams. And I see that there are, like, multiple layers of communication. It's just up to my terminology and understanding. so first it's a language fit here language is quoted because it's not only not like a natural language english or german or japanese you name it yes there is more language in terms of how do we communicate with each other what channel do we use audio visual channel it all matters then a cultural fit even then we share a common language like english we can be from different cultural backgrounds and then a personality fit. Here psychology can help you but I think it's a separate topic you need to understand yourself before you can understand like well other people it deserves a separate talk maybe for another year. So about this language fit I think that the goal of of the language feed overall is to reduce the cognitive load. Yeah, and this is completely the opposite thing what AI slopes does, right? So do what's expected. Follow structures, follow templates, like you're writing email. Just follow the structure, keep it short. I sometimes, I just highlight something in yellow. I make something bold so people can instantly see and can instantly know what to answer. Also, reading is better than spoken. Not everyone is comfortable with the accent. Not everyone is listening 100% of the time. And also, for some examples, use different means to emphasize concepts. For example, I used images like before and after to illustrate some features I implemented. yeah to just show that before we had no grasp basically it was like but now with my feature you see how the product is changed because because this business person they can be lost in calls during the day they don't even remember about you so you need to constantly remind about yourself and reducing the cognitive log a lot and also yeah cultural fit just remember about this difference like my personal example i used to work with one latin american person and they had they used to hand over the requirements as they were apologizing like sorry but if we could have this thing added but it's not that important you know it tricked me several times because they didn't want to be direct uh and i yeah i just ignore it but in reality, it was very important for the project. So the culture context matters. And next, sometimes you enter a project and it's not doing quite well. And you think, if you think about the word misunderstanding, miss means that we're missing something. So we made some assumptions and we're missing something in these assumptions. So, again, a personal story. We had a project with initial wrong assumption when we are going just to copy-paste the logic from another app. But the stakeholder, they didn't seem too enthusiastic about it and they didn't believe the project. So I had to do the research on the data, on the textual data they had. I had to jump on a call with them and to discuss and let them show what they need. And I had to go back and propose some alternative solution. And the difference was like in this image, before-after image, I saw that the stakeholder got more enthusiastic about the project and they were feeling that they were getting exactly what they wanted to get. because if we wait too long letting these things flow a failure may happen and it's just it's not just your fault it's not just your area of responsibility because typically more people more places for communication to fail something wasn't properly agreed was slipped through and nobody noticed it until it become a blocker so somehow you need to you need to for example your Project manager may silently note and agree on something you would never commit to Yeah, business would believe them So no, not everyone would dive deep into your technical part Somehow you need to step inside you need to help to clear things out until it become a problem a blocker Why we are not doing this way you were agreeing on that and And by following the steps, you will increase your influence on the current project, the scope, and the scope for the future projects. And in my career story, what I noticed is that I started to collect requirements, including nice-to-haves. I was able to manage translation on my own, and I was showing the result back and doing the whole cycle. And from the second data scientist, I started to be the one and only data scientist, and later on I started to have more junior data scientists to manage. And what I love about this is that this kind of business communication actions are not just full-time activity, another full-time job. No, they can be simple, not time-consuming actions. Like, I love Dallana Lu, she's a data scientist and she shares some career tips. And she shared in her newsletter story that one data scientist felt invisible at work. So business didn't seem interested to communicate to her. So she started to send weekly updates, like a newsletter, to her stakeholders, and the results were immediate. Stakeholders, they became more engaged. They expected to already get these messages on a weekly basis, and they began to see her work as important and strategic rather than just another technical project. So, it all happens step by step. You need to show your readiness to jump into the unknown, to ask questions, to go deeper, to pay attention to details, and to do the job and go back, communicate the results back. And first, they would notice you, then they would see you, and then they would trust you. Is that? Thank you.

Speaker 1 [21:25]

Amazing. We have plenty of time for questions, so I'm going to start with the questions, but feel free to go onto talks.pycon.de to leave some of them. So the popular one. How to deal with scope creep in projects? Is there anything we can do to avoid it in the first place?

Speaker 2 [21:42]

How to deal with what?

Speaker 1 [21:44]

Scope creep.

Speaker 2 [21:46]

Scope creep. Let me see. Ah, okay. I got it. You mean requirement changes? It's not my question. It was about requirements. Okay, I think that if you are transparent and you have already some relationship with stakeholders, with people who are accepting your work, it's also about transparent communication. Because often they start to figure out things on the way and they think that adding one thing, it's just like why it's taking so long, it's just one feature. Yeah, but you need to be transparent and you need to be ready to have some reasoning and proving that actually this feature can break what was already agreed. And also, because some projects, they especially related to Gen-EI, these agentic loops and a lot of this nowadays stuff, I think that people don't have even a clear picture of what they want. So I think having this, you know, creation of this step-by-step project evolution helps because, for example, we say, okay, let's do MVP 1 and let's think about the most critical features that you would like to see in the project. And they can add on features, but we can push back and say, okay, this is good, we really appreciate it, but this will be MVP 2. Yeah, this will be MVP3. So it's good that they want something bigger that is proof that our work is valuable, they are going to use our project, but it's also like you need to train your business people to think in those stages.

Speaker 1 [24:04]

one popular one is why are business people so bad at saying what they need shouldn't that be their main skill

Speaker 2 [24:16]

think it's a it's also it's it's even not a selection problem yeah imagine if you go into some like restaurant they have only three options that would be easy for you yeah but what if they have like 30 options 40 options that is not like pizza and you have different like variations and you want to combine something yeah but imagine going to a restaurant when you have basically no menu and you can just and you cannot just pick some familiar food you can you need to invent something yeah that that would be freaky one but at least you know some ingredients you can explain how to mix them how to like fry or like steam but what if you don't know like what if they require you to use some unusual ingredients or some stuff that is new. I can picture the struggle, let's be supportive.

Speaker 1 [25:20]

With that, I'm sorry I have to end the session because we don't have that much time, but there are many questions rolling in, so you can ask them to Daria in the Discord channel or meet her after the talk and talk to her. So let's thank Daria again for a wonderful talk.

Speaker 2 [25:33]

Thank you.

Speaker 1 [25:34]

Thank you.