Okay, everyone. Hello! Hi, this is for the DevX Roundtable. For those of you who haven't met me before, my name is David Gengar, and my passion is technology. That's why I founded DevX with the goal of helping technology companies succeed. We're not just a staffing agency. We bring great minds together and create community. If there is one thing I would like you to stick with and resonate with you, well into next week and beyond, it's this: Do you know your technology? And do you know your staffing requirements? DevX is here as a partner in order to help you determine what you really need, who you really need, and how to keep your technology projects on time, on scope, and on budget. As a former CTO, I really understand the pain points of every team. That's one of the reasons these gatherings are so important. The DevX Roundtables are an opportunity for us to learn, share, and grow. As leaders, you've all had incredible successes, and yes, experienced some setbacks too. That's why I'm delighted to gather great minds here tonight, because this group has the power to change everything with a single idea. Technology has incredible influence over people's lives and businesses, and there is so much more we can do together. With determination, we can become the next Silicon Valley. One clear trailblazer is Yossi Hoffman, CEO of Forward Slash and our generous host this evening. In fact, few people understand collaboration as well as Yossi does. In addition to collaborating with us, Forward Slash's business model is built on a profound understanding of clients' needs and wants, and on coordination with complex teams of internal staff to get work done on time, on scope, and on budget. Perhaps the greatest challenge of any CTO is how to keep tech projects on budget. And that's the topic for tonight. Is there such a thing as a 100% success rate? How much blame do we lay on inadequate scoping? And what can help speed up actual development? These are just some of the points that our wonderful panel of experts will address this evening. And now I would like to hand it over to Shulen Roden, Head of Director, Director of Development at Forward Slash, and is doing us the honor of moderating the DevX Roundtable tonight. Thank you. It's an honor for Forward Slash to host this tonight. It's a really amazing group of people here and community to be a part of, building amazing solutions and technology that are bringing big growth and success to different businesses. So, without further ado, first, I'd like to call up my partner in crime, Yossi Hoffman. Get over here, Yossi. Don't be nervous. Give him a warm welcome. This is his first panel, so show him a lot of love. We also have Max Hauer of ConnectBooks. Um, and Nachman Leiser, who is the CEO and founder. I'm sorry, Nachman Leiser of ConnectBooks and Max Hauer of GoFlow. Apologies. I'll give a more detailed introduction as we move forward. Just to give a little bit of a structure to the conversation: every time there is a visionary leader that has an idea for an initiative, a venture, the first thing that, of course, you have to decide is what is an appropriate investment for the business in order to achieve their goals. Not so much a question of how do you figure out how to scope software and what it should cost to build a specific piece of software, but, um, how do we even make that initial decision of what our appropriate budget should be? That decision is made, and we start moving forward into the production phase, execution phase. It's critical that at all times, as much as you know, you're flexible and situation changes and you learn new things to constantly adapt in realities and make sure that everybody is aligned at every minute with the vision and the success of the project. And then ultimately, every single person that's part of the team of executing on the vision and building the amazing solution, they will need to really share in the ultimate vision of the success. So, besides having processes in place to make sure that from a development standpoint, things are being done as productively as possible, also the human element to make sure that everybody's interests are aligned. And so, those are the three main topics we'll cover tonight, not so much the engineering side of things. And so, the first question, um, we'd like to throw it to Nachman. Nachman is the CEO, founder of ConnectBooks and Bottom Line Management for over 10 years. He's been an entrepreneur, financial analyst, and profit game-changer, usually all three at once. After working as CFO in several businesses, growing their revenue by double-digit percentages and more, he founded his own e-commerce bookkeeping and accounting firm that specializes in uncovering ways to reduce costs, eliminate losses, and scale profits. He helped online sellers in the red become profitable within a year and exceed the million-dollar mark in net profits. He developed an industry game-changing app, ConnectBooks, that partners with QuickBooks and online marketplaces like Amazon, Shopify, Walmart, and more. Today, ConnectBooks helps hundreds of sellers reconcile every transaction in ConnectBooks in a click and see itemized and bottom-line profit and inventory updates as they happen. Nachman has been regularly recognized as a pioneer, an innovator changing the role accounting traditionally played for e-commerce sellers and creating systems that double, triple, or even 10x profit margins for his clients. His Master's in Science with a major in accounting from FDU. And so, to kick off our discussion, what are some of the key factors you consider when deciding, you know, what to invest in a new technology project? How do you determine the initial budget, or what are some common mistakes, pitfalls to avoid? Hi, everyone. So, first of all, I want to say hello to everybody. Really exciting to be here. And what I would just start off with is that when I started my initial, initial journey in technology was six years ago. And I think almost everybody who helped me out on my initial journey is actually here in this room. So that's quite exciting. Um, when I started six, seven years ago, obviously, I didn't know anything about technology. I didn't even know what software even means. All I knew was that you make a software, and then eventually it cost a little bit of money to pay a few developers, and then all of a sudden you just have customers, and you just make money. It was a very long journey from when we started. I started exactly with nothing, and today we're a team of 25, and we service over a thousand customers. So, basically, the question was, what are the common pitfalls that I have seen? And when I advise a lot of startups, the first thing I always tell everybody is figure out first your destination. And that's something that I didn't do, and something that I had to figure out later on, which makes stuff a lot more complicated. The problem is that when you don't understand your destination, then whatever you're going to do originally, and everybody can still, and anybody here who is in technology, and I've spoken to people who are way bigger than me, and people who have over 100 million dollar companies, they have problems in their company today that are still there because when they started programming, they never realized where they're going to want to be one day. And since they never realized where they're going to want to be one day, they are still stuck with certain technologies from day one. And it even works like that with public companies. They're actually doing today with certain software that is public, these issues that they have, that they're still up until today. And when you're public, and you're that big, you're talking about like 10,000 employees, you're not going to make a huge code change that affects your core technology just because you want to move today to a different place. So, I would say the first thing is, whatever you want to understand is, have a real, clear vision where you want to go. That means to say, do you want to be more like of a program to serve just the hamburger people? Do you want to be to serve everybody? Do you want to go the VC route? Or do you want to go just a route where you would just want to have a good, profitable business? And once you understand your destination, then you can start making decisions. And the thing also with software is that there's a huge gap. Software is a gap where I would say is that either you have like a very niche product and you service like a certain industry, very high-paying clients, you charge a lot, or you want to go a different route where you're going to have to grow very, very fast. And that when you want to go the other type of route, where you want to like, go more VC route and other stuff, the only way to make it is to go big. So, the idea is like, either you stay very niched in a certain market, and you understand, okay, even if I have 25, 30 customers, I'm already making money. Or the other route is, no, I need to get a lot more customers. But when you want to get a lot of, when you want to, when you want to start going the other routes where you're going to get a lot of more customers, then you have to understand. Now, you have to understand that the only route you can do is by going big. Now, adapting to the mindset that you're only going to go, you only, the only way you're going to go is by going big, you have to also understand every decision that you're doing, your codebase from day one will affect you in 10 years from now, unless you plan on doing half what I did, which was ripping out big parts of the code, and restructuring databases, restructuring setups. Everything will have an effect later on. So, what I'm saying is, when you're starting out in any new project, the first thing is understanding the destination. The reason why you want to understand your destination is because these decisions that you can make early on, that will have, will maybe add on a little bit to the workload and might have a little bit of complexity, but down the line, it's going to ease things off, and it's going to make everything work the right way. And the best thing, what I would say is, if you're not sure, reach out to people who have been there. Like, if you're not sure exactly what the proper way to do is. And let's say, I give you an example. I had a guy who called me, he said, "I'm starting out now, what should I do?" So, I told him, "Based on where you're going into, and he had investors," I said, "You're planning to be a company that's going to have over a few thousand customers. You're going to need an in-house team. Now, everybody knows that when you start with one, one developer and you have another developer, another developer, you lose out. When one person leaves, the next person comes in, or if you go to an agency, sometimes you lose out a lot. I said, structure yourself from day one for success. Have right away a CTO in place. Have somebody who's going to know the codebase from early on. Have the right people, um, who you can consult with, which database to use, which code language to use, how to structure it, how to layer it properly. Not that when you find yourself with 500 customers, you basically have to start reworking." Yeah, just to mention that also taking questions from the audience, so if anyone has a question on what Nachman just said, feel free. So, to your point, obviously, there's a much bigger picture to figure out before you even could begin to figure out an investment. Um, there's always the, uh, possibility that mid-course, you know, you want to turn the ship and things might change. So, yeah, you're always going to mid-course change. The question is, could that have been avoided? Any suggestions for mitigating the costs of that happening? The best thing is talking to people. When they, having the right people you can consult with is definitely going to save you a lot. Okay. Um, so, anything you want to talk to specifically about once someone has that vision and they know pretty much which, uh, one of those buckets that they might fit into? Like the next step that you would take to begin actually from a business standpoint, making decisions about, you know, investments, budget, putting together financials to align with their vision. Well, it boils down back to saying before, if you have the right person who can advise you, like, from a technology standpoint, what you need, and that person has been in your shoes before, so they'll know exactly, you know, when you're saying you're planning on accomplishing X, Y, and Z, they'll be able to tell you, "This will work, this won't work," and that will give you a bigger scope on the project for, you know, where you're heading financially. So, in other words, everyone's at the right place tonight. Everyone should make those connections and find that amazing advice. So, obviously, the goal is to start building and start executing on these visions. The topic of how from an engineering standpoint, you know, you decide what to build and how to build it is an event unto itself. But the critical thing as you're moving forward, especially, you know, an agile world where you want to move forward as quickly and as carefully as possible is to make sure that at all times, you're staying aligned with the ultimate vision, what success looks like, and also your financial goals. And so, with us tonight, we have Max Hauer, who's an accomplished entrepreneur. At age 20, he built his first company, has since built two more, including Solida USA. He has an expansive background in marketing, marketing communication, sales development, has been profiled in Wall Street Journal, New York Times, and numerous other major media outlets. Hamming magazine, not yet. Boldly creative, Max has the entrepreneurial abilities to envision new winning ventures and the hands-on business experience needed to make that vision a reality. Specialties are business development, sales development, branding, identity, marketing, and most importantly, keeping a team aligned and keeping a team productive and building a team so that at all, at all times, no matter how fluid a situation might be, the team is constantly performing. Now, currently, he's the CEO of GoFlow, which is a cloud-based SaaS platform, which I'm sure everyone in the room is familiar with. It helps enterprise e-commerce sellers manage their multi-channel order, shipping, inventory, listings, transfers, purchasing, and analytics from a single interface. And so on. So, question to you, Max, is, as a project, you know, as an initiative is moving forward, and, you know, things are constantly evolving and changing new insights. How do you make sure that, number one, the team, what's the process is that the team is always fully, fully aligned? And then how do you deal with changes of direction or to scope? Thank you. Thank you to you and thank you to Forward Slash, to Yossi, and to, uh, for putting this together. I've done events in my life, and I know how much work goes into it, and how much it costs. I appreciate it very much. A bit of my backstory as it relates to this conversation: so, I have built a few e-commerce companies before joining GoFlow. Um, we initially, my first e-commerce business, we started in 2005. The first website that was launched in 2005. The first website at that time, we had to hire a whole team in the Ukraine to build the site because there weren't really any any website developers in New York at that time that didn't charge half a million dollars to build a website. So, I built my first company, my first e-commerce company, 2005, and then we grew from one website to two websites, and then to three. Then we started doing Amazon into late, uh, 2000, and at about 2015, so, it came to a point where we had about five, six e-commerce stores on the internet, and, including Amazon. And we found ourselves struggling very, very hard to manage orders, to manage inventory, to keep things afloat. I used to work whenever we had like a major sale or a big weekend, I used to work myself, you know, I had to help out in the warehouse. I used to work, you know, sometimes 18 hours a day just to get orders out the door. So, we quickly realized that there is a need for a product like GoFlow. And, uh, that's, that's where I got involved. We hired the team to build a product for ourselves. But then we quickly realized it's going to be a lot bigger than our needs. So, we pivoted GoFlow into a separate company. I was not involved for a long time. I kept on focusing on my e-commerce business, but in, in about, about, about, what was it, about COVID time, I got involved full-time into GoFlow. And, you know, the other businesses, basically, run on its own by now. But, I can tell you, I can tell you, when I got involved in GoFlow, I really started having fun, because I quickly realized that the types of, I've, I've employed many kinds of people and many teams in my life. But, uh, having to work with a team of developers and programmers on a daily basis, that's where I really started to have fun. So, it was the first time I had to deal with crazy people, and people that like to color outside of the lines, and people that have very strong emotions in one extreme to the other. So, it's, it's, it's, it's been, it's been, it's been a real pleasure. My background is not programming, not development. So, it's great to be here with, uh, with the whole room of people like this. So, I appreciate it very much. So, as far as, as far as budgeting goes, um, we don't really work with budgets, but we, we, we face the same problem. So, when I got involved in GoFlow, about four years ago, um, you know, my job was to help bring the company to the next level. Bringing the company to the next level meant that we had to further develop the product. Build a whole lot of new features. Build new features that actually the customers actually want and actually for the company to start to be proactive and not reactive. So, at that time, I want to paint a picture for you. Um, we had a whole bunch of people working really, really hard all day, every day, but the majority of their time, effort, and energy was spent on, on putting out fires and being reactive and turning the wheel, so to speak. And actually delivering features to those customers who screamed the loudest. So, those customers who would, who would threaten, "If you don't build this feature for us, we're going to leave. We're going to go to the competition." Those companies, I want to give you a secret, it doesn't work anymore today, so don't try it. But back in the day, this was the best way to get GoFlow to build something. And obviously, what happened was if a customer would scream very loudly, so all the work that went into some other feature that, that developers have spent many, many days, months, and weeks, and hours to build, basically, you know, was shelved and went out the window. So, not only were we not able to ship any products, we were not able to build a company at all because we weren't able to ship any new features, build any new integrations. You know, I don't have to tell you, I'm sure many of you struggle with this every day. So, and I had very big ideas for GoFlow. We had, we had a couple of very major features that we needed to launch, such as an API, such as listing building tools, you know, intricate reporting, um, sorry. And, so, so we found ourselves in a predicament. Okay, we, we found ourselves basically telling, telling each other, "What happened? Back in the day, we used to ship features, we used to build product, we used to, we used to, uh, we used to collaborate and we used to," you know, we, we had a plan, and we delivered on it. But it came to a point where everybody was telling me there's no way to build GoFlow further and, and to get all these features live unless we hire a whole new team of developers. And, obviously, the budget wouldn't allow for that. So, my, my initial approach was, um, we're not able to hire new developers. First of all, new developers mean, a lot of ramp-up time. So, six to, six months to a year is not going to be any, it's not going to bring any productivity from these developers, anyway. And we need answers now. We need to start building stuff and ship stuff right away. So, the, the thinking was, we, we have to find a way for the existing team to be a lot more productive for this existing team to deliver a lot more. Basically, deliver with what we have. So, we figured, other companies before us have probably solved these problems, and they've probably beaten the path for this before. So, you know, we looked into all these frameworks that exist out there, Scrum, Kanban boards, and agile development, and everything else. But, then we realized, you know, A, it's not going to work for us because we're mostly a high machine company. And, having this kind of structure and formality that frameworks like Scrum call for, you know, having the daily standups and the Scrum masters and, you know, and then the, the, the formal follow-up meetings every week, writing stories. Nobody can, nobody in this world can write a story if you know how Scrum works. So, it, you know, wasn't, wasn't, wasn't really, wasn't really a realistic idea. Uh, but then not only that, the big hole that we found with, with frameworks like Scrum, was the big idea of Scrum is that you come up with a project, you come up with an idea, and then you break it down into a whole bunch of little, little features, and you hope that one day, you know, all these, somebody said to me once that Scrum is like a shredder machine. You, you, you put in, you put in a big piece of paper, and it shreds into a whole bunch of little pieces, and then you create tickets out of these, and you hope one day it's going to, you know, develop into a product. But that, that didn't work for us. So, we obviously knew that we needed it, we needed, we needed some kind of a framework in order for our team to be more productive. So, after a lot of trial and error, I can report to you today, after four years of trying, I think, I think we figured it out. It's still a work in progress, but it's working for us. Um, we don't really work with monetary budgets. We don't work with budgets when, you know, the team, the team is our own team. So, we don't really need to put a budget to it. But obviously, we need to put a budget to it as far as having goals and, and having completion dates go. So, what we, what we figured out was first of all, we wanted to look at what's wrong with the current system. The current system basically meant that every developer was working really, really hard all day long, every day. Nobody was slacking around. Okay, we don't have employees like that, and but nobody had any kind of deadline at all whatsoever. Everything was open-ended. There was absolutely no transparency. If I wanted to know where are we at with a specific feature, or if a customer would ask our sales team when are you going to launch X, nobody had an answer because nobody even knew what what the team was working on and when it's going to be done. So, there was no deadline, there was no plan that we could follow. And I, I, I always told my team that the worst word that I'm that I can hear is, "So, what's up with feature X, we were discussing like six months ago?" "Oh, that." So, the word that I, I was scared of the most was, "Oh, that. You have to understand, you understand, you know, I know you're not very technical and I can't explain to you all the exact details, but you have to understand, you know, we started this and then we realized that and then we had a bunch of prerequisites in order to build this, we need to first build that." So, this is the situation we kept finding ourselves finding ourselves all day, every day. So, the framework that we figured out is A, we needed to find a way for things to have deadlines. So, there's no such a thing that any developer can work on their own on a project until they will call us up and say, "Hey, it's done." And B, it needs to be broken down into digestible pieces. And C, it needed to be collaborative. Okay? So, if you want to build a feature, who else is going to have to be involved in this so they can do things simultaneously? So, we figured out that the best way to do this would be of with what we call, what others call time boxing. So, the idea is that you have a feature that we define exactly what the feature is and what it's supposed to be, and then you give it a time frame of about six weeks, four to six weeks, and then you break it down into specific tasks. So, each task gets assigned to a specific person within a certain team, and each task only lasts for for a single week. It cannot be longer than a week. So, within that week, these tasks that belong to this particular project or feature project slash feature has to be completed within that week. So, instead of looking at a budget of how long is this going to take and and and how long is it going to take in trying to estimate what, basically, instead of looking at it trying to estimate how much time it's going to work, we look at it how much time do we want to spend on this project. So, so, so take take for example, take for example, um, an analogy. Let's say you want to take the kids, uh, you know, Halloween. All right? So, instead of, so you know, you're going to, you're going to, you're going to dump into a car a bunch of screaming, yelling kids that want to stop at every gas station to go to the toilet and then they need snacks and then they need cold water. So, instead of looking for a very interesting place you can take them at, you're going to say, how much appetite do I have? How much time am I willing to spend with these two crazy kids in a car? So, the furthest I want to go is three hours. Okay? So, you decide I want to spend on this particular trip, I want to spend three hours. And then you look for places to go that fit in within that particular time frame. So, so instead of having a fixed project with variable time, we figured out to have a fixed time frame with variable tasks, and things have to be completed within this particular time frame. And this is the framework that has worked for us. I mean, I can go into a lot more detail, but I just realized I'm taking up all my time. So, thank you. Any, uh, follow-up questions to that? So, that's why, that's why each project that is time-boxed for four to six weeks gets broken down into individual weekly tasks. So, so at the end of the at the end of the week, you have to report to the project manager and give an update of where things are. If we realize that there's a problem, it's going to be reconsidered each and every week separately instead of him having to run with this for however time it might take. Any other questions? There's going to be actually like roundtables after, so you could, uh, debate all these points. Um, thank you Max. So, ultimately, like we said, the team has to be fully on board with the overall vision. Um, just by way of introducing Yossi to direct this last question to. So, I've been there from day one, Forward Slash, alongside Yossi, and seen, you know, all the growth, and from day one, I could say there's probably two main guiding principles that really drove the company forward. Number one, is we deliver value to the client no matter what, right? If we came to terms with the client and the client is expecting to be provided with a certain result, a certain deliverable, we're going to honor the terms of our agreement, that we're never going to let our clients down. And then the second thing is a really unbelievable level of humility where everybody realizes it's not just about them, but they have to have, you know, their teammates in mind and the client's issue and some interests of mind. And that's really what it takes to have a very successful team, really all dedicated to the same cause. And so the question is, um, given that success, so what are some of the, uh, and I've seen the effort that goes into this to make sure that everyone on the team, their heart is really in the right place, and everyone's interests are being taken care of, and they feel like we're worried about their success. But then everyone still carries the same level of responsibility for the success of the bigger picture, the success in our case of clients of the organization. So talk to us a little bit how you implement that in Forward Slash. Thank you Shula and thank you everyone for coming. So yeah, I think whatever process you're going to have, any process you can have, first of all, um, you described in some way Agile, but you adapted it to your company. I think it's a very important point. People try to think of, people here about processes or systems and they think, what do I have to do now to change my entire company to adapt to a certain process? There are fundamental processes that people talk about like Agile, Scrum, business leadership, EOS. I think that you could follow a certain process and adapt it to your team and to your company. You don't have to religiously follow every step that you read in a book and every diagram you saw and every org chart you saw. Learn the basics of the process and then from that process see what works and what doesn't work to help you in any different way. Like Max did, because you in a way, you did do sprints and Agiles, time blocks is sprints in your way. Um, all of this is, uh, only as good as the people on your team and the people working and adapting to the process, which is could be a challenging thing for sure. It obviously starts by hiring the right people and and I'm sure companies have HR processes or have their ways of hiring people. But it doesn't start and end with the hiring process. I think it's actually it's a very important step in the process to hire right. But it pays to invest much more along the way once you have an employee to keep on bringing the most out of your employees. You have to teach them the process. You have to make sure they follow a certain process. And there's technical details how you can do that. Time tracking, audits, evaluations, that's all beautiful. It's all good, and it's very, very important. But it doesn't, it's very, very important that the tech leads, team leads, project managers, project owners, however your setup is, to have a human side of things to constantly do check-ins and relate to the people on your team, not only a managerial perspective, but also very important to make sure that the people working for you or the people who are working on a project, if it's an agency working on a third-party project or it's your own company working on your project, that every single person working on that project, it doesn't matter if it's a strategist, if it's the CEO with his vision, all the way to QA and DevOps person, they have to understand and they have to feel meaning in what they do. And when I say this is, when I say they have to feel meaning in what they do, is they have to be part of the vision. They have to understand what the company is building, and they have to understand their role within what they're doing, what impact it's going to have for the project. So, it comes down to even a QA person that can just get a task, test this and this feature. You can give it to a QA person that's just a robot. If you don't have automation testing and it's a manual tester, they test, they see if it's a bug or not. It works, it doesn't work. But imagine that QA person who from the beginning understood the entire platform, understood the vision of the company, understood the user experience of the system. Imagine what more that QA person could have done by bringing up front-end issues, things that's not even, you know, his department. But you know, "I tested the form, it works, but I think we should swap these two fields, it's just easier." Like I'm giving like very like practical examples, but it's much, much bigger than that. So what I have seen working for me is everyone in the team must be aligned to understand what their role is and what they're actually doing when they come in every day and sitting down and program or design. They're not designing, they're designing, but they're designing something. They're designing something for someone. They're designing for customers, customers. And I go, I've seen it work tremendously. I spend a lot of time to pick UX people and we have a big team, a very big team just to pick random front-end developers and just tell the whole story of the project, who the CEO is, what's his vision, how many companies companies you have built, what failed, what not, how this product he believes is going to make a big difference in the industry. That gives the employee that when he does simple front-end coding that he's into something, he's doing something. And I know it's easier said than done or it sounds like a story, but if you're really invested in doing that and you make the employees feel that they're part of something, you get much better productivity. And you also get a lot of surprises. You got a lot of things that's either the employees, it's not their job. If you have let's say deadlines and you want to, you know, you have emergencies, if that employee knows he's part of the story, he starts part of something, the attitude towards giving you more is going to be much different than the attitude of just sitting in coding. So I think I could, yeah, I could back up a lot what Yossi is saying because we've actually had amazing, talented, very senior engineers. We made the decision to let them go because they were not aligned with the client's success and the company's success. And actually that led to real cost drawbacks because they would make decisions more from what they thought was, you know, the framework they knew or engineering question they knew. And they refused to put their heart into where you could have someone much more junior who wakes up in the morning excited, passionate about the client, the project, and they make such more, uh, and I just wanted to come back a second. So Max, like the framework that you figured out, um, the way you tweaked it and and, you know, figure out what actually works, cut out what doesn't work. Um, so let's say comparing it to other, actually I'll throw this back to Nachman. Um, you know, what other project management processes, approaches do you see working that also helps ship and deliver things with all the benefits, you know, that Max is talking about? Sure, so this is something I really wanted to share, which is I think a very interesting topic: how we were able to boost productivity close to 400% literally saw a shift over a two-month timeframe by developing a lot of different techniques. So one of the first thing, one of the first things we saw was that developers were developing a lot of features. And then we also had a QA who would go over every single task to make sure everything was working properly. So the way developers work is they would always tell me, "Look, my job is to develop. I build the features. Now you go test it or whatever the tester was, figure it out and then have the CTO do migration and then get it live." One of the things what used to always happen, I would say is almost almost every other task that the QA that was developed actually came back to the developers.