[ BETTER TECH LEADERSHIP ]

Company at startup, company at scale

[ THE SPEAKERS ]

Meet our hosts & guests

Leszek Knoll
CEO, BRAINHUB

Over the last decade, Leszek has developed several successful businesses, among them a software development agency that supports Fortune 500 companies. With the challenges a growing business brings, he observed that stepping out of a tech role into a leadership one brings the need for a different approach. As a host of the Better Tech Leadership podcast, Leszek is focused on bridging the gap between tech and people skills.

Robert Coletti
Co-founder of Cello

Co-founder, Product and Technology Leader of Cello.

Transcript

Leszek Knoll

Have to yeah, exactly. So maybe let's talk about what that might be. Let me put more context into the question. So what specific problem is Cello solving?


Robert Colletti

Yeah, I think a lot of products out there, customer acquisition costs are going up and word of mouth, they already have strong word of mouth that's helping them drive growth. They're looking to make it really easy for their users to refer their platform. And they know product like growth is a thing out there, but they don't know how to actually build it in their product. Especially in B2B SaaS.


Leszek Knoll

Okay, and how do you solve this problem?


Robert Colletti

Yeah, I mean I think what we're trying to do is build something that's like a really simple out of the box solution for any product to just supercharge word of mouth. They can embed a component like an intercom or other components that are out there on the market and then it makes it easy for the users to refer and get rewarded.


Leszek Knoll

You don't have to build it yourself. It's basically a component. It's ready to use. It's super optimized for referrals. You don't have to think about things like that. Plus there's a whole thing to manage those and correct the whole reward process itself.


Robert Colletti

Normally the customers may have to do that themselves, then they could do that. They don't have to worry about taxation, how rewards work, it could be rewarded in multiple countries. We take care of all of that. So that's fine. I mean, what we're seeing is customers are out there, they're either doing two things, they're either looking at what's out there on the market already and there are some products out there but maybe not providing the exact experience that they want or they're building it themselves. In building it yourself, obviously it's expensive. You don't only think about implementation, but the maintenance of it. But also it only works with certain types of products. It works really well for some of these PLG products, like a collaboration product. There's a really strong reason for you to refer someone to a messaging product, a chat product or a collaboration tool. For many other products, users love it, but maybe there isn't such a strong reason to refer someone else. This is why getting monetary rewards makes it more powerful.


Leszek Knoll

Cool. And where are you at with the product?


Robert Colletti

Yeah, we started Cello earlier in the year and we've now launched and we're live with customers already. I would say it's early days, we're just scaling the number of users. But yeah, we have lots of customers that are in implementation mode, some turning it on. We're starting to get the data flowing in and we're already starting to optimize some of the user engagement.


Leszek Knoll

Have you noticed anything interesting in the data that you didn't actually realize before or at the time when we were building the thing, designing the thing or just exploring with test users? Meaning interesting data coming in?


Robert Colletti

Yeah, I mean the interesting thing for us is I guess how out of the box. This whole out of the box versus customizing. I think that's one of the main design principles we're considering and also engaging with customers on. Because I think it's one of these things where customers, if you ask our customers, they love that it's out of the box, but they also want it to be flexible in a way. But if you make it too flexible, then it makes it harder to roll out changes. And that's some of what we're considering now, like how much flexibility and the.


Leszek Knoll

Flexibility is in terms of design. I assume it has to fit the design of the but that also on the feature front as well.


Robert Colletti

Yeah, because we're not a product, we're a product that lives in other people's products. We are not our own standalone product. So anything we do need to we need to live happily and feel like we're part of our customer SAS products. So the things that they like, that we're like an out of the box widget, that's all there. But they also want us to do it with their menus and hooks and really make it feel like the flow is completely hooked into their experience.


Leszek Knoll

You have a technical background in a sense. I looked you up on LinkedIn, obviously, but then throughout your career you were more focused on the product side. And I was wondering at this stage or basically at Shadow, what's your focus around the product? How much time does it take? Is it 100% of your time or your engagement? Or it's also basically build up your time these days.


Robert Colletti

Yeah, my title is CPO, but I'm really better product development and technology as well. Yes. I would say 90% of my time is doing product development, thinking about strategy, what we're building and working with the team. We have product managers also within our team and then obviously great engineers. But yeah, both, I would say, completely hands on with the product.


