The Data Hustle — Zharko Cekovski

>> Okay, so I am a a data consultant technically. I mostly do data engineering and my main area of focus is getting companies unstuck with their data projects. That's mostly what I've been doing the past two years. A client will call me in when everything is

burning down and I'll come in and uh help them wrap up their project with a needle bow at the end. Yeah. >> Beautiful. Beautiful. Um yeah, so you you you are coming in as a fire brigade to save people. up. That is a very noble job and I'm sure it must be very hard with the timelines and the the clients you're dealing with that >> okay the basics where do people get stuck inside of their git projects? So it depends like what the project is. Usually there's an issue with priorities and communication and you'll have a project that has done a lot of work in some area that ends up being useless. Uh I've had a couple of projects where it

was brought in where essentially the client had built a platform that they had no way of maintaining and they had no way of reliably uh like fixing when something breaks or reliably adding stuff to it. it was just like uh they got someone and they're just said just build something however you want and at the end it was a disaster. So I've come into a lot of these situations and I've had to like uh essentially teach my clients like how to talk about data because a lot of my clients are like small and medium businesses that don't really have that much technical acumen. Usually there's like one uh developer in the company who's uh tackling data either like a backend engineer who's

repurposed as a data engineer or like a purpose- hired person who is usually overworked and underresourced. So, uh that's the most common type of client I work with. And uh yeah, uh usually the most effective thing that we can do in situations like that is actually teach the client what the constraints are and what a realistic project looks like. And after we have that done, I can uh do all of the other work like gathering requirements, understanding the business logic, what the sources are, what the end goal is, what the consumer of the data is. because a lot of these things, believe it or not, are just not known in a lot of uh projects, es at least the ones that go wrong.

So yeah, once you have all of those things figured out, the rest of implementation is usually relatively easy. It's just time consuming. And now with the advent of AI, even that's less of a problem because you can just give it the description of what it needs to do and it can do like 80% of the work for you. I find that like for most projects the biggest issue isn't the actual project itself. It's the last like 5% of the work where you need to wrap it up but there is no like uh defined idea of what the completed product looks like. So this is like a part where I have to like turn on a bit of my like business

analyst brain not so much as the data brain. So talk to a client, understand like what their needs are and like how they're planning on profiting from this data and then trying to design a solution around it. What I'm hearing here is it's not about like fixing the technical challenges because well I will put them in the same corner. It's also about teaching them and educating them. have gone into doing data projects have basically no foundation for any of this. They just heard it. Oh, data is a good thing. We're going to invest in it. They brought in someone usually somewhere relatively junior to do it and they kind of found themselves in a crime and then I come in. But uh once you explain to

if you're a nurse or some type of a medical professional, you're going to get a job to their sites. So they that company basically only did front-end development with a very little bit of back end. had like very very little understanding of like data tooling or practices or how orchestration works or any of these things. They were basically going by the seat of their pants with like node scripts doing all this stuff. And then they brought me in to rescue a project they had started like six months previous with a developer who randomly disappeared. This was a a massive show. So I show up. Turns out the developer his the entire project was running from his personal computer. They had no cloud

setup anywhere. I had to do that. I had to explain to them like what they should ask from a data developer because previously they had no experience with this and then I had to essentially create an entire orchestration that will work without me. So when I eventually leave because this was very obviously not a permanent job they would be able to uh if not you know develop it themselves at least very easily hand it over to someone else. So that was like how we went to and it went from uh everything is burning, nothing is working uh you know dead on arrival project to working uh importing tens tens and hundreds of thousands of jobs every day doing it under budget

>> So in practice working with the UK is relatively easy. They're they're they have a business culture that's very used to having um you know contractors from abroad. So with them I've rarely had issues. Uh the the biggest issues you're going to have is when you have this are this is this kind of like not a technical thing. you have someone from the UK who has an extremely thick accent and you can't understand what they're saying. That's the I think the biggest issue I've ever had. Uh mostly they are really good at working remotely and with uh contractors from abroad. >> Yeah. One of the thing that I always find interesting when you read any material when it comes to consulting or

