Consulting Spotlight

Michael Bernzweig (00:02.935)
Are you ready to unlock the secrets of consulting success? Tired of sifting through endless noise to find actionable insights that actually move the needle?

Welcome to Consulting Spotlight, your weekly deep dive into the transformative world of professional consulting. Your host is Michael Bernzweig, who in 1998 launched Software Oasis as one of the first platforms enabling businesses to download, license, and deploy software instantly across their networks with a single click. Today, Software Oasis has evolved into one of the leading communities where businesses find top consultants across the USA and Canada.

Each week, Michael sits down with industry titans, innovative leaders, and game-changing executives to bring you exclusive insights you won't find anywhere else. From emerging methodologies to market trends, Consulting Spotlight delivers the strategic intelligence you need to accelerate your consulting career and stay ahead of the curve.

Join our growing community of consulting professionals and decision-makers. Subscribe now on your favorite podcast platform and visit softwareoasis.com/subscribe to get our bi-weekly newsletter delivered straight to your inbox.

Get ready for weekly data, trends, analysis, interviews, and insights that will propel your consulting career forward.

I'd like to welcome everyone to this week's edition of the consulting spotlight. And today we're in for a real treat and an insightful conversation with Vigandas Plasis. He's the founder and CEO of Cortip. So with that, I'd like to welcome you to the podcast.

Vygandas Pliasas (00:23.15)
Thank you very much, Michael. Hello, everyone. So as I was introduced, I'm a founder of Cortip. I have services with executive consulting. I provide a fractional CTO service. I'm really happy to be here with you in the podcast.

Michael Bernzweig (00:43.808)
Yeah, it's really, it's wonderful. I can see from some of the questions that have come in from the audience that we absolutely have a lot of people interested in your solutions. So I was hoping we could start off by having you share a little bit about your journey, you know, maybe how you got into the type of consulting that you're focusing on and a little bit about what

the services of Cortip include.

Vygandas Pliasas (01:19.18)
Okay, how far back should I go? To the very, very beginning.

Michael Bernzweig (01:22.595)
as much as you think is relevant to help the audience understand your journey. It's always interesting.

Vygandas Pliasas (01:29.48)
All right. OK, so my journey started from developer. So I was working on various large projects. Most of them were US-based projects, Germany-based projects. And I changed a couple of companies. And

Then one day decided that I'd like to work remotely. And then I switched to remote work, which is actually more challenging and requires way higher discipline, I'd say. So the journey started as a freelancer, as a contractor. And it happened that I really quickly jumped through steps of career, let's say, and

became team lead, then became engineering manager, being in R &D manager's position, then CTO, fractional CTO, head of engineering, and so on. And when I was growing, I realized that this is how I can help companies, that I noticed a pattern of what I'm

I can really do well with those companies. And that was getting things right, fixing the process of engineering, of product management, how idea travels from stakeholder mind, maybe from the client into product planning, into scoping, into designs, and then goes to engineers that gets

developed and then released. So basically the full cycle. And then also I noticed that there's another service that I do practically every time with every client is finding proper people to join those teams that I'm actually fixing. it is like executive consultancy being like a fractional CTO.

Vygandas Pliasas (03:49.193)
and also executive recruiter.

Michael Bernzweig (03:53.397)
sounds really exciting and it sounds like you're helping out at a lot of different levels and different organizations and and that that makes me wonder are a lot of the organizations that you're working in funded pre-funded series a series b could it be anywhere along the way

Vygandas Pliasas (04:15.566)
Usually it is a bit earlier stage up to series A. A lot of clients are SMBs that has another main line of business. And then they've noticed that they have a good tech that other people want and they start building SaaS for B2Bs. And then, you know, some

gets some issues, to start struggling a little bit, and then I come in and help them to streamline all of that.

Michael Bernzweig (04:53.781)
Interesting, interesting. So it could be typically SMBs, but could be enterprise level clients, maybe a division of their organization or something like that. So for the clients that you're working with, like what are some of the most common challenges that you encounter when companies are transitioning from more of a agency model to an in-house development team or something on that, that, that idea.