Leszek Knoll

How is it different than at the time when you were Twilio or Reuters?


Robert Colletti

Thompson yeah, I mean, obviously, early stage startup, it's much smaller team hands on. You have to make really deliberate decisions around what we're prioritizing. So we're actively everything that we're deciding to do is being discussed, engaging with customers on that. And it's almost more important what you're not going to put in the product, that's what you're going to put in at such an early stage that you can pivot and constantly iterate on it. I would say at Twilio or Thompson, Reuters or Affinitive, we had much larger teams, right? So I managed director level product managers that would each own their areas and we had separate scrum teams. So it was really doing things at much more scale. Sometimes we worked a little bit slower, but sometimes with teams who work independently quicker. So I would say it's a completely different scale of what we're doing. Different. Completely different apples and oranges.


Leszek Knoll

Yeah. How was the transition from that to hands on?


Robert Colletti

I love being in the transition. I think if you talk to anyone in Cello, they'll say that they're having more fun than any other time in their career and some of them have worked at other startups also, and very early stage also. But yeah, I think it's refreshing for everyone. For me.


Leszek Knoll

Yeah, amazing refreshing in terms of the impact you have or the flexibility you have or is there any specific factor that you find?


Robert Colletti

I mean, you think that with a smaller team you couldn't have as much impact. But because we're a developer product and we're being integrated in other customers products, that's like a really grateful where there's a lot of scale you can get from that, which is what I learned even working at Thomson Reuters, but really at Twilio, where we were developer products and we were only as good as our customers products. Right. In a way. So I think it's amazing what you can do with a small team and a developer product being a vessel for other customers.


Leszek Knoll

Is there any way you could get as close as you can be? Is there any way to get as close as possible? Is there any way to get as close to the startup sort of mode or attitude to approach in the bigger organizations? Is it possible at all or how close?


Robert Colletti

A lot. I mean, the startup mode, it's all you organize your teams. I think there's a lot of constraints at large organizations that they always try to break down. So things like microservice architectures, scaled Agile framework, you can do things where different teams can run independently. The challenge you get into is there always are dependencies. Either you have to align what you're delivering from a business perspective, otherwise you have lots of teams running doesn't make sense, your product releasing and then there's usually technical dependencies. Like in an ideal world, everything's microservices teams can run. But usually you have platform teams with shared services. Otherwise every team is building duplicate things and those things have to be aligned and that's where things slow down. So it's about getting the balance, get the balance right at bigger organizations.


Leszek Knoll

In that case, aligning those teams. How?


Robert Colletti

Well, we did Twilio or in financial services, we used Scaled agile, safe, probably in financial services, a modified version of it. It's really more of a purist approach. And yeah, we'd have release trains, regular drops where things were aligned across teams. But then within Sprints, teams can do their own thing. So there's certain way, there's dependencies, you deline but then teams can independently release.


Leszek Knoll

Okay, and what did the communication between teams look like? Did they actually directly interact or was it on the level of API? Different companies take different approaches, both.


Robert Colletti

Yeah. So some things it depends on some of the teams. And we were reorganizing, we had like two pizza teams and ten Scrum teams and it was growing very quickly. And other teams within Twilio. So the product that I worked on, Flex, is a programmable contact center with a full experience that customers can customize, they can fully customize it. But it was also built upon all of the Twilio services, all the messaging services, which made it powerful, but that also created this dependency where even teams and other parts of the organization would have to work together. Because we were working on top of the Twilio conversation API, those teams were.


Leszek Knoll

Actually cross functional teams.


Robert Colletti

They would be basically a number of different customers across Twilio that would say okay, we need this reflex or that or we want the ones that API to do this and then they would have to prioritize as well.


Leszek Knoll

Okay. And that's the interesting part for me always, which is how does the objective, what the objectives look like in those kind of big teams? Are they like very generic or very high level outcome oriented objectives or are they more related to features that has to be delivered different companies like different approaches again and some of the teams have high level objectives. Definers we need our customers or we need our users to be able to do this or we want to say change in behavior. But that's really high level, that's not easily translatable, that leaves a lot of flexibility and freedom for the teams to decide. But there's a potential benefit that you leave freedom for the teams to experiment. But also there's a risk based in that mechanism. But also some teams sort of work on that objective on a high level, but then they're sort of translated into more feature oriented objectives. This and this has to be delivered in this timeline. And I was wondering, in those big structures, what approach did you guys I.