tech or whatever it's very US focused obviously uh it sort of misses the perspective when you're working in in different regions and how does it work if you have a bit of a language barrier or things like that. Uh what are some other things that you've run into you know doing this that you didn't really expect beforehand but you think people should be aware of when they're doing uh crossber work like this? >> The single most important thing I've learned doing this is that different regions have a very different communication styles. So working with a British client versus working with an American versus working with Scandinavian ones. I've also done a lots of those. There's very very stark differences in communication styles and

if you don't understand those it can sink your projects. Like one example I have is when you're working with American clients you need to spend everything to be positive because they tend to be scared of negativity. When you're working with British clients they appreciate frank communication but they also want politeness. Like you you can be direct but you can't be too direct. Uh, also they also don't like directly acknowledging problems. You need to like dance around it a little bit, but they're less sensitive than Americans. And when you're dealing with Scandinavians, you kind of need to have your own inperson with them because they tend to be very insular when communicating. They there there's a very very defined in-group and out group. So

if you're not in the inroup, you're going to be uh left out of like half of the communications, which uh sometimes can be very detrimental when it comes to technical development, but otherwise it's relatively fine. Yeah. Any comments on this? My experience, what happened to me often is for me wasn't necessarily a language barrier, but the difference when an American says something like not bad versus a British person saying not bad is massive. So even if you speak the language really well, it's good to calibrate in cultures like the way that they give feedback and more or less what is their standard of like this is great and make make sure that you know when they use expressions like does this mean you

don't want any changes or to be a bit more forgiving if you're a very obviously foreign. That's for me it's that that's kind of less of a advantage I can use because when I talk to Americans they just assume I'm one of them because of the accent which is a double-edged sword. On one side they're more willing to uh to collaborate with you because they're not really afraid of overstepping cultural boundaries but on the other side they find it extremely weird when you overstep one of theirs. Yeah. Yeah. >> That's very recognizable. I one time worked for a Japanese company. It was a consultancy assignment.

>> And one thing that shocked me is they were very strict with the Japanese uh consultants and the Japanese workers. >> And I was like, I don't know how to address somebody formally in Japanese. They're like, oh no, you don't need to worry about that because you're not Japanese. And I'm like, "Oh, okay. I guess." >> So that's totally recognizable that they're going to give you some permissions. But at the same time, I don't know what you think, Arco and Tony, but I love it when people don't even have to think that I'm from another culture. Like the whole culture is not an equation neither for positive nor negative. I don't know my in my experience and and this is something that I've seen working

in different regions and and now I'm learning this as well in the new region you know in the Middle East is um if you are able to understand some some basic tenants of their culture and even adjust the way you speak maybe throw a few words in it already helps to build a lot of rapport because they see you're trying and there is one part of it where if you are able to speak with an accent or dialect that's something similar to what they're used to it it leads to less cognitive processing and there's a lot of psychological research that's been done on that and there is unfortunately to this day still uh there is going to be still a difference

in how people perceive your value based on how you speak. I mean, we all know uh if we have a British broadcaster uh speaking about nature documentaries, we are immediately enthralled, even if they're saying exactly the same thing as somebody else with a different accent or dialect. So, I've seen some of that. Uh it's not something you need to worry about too much, but it is something you can do like if you really want to go that way, that extra mile. It is something you can spend some time on. um or at least make it so that you do not like completely not understand each other. I think that's the bare minimum of course. Um really depends on what type of role you're applying for. I

recently had like a somewhat unpleasant experience when I was recommending a friend for a marketing director role for a company I worked at and the feedback that they got uh for the interview was uh we really like this person. They're very qualified, but they have the wrong accent. >> Yeah. >> Yeah. The the the person I recommended was I think from Indonesia and he had that very, you know, specific accent. He didn't sound like he was American or British. And they basically said, "Yeah, very qualified, nice guy. He doesn't have the correct accent." They they don't want to put him in front of a client. That's that's a a reality that a lot of companies will not tell you to your face, but behind closed