Vygandas Pliasas (05:00.386)
Yes.

Vygandas Pliasas (05:23.628)
Most common problem is that there are a lot of ideas. There is very long roadmap. And execs, comes up and are quite creative and wants everything yesterday. And that makes development team, product team, if there's any like that, to struggle a bit. There are sometimes that

Founder says, okay, now I need this and next day they say, now I need another thing and then after a week, so where's the first thing? And it's like, you know, like a circle of doom, you know.

Michael Bernzweig (06:01.431)
Yeah.

Managing the priorities and the expectations, right?

Vygandas Pliasas (06:08.576)
Yes, yes. And then there are some people missing. There are some great developers and they are placed into head of engineering position and they are not used to, let's say, manage engineering managers. They are not used to manage team leads. They don't know how to train them, what to advise them because those guys have directly managed people.

and they are having their own issues. so the higher you are, the worse problems you get to solve. Because if you get notification, it's usually something bad. Because if it's easy, it gets solved at individual contributor level or client manager level. But if it gets to you, it's something bad, really.

Michael Bernzweig (07:02.179)
Right, no that makes a lot of sense. It's interesting how it is, you know, it feels like such a unique journey for each organization, but the reality of it is a lot of these pain points and challenges are very common across organizations.

Vygandas Pliasas (07:20.906)
yes, yes it is.

Michael Bernzweig (07:22.975)
Interesting. how do you initially as you start working with an organization assess the company's technical maturity and what is your approach to creating a roadmap for improvement along the way as you're working with these organizations?

Vygandas Pliasas (07:42.732)
I always start, I try to keep it simple. So I start with somebody who hired me and then who they are managing and then I go down. So it depends how large the organization is, but on every level, people say different things. On product area, people say one kind of things. Let's say, our developers not develop.

Delivering properly nobody's testing right and and so on and you go to talk to engineers Then you get our product doesn't describe what we need to do. There are no requirements and it's and so on and you can even dive deeper and then you start asking let's say team lead so how What's up, know where those problems come from? What's your take on that and they are our engineering manager doesn't train us. We don't know

approach it we don't know how to push back

Michael Bernzweig (08:41.239)
A lot of times it's really identifying the real root of the problem.

Vygandas Pliasas (08:46.582)
Yes, yes, correct. And then you basically get all the problems. It's sometimes like 30 page report, all the findings, know, and diagnosis what's probably an issue. And then I go back to stakeholders and discuss all of that. You read it and we...

pinpoint what are the most effective low-hanging fruits, what are the most strategic issues that we need to fix. And basically then I start preparing a plan how to fix it. And again, involves iterations like interviews with the same people. I present them options, what could be solved.

listen what's their take on those problems, how they see it. Maybe somebody will say, that's not a problem. That's a problem. There might be some new things coming up. And basically iterate, iterate, iterate, and talk with everybody and get the overall vibe and try to get to the root cause.

Michael Bernzweig (10:04.875)
Obviously, that's important because you can't can't move forward on fixing things if you don't know what the real problems are so that Definitely sounds like the the correct first first step so it sounds like over the years you've worked with a whole range of clients and I'm sure you've had some successful outcomes some not so successful outcomes and Obviously you're always aiming for success, but I was hoping you could share with our listeners maybe

an example of a client that you were working with that you're particularly proud of the outcome and where they were at before and maybe after and, you know, successful or not successful, you know, whatever it is, but just maybe an example just to give our listeners an example of what you actually do day in and day out.

Vygandas Pliasas (11:00.334)
Okay, of course. I'm really proud of a client. They are still the client, so we work still. But on a bit lower capacity, fortunately, unfortunately, I did my job well, and I'm not really needed that much anymore. Yeah, so the problem was that they had the budget, they had

Michael Bernzweig (11:20.483)
It happens, it happens.

Vygandas Pliasas (11:30.414)
a couple of agencies hired. There was a head of engineering, there were some project managers, and the goals were to get things delivered because they weren't and the budget was burned. it is quite a big company. They have the budget, but it was not used effectively. So I stepped in.