Robert Colletti

Think it's a hybrid. So there was more of a strategic objective setting with longer time horizons. It's their own modified version of OKRs. Basically a lot of focus on what the longer term strategy is, where the company wants to go and then individual teams would roll down to team strategy and then you would have outcome based goals but then deliverables as well. I think I've worked in a number of different models and the best approaches are a mix. I think joining two outcome based, especially with different time horizons, sometimes it's challenging. Things take longer to deliver, longer than a quarter. So mixing between outcomes and outputs. Outputs, yeah, I mean, we're now we've experimented with a lot of things and even within six months and had debates on this and we've now adopted basically our own model of OKRs that takes a bit from reforge. I don't know if you're familiar with reforge, but they have this model of you could have inputs, discovery outcomes and outputs and you can then set goals on that. So we still have a quarterly goal which is an outcome based metric and then you do it on a monthly basis.


Robert Colletti

We set the goals that could be any goals, which is I think better for a startup so that we can really supercharge these learning loops. Twilio, we didn't do it as often. Obviously it was a longer thing, but we still did have outputs and outcomes.


Leszek Knoll

Cool. Actually you actually went where I was going with this. So I just wanted to ask you how did you translate that experience into Cello? But it pretty much answered the question.


Robert Colletti

Well, we have this debate with the cofounder, Stefan. We both come from different we have very different backgrounds. So I never did OKRs at a small at a smaller startup that's starting from zero. I did a lot of reading that could even be dangerous at a very early stage. If you use OKRs too rigidly, it doesn't give you as much flexibility. We didn't also want to just have no goals. I think some startups work this way. They're pure because it's a small team. So we started with something not the monthly thing and then we evolved it. So we have a bunch of, I guess, different learnings, different team members, brought different things in where it wasn't just Chet and I, but all the different team members from different companies. They worked like, let's try this. Cool.


Leszek Knoll

I think the funny thing is I rarely talk with anyone who is an OKR purist or everybody sort of like, plays with it. I think it's really like a broad or generic model and the secret sauce is actually making it work for you and sort of adapt to your needs. Cool. That's really cool. I assume that the nature of output and outcome, sort of object definition of objective is the way to engage the entire team into that's, the way to sort of merge them in an emergency. I just want to ask, like, is that the way to sort of engage people in the objectives, not just features? Because that's the tricky part for me.


Robert Colletti

I mean, that's always key. Everyone needs to be engaged in the problem you're solving. And I think outcomes are good at that, but it's deeper than that, right? There needs to be the strategy. Even at Twilio, one of the values is write it down. But it took the Amazon model of doing narratives and really having everyone understand what we're trying to do. And I think sometimes, OKRs, like, oversimplify it down to metrics and even Reforge advocates this, really write it down, really detail so that you get everyone on the same page. At Cello, we don't we're smaller, so we can talk, we don't have to put everything in a document. But we still have this really a lot of engagement around how we prioritize. We have this Miro board, something we call this mega board, where we're looking at customer feedback, hypothesis and risks as well, because you're constantly looking at we're building some things we're not sure about everything we're building, right. Some things we're trying something, we might want to shift it. So we put these on the board, deliver something and then learn from it and then go into the next cycle.


Robert Colletti

So I think this kind of engagement, constantly looking at what we're doing, revisiting it together as a team, build shared.


Leszek Knoll

Understanding, cool and referencing to it very, very often, I guess. So what we have heard in some teams is that, like, there are cool boards out there, but they get updated very fast and you just have to be sort of edit. The thing that you have to play on, I'd say weekly basis or biweekly basis. Like those boards usually, unless you're very sort of disciplined about updating it, reviewing it.


Robert Colletti

I think there's a problem with this thing. It has to be a tool that's useful to everyone, like project management. Then when it becomes even with safe, agile I think we've had that problem with something, when it starts feeling like project management, then it's probably not a good thing. It needs to feel like it's a strategic tool to help teams align.


Leszek Knoll

That's the way to the project management tool.


Robert Colletti

Yeah. Even us, we debate it, we put it in a Google sheet, put it on a Miro board, but in the end, it doesn't matter so much.


Leszek Knoll

How does your roadmap look? Like a car. You go, yeah, that's a good so.