doors, it does factor into the equations. >> It's kind of tricky because like whenever they talk about accent or not speaking a language super well, I don't know how much of that is just like hidden racism versus truly functional. And of course, they cannot say, "Oh, I would prefer to work with somebody from the same skin color as me." But when they bring up the whole language thing, it's kind of hard to Okay, I I guess I I cannot relate to that. right now with this current like job market climate where a lot of companies are basically posting jobs they have no intention of ever filling and then when you get the uh responses if they respond which they sometimes do believe it or not uh the

responses you get can be really really like confusing because you you know you were at the interview you talked to these people they seem to respond well and then you get a response saying like not culture fit and you just think to yourself like what did I do wrong? But a lot of these times these companies just just not interested in hiring anyone. I had a very recent experience where I uh had interview for a Swiss company through a recruiter and I went through all the interviews. They were very happy. You know, everything went well. I was vibing very well with their engineers and with their managers. And then uh I got a rejection and the note said um talks too much about self. And I

then the company rejected them and said uh lacks lacks assertiveness and self-confidence and it's like okay which do you want and from what I've seen like two months later they have not hired anyone they're just reposting the same job >> that's also true sometimes uh you cannot take it personal if you don't get hired sometimes they they are just pretending that they're opening jobs to show investors Look, we're growing. Sometimes they already have an internal candidate, but they just legally need to show that they're doing it. So it's >> I think this is something that like goes for everyone in the entire economy looking for a job today, but I think it goes doubly for contractors and people working remotely where you need to

develop a very thick skin to stuff like this because there's no escaping it realistically like uh and it doesn't matter just how like self- assured you are if you continue getting this feedback eventually it's going to like harm your self-image. So like we especially as contractors and like consultants who go through a lot of clients and a lot of interviews have to especially keep this in mind because I have seen uh some colleagues of mine lose heart uh over the past like year or so from dealing with stuff like this. It is an interesting environment that we're all uh going through. To bring it back to something a little bit more positive, I guess. Uh let's say you do get into the door. You

>> I think like over the past few years, uh the perception for hiring overseas people has changed a little bit. Uh, previously it was basically just where you went to get the lowest price labor you could. So that was for some

industries that might still be the case, but over the past years I've seen that companies are much more willing to pay you more if uh you're someone who has like a bit more technical expertise. I I've I've I've been talking a lot with other people from this like general area of the world and from what I've seen the rates have climbed quite a bit. So it's completely normal for me to request a rate that like 5 years ago would have seemed completely ludicrous and a lot of clients are just happy to pay it. So I'm not sure like how much further this will go but for now the at least in Eastern Europe not sure about the rest of the

Uh so that's actually one thing I wanted to talk about. A lot of uh clients I work with and also from hearing from other uh colleagues who work in similar positions is a lot of companies that end

up hiring people like us tend to have big gaps in just basic development skills. Like I've had clients who have had uh ID companies for like 10 plus years who don't have separate production and test environments for example. Like I've I've had to set up the first CI/CD pipeline for lock clients. Uh I recently had one did know of what what a blue green deployment was like e even to like uh much smaller things like having a unit test suite available like a lot of clients are missing very very basic things uh in their sort of environments and that's actually a very good thing for us at least a silver lining is that we can introduce these changes very easily and quickly

upon starting a job and that is kind seen as a win. For like example, like one of the first things I did when I joined my previous company was I just implemented uh a a triage system so we could triage errors in the in the app and just allowed people to actually prioritize things rather than just uh drop whatever you're doing and handle the newest problem. And that just that one thing on its own I shared a document that's like less than 100 words and it allowed them to increase velocity just just from that nothing else. It was like a 20minut meeting and that on its own improved the efficiency of the entire company. Yeah.