I've worked with head of engineering, worked with project managers, and basically switched from agency approach into in-house teams. So we changed who works how many hours. So there were some part-time key people. We switched them also to working full-time. I worked a lot with head of engineering to get the guy into

executive chair. So to start doing more strategic decisions, less coding, more teaching people how to approach problems, how to think about various problems and let's say plan careers for those people, how to potential leaders and get them into team lead positions to motivate everybody and basically how to look

for long game to get everybody trained on the product, on the problem area so they would know what they're working on really well and would start coming up with ideas themselves and fix everything themselves. it would become easy to everybody to work.

Yeah, we achieved that and they even spend less than on those agencies. And they basically caught up with multiple years of depth of releases and they fixed everything and continue doing all that.

Michael Bernzweig (13:44.769)
And you know, the bottom line is, know, that's what you're trying to achieve is a dream outcome for the client. So, you know, obviously it may mean the end of your relationship with them, but obviously it's going to lead to, you know, positive referrals and the like in the years to come. I think that's, that's the kick.

Vygandas Pliasas (14:03.342)
The door is always open. For example, if they would decide to scale, it would be probably safer to get some advice, which won't be that many hours, actually, but then to just get to the right direction, double check some ideas, and then move forward.

Michael Bernzweig (14:26.807)
Yeah, no, and that's great. I I think that was a big part of obviously what I was hoping to hear. so as far as like a methodology, do you have a particular, you know, core methodology that you use for evaluating and optimizing existing engineering workflows, especially in companies with

I'd say established but inefficient processes.

Vygandas Pliasas (14:58.414)
Well, first rule, never rush because it scares people, it's dangerous, don't rush any decision and don't start brainstorming when talking with somebody who hired you because you might brainstorm incorrectly. Yeah, don't guess. So with engineers, it depends what approach they chose.

where usually the first question is to whoever gives tasks to them, what was your estimate and what's the result? Surprisingly, it is very rare that anyone would track the original assumptions versus how long it actually took because as soon as it gets done, everybody switches to the new thing.

It's rare to get into retrospective and see how it was planned and how it was done. Maybe the planning is incorrect. That could be the reason. Maybe communication of where we're planning it to the upper stakeholders is incorrect. Of course, like engineering, there might be issues. can check on GitHub. You can check pull requests. You need to make sure that

the lead of those people is actually working with everybody and checking the pulse. What's the mood? How everybody feels? they not burned out and they still know what they are working on? A lot of things.

Michael Bernzweig (16:39.427)
makes good sense. you know, obviously, some of these projects, I'm sure, you know, take quite some time from from beginning to end. And while I'm sure there are other projects that move along faster, you know, they're very, very straightforward. How do you, as you're working in different organizations, how do you

Vygandas Pliasas (16:51.756)
ass.

Michael Bernzweig (17:05.613)
get buy-in from different individuals within the organization? How do you avoid getting resistance from individuals within the organization? Are there certain things that you find work better and not so well?

Vygandas Pliasas (17:24.758)
I'd say it's unavoidable. You will get it more or less. I think, well, my approach is usually reach for consensus as much as possible with everybody involved because, well, you need to ensure that everybody in the team understands what needs to be done.

Michael Bernzweig (17:28.631)
Yeah.

Vygandas Pliasas (17:52.782)
and what's the goal, what are the benefits? Does it mean more work for them or does it mean easier work for them? It depends. if they are able to share their mind on the plan, it's easier to make the plan that business would achieve the goals and everybody would more or less, not 100 % of course, would get also what

they would expect.

Michael Bernzweig (18:24.429)
Sure, no, and I think that that makes a lot of sense because obviously it's better to have allies than enemies, right? It's gonna help push things forward.

Vygandas Pliasas (18:33.55)
Usually people sense that something's wrong, so they are aware. I try to keep everybody calm and we will fix it. I just need your help.

Michael Bernzweig (18:38.221)
Yeah.

Michael Bernzweig (18:45.667)
Yeah.

Yeah, no, that makes a lot of sense. The other thing that we, one question that we had coming in from a lot of listeners, so I'll share with you. What are your, I guess I would say, critical metrics that you recommend clients keep track of to measure the success of their development processes, and how do you help them implement these measurement tactics?