Robert Colletti

We have a roadmap, but it's obviously a startup. We almost think of it as not a roadmap. Right. So we want to think into the future and think about the things that we need to do, but have the flexibility to change it. So it goes we have something that kind of maps out where we want to go two or three quarters down the road, but it's not the roadmap per se. Yeah. And obviously, nearer term, there's things that our customers are asking for, so that's the roadmap, we commit to that and we're going to deliver it, but we also want to work with our customers and get the feedback and then steer and give them the opportunity to steer. There's not two quarters of committed things and trust me, I've worked in that environment as well. And then customers are frustrated that they don't have the flexibility to drive the product.


Leszek Knoll

How do you get customers to be sort of part of a process?


Robert Colletti

We have Slack channel set up with them. Every customer we're engaging with individually at Cello now, as we get bigger, then we'll scale those processes, we'll have support processes and then we'll have to have the ones we engage with more and the ones that maybe are as interested right. In really driving that stuff.


Leszek Knoll

How often do you talk with them?


Robert Colletti

We're talking with them every day.


Leszek Knoll

Nice.


Robert Colletti

They're asking those questions, they're implementing hooking into their Stripe, doing this and that. So, yeah, we're learning from them and they're learning from us.


Leszek Knoll

Let me just go a little bit one step back. You say it's not a roadmap per se, but why wouldn't you call it a road map? Sorry.


Robert Colletti

Roadmap to bigger companies. You expect it to go into customer and say, well, what are you delivering, right, in the next year? And you go in there and you sell that and customers then say, Great, I'll take your product and implement it. And there may be a bunch of things that they ask for that they wanted to have but they don't have yet. So you want to publish that? I think the negative things about roadmaps is that you're basically future planning everything. Right. And it's also hard to predict how long it's going to take to deliver things and then by committing to things, you don't have the flexibility, then things change, right, yeah. Business problems change.


Leszek Knoll

The bigger the uncertainty, the closer you look, I think.


Robert Colletti

Yeah, it's more predictable in a larger company, then, you know, when you have 50,000 customers asking for different things, it's more predictable. You don't need to be so flexible at a startup. That's not the case. Right.


Leszek Knoll

This one is a specific but actually I need your advice on that. So we're trying to figure out what is the right what we're trying to figure out what is the UX role like so far? We thought about UX team member as a Swiss knife sort of generalist, with a broad, extensive knowledge about research design, UX design, but also UI design. Like, it's very, very broad. And we started we are at the point where we need to sort of make decision whether we are going this way in the future or should we sort of split it into researchers or UI designers specific roles. And I was wondering what's your experience in that field?


Robert Colletti

Yeah, and my experience goes back years ago. I think the roles evolved a lot. And you can't have one. It's not one size fits all, right? It depends on the organization, the product, the experience. I would say years ago, the old school way is product managers, business analysts. It's much more of a funnel right approach. UX designer was seen as someone that's doing visual design or designing workflow.


Leszek Knoll

How do I designer word sort of labels that rule that's it right.


Robert Colletti

And even when I was in definitive Thompson Reuters, I managed a team there that was large one time before I managed it, they were a large team then they were bit unloved, they were reduced in size. And then I took them over and we grew that team a lot back from a smaller team because we had to sell internally. Like what is UX? And I think UX now is more user centered design. We really have designers that understand the customer. They start with the user, with the problem, and then how you design the product is almost secondary. But they're really strategists analysts. They're thinking in terms of the customer and not just the design of the product. So I think the new world is product manager, user experience, designer, and then engineers. They're all sitting at the table. It's not a thing coming through. They're basically understanding the customer problem together and coming up with solutions together.


Leszek Knoll

Yeah, but there's one thing for me that it's also difficult to figure out because I think they're sitting at the same day table, but they're not always at the table. Or no, maybe let me rephrase that. I think that people more concerned about the engineering part are more thinking about right now, what we have to deliver right now and are slightly considering what we're going to build in the future. But the UX designers are basically the product. People are more about what's coming next, what we are building right now and what we've built before and how do we validate it. So there's also this context of not just strategic thing, but also in terms of time horizon. I think on the one hand, you have to Validate What's been built, whether it's actually Solved The problem or It's pushing us for What We Are building Right now, because there Are many things and discussions at the table happening Right now, how We Are Building things. And also they need to be one step ahead. So that way, basically, the process continues. They're thinking about the next step in the roadmap. That's how I think about it.