you talking about it this way, it sort of brings up a thought to me on what is impactful and and special and like technical for a company just differs so much. And I feel like, you know, we're all getting kind of we're all getting kind of pushed into this uh full career fair mode where uh AI is going to overtake everything and automate everything. And then they're talking about these giant companies and corporations doing things, but there is still a huge amount of small to mediumsiz businesses. They don't even know that something like that works. They don't even know what git is. And if you come in there and you like even set up what you know for you might seem like

We talked about of course applying with jobs of recruiters, but are there any other things that you you're doing there? >> The thing I found works the best is making allies in your client companies,

usually with other contractors who don't work in your same area. Like the the best relationships I've developed, the most profitable ones have been from with people who don't work in data or even DevOps. the the the best people I've uh like created relationships with were either in AI or marketing like either like MLOps developers or marketing because they'll join a company they'll do like MLOps or they'll do marketing and of course they need data and they're say oh I know someone who does data and then they call you but if you talk to other only two other people who do data they're going to be in a data company and it's not expanding they're handling you all to work like

they're they're going to, you know, buy you a beer and they're going to complain about how dumb their client is, but you're not going to get a job out of it. So, usually for me, it's just making sure I have connections to everyone in the company, not just the limited data team and also usually also helps with managing internal politics with clients because if you only talk to people who are in tech, they only understand what the uh tech side of the business is doing. But if you talk to people who work in finance and marketing and sales, you kind of get a better feel for what the direction of the company is and you can maneuver better. >> I have a question. So imagine that

>> So uh two things I ask always are basically how do you handle your documentation? So knowledge because this is something usually it's the the last thing any company handles and the second

developed anywhere. >> Yeah. So if they haven't even considered the idea that deployment should be automated, that's already a crazy red flag >> because I have I have worked with companies that have like a very very good automation and those usually when you ask them the technical person will just you know their eyes will light up and they'll talk about their Terraform stack and their uh Kubernetes and their stuff and they'll talk about for three minutes because they're very happy that someone asked but if uh they don't have any of that thing they'll just kind of blankly look at you well we have a script Yeah, it's it's it's a very easy way to like get a very quick idea of where they

are with uh their setup. Like I I I do know clients who don't even know what Git is. I've I've seen ones that don't know how Kubernetes works. I had a client where the entire pipeline lived on the laptop of a contractor living in the Philippines. Like there was one week where there was a power outage in the Philippines and we couldn't deploy. >> Yeah. So lots of these things happen even in companies that are relatively big and like wealthy like the the company with um so I don't want to name names but the company that had the the Filipino laptop guy is working with both Amazon and Nvidia currently. >> Yes. Yes. >> This reminds me of of a company that

back home in Amsterdam that had like 20 laptops running all the time in a server room and that's how Yes. You know that software that actually moves your mouse and clicks. So it's not a script not not like PowerShell or something. They had a room full of laptops where they would like drag like a mouse every so often and that's how they would deploy pipelines and stuff and I'm like well actually that's that's a very interesting use case because that brings another point. The reason why they did it is because the company was going through what I personally call dead by DevOps, which is when the deployment team creates a process that is unmaintainable.

two things will save you a lot of time, a lot of developer time, a lot of PM time, a lot of just headaches avoided. Beyond that, it's really iffy of what uh benefits from automation and what doesn't. There are certain things like recently with AI, we've had like a much bigger possibility of doing these things. So some things we've done, we've set up bots to essentially summarize Slack messages. So once in the end of the day, you'll get like a pop-up that says, "Okay, today on this date, uh these two people discussed this, this client brought this up and this was uh marked as done." And great, you have like a little summary. It frees up cognitive load. It makes it easier to

understand what is happening and it's relatively easy to set up. There's some tools that do it for you. You can be up and running in 15 minutes. Uh you have the meeting summarizing bots also really good. Like uh you no longer have to have a person who takes notes and then shares them. You just get an email at the end of the meeting that has like really uh well formatted summary. Okay, everything else done. you can have lots of these smaller automations that free up cognitive capacity for companies uh and just allow people to do more actual real work. Like I think like one of the uh biggest like frontiers yet to be uh like properly explored is not so much uh