Vygandas Pliasas (19:20.886)
Success of development. first prop. Well, I usually tell everybody you need to count bugs to know how much issues you release into real world and check the effects, how many you capture before the release. How are you estimating and how much you put into the roadmap versus how much actually gets

done in that same quarter. It would show how well you are planning and how well you actually understand what needs to be done and how long it would take. issues, defects and deviation from expected timelines would indicate potential issues and how all the requirements are communicated, how it's landed from

Product side and stay hold us into engineering.

Michael Bernzweig (20:25.187)
Got it, and that sounds fair. And are there systems that are suggested to measure some of this after things have come through the process, or is it really just looking at the structure of the framework of how everything is being implemented?

Vygandas Pliasas (20:53.268)
So it's quite the big.

I'd say fix. It's not usually one person's performance update. It's multi-department cross-functional people or teams, like organization. I think the best way to understand is if your stay-hold is smiling. They start smiling.

Michael Bernzweig (21:06.147)
Bye.

Vygandas Pliasas (21:28.482)
If the stress levels decreases, if people are less angry, means you start to manage expectations. You start to understand each other better. You start to deliver faster. You make less mistakes. So your clients are happier also. So your support personnel is happier. Everything starts to line up properly.

Michael Bernzweig (21:53.923)
So here's a question I missed that came earlier from where you were giving that example of the client. So one question that came in from the community, how do you approach knowledge transfer and documentation in your consulting engagements to ensure lasting impact after your involvement ends on a particular project?

Vygandas Pliasas (22:21.824)
good question. I usually...

Michael Bernzweig (22:24.897)
That's what I thought. That's why I went back to it. I thought it was great.

Vygandas Pliasas (22:27.246)
So usually it is in very bad condition when I start, you know, if it was good, it would be a good indicator that I might not have what to do that. So, well, my approach is not maybe not that much oriented on the documentation itself. I had focused more on getting the roadmap items

properly described so we would know what was supposed to be done and what were the requirements. And I always try to reduce the risk and try to involve more people into knowing the domain, the functions of the product so there wouldn't be no person who is only one who knows some specific areas.

So it's not super convenient. It's a painful to switch people on some tasks. Of course, I'm talking about the relevant people, let's say developers, but that gives you some protection. if somebody leaves, somebody gets ill, anything could happen. So the knowledge stays. And if you backfill, that is somebody to at least lead the...

show the direction where to get started. So it's not like completely empty. For documentation and agile environment, it's sometimes complicated to get it right. One quarter it might be one structure, another quarter you might have another designs, facelift, it's again different. So high level roadmap descriptions, details in epics.

If you use Jira, that kind of stuff definitely, but writing help guides, not my area.

Michael Bernzweig (24:34.877)
Yeah, no, no, that makes sense. It makes sense. So I definitely wanted to come back to that. the other thing I was wondering, so are there strategies you recommend for companies who are, I guess, struggling with transition to remote first development teams, particularly in terms of communications and collaboration?

Vygandas Pliasas (25:00.286)
yes. So if you go remote, it's fine. If you go on site, it's also fine. If you go hybrid, that's where you will get issues a lot. It's very easy to mess up things. I have a story. So I was working remotely and I was managing people who were in London in office.

Michael Bernzweig (25:15.062)
Interesting.

Vygandas Pliasas (25:27.874)
And they were key people that were leading other people that also I was managing. So that's a weird mix of remote and on-site team. And then we have meetings. It's like operating on quite strict regime. On the calendar, we have like various synchronization calls, all hands, and planning, and design reviews, all of that stuff.

And then we have the meeting, but in the office, a boss comes and they grab the people, say, let's go drink coffee or something like that. And you're sitting here waiting, so somebody will show. No, not going to show. That starts to mess up a lot of your agenda. And they get back. They say, can we have a call? But you have another call scheduled, so you can't really just drop those other people and go.

Michael Bernzweig (26:15.811)
Sure.