Robert Colletti

Generally, yes, I would say, but it's not always the case. I think it also is the type of organization Some organizations are more business lead. And then you have business teams. Product teams are more strategic. You look at, like, Twilios or Google's of the World. I think they're more the tech teams that are there have just as much influence on the strategy. Sometimes Product Managers are almost second fiddle to tech leaders in the Team, where it's almost interchangeable. So I won't say it really does depend on the organization and how that is.


Leszek Knoll

Okay, for sure. Let's have a look at how you guys do it at Cello in terms of specific features that you are trying to build. How far are you as a product person working with the UX designers? How far in the future? How much in advance are you compared to the engineers? Are you thinking about this?


Robert Colletti

This just came up. We discussed this in our retrospective. Just yesterday. I think at Cello we provide some visibility, but we could probably do more. I think in terms of that was the feedback is the more we can know about what the strategy is It was almost not what you're saying. The engineers do want to know a bit more into the future so that they can think about where we're going. But generally they have a good understanding of not just what we want to do now, but thinking about at least where we're going with certain things, like our multitenancy model, how our customer data even down into, like, the platform features. I think there's a pretty good understanding there. That's not just a superficial UI thing. But we can do better. This is something that we're going to.


Leszek Knoll

But what about the product people themselves? You Have this duality or There are multiple models regarding how to set it up. But I was wondering sorry for getting too much specific, but I'm really looking for that answer. So, for instance, let's consider a UX person or a product person. There's a feature that is being built to accomplish an outcome right now, but I assume you're more or less ready for the next one to be built. Or Is It how much in advance the UX people or The Product people are compared to? Is it weeks? sprints.


Robert Colletti

No, we don't. We do things. We write the more detailed requirements right up against just for the detailed ones. And I think this is again, it's a philosophical thing. You don't need to spec everything out. But In Terms of the flow and what we want to build that we're thinking we're ahead, going back to the menu, the way we integrate with our customers products, that we can't just say, hey, we're going to try this now or try that. So we are looking at the different options. We're going to engage with customers on that. We're going to have more of a strategic approach. We'll talk to the engineers as well to see the technical feasibility of these different options. And then in parallel we're iterating as well. We're looking at what cloud we've just released now and so that we can learn so that we don't have to build everything before we get into customers hands. Okay, so it's more of a hybrid approach, I would say. We're not looking quarters out, but we are looking at least two months of what we're going to build on a feature. We have a bit of a strategy around it.


Leszek Knoll

Cool. I think in many cases this is difficult to get it working right because you don't want to focus on right now, on today only. You want to look in the future. You want to decide some certain things on the spot, but also you want to see the direction where the thing is going. So the decisions on the spot support the future things and you just want to balance it. That's tricky.


Robert Colletti

That's what I'm well, also when I'm talking to customers, right, because as they get their hands on the product, they use it. They're asking for certain things. I think as they use each iteration with Cello that we deliver customers, there's one thing to show a prototype or talk about something in abstract terms. Some of them to actually see Cello working inside of your product and see your end users engaging with it. And then from there you're going to get different feedback. So this is where you can look ahead. You can validate, but you actually have to iterate with a working product.


Leszek Knoll

Speaking of validation, how scientific are you in terms of validating things?


Robert Colletti

When you say scientific immediate.


Leszek Knoll

Yeah. I mean, there's a hypothesis and there's things like that.


Robert Colletti

We do that. We do our research. So the early days of Cello, we were very clear about the personas that we wanted to engage with. So for us, we have growth managers that are buying our product. We have developers and product managers that are integrating and then we have end users that are they're the real users of Jello. Right? There are customers. Customers. So, yeah, when we did the early research, we wrote it down. We had a research plan. We had the key things we wanted to validate. Like for example, how much would rewards motivate someone in the VDP space? Right? Do we see different types of end users and different behaviors? A lot of them said, yeah, definitely. Some of them say, well, I would like to have donations instead of gifts. Right. So we did a lot of research but yeah, we were pretty structured about.


Leszek Knoll

Our approach and right now with this sort of prey to building things but right now when you deliver features, how sort of discipline are you about validating things? Whether the features actually bring value or are they used at all?