the client I'm working with right now made a commitment to reduce meetings to two a week per team. So you have two meetings, one on Tuesday and one on Thursday and the rest of the week you can just work all day in in the order you want. So if if you're any person who does any serious work I can sit down for example me I can sit down and I can spend four hours just thinking about a problem and the quality of the work that you generate by thinking deeply about something for four hours usually with the assistance of like u usually an AI bot or maybe talking occasionally to a colleague you can generate really good like solid work that doesn't basically

exist in one of these companies where there is like a meeting every 15 minutes, you can think actually think deeply about things. You can think, okay, so we can make this change, but does this change make sense in light of the other change I'm planning to make? Like uh right now I'm doing a refactor on a pipeline for DBT and I'm thinking, okay, so if I added uh these test gates in the pre-ingjust step, does it make sense to put them also in the bronze layer? Does it make sense if we're filtering this in the bronze layer to also put the same test in the gold layer? Does it make sense to uh do this testing further down or further up the pipeline? Because we

have like a weird situation where there we there was like acquisition and now we're merging five different pipelines into one. So lots of like space for problems to pop up. And then you you also have to ask questions like okay this pipeline isn't documented very well. Let's talk to the person who built it. Let's figure out like what the quirks are. And you can deep dive into these things and then come out at the end of the day with a very deep and good understanding of like how a piece of technology works that you can't really do in a company where you're just jumping from meeting to meeting to meeting every like half an hour. Yeah. Like right now I have a mental map

of like a 15step pipeline built up because I was able to focus for two days straight on this. uh if if I was working at a regular company where I had like a daily and then I had like a weekly with my manager and then I had to have like um like a team building exercise and then I had to go and listen to someone's lunch and learn and then I had to go to like a client meeting once a week for like four different clients we're working with. I would just spend all day uh going to meetings, recovering from meetings and getting ready for the next meeting. I would be gaining essentially a developer salary to just be like a

background decoration in a meeting. >> It's interesting you uh you talk about this dichotomy between schedules of builders and uh other people in the business. Uh Paul Graham from Y Combinator has once written about this. He calls it the uh builder versus manager schedule. If you think about a manager, >> they want to fill up their day with as many meetings as possible because they want to see what is this person working on, what is that team working on, and that's like how they measure their productivity in a day. And that's great for them. But then if you're a builder and you're actually want to have large amounts of uninterrupted time to do your work, >> yeah, >> that is terrible. Like you're not able

to do your work. You're not able to deliver the impact. And it you feel the frustration inside like I I know I can do more but I just constantly >> Yeah. Yeah. >> of a you know a good day's work when you're doing that. >> Yeah. Like I've had a couple of opportunities where I was put into a manager role like uh if you look my LinkedIn my last position basically was a as a product manager. Uh one like big thing I do when I am in ever put in imagine position I don't seek them out they kind of find me and um what I usually do is I kind of think to myself okay I am not like a big boss I am

basically a um overqualified secretary for the team like my job is not to to make myself good my job is just to make sure everyone else is able to do their job that's like how I approach these What you that usually means is I prevent any person on my team from going to meetings. Like the client wants to talk, okay, I'll go there. No one else needs to show up. The ma the upper management wants to discuss something. Okay, I'll go do it. Uh the the tech lead wants to know about technical updates. Okay, give me a summary. I'll go talk to him. Like my developers never needed to attend meetings. They can just focus and do work. And usually that was very effective but

with the downside that I had to go to meetings all day. I I used to work in a company that had a very strict uh limit so that if you worked in sales, you could only involve a consultant was it like I think it was like two times a month like if you thought that the meeting was going to be difficult and you needed a technical perspective and that completely changed the landscape. >> That's basically what I was hired to do. I was the the technical go-to guy for a lot of these meetings and it really helped because we had uh two developers that were just able to work all day without needing to jump into meetings. Yeah, when when I was able to I even uh