Vygandas Pliasas (26:24.194)
get back to the original call. But if it's completely remote, the difference from the office is that you will never meet at the coffee machine. So won't have any chit chats and you won't see the mood. So you need artificially have calls on the calendar. You need to have group calls. You need to have one on one calls. You need to have

at least one call with group of people for random things. Let's say coffee break call for 30 minutes, something like that. And it has to be quite strict and it occupies a lot of the calendar. It is harder, but if you get used to it, it's an idea. Operate like this. I've been working remotely before it was popular before COVID.

So kind of got used to it. But it is different. You need to be really methodical, and you need to be strict. You should not allow anybody to start missing the calls. And I would really recommend to somehow make sure everybody's using the camera so at least you see a bit of them. Because if people

Michael Bernzweig (27:46.168)
Right?

Vygandas Pliasas (27:50.038)
stop using the camera, the communication gets kind weird and it's not too good. But it's very doable. I specialize into building that kind of themes.

Michael Bernzweig (28:04.001)
Yeah. So, so a lot of times the challenge is not a fully remote team or fully onsite team. It's that hybrid.

Vygandas Pliasas (28:11.478)
Yep. And if somebody is used to have ad hoc meetings, let's say talk and solve the problem with the remote setup, you cannot just get it solved. It's very hard to just get on the call and figure it out. You need to plan for it.

Michael Bernzweig (28:28.065)
Yeah, yeah. Understood. So I guess I wanted to wrap up by asking you this. So obviously you've had extensive consulting experience over the years. What are the most overlooked aspects of scaling a SaaS product that companies should pay more attention to?

Vygandas Pliasas (28:53.282)
Most overlooked aspect of scaling. Hmm.

Vygandas Pliasas (29:02.676)
If the company gets funded, they start scaling faster. And at that moment, you need to be in a position where you have already figured out your blueprint on what works.

Michael Bernzweig (29:23.031)
Yeah, so you have to have a game plan before you start pouring money on a good idea.

Vygandas Pliasas (29:26.37)
Yes. you need to... So when the team is small, it probably could be a bit weird to have the roles like head of something, manager, lead, most of something. But if you get used into the rhythm of that structure on how you approach problems, how you make decisions,

how you work with people, how you train those people. When you need to scale, it gets much easier because you already have the structure which works. You basically copy paste. So one, let's say, engineering manager can have 10 teams under them.

Michael Bernzweig (30:15.627)
It is very interesting because a couple episodes back we had the founding partner of Mendoza Ventures, Adrian Mendoza on the podcast. you know, what was interesting to me, the whole world of venture capital and investment and angel financing and VC financing was a whole other world I was not familiar with. And, you know, he explained how, you know, many,

angel investors will invest in an idea when it's still a concept and they haven't quite found product market fit but you know most VC firms really just want to work with solutions that have found product market fit even if it's early and where they can just invest additional capital to blow up an idea and get it

Scaled, you know, and I think that's that's where they fit fit best and it sounds very similar to what you're describing there because I think a lot of times, you know, if an organization has not found that product market fit, they tried to scale too quickly. think other kinds of bad things can happen. So I think it's really a matter of finding that perfect balance. Well, you got

Vygandas Pliasas (31:12.749)
Mm-hmm.

Vygandas Pliasas (31:36.35)
I've seen a huge company hiring like crazy and nobody knows what's going on. Join and what I'm supposed to do. Good luck, figure it out.

Michael Bernzweig (31:52.331)
Yeah, exactly. Well, the goddess I really appreciate your taking the time out and the deep dive on on consulting and everything that you're doing over there. And, you know, for any of our listeners that would like to get in touch with you goddess or his team over a Cortip, we'll a link in the show notes. And for anyone that would like to keep

Up to date with all of these episodes and the latest going on here at Software Oasis, you can subscribe to our bi-weekly newsletter at softwareoasis.com backslash subscribe. And thank you so much for joining us on the software consulting spotlight today.

Vygandas Pliasas (32:39.192)
Thank you very much, was a real pleasure.

Subscribe to our bi-weekly newsletter https://softwareoasis.com/subscribe/ to stay updated with more insights from technology leaders and transformation experts.