Robert Colletti

I mean, generally we're not in this mode of feature mode, but we're thinking more about what are we delivering, what problem are we solving, how does the whole thing work together? I think this feature I've worked in places that we're more obviously focused on features, outcomes, but also features. Sometimes you can get into this feature factory mode which can be so a lot of we're doing is deciding not what not to deliver as well, just important of what we're actually delivering. So yeah, I would say we're not thinking about things as much as features, but thinking about the whole how are we improving the whole experience, each thing that we drop.


Leszek Knoll

Okay, yeah, sorry, I meant that by I package actually solution into the features. So for me it's a combination of those two actually features, solution to the problem. Cool. Speaking of scientific approach, when we spoke before you told me the story, how you figure out the name for the company? I find it super interesting and if we could recap on that yeah, that was fun.


Robert Colletti

The branding. We went to an interesting exercise to try to find her name. We had a previous name that we started with, but it was always like a working name and I guess there were different opinions. Should we leave it, should we try something new? So we said look like everything else we did with Jello, probably we can find something better. But it's not easy to find a name, right. Everything that you pick, you have to look at domains, whether it's taken or not and then what is the perception of the names? So we actually did more of a structured approach where we did research on certain names, we sent surveys to investors, to potential customers where we did we use a very scientific approach to test like the feeling wheel how evocative a name is. We went through a whole structured kind of approach which is I guess we're a small startup, many don't do it, but it was a good learning experience in the end. Do you think we like the names that we got?


Leszek Knoll

I liked the part where you sort of told the story. You compressed it a lot, but there were so many details that I find interesting. You spoke also with investors and you sort of wanted to engage investors, but you were also following a certain direction that you had you played with the names, you had a name, but you also validated different approaches and solutions with different people. That was super interesting.


Robert Colletti

Yeah, we did some of the things that we looked at for end users, like the emotion wheel. We use different things. You basically have a wheel when you say just think about if you test the name in context, then you get a different thing. But with brands, you're going to create the brand. Right? So a lot of times if you have an open vessel name, you can just ask someone, what do you think of when you hear the name Cello? Or you hear the name whatever windshield wiper, whatever the name is. Yeah, exactly. You can be very grounded in something or it could be more open ended and you just get what people feel, whether it's optimistic or the standard ways of testing this. And then you can see that this name definitely has certain names have very strong connotations with one thing, and you're like, well, maybe you want to pick something that doesn't that's more open.


Leszek Knoll

Are you happy with the name?


Robert Colletti

And again, it's like you're never sure. You feel so you feel unsure, I would say, when you pick the name. But then as you start to build a brand now, I think we love it and we're loving it more and more by the day, especially releasing the website and seeing the brand come to life. We work with an agency that did a great job on actually introducing the logo and the name and all of that. So, yeah, it's really nice. I was reading at the same time I was reading the Shoe Dog book, the Phil Knight book on Nike, and.


Leszek Knoll

I just read it at the same time.


Robert Colletti

And he was talking about how they came up with the name on Nike and how painful it was. It's good reading. If anyone have anyone going through this dilemma and all of that painful process of naming it's a good book to read those chapters.


Leszek Knoll

I didn't read that one, but it comes up every now and then.


Robert Colletti

It's like, maybe other name was like Dimension Nine. I forgot what other option it was before they picked Nike.


Leszek Knoll

I've got a tricky question for you regarding the leadership role, because it's full of paradoxes or different tradeoffs. And my question is related to sort of this trade off between trusting the team and also knowing where the things are and how to balance those two so that you leave the space, but also you know what's happening, you know where things are going. You don't over control. I assume that it's absolutely different in an organization like Twilio because you're talking about different problems on a different sort of scale. In Cello, you're basically involved in, say, daily basis and the things that are actually happening. So it depends on the context. But I think you hear, like, you know what's happening.


Robert Colletti

Yeah, obviously I'm in decisions on detailed decisions on all things with Cello, but even in large organizations, I'm the type of leader that's involved in the detail. I mean, sometimes my teams are like, get out of here. We don't need you in this meeting looking at the user experience design. We'll come back to you and get your feedback later.


Leszek Knoll

That's actually cool feedback, by the way.


Robert Colletti