eliminated the daily. We just had a Slack thread. You just post like daily thread and you just write like a sentence about what you're working on. No need to fire up a camera. Also, another thing I have noticed is that uh in terms of like focus, it's a lot better to have audio only dailies if you ever have them. When people have like visual ones like this with a camera on, they tend to spend a lot more mental energy on them because you're essentially like sitting here and you're seeing this. Okay, I'm being observed and you're just thinking all day, don't pick your nose. Don't pick your nose. Don't pick your nose. And that occupies so much like brain power that by the end

of the meeting if it's like a 10 20 minute meeting you're exhausted because you've just spent your willpower on this instead of you know coding fixing problems dealing with bugs you're just spent spended in this meeting going like okay they're all watching me don't do anything dumb don't do anything dumb don't do anything dumb it just it's a big sink of energy and mental power like that you kind of just fur away every single day with no benefit by having v visual meetings just just uh put it in voice chat and get it over with if if if actual like verbal communication is necessary. >> Yeah, >> a little bit shifting the gears. There is one question that it will probably it

will not age really well. So, we're today on May 2026. And since you're an expert, I'm curious, what are the things that nowadays AI does terribly when it comes to deployment? And some things that it surprises you of how well they do it. I've seen it used is um Oh, okay. So uh if you ever decide to use it to actually deploy anything, rethink your uh approach like AI the way I've seen it is um akin to a very enthusiastic intern right now like very books smart has studied all of the the the has read all the technical blogs has done all of the exercises it can ace a tech interview putting into an actual development environment it flounders.

really badly like a lot of the time. So I would I would basically give it a tasks that look like tech interview questions. So if it needs to do a very self-contained task that you could very quickly check, uh AI is wonderful. I love it for stuff like this. If you needed to do something that is not complicated but very painstaking, for example, I've used it to build a self-healing test suite. It's it's wonderful for that. You can just throw it. It it will it will make lots of mistakes. It will bash it head against the wall for hours on something that you can probably do in five minutes, but it frees up your attention and it gets it done eventually. That's also a good

application for AI for essentially like minor tasks like writing notes, summarizing emails, I I use it basically for moderating tone because with like different clients, you need to take different tones when you're talking to them. Some are very jumpy and scary. You have to be very formal. For some you need to be overexlained. For some you need to underexlain. AI is great for that. I have like a bunch of agents except for this. And um anything that has to do with uh it building an entire system on its own, I would never allow it to do it on its own. Like uh I've seen a lot of cases where it will uh partway through uh change the requirements that you set for it in

order to be able to meet them and then you just have like a useless app that looks like it's working and if you you spend like $100 worth of tokens building it like with AI it's it it basically is like a overenthusiastic intern that requires per programming to actually work properly for now. Maybe tomorrow uh Claude will release some super genius model can handle everything on its own, but we're not there yet. >> It's just saying because I think two years ago I I asked one to build something on GitHub actions and it was like hilarious how bad it went. Uh but recently it's been building some stuff like oh I didn't know this was a possibility. Interesting. So to me, I'm

not an expert in deployment, but it's really interesting to see like, oh, it's catching up in some aspects. >> Yeah. >> Scripts and deployments and to maintain like Terraform. Um, I don't think it it's like reliable. If you just need something to generate all of the boilerplate, it's great, but uh it always messes up on fine details, especially if you have something that's non-standard in terms of deployment. >> Okay, so >> for example, I have a client that mixed the British and American spellings and it it just didn't work very well.

>> I am in the process of bip coding a website. It will be posted on LinkedIn follow. And yeah, uh I'm not exactly sure what my next step is. Maybe I'll create a company. Maybe I'll just get another job. Maybe I'll get hit by a bus. Who knows? typical Eastern European joke to make. I'm not sure some of our overseas audiences will understand it. Jarko, it's lovely to have you over. I I had a wonderful discussion and uh yeah, very excited to see what you cook up with. And please do send the website.

We'll add all the links in the description below and whenever you're ready, we'll add it. Good luck in all of your ventures, especially with the upcoming book. Sorry if I spoiled anything.