On this week's podcast, we're joined by Alex Polyakov. Alex is the CEO and Founder of Project Simple. Alex and his company are on a mission to make Teams better by building the first ever AI Agile Software Management Platform and solving the ever-growing list of problems and frustrations that come with Jira. Go see what Project Simple is all about by visiting them at projectsimple.ai
...or connect with Alex on LinkedIn!
Enterprise Agility Coach Om Patel and Product Manager Brian Orlando sit down with Alex to talk about his journey from Software Engineer to CEO and Founder, the frustrations of Jira, and many, many other topics.
0:00 Guest Intro
0:33 Alex's Journey
3:01 Raising Funding
4:44 Fear of Failure
6:08 Learning New Skills
9:58 Sponsorship & Mentorship
12:35 Rotating Roles
13:36 Making a Difference
15:25 Strategy and Problem Solving
19:15 Start-Up Success Factors
20:58 Investing
23:57 Early Investors
25:48 Jira
30:07 Better Concepts and Systems
33:06 Better Ways of Working
36:40 Delegation and Ownership
38:47 Visibility
40:40 Wrap-Up
= = = = = = = = = = = =
Watch it on YouTube
Please Subscribe to our YouTube Channel
https://www.youtube.com/@arguingagile
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Alex, Alex you're a CEO and founder of your organization. Alex. Welcome to the podcast. Thank you. All right. Was like Alex and I we started corresponding online and started talking about the podcast and our mutual well, I don't know about mutual, but my hatred of JIRA. Pretty mutual. Okay, our mutual hatred of, sorry, I don't want to put words in your mouth, our mutual hatred of JIRA., but now that Alex is here. I find it super interesting about your journey from, engineer to CEO, because I consider that somewhat rare. Yeah, and Alex, you're a serial entrepreneur. You've done this more than once. Yeah, I guess stupidity is a big answer, but yeah, I, I, I was never intentioned to be running the company. And as a matter of fact, my first experience. It wasn't really my choice to be the CEO. It was two technical founders. We got together. I actually went to work for my partner at that time. He was running a different company, but that folded. I guess he forgot to tell me it wasn't well funded. But when that folded we were sitting there and we decided to launch something else together. But by that time, he went through so much stress that... He was like, listen I think because you took a job of a product in a previous startup, I think you have a better way to communicate. So why don't you take the reins and be the CEO? And that kind of spawned off the next phase of my career which is interesting in many ways. Not only was I a tech guy, engineer. But I'm also the guy that had to learn how to sell, the guy that had to develop the vision of a product. Now, I always had a knack for that, especially in user experience, love doing that, used to be a full stack guy. Now, I wouldn't touch the front end with my uh, with a six foot pole. But , there were certain things that were extremely difficult for me and because, uh, being an engineer, it's sort of more of a exact science, but becoming, becoming a CEO and especially of a startup, you have to wear the hat of perception is reality. So I had to go through and educate myself on a lot of things. And I had to almost learn how to change my own persona depending on who I was communicating with. And that took, that took a little while, but you know, there are certain things that came out positive out of that because I'm not a natural business person. Because I'm not a natural product person. I'm more of still the engineer. I have this thing in me called the prep work. So I had a chance to pitch the startup so I would learn my routine. I would learn my slides. I would work on them for hours. And we actually won. I had to pitch in front of like 800 people audience. Won in the first place. Got the votes. It was pretty exciting. And that kind of built a lot of the confidence moving forward. That gave us a little bit more of reinforcement. That we were recognized and now we could rely on it to build a business. So that's kind of how the previous started, the startup began. I ran it for three and a half years. It exited in 2020. I wasn't there when that happened. But that's a kind of a different story. Awesome. So let's kind of just take a slow mo walk through that, if we may. When you got into this role as the CEO, what did you experience as the, the, the top things that really bothered you initially that you conquered and how did you, how did you win those battles? Good question. So number one thing that bothered me is taking money from my early investors. I was always very forward thinking. Frugal and responsible taking money and even though I knew it's a business and they could burn through it, I had the personal responsibility that I could not let those folks down so they've supported me and I felt responsible for every dollar that I spent, , which is very contrary to how people raise capital right now. There is some access to easy money and if you know how to pitch certain things very well, you could be very lucky. Plus there's connections that you can have. I did not have that starting out, so I had to sort of go from the bottom. That's interesting. You actually stood through and stood true, I should say with your scruples, right? It's somebody's money, but you felt responsible on how that was spent? Absolutely, yeah. I, that is so refreshing to hear, because you don't hear that very often. Well, so here's the thing, right? What most people don't recognize is being a startup CEO sucks. I made a lot more money being an engineer. My ex wife didn't work at that time. We were a family of three and I had to support everybody and it was, it wasn't easy. So you're writing these checks for quite a lot. You're paying salary to the developers, you're doing all these things, but you're, you're writing a check to yourself and you're almost crying. You're like, whoa, whoa, what's this? Right? So there were many times when I was like, why am I doing this? This doesn't really make sense. But you couldn't let yourself you couldn't let the investors down anymore and I didn't view them as investors. I viewed them as friends that helped me out to get started. Now that's number one. Number two the fear of failure is huge, right? Because what you're doing is you're putting yourself out there. There's a lot of emotions. And what happens when you're, you're, you fall flat on your face? That disappointment is significant. You have to scrape yourself up from the ground. You have to build your own ego back up. And what, to do what? To go back to a previous job? I mean, that's tough, right? So there's a lot relying on you because again, you're seeing yourself in your own shed of light, right? But then others see you as the successful person. Oh my God, you just slapped the CEO title to your LinkedIn profile. You must be, you must be a world conqueror. It doesn't happen that way. You know, and I think the third one to me, what constantly kept me up at night is my own team. When you run your own team, what I yes, I could fail, I'd figure it out. But I didn't want my team to fail. Having that on my conscious that they would need to look for jobs, that their families would be impacted, is, is probably something that bothered me a lot as well. Especially because I had good guys on the team, good gals on the team. And I always took that to heart my failure was failing them, not vice versa. So, I know a lot of people don't think that way. The loyalty factor right now... Is different than it used to be about 30 years ago or so. But you know, certain principles are are still there. That's awesome. There were two things in your story that I honed in on one was the difficulties in coming out of building things for a living and coming into product management that's one, that's one path. The other one is... You had to learn coming off of development teams and . Now you're at the center of everything. You have to learn that each persona you're interacting with, you have to change your communication style , to really make an impact or to get through to that different individual or team or a business or whatever, like I'm real interested in first of all, how you even became like self aware enough that you, oh, oh, I have to make this change in order to make the most impact to elevate my communication. And then how you actually. One about learning the skill and changing your communication method because I I think of lots of people I've interacted with on development teams that Number one they never even became self aware enough that they knew that this was a shortcoming and number two Where would where do you even go to learn this skill? Yeah. I think observation and mentorship are the two critical things. Now, there's a funny story. Here I am working in, as a developer, maybe in the third or fourth year of my career. You know, must have been early 2000s. And we have a company picnic. And in this company picnic, the entire company is like 250 people show up. And I, and the CEO sits right across from me. Now, I... Poo my pants, right? Oh my god, a CEO sitting in front of me. And I, I, I was quiet. I didn't say a single word. I mean, I mean, this is a CEO, right? And I'm like this... You know, junior developer. And there was something, and I wanted to ask a question, and I said, Mr., Mr., and his last name. And everybody chuckled. He's like, did you hear, did you hear Bill? He called you Mr. And that was the funniest thing ever because the amount of respect for somebody in that position was so huge. You know, here I am just a few years out of college. It's very different now I guess maybe that's just how we were raised as a generation. Right now, people feel a lot more comfortable talking to pretty much any level. For me, that, that had to be acquired. Maybe, maybe there's a little bit that has to do with my background being immigrant, obviously. But. When I got to lead the company I was shy asking the right questions, kind of going back from the background. And my mentor in sales by the name of Rich Geis, unfortunately he passed away, which was a huge shock, but he was a sales trainer and, but he taught me beyond sales. And one of the things he said, he said, Don't take anything big about it. You're a business person. The other person's a business person. You're just two people having a conversation. You know, don't treat it like you have to lift somebody up, or they have to lower yourself down. You are on the same level. You are both business people. True, that person may be running a larger company. You're running a smaller one. Doesn't matter. You're both people solving a different business problem. Was music to my ears, so I started, actually early on I would craft titles for whoever I needed to communicate to, and that's something you have to do. If you talk to a VP, you better be a VP. Cause they're not going to talk to a CEO. If you're a director, they'll talk to another director. You're on the same level. So there's something subjective about these things, but you kind of have to pull, pull any, any trick you can get out of your hat to get the conversations going. But later on all it is is just mutual respect. You all have a job to do. And you know, the, the sooner you feel like you're the same level and the sooner you try to. Communicate at the same pace, the easier it's gonna be. People that do that are rare, first of all, we, I think we can agree on that, right? Coming from a development background, and being able to communicate at that level, to your point, being self aware that you need to change your style, to suit the the occasion, so to speak, right? And the second thing is how do you hone those skills because you don't practice them, you don't learn them? You, you never taught those in your role, no matter what your role is. Right? Well, where, where I was gonna go is, I was gonna say sponsorship, I work with a lot of product managers who it's it's their first product management job, role slash job, right? And the, the, the thing that I will always coach them to say is you need to find a sponsor in the business that can get your foot in the door because like, well, welcome to doing, you do sales now, but you've never done this in your career before. Now you do sales. In the realm of a startup, it's pretty clear that you don't sell things. You don't get customers to consistently use your product. There is a chance that in the future you're going to roll off your entire development team. You have to, you have to, you have to fire coworkers basically. Maybe you're not firing them, but the company will the company has to run out and make a sale to maintain the payroll. Basically, most of these product managers have never been in that spot in their career. Maybe this is like a generational thing or whatever. This is like early in my career, this is the way the company was. I don't know. But the point is, partner with these people, ride along with them you know, be involved in their world and understand what they go through. So you can start absorbing. Some of that skill I can, I can, I can segue here a little bit. I mean you know, it goes alongside of what you said. I always wished that I would have somebody that I could be a right hand man of. Unfortunately, I never found anybody that I could be a right hand man of. And I would have been the best right hand man. And I would have picked up and learned a lot from that person. But I just never found the match and when we launched the business I became essentially the front runner, right? So I had my own right hand man to help me out, but there was nobody I could follow. And that makes a huge difference because there's a lot of companies and a lot of startups that are founded by multiple tech founders. But not a lot of them can, can get out of that and somebody stepping up to be running the show. But that's a very unique skill set for an engineer to, to know how to sell, know how to market, know how to talk. Beyond just. engineering and beyond the product, that's, that's huge. An engineer that understands the culture of sales, the culture of marketing that's, that's, that's huge difference. I mean, there are different people. We're all built different. We're all wired different. We have different motivations and to learn how to motivate everybody and how to tie them all together. I Think a lot of times it's not even skill, it's luck. Certainly the opportunities are not there for people to gravitate up into other areas like this. I, I don't know, other than like maybe these companies that do the, the 12 month round robin type of thing where a newly minted person comes in and they're just seconded each of the areas for a month or two at a time, but even that's just superficial because you don't have long enough to develop a relationship with anyone where they can be your mentor or sponsor. Right. But yeah, companies don't really, they stay, they compartmentalize people into roles here's the interesting thing about rotations. When you're rotated to observe, that's one thing. When you're rotated and you're allowed to make decisions, that's a totally other. You see rotations based on observation and being a helper. You don't see rotations when you're allowed to take charge. Right, right. Those are the ones. So if I was in your shoes type of conversations, right, I would be doing this. If more people had that opportunity, I think they would learn and start to respect what the other, what the other side is doing. Right. And we had this conversation earlier that engineers generally is an underappreciated class. Why? Well, think about any company event who gets most of the celebrations. The accolades. The sales, right? Yep. The next one is the marketing. Worst case scenario, implementation team, customers, customer support, right? The engineers, we only get the heads up and by our immediate manager, if we solve a critical issue, right? But something needs to really just be completely blown up. And we have to save the day and only then do we get a pat on the shoulder, go, okay, good job, right? Yeah, and also assuming that , your leader in that segment of the business has the forethought to include you not just saying like, I solved this issue or my team, right? And it just hides the name. spEcial thanks goes to, right? Yeah, you're right. Often it's like the team I led solved this. So the focus is on that person always. Exactly right. Yeah, exactly. That's what I call master leadership. That's the opposite of servant leadership. But that's where startups are unique. Because let's say you close that big customer. You're 20, 30 people. You're going to get your whole team together. You guys are all awesome. I couldn't do this without you. I mean, that's where the whole culture is, is completely different. You go there because you actually feel like you're making a difference. I mean, look, for everybody that worked in a corporation, or and was a tech guy, your software may not have ever been used. You know, there could be years when you were working on something, sight unseen, and maybe the problem was interesting, maybe not so much, but a lot of times, you don't have that level of exposure. Here, you actually feel like you're making a difference. Yeah, I agree with that. You know, I think the structure is not so hierarchical for those startups, so it's easier to have the Connection points with everybody and leadership, right? Flat organization. Let me let me pivot to, you're moving to product management. Since I am a product manager, I will bring up the product management centric point about finding difficulty in product management by pointing out it's either either starting with developing things and backing into your strategy or starting with without a product vision by just starting by starting and then backing into your product vision You had strong opinions on sometimes you just start and then you figure out your strategy and your vision and all that stuff. So, good question. I like all my good questions are in the form of statements. Yeah, yeah, yeah. It's a good question in the form of statement. So here's a funny thing. When somebody said, after my departure from the startup, somebody said, well, Alex, are you going to launch something else? And I said, you know what? I'll consider this definitely, but I think I'm going to go with an easier problem to solve. All right. Now, background wise for anybody listening my startup was an insurance, not the space you want to be in. If you want to be moving quickly it's a particular space. It's tough to break into. There's so many different challenges. But I think from the product perspective, I don't think there's anything correct that I did. I think there was a lot of gut feel. A lot of it was gut feel. I always looked at features this way. I mean, when you're small enough you're obviously building a core functionality and you're, you're delivering it. But then what happens? If you can't stop, if you stop, you're losing your marketing edge. And if you lose your marketing edge, the big giants are going to pass you. And people copied us. You know, I built the competitors, I spoke to the number one leader on, in a space we were in. They controlled 85 percent of the market. And when they found out about what we were doing, they dangled a lot of like Hey, let's integrate let's type of thing, but they wanted to play around with what we had. And me being an idiot, I just gave it to them.. And then before you know, it is a conversation that goes like this. Hey, you know what? We decided not to go with your solution. Why? And then we find out they have a competing offering. So while they were playing around, they were actually developing. People do steal ideas. So what do you defend in your ideas? You defend by. Thinking farther, right? So people can copy what you have now, but they can't copy your thoughts, your dreams, your innovations, your concept of what you'll have tomorrow. So the challenge is if you're building a product that already exists and you're just making a better version. It's easy, but when you're building something new, you can't really stop. You have to invest in things that you're going to do tomorrow. And that's a lot of gut feel. There is no data that says somebody is going to use it. There's no data that says somebody is going to need it. You have to place a bet. And we have this, this talk inside of the company all the time. You know, do we concentrate on this feature or that feature? I can't say we always made the right decision, but in the end, the exit proved that we did, right? So we built a a very good platform for visual collaboration, documentation, and insurance. And that was powerful, that was recognized, and we had some big name customers. And that proved it's worth, but early on. Nobody knew it was going to be, it was going to be correct. It's a gut feel. You have some indicators that could be false indicators where they could be positive. And just because somebody says, I like it, doesn't mean that they'll implement it. Right? Like we, we, we ran into it. We, we sold our solution to a couple of companies and the people really didn't use it much. Why? Well, it turns out that some people just didn't feel like using what we had. They felt like traveling was a better option. It's not the cheapest option, but it's better individually for that employee. And so here it is a better offering, but implementation will take time. And I think, I think any, any startup that's making decisions Need to evaluate whether it has the metrics to scale and prove it's worth. There's obviously opportunity to test some waters and maybe you could, you could take a thin slice. Or maybe you just go for the big deal and just say, look, we have this thing that nobody else has. Sometimes you just have to do what you have. I don't think there's a formula. See, there's three factors of startups succeeding or failing. Startups that succeed, they had the right product, at the right time, and a lot, a lot of luck. Right? And that's really the only thing that's been, that's been proven. Those are the three factors that made startups succeed. The rest, I think I'd attribute that to luck. Interesting. Three factors. I think this might be fodder for a future podcast. Just talking about startups and what makes them succeed, what makes them fail, and what makes them just basically muddle through. Yeah, just like what we talked about AI, right? And I, I said AI and product management, right? And AI and product management predicting which product is going to be better or which features should we build, build or deliver. And I said, okay, well, that sounds great. What if we had AI that told us that, but then guess what? That doesn't really go well with our reality. If AI is screaming at you and says, Hey, it's going to be, and it's going to be bad. You're not going to succeed. And you succeed. What happens? Cause AI is just AI. It can be wrong. It learns from examples. So same thing about you know, us as human beings, there are so many startups that succeeded when everybody else said they failed that. They were utter success. So I don't think there's anything predictive about that. I think some just should have never been launched in the first place. And we can talk about the investment money that, that, that beefed them up and created an image and unfortunately didn't play out. Or we can talk about the actual examples when somebody grew companies organic way was wildly successful. I mean, SurveyMonkey is a prime example. They were homegrown and acquired by Intuit. But you know, they did a tremendous job just building their business and in their own way. Took them longer, but hey, just there's many, many, many ways to build a business. Yeah, let's let's dip into investing. That's a, that's a good conversation to go into right now because I feel the best investors are, are I don't, I hate to use the same term while I'm talking about it, but the best investors are invested in your roadmap. So, so I would correct that, that a little bit investors don't invest in products. They invest in companies. They don't care what the product is. What they care is about the KPIs that you can demonstrate. They care about the monetization, if there is any. They care about where that will take you. It's not about the product. At that point you know, they'll trust you to make the right decisions, to build the right feature sets. They don't really, they don't really care. Now, they'll help you if, if they're savvy enough. And a lot of investors actually, for that reason, they only invest in companies that are in a niche that they understand. They're not just gonna go and, hey, you know uh, invest in healthcare when they have no idea what healthcare is. And I've heard that before. They say, I'm investing in the individual people running the company because I believe that they... Can drive whatever the you know, whatever the product revision or whatever it is, but then but then there's also KPIs, right? So what are the indicators that you could show? So here's a funny thing. You can show so many different things Early on the first thing you teach a startup is hey, listen, do not Do not pitch your revenue to any investors why you don't have that much Right? I mean, even if you think you have more than enough, you probably don't have enough to impress. So that's, that shouldn't be your number one , success factor. What, what, what can you pitch? You could pitch a lot of things. Transactions, users signups you name it. There's a whole set of different KPIs that you could track to show success. Now, whether those metrics that you pick are there just to raise capital, which sometimes you you got to do what you got to do to pitch and other times you'll actually have a valid business that it shows and it's proven. Right. And it depends on which stage, what kind of investor is going to make that decision and how solid you are in representing their data. You know, I don't think the due diligence is that detailed. I think the due diligence in a lot of ways are superficial, right? So pre agreed fiction. That's kind of what we call it. You know, you're basically, it's kind of an old standing joke. What do you, what do you call a sales interview? Is where one guy is lying about where he's going and the other one guy is lying about where he's been. Right? So it's, it's kind of a very simple thing. In the end, you just have to convince enough that you know what you're doing and you have a solid, solid strategy and approach. And that the end result actually justifies the means, right? But I agree with you that when you look at the strategies as a whole of the investors, if they're investing in multiple companies, a lot of them spreading the investment kind of all over the place you know, like butter on the bread and they're really like roulette table. Yeah. Like roulette table. Yeah. One is red. One is black. One goes on the four digits. One goes here. There. And a lot of them are just basically calculating the odds. Hey, listen, all I need is for one of them to succeed and I'm golden. Right. I think investment is difficult in many ways and people are betting and it's good. But I think the toughest thing for us for startup founders is always the early investors because the early investors they will write personal checks and you have to build individual connections. Right. You have to be very personable. You have no KPIs. It's basically pure personality. If they like you, they'll do it for you. How much of it is personality? How much is story? I think both. I think you gotta have both. For me I think it's the humble nature of how I approached it. But I wasn't actually raising capital at all. I, I asked for advice and I got money. So it's actually a standing joke. You ask for money, you get advice. You ask for advice, you get money. And actually with engineers, it's interesting because yeah, I want lots of advice. Pile, pile on good advice. And actually with engineers, it's you ask for decomposition. Right. And you get nothing and you ask for estimation and you get a decomposition. That's right. That's right. So yeah, it's, it's exactly right. Actually, it, it's interesting how certain things work behaviorally. But yeah, I mean, some people just get lucky that they have a good, good story, great delivery, good personality. It also helps if you've known somebody for a little while and you're not just leaching for the investment, especially if, if you, you've really had, okay, so if you really have no KPIs, you don't have anything, it's really early. And you have a good story, hopefully and you're just saying, look, in six months we'll build up mindshare. That's all we'll do. We won't have a product yet. Please invest in us. Right? It's a tough one. I call it selling by proof and selling by dream. Selling by dream. I like it. Right? So I mean, there's really only two options. Yeah. You either, you either sell before you have it because you can draw that immense picture. Right. Or you can sell because you have proof. Right? Yeah. And it's easier to sell by proof. Sure. But it's tangible, but, but it's, but it's harder to get there. the original thing where we linked up was we, we bonded over our I'm not going to say hatred. That's too strong a word, but actually that word is just right. Oh, that word is just right. Okay. Well, we, we, we bought this our, our mutual, our mutual dislike of a certain Atlassian product. It's it could be any Atlassian product that starts with a J and could be, could be Jira could be, could be any Atlassian product. Tell me what you most like. Jira or tell me what you most dislike about Jira. Okay. Most like is about 20 something years ago when I first used it. That was pretty good. You know, it was just a ticketing yeah, it was a ticketing system and it worked great. Yeah. It was a internal installation, but it was much better than a company, by the way, it was much better than all other web web based apps that we had access to, to manage all that stuff. The usability was there. It was very nice. Income again, in comparison with what was out there at the moment for a corporate tool, it was quite nice because we were used to launching all kinds of windows based desktop apps to do the same thing, built on Microsoft templates and all that they looked ugly that they were bloated and here it is a web based tool. It was just pretty awesome. Now I think what it morphed to today. To me is really, really strange. You know, it's number one in development, as a tool. There's really not a competitor for JIRA. And we can talk all about the competition in this space. We could talk about linears and shortcuts. And all of the other ones but history has shown that despite these competitors, there's only one competitor that... Try to take the piece of it and it became Atlassian. It's called Trello, right? But all of them are identical. There's not a single thing. They're all glorified, express Excel sheets. And I would even call them. They're all sales forces of project management, right? So they're all these pieces you can configure and you can do anything you want. The problem is. If, if you're executing a discipline, and I call Agile a discipline, why are we using these generic things that actually are responsible for... The largest number of anti patterns and inefficiencies within the process. You know, most people don't know how to implement Agile, right? And we can discuss it all over and over. Big company, all separate pockets, all separate podcasts. And the challenge is, is that. It never morphed into something helpful. Instead, it went the other direction. It compromised on its values in order to expand one size fits all and became bloated. I mean, I had somebody say, say this to me the other week and say, if you need a project to launch project management you're doing something wrong. I found that so interesting. Like to implement project management, you need a project. That's that's kind of funny. Yeah. And like a a hundred percent in agreement about like they, Atlassian has taken many, many strategies and you'll see many, many people online getting. It's like, oh, they took Atlassian through IPO and they expanded Atlassian, this and that and this and that. Well, they did that through compromise to say, we know how Agile software development is done. We just don't think that's where the money's at. So we're going to let you bend Agile software development to encompass all these other things and these large organizations that really don't. I want to develop a tool suite for people that don't really have to learn how to do Agile software development. They can just call it Agile software development in name and use our tool. Which is still a ticketing system. That's insanity to me. Well, then on the other hand, you have to applaud them because those investors that backed that company, they made a ton of money. They made it successful. Successful business. They're still buying companies. It's the only product that has a I effin hate you website in its name. That I know of, okay? And we all know about it. website. It's the only solution that I know of that everybody using it hates. Yes. And the ones that don't basically claim that you're not using it right. And, and, and those people are making money because they do configurations on it. Yeah, there's, there's a, yeah, there's a configuration for that, yeah, exactly. So, so yeah, and then, and they're selling configuration services. So yeah all in all, I think it's bloated in many ways. I think it should go away because they're really not pushing the envelope. But they built a humongous mousetrap. They built the integrations, they've made it so heavy people can't switch out of it. There's all this data, you put it in the cloud now, people don't want to mess with it. So, they build it into a big, big massive trap. However, there's a way to get around it, and that's very easy. All of these projects that are being executed in JIRA and what not, you can just cut off. It comes next sprint, just drag. Whatever the elements you need for that sprint only into the new tool and start over. And there's no loss. You can't search for anything in Jira. Actually, it's funny. There was an ad recently that popped popped in front of me , and it was like confluence, and then it says 71 percent of users search less in confluence. I couldn't resist, I left a comment. I said, those are the same 71 percent that can't find anything. Well, I had a chuckle. I took a screenshot, sent it to my team. But ultimately I think, I think if we are to change and you and I, we connected on the development and product management kind of aspects and we can do better. We can do so better. There are ways that we figured out how to make teams more efficient. There is a new discipline called product management, which now talks about metrics based decision making. And There's all these techniques that evolved over the years. They're all kind of rooted out of agile that came out into a different way of product ownership, as opposed to these big project management running the show. And it's all exciting. There's lots of things, but we still haven't figured out how to. build stuff right. Right. And mostly this goes to larger companies, small companies, one team, no big deal. Yeah. Two teams, a little harder, but still not as challenging. Three. Oh boy. Yeah. Right. And it gets exponentially more hard. Yeah. And can we do things differently? Yes, we can, but we have to start with something a little, a little different. And that's kind of the mission that I took upon ourselves. Again, launching the next startup, right? And primarily around. Not only building better products, but also making engineering teams better. What if there was something that was all about execution, but it actually helped build teams better? I was in Warsaw last year. Kind of by accident ended up at this LESS conference. I was in a Agile conference in Prague before, and my team was in Warsaw, so I went over to see my team. And I'm walking on the street and, browsing LinkedIn, and there's a picture. Hey, I'm here at the conference, and I look over, I'm right next to that building. And I was like, whoa, cool. So I go in there and I... I got inside in the let me participate in some of those discussions. And one of the discussion was very interesting. It said if we're all talking about teamwork, why over the past 20 years we've given our engineers the tools to work away from each other's into individual silos. We gave them slack, we gave them email, we gave them a thousand different asynchronous communication tools. And now we, but we keep on preaching teamwork and all of that stuff. So, I think there is a way we can bring people together. We just need to, again, revisit how we've done things. So interesting you say that. Talk about one or two ways that we can do things differently going forward instead of these tools that allow people to just work by themselves in in silos. I think the big one is swarming. So in engineering we always Well, we should be working to break things down. And the pattern of people not pulling but being assigned work is the one that needs to go away really badly. Amen. Right? It stops everything. So it stops the self organization of the team. Then Decomposing the work is something engineers are really bad at, hence my comment previously on, you ask to decompose, they do a bad job, you ask them to estimate, you get a decomposition. Some of it you don't need the estimate, but just asking for one gives you better results the next thing that needs to go away is the Micromanagement. Right? So, I have a story. This was again in the same company where I called the CEO and mister. And we had a QA. This kid was brilliant. Okay, so back then I worked you know, as a government contractor, and this kid memorized a 450 page manual about with a lot of business rules in it. Amen. Nobody would do that, right? And he just read it. And. You know, he became the expert. Everybody came to him to ask questions. Well, one day we're showing up for work and we find out that he's been reassigned. I'm like, you took our best guy and you just, and everybody was complaining. Well, this wasn't my first lesson. Because he said, well, guys, you don't realize, but he was pulling all of your weight. How so? Well, why didn't you read the manual? And then it dawned on me. Yes, that's right. Because we had this exceptional, talented kid on our team, he was actually carrying all of us by learning what we should have learned in the first place. So we became lazy. So plucking him out from the team made us step up. Keeping him inside would have been a safer bet, but we would have not have grown because we would have still relied on that individual. And as, as interesting as it is, that's how I look at the micromanagement people are like, you have team self organization and that's what the micromanager says. Well, nobody's going to self organize, right? Not as long as you keep getting, being micromanaged to self organize, right? You can't delegate ownership. You have to facilitate it. And, the short of it is... If you want teams to organize, you have to tell them direction and let them figure out their own way. But we're so compelled in this legacy way of working that we keep on doing micromanagement. And so if we build a tool that actually... stops micromanaging, then that's actually going to help the teams to come together. And the question is, how do we build such a tool? Well, this is again, a thought of, it's very easy to build such a tool. You only micromanage when you, A, do not understand where things are, cannot comprehend the next steps to get there, and cannot visualize. It basically comes from a lack of visibility, transparency, and trust. You put the tool that gives you that, not as a report, or some kind of a composite of reports, but you put it as a front and center way of visualizing the information in progress, and now you've just solved the problem that you can scale back to micromanagement. I love that. That's one of the things that I basically encourage my teams to not write status reports of and and the like just put a dashboard in there and it's gonna show you everything. And that's where teams balk a little bit because they're afraid that it's gonna show them everything. The good, the bad and the ugly can't improve what you don't see. So just put it out there. If it's ugly, let's talk about it. Right if it's good, nobody's gonna talk about it. This is gonna go. Yeah, that's expected like There are two things you said that I wrote down They were there were so like one thing was like just blew my mind and I didn't Stop us. I want, I didn't want to stop the conversation, but like you can't delegate ownership. You have to facilitate it. When you want to delegate something like generally you delegate something to a product manager and then I as a product manager, I would be I would be aghast. That's my five dollar word for the day. I would be aghast. Aghast! I'm like an old Hollywood star from the 1920s. I'd be aghast if anybody from the business walked to up to one of the developers on my team and said where are we at with XYZ item. Well, I'll give you, I'll give you an example of a delegation versus ownership. Okay. All right. Okay. A delegation goes like this. Hey I'd like you to draw a user experience diagram for a pop up that occurs after you click this button, and here's the text that it gives you. That's a delegation, right? An ownership is like this. Hey, listen, our users reported that when they're doing this and this, it's not going according to plan. And what I'd like you to do is think of a way that we can solve this. Yeah. Right. Come back to me with three examples. Right. Yeah, so I want to finish the thought before we go back to what I was saying earlier. Right? So what you're saying between the difference in the difference between delegation and ownership, ownership with ownership, you're expressing intent, essentially just saying we'll figure out something and then let them come up with the how you're not steering them in any way with with you again, can't delegate ownership. So I can't I can't. Promise that the person I shared this with will take ownership, but when I phrase it with the questions that they have to discover, chances are that they're going to be caught up into the questions of discovery that that will draw enough energy for them to own anything that falls out of it. They'll build a relationship with that problem a lot closer and deeper, which is going to be reinforced with organic thought process, right? As opposed to, I have to do this so that you, you have a good check box to give me on the bonus increase or something like that, right? But, but as far as visibility in across the org, I think one thing to recognize is, and, and we can, we can see it by the ways that senior leaders in the organizations work. A lot of them, they don't care what's happening until there's a red flag. Or until they can't comprehend or can't get a direct answer. However, the way companies work a lot of times is very imprecise. I'm a CTO, a CEO says, Hey this sale that we closed, we got to realize this revenue. So onboarding of this customer by such and such date. How are we doing with that? The CTO is going to turn around and go to his directors to VP, right? VP is going to go to the directors. Directors are going to go to the managers. So that's how we're actually collating that information. Okay, the alternative to that, somebody's gonna open up a tool and go, it's 75 percent correct. What does that mean? Nobody knows, right? So we were 75 percent there. These are the tools that are being sold right now, right? A place where you get to... Move around Gantt charts and update a lot of, a lot of percentages, which have no idea where you actually are, right? So you, you have two avenues. You can either go and ask for reports and then you collate the PowerPoints. Or I'm going to use this tool that everybody lies to anyway, right? And I think, I think we've grown quite a bit as an industry. So isn't that something that we can come up with a scientific way or I mean, and the good, the good answer is yes. The right answer is yes. I mean AI is on the cusp. It can detect a lot patterns and trends and things like that. And we're, we're going to see that transition. So. You know, hopefully they'll take away from the legacy bloatware that we're, we're using in, at least in, in the engineering. I hope so. I can't wait till the end of Watermelon Reports. Oh, I thought you were going to say the end of JIRA. The end of JIRA, love that too. We're going to, we're going to have to wait a long time for that one. Well, I'll be here patiently waiting. We explored a ton of stops along the journey. We did. Including, including like the, the communicate. Like I feel, I, I feel like I wheel a whole podcast back and just talk about changing communication style and learning that skill. I still want to talk. A ton more about that investment the tools that you use a journey along the way figuring out what problems to work on. There's a million different things, Alex, that I, that we didn't get into . Definitely. There's a, there's future podcasts coming on some of those, at least I made some notes. But yeah, thank you so much for for coming and lending us your your wisdom. I don't know if that's a lot of wisdom. It's a lot of pains that I'm just sharing, but Thanks for lending us your pain. That's where most of the wisdom comes from. Yeah thanks for the invitation, guys. I, I really enjoy being here, and I guess for anybody watching if you have questions you know, it looks like we could probably get a little bit of help from you telling us what you'd rather hear about. There's lots of topics that were discussed and you know, if anybody's at all interested, I'm happy to connect again and explore anything else. So we would love to have you back. If you have any questions, as you said, put them in the chat below and don't forget to subscribe and like