That's one thing I say. I say I like to get involved. Kick me out. Please kick me out if I get too involved. But I think leaders it's important that leaders are there to support, to be involved, right, and also be able to do the job themselves. Having experience, I have like a technical background or having done product management, then I think it's easy for your teams to then come to you with problems, with like specific things to solve and being there and not losing sight of the detail. Right. I think a behavior that's not great is when managers only look for the problems, right? And they go from problem to problem, like hit and run managing style, right. If you can try to just be there for all of your teams and be there and really try to stay close to the detail, even if you're not micromanage, you don't want to do micromanaging. But when they need help, you need to understand so then you can get involved. It's tricky balance with more teams. Obviously you can't understand every detail, but I think you need to try understand the platform, how things built, how it works, being able to demo things, all of that.


Robert Colletti

I think sometimes leaders lose sight of.


Leszek Knoll

That, but at the same time, be careful with engaging too much.


Robert Colletti

Well, yeah, you don't want to be you need to give team members room to grow, to make their own decisions, and they're going to solve things different ways, especially if everyone brings different experience to solving the problem. I think that's a mistake I made early in my careers, that I would go there and try to review and think that because I have more experience than certain things that maybe I can kind of steer it. But sometimes teams make their own mistakes or they bring their own experience. They come up with much better solutions than you ever do it. I think you only learn that from mistakes.


Leszek Knoll

Yes.


Robert Colletti

Honestly. Right?


Leszek Knoll

I mean, some of the best things that happened at BrunoB are where the team actually had full control and one of the best initiatives originated there.


Robert Colletti

The biggest two is making mistakes. I know it's like a cliche, but I think in a large organization, sometimes that's harder. Everybody play at lip service. Like, okay, try something. It's okay to make mistakes. But there's a lot of risk management and you have lots of customers and no one wants to miss steps. So it becomes harder for individuals to learn and try things. But that's how you learn. I mean, I think any of us, if you look back in your career, in my career, I'm sure the biggest learnings from where you make it. So you have to give the teams room to do that.


Leszek Knoll

Sure I'm the person who learns this way. I think this is the most powerful way to learn. When we were building startups of our own, I'm saying about me and my co founder, we could read so many books about validating stuff. Still we build the thing and then we try to sell it. So it's like you can read a lot and still make those same mistakes over and over. Or maybe not over and over, but you have to basically get your ass kicked every now and then. Yeah.


Robert Colletti

It's not even big enough at them as mistakes. Right. It's always learning their learnings and their pivots. Right?


Leszek Knoll

Yeah.


Robert Colletti

I think if you're smart about it, then you don't have to make them so big and dramatically smaller. You can make them into smaller pieces and risks and do it smart. Right?


Leszek Knoll

Yes. I think, like, off topic, but I think maybe it's a European thing. Maybe it's Eastern European thing. Maybe. But I think there's a big pressure of failure. I think it's a cultural thing, I think, in the US. Which is there's a less sort of risk of failing or fear of failing. I think it's just more natural to fail.


Robert Colletti

Yeah, I think it's one of those cultural things that people I mean, I'm not a cultural expert, but I guess I grew up I grew up in New York in the US. And I lived in Europe now for many years. I do think that is a different thing. Even my kids, it's something that I try to instill into them. It's like the American way of just trying great things. Not a bad thing, right? Sometimes it is there, but I'd say we shouldn't generalize.


Leszek Knoll

Right? Yeah. But I think it's more and more Polish, German or Czech companies are going this way and being competitive. And being competitive, actually, I think the fear or lack of fear of competitive actually built in. It has to be built in. Otherwise you're not that competitive or innovative. So I think that proves that we're going there.


Robert Colletti

But it also has to do with how companies are funded. There's more, like, for the structural things that actually have to do. But it's not just culture. It's about risk taking. Right. If your investors expect you to try to hit a home run, that's a different profile of investor that changes how you operate in different countries.


Leszek Knoll

Right, exactly.


Robert Colletti

In the US. This is a very unique thing right. With Silicon Valley and how investment is done there. So yeah, I think some of that, which is now in Europe as well. Right.


Leszek Knoll

Is there any book or podcast that will help you in the hard times when you were struggling as a leader or that actually opened your eyes to something or something valuable or change your mindset in a bit?


Robert Colletti

The Reid Hoffman podcast. I forgot the Netflix guy.


Leszek Knoll

The Netflix guy?


Robert Colletti

No, he's sorry, I have to look at my yes, just go ahead. Look at my favorite podcast list, right? Masters of scale. That's a good one.


Leszek Knoll

Yeah. Nice title.


Robert Colletti

Yeah. So, yeah, he's the one that started he's PayPal Mafia, right? He started LinkedIn.


Leszek Knoll

That's okay.


Robert Colletti

Yeah. I think the earlier ones, obviously, they've done it now for a number of years, but the earlier ones are great. He interviews like Brian Chesky goes into a lot of different leaders on how they've scaled their company. It's a really good one. I listened to this before I was even a Cello. Even for larger companies, there's just so much there to think about and use in any size organization.


Leszek Knoll

Yes. I think for us, it's super interesting. It's a completely different way to lead a company of 50 or 60. We haven't seen much. We are at 100 right now, around 100 people on board. But it's oh, man, I can't wait. What sets 200 people on board? It's going to be completely different. I assume. So. I think there's steps to it. So thank you for that recommendation.


Robert Colletti

Yeah, definitely. I love Reforge, too. I think, like I mentioned earlier, I think I've been involved with them for a few years now. I think their stuff is really good, well thought out. They've grown a lot over the last few years. They're really good resource. A few of us have been involved at Cello and we go back to the materials. Right. Constantly.


Leszek Knoll

Yeah. There are those materials that you go back to.


Robert Colletti

Yeah. You go back to it and look at it. And again, like we said, you apply it in different ways, but you can go back and say hi. Okay.


Leszek Knoll

Yeah. It's like a bible of business in a way.


Robert Colletti

There's a lot of things there. Yeah.


Leszek Knoll

Bob, thank you very much. It was a pleasure. Cool stuff. And really valuable.


Robert Colletti

Yeah, great. Awesome. Do it again sometime.


Leszek Knoll

Yeah, let's do it again. Let's do it again. We'll be here in the first quarter of 2023, so I'm holding accountable. Words sounds good. Thank you very much.


Robert Colletti

Cool.


Leszek Knoll

It's very cool.


Robert Colletti

Yeah. Good.

Explore similar episodes

Jason Wilcox: Overcoming Hiring Hurdles in the Era of AI and Emerging Technologies

In this episode, Matt interviews Jason Wilcox about the challenges and strategies for hiring and managing teams in the era of AI and emerging technologies, focusing on cost-cutting, vendor collaboration, and evolving leadership roles in product development. They discuss effective remote leadership practices, critiquing the “build fast and break things” philosophy for larger organizations, and stress understanding end-user needs to minimize unnecessary iterations. Jason highlights the significance of soft skills and ongoing training for leaders, as well as the opportunities and challenges posed by generative AI, including hiring mismatches in AI and machine learning, and the anticipated adoption curve of AI tools in development.

listen now
Yariv Adan: Leadership, Innovation, and Investment in the Age of AI

In this episode, Yariv Adan discusses his career in technology, emphasizing privacy concerns and his contributions to global products like Google Assistant. He explores the challenges and advancements in conversational AI, advocating for systems that understand user preferences and seamlessly integrate with existing applications, while remaining optimistic about overcoming foundational challenges. Yariv also highlights the importance of investing in early-stage AI startups, focusing on team capability and innovation, and critiques current data modeling practices and security issues in healthcare infrastructure.

listen now
Imke Gaus: Empathy and Excellence - Crafting a Collaborative Tech Culture

In this episode, Imke Gaus shares her journey to leading the software engineering competence center at Volkswagen Group, discussing her career path from startup roles to her current position at CARIAD and the mentors who influenced her along the way. She highlights the integration of software development in the automotive industry, emphasizing customer impact, reliability, and security in digital experiences, while also exploring CARIADs focus on enhancing safety, sustainability, and comfort through a unified software stack.

listen now
Antoine Fourmont-Fingal: Beyond the Basics - Elevating Product Management Through Adversity

In this episode, Matt and Antoine explore the critical role of mindset in product management, discussing experiences from Lazada and Alibaba. Antoine highlights the importance of aligning commercial and product development goals, stressing collaboration and nuanced objectives beyond revenue metrics, while also emphasizing market relevance and flexibility to avoid rigid frameworks. The episode addresses challenges like tech recession impacts and team layoffs, advocating for resilient teams and personal development.

listen now