The full transcript

Oleg

Hi, everybody! Welcome to Devico Breakfast Bar! Here we speak with different people involved in the business landscape, share their expertise, delve into the latest tech trends, and explore the ins and outs of IT outsourcing. I'm Oleg Sadikov, and today I'm excited to have Daniel Bartholomae, entrepreneur, founder, and tech enthusiast. Don't forget to subscribe and hit the notification bell so you don't miss our new episodes. Hi, Daniel! Could you please share a bit about your journey into the tech world, from writing your first program at the age of six to becoming the founder of optilyz?

Daniel

Hi, Oleg! Thanks for having me. Just to quickly correct that I'm not actually one of the founders; I'm just a managing director at optilyz. But I'm also the CTO and taking care of the tech there. So, happy to talk a bit about the tech journey.

Like you mentioned, I had quite a lot of contact with computers quite early on. My father was a developer actually, and we had an Atari ST at home, which I used to work in Pascal ST from quite a young age. I’m not sure how young it is compared to others, but around the age of six, I started working a bit with it. Don't expect this to be any good. I barely got programs to even compile and run. It sparked the joy in me to be able to type in something, and then something happened. And during school, I did a bit of that. During university, I actually focused on mathematics and physics, which both had some computational aspects to it, but I wasn't doing as much there as I might've been doing before. And then my very first job was as a management consultant at McKinsey, where I wrote almost no code at all. There was, I think, one project where I worked slightly with someone else and basically looked over their shoulder for some code-related topics, but most of my time there was spent on helping bigger corporations to set up small companies, to solve the innovation challenges, and to implement the innovation strategy. And after being in consulting for a while, I realized that consulting is a lot about sales, and I don't mind sales, but it's not my main thing that I like the most.

I thought about what I actually like the most. And the realization came that what I like is to build organizations that do things without me, also build stuff that does things without me. And that led me to where I am now, which is basically in startups, typically in a CTO role. Because in startups, you build organizations, you build teams, which should do what they should do without you needing to interfere. And as a CTO specifically, you build systems that should do without anyone needing to interfere. So, after my time at McKinsey, I joined another startup and became CTO as my first really technical role. So, it's a bit of a sidestep, not the typical approach of being a developer first and then growing into CTO role. But I came more from management and management consulting and then brought my tech experience up to a higher level, also in the CTO role itself.

Oleg

Okay. How did you successfully assemble a team comprising senior full-stack engineers, product managers, and designers while operating within the constraints of startup budget?

Daniel

Setting up teams can be hard because, at a startup, you don't only have the limit from the budget, but you also not having a big apparatus to hire. You don't have a lot of recruiters in-house. You don't have a huge HR department. So, you need to work with the means that you have on your hands. And one of the realizations that I learned during my time as CTOs – so I didn't learn it from the beginning – I made that mistake myself – is that it's really important to actually start with more senior people and only then get more juniors into the mix. I know a lot of startups that started by hiring junior because the people in charge – the founders – might not have been that technical, might not have been able to actually differentiate is it a very enthusiastic junior, or is it someone who actually has the experience of a senior, and is it the right kind of experience that is needed here. And also because senior developers, obviously, are significantly more expensive, is it really worth it to pay double what you would pay to get a junior developer? And therefore, I do understand where this comes from, but in practice, hiring more senior allows you to set up the right foundations, and the right foundations will allow you to move significantly faster. So, how do you do that?

In my case, I've been working a bit with also external providers for talent, be it with staff agencies that just help to set up initial projects, but also with recruiting platforms. Honeypot or Talent.io, I think, are the two best nodes nowadays to find people. And then, when hiring, it's important to have your own brand and to create your own brand of how you convince people to actually bet on you. Why did they join your company and not go for something else? And in my case, for example, the feedback that I got again and again was that people who worked with me just learned a lot more in a short amount of time than they learned in other situations. And that's what allowed me to attract people because they felt like they wanted to learn, and also to keep people because they felt like they were still learning.But there's other values as well. It's about being transparent potentially so that people know what they can expect. It's about creating a good culture where people like to work. It's also about pay. You can't not pay well and expect to get the best. And if you do this mix right, then you will be able to attract the right developers.

Oleg

I definitely agree with you that it makes sense to start with senior people first, rather than juniors because, in quality assurance, we say, 'The earlier you find the bug, the cheaper it costs.' The same is here. I think those things are very connected to each other. The earlier you build it from the ground up in the right way, the less expensive it will be for you to change, fix, and generate in the future.

Daniel

That makes a lot of sense. And it's not only about building it the right way but also building the right things. In my experience, if you hire more senior, then you're able to hire people who also understand a bit more of the product side of it. So, not just the technical side, but also understand which features are actually relevant to the user base. And most time wasted in startups, especially in startup development, is building something that no one uses. If you have people who are also confident enough to say, 'No, I will not build this now because it's not the thing we need,' and instead are challenging you as the founder or as the management team to actually find the most important thing to build, that is a value of its own. And that is something that you get significantly less from people with less experience because they might not feel comfortable enough to actually push back because they might feel like, 'Oh, I don't know, I'm still new in this field. They all seem so experienced.' But if you have someone who is more senior, they already have seen features built and thrown away, so they are more forthcoming to push back.

Oleg

Agree. As you have experience in building cross-functional teams, what are the primary advantages of organizing teams in cross-functional manner, particularly in terms of fostering innovation and driving results?

Daniel

So for me, working in cross-functional teams nowadays is more or less necessity, as long as you do any kind of innovation. There are situations where you don't need cross-functional teams. If you really try to just build 100 Shopify shop, for example, or the 100 WordPress landing page, that it looks exactly the same as the others, then it might make sense to specialize and to have people who are experts in front-end styling or experts who know the payment system. But as soon as you need to innovate, then you don't know what actually is the most important thing to do, and the only way to figure it out is to work on it together. And when you don't have a cross-functional team, you will be slowed down by handovers. So, one team will work on something, and they will then need to wait for another team to do something before they can continue. This might not always be visible because the team will not stand still.

They will still continue, but they will continue on something that is not important or not as important as the other thing. People tend to try to keep busy and occupied, even if it's not on the most important topic. And if you have a cross-functional team and people actually talking to each other, then you can shorten this because then you don't need to wait for the monthly alignment call or even if it's a weekly alignment call. But instead, people talk to each other each day, maybe multiple times per day. And I'm personally actually a big fan of the idea of cross-functional team members. So, not only cross-functional teams but making sure that everyone in the team at least knows the basics about all of the disciplines needed to get work done because, again, the shortest way to hand over something is if you just need to hand it over to yourself. I can think about a task and then think about the task from a different perspective in seconds. I don't need to explain it to myself. As soon as there's a second person, I will always need at least a few minutes to explain all of the contents, and something will be lost because I think about something different than what I talk about, and I will only give part of the information. But if everyone in the team has a broad enough understanding to also know the other areas, at least the basics around it, then they can already focus their communication on what is important right now, and they can also just solve more of the problems without needing to wait for feedback from someone else.

Oleg

What are some key considerations or best practices to motivate cross-functional teams?

Daniel

I think one thing that I realized after everything happened with COVID is that it can be very helpful to work in person. And personally, I'm a remote person. At current company, we work for primarily remote but what we try to make sure is that once a quarter teams meet in person for a day or two. And this isn't necessarily then to work for that time, but just to get to know each other, to have fun. There's a very famous picture in our company of a team ice skating by one of these offsides, which doesn't sound like it is the most important thing to do at a job, but getting to know other people then helps for the rest of the time until the next meeting, because then you will be significantly more likely to actually bring up topics with the team, to create trust, to ask questions than if you don't know them, or if you only see them for five minutes each day in a video call. Meeting from time to time in person actually is really important for all kinds of teams. And then specifically for cross-functional teams, there's always a question of how much you actually have a cross-functional team, and how much you have a collection of one-person teams that are each non-cross-functional. That's a typical mistake I see where you might have a designer, front-end and back-end developer, and a product manager, and that's your cross-functional team. But then if you look at how they actually work, they talk maybe once per day in a stand-up, but don't actually talk with each other. But everyone just says, 'Oh, yesterday I did this. Tomorrow, I'll do this. And there's no blockers,' without listening to anyone else. So, they could as well not have that meeting at all. And then, the only place they talk is every two weeks in their sprint planning. And that's not a cross-functional team.

That is for individual one-person teams all working on their own stuff. And the only way to ensure that you actually have a cross-functional team is to make sure that they work on the same thing. Closer they work on something, the better. And ideally – that's where my cross-functional team member topic comes from – even work on topics together. So, not the designer working on the design and then handing it over to the rest of the team, but the designer leading the design session by the full team – the developers, the product manager, and the designer – everyone together thinks about design and sketches things in a tool like Miro or in a design tool like Figma but without high fidelity, just getting across the ideas. And then maybe as a next step, the designer takes homework – 'Oh, now I need to create a higher fidelity prototype out of this.' Maybe the developer takes homework – 'I need to experiment with our APIs, whether they even support what we want to do in this design.' Product manager might take homework. But the main discussion is actually happening with everyone in the room together on the design and not with everyone individually working only on their own topics.

Oleg

What is ADR?

Daniel

ADR, architectural decision records, is a method that can be used to write down decisions taken in a project. And I'm a big fan of that methodology because A: a lot of times decisions are taken and no one notices. So, someone might introduce the library because they need it. And they don't realize that by introducing that library, they basically force everyone coming after them to use that library. And B: by making the decision concrete and writing it down, it's also easier to know what can be changed. What I've seen happening a lot of times is I come into a project, and they use whatever tool, they use this specific build tool. And now we wonder, 'It's not working perfectly, but are we missing something? Did the person who implemented this tool know something that I don't?' And that's when ADR comes in. ADR is an architectural decision record. So, you write down the decision, and you record the decision about the architecture you made, and you write down why you made it – the knowledge.

And it doesn't even need to be long, but it just needs to be fair to what the decision was actually based on. One ADR that I really like that we have at my current company basically says, 'We chose tool A because we felt like it didn't really matter which tool we take, and someone already knew A.' And that was really honest. We didn't actually check five different tools and made a long process to decide because we felt like it wasn’t important. But if in a year or so we look back at that and realize, 'Oh, tool A doesn't do the job' when we read that ADR, we immediately know we didn't really think that much about it. It didn't make a difference back then. So, if it makes a difference now, we can change it. We can now make the decision, 'Okay. Actually, tool A was the right tool for the job back then. But tool B is the right tool for the job now.' And we just change it.

Oleg

Where do you store ADRs?

Daniel

We have our ADRs in our GitHub, in the repo. We use mostly a monorepo nowadays. And in the same monorepo, we also store ADRs as Markdown files, which means that it's easy to see them next to the code, their versions, all of the benefits from the existing tooling. All of the discussions can happen in a pull request, which is familiar to every developer. It's not perfect because, for example, having longer discussions in a pull request is not as nice as it would be if you, for example, had a Google doc or something where you can do inline edits and inline comments more easily. But you can still do a bit of those similar to code. And last but not least, it also allows us to have grouped pull requests where pull request not only introduces the ADR, but it also introduces a code change. There's a nice way to link these together. And when you look at a code change, or when you look at the ADR, you can just click to the pull request and see the actual code changes related to it.

Oleg

How do you navigate the balance between fostering autonomy and ensuring alignment to organizational goals within team practicing radical agility?

Daniel

So getting everyone aligned and giving freedom is a problem that we haven't run that much into yet because we are always... So, I've been working mostly with companies that were kind of small, typically below 50 people, and there the problem is a bit lower than it is in bigger companies. I would say around 50 people, we do start to also feel that problem more. And one thing that helps me a lot, regardless of context, is always share a lot of context. So, I don't just give direction. I always explain why I think that direction makes sense, what could change that could make the decision no longer make sense. So, give as much context as possible so that people can use that to make the right decision. Don't need to just replicate the decision I made. Because a lot of times, the decision I made is actually wrong. And that might sound surprising, but I work in startups. The decisions change. The context changes. So, what was the right decision one week ago is not the right decision one week from now. In a lot of situations, information can change, and I want people to feel comfortable that they can actually change the decision and do the right decision from their point. And for this, they need to have the context. They also need to have the methods to be able to communicate about it. And they need to have the trust that they know that they can trust in changing that. Well, the first thing for me is always create a lot of context.

The second thing – and that comes more with bigger organizations – is to set up structures all where the teams can actually work independently. So, any kind of setup, any kind of split in your organization has benefits and drawbacks. It will always make certain decisions easier and certain implementations easier, and others harder. And you can't have a perfect setup where everything is easy. So, depending on how you split your organization, that is already a strategic decision on what you want to be easy and what you want to be hard. But if you make it possible for teams to be as independent as possible from each other, then you reduce the problem that you have in a big organization to align and give freedom to multiple small organizations to align and have freedom. And that is easier because the smaller teams, they can just talk to each other. How do you actually do this split? For me, that's where it comes back to cross-functional teams or cross-functional team members. If I have teams that can fully achieve something without needing to talk to others to be able to do this, they need to actually have a broad set of skills. And that's where cross-functional teams come from. Cross-functional teams also is a method for me to make alignment easier.

Oleg

Okay. What are the disadvantages of cross-functional teams? How about knowing anything and nothing at the same time?

Daniel

That's a good point. I think there's different disadvantages. I mentioned already very early today the topic of if you work on the same topic over and over again, and you don't actually need to innovate that much, then you might not get as much benefit from the cross-functional team because you don't need that many functions. You can just work with one function and get your work done. There's also the question of can you actually hire for that. Because you need a broad skill set to be able to work cross-functionally. And even worse, if you try to hire cross-functional team members, that means you try to hire people who know design, product management, QA, development, front end, back end, infrastructure – it just becomes a lot. I would also say that this means that if you work in a high-growth environment where you need to double the headcount each year, that could be hard. You might not be able to find enough people to double your headcount if you try to hire cross-functional team members. For cross-functional teams, that's not as big of a problem, but still, I mentioned before, if you have a cross-functional team where everyone is just doing their own thing, and no one's collaborating, that isn't really a cross-functional team. So, the problem might be smaller, but it's still there.

So, what can you actually do to make sure that you have these kinds of skills available? One thing is to be aware of the trade-off and to make conscious decisions of what you actually need. Do you really need a back-end specialist who can write completely scalable distributed systems for the thing that you're working on right now? Or is it fine if it only scales to a certain point, and then you need to change things, rewrite things, maybe call in additional experts, maybe have an expert team look at it at that point? Often, it's the second. You don't need to have the best design, the best infrastructure, the best product. You just need to have a good combination of all of those. And if your choice is between having the best design, but it never gets implemented because the handover doesn't work, or having a good enough design that you have ready today, the second usually is the best choice. So, one thing there is to just accept that you won't have the best at everything, and that's okay. That is most likely even better than having or trying to have the best at everything.

The second approach is that you can enable team members or enable teams so that they don't need to have all of the skills themselves but can get support. I mentioned this idea of cross-functional team members where everyone knows a bit of design. We have that same thing for QA. We have the same thing for front end, back end, but there's always something where, for example, a certain CSS bug means that you want to talk to the one person in the company who knows CSS better than anyone else. And having that kind of support, being able to reach out and get support when you need it, means that you don't need to have all of the skills perfect and all of the teams all the time, but people in the teams just need to know when they need to reach out to get a specialist. And then, when they get the specialist, the specialist can help with the specialist skills.

Oleg

With the growing trend of remote work and disrupted teams, how do you think it influences the approach of outsourcing? And what considerations are you taking into account when working with a remote tech team?

Daniel

I myself actually mostly went from outsourcing to insourcing over the last years in the situations I was in because I needed to build more product skills into the teams. A lot of times, when working with an external partner, they might be further away from what you do internally. There might be also restrictions on what can people do. Do they need to spend all the time writing code, for example.? And if I look at my current developer setup, they spend a few days each month not working as developers, not working design, but literally working side by side with the users that they support, just to get a better feel for what this is like. And that can be a bit harder with outsourcing. On the other hand, outsourcing also got a bit easier with remote due to not having a big difference whether someone is on-site or in a different country, for example.

In our case, we do have people from Spain to Turkey at the moment, working all in the same time zone. That's why we don't go further west or east. But working from significantly different countries, that's also came with doing kind of outsourcing. So, we have people working for us from Poland or from Romania who are freelancers or working by external agencies. We use at the moment remote.com, for example, for our contracts in Turkey. This allows us to focus on the actual content. And that can actually be quite beneficial if you're able to have people work as if they were full employees, and they still use the same methods, they are fine staying at the job for a long time, they are fine not only writing code. But you can hire them from more different locations.

The only thing I would be a bit worried about is if I try to hire too much from countries that are very specifically trying to outsource, then this makes hiring also a bit harder because a lot of people might be used to jumping from project to project, jumping from company to company, and that might not be the setup that I want for my own current setup. So, I need to actually make sure that the people I hire will not do that. They will not jump to another company as soon as they realize that they will not only be writing code but will also talk to users or do other things, which might not be part of the typical developer workflow. But as long as I take care of that, and I'm aware of the trade-offs, then there are also the benefits I mentioned before, and bringing that together can make a lot of sense.

Oleg

But I think before starting their job, people already know that they will work on different activities. No?

Daniel

That's partially true. So, they know, but I compare. My experience was that, for example, I'm hiring both in Germany and Poland. And for people in Germany, I often had the experience that they came from working at the same company for a long time, working in the office, working on product topics. And they already had the experience of having to jump in when a colleague asks something that is not directly developer-specific. While for people that I had coming in by agencies, they often didn't have that experience yet because they were hired in models where they just joined a project. There was a product manager trying to make sure that every single minute spent was spent on writing code. They were basically forced into a model that might not be ideal for them. And then they found this interesting, but they never experienced it. So, I did have situations where people thought that they would like it and then tried it out, but our company was the first company where they could try it out. And once they did try it out, they realized, 'Actually, I don't like it that much. It's not the way that I would have expected it to be.' It can be dangerous even if you're clear upfront, even if people say they want to work in a certain way. It can be dangerous if they haven't experienced it yet, because then they might not know whether this is really how they want to spend their time.

Oleg

Do you find any difference between working with freelancers and dedicated engineers from agencies?

Daniel

So far, I've seen mix between both. I've both seen freelancers who worked really well with product as well as those who didn't, and the same for dedicated developers. For freelancers, what usually was an important thing is that, especially in Germany, for example, by law, to be a freelancer, you need to actually have multiple clients. You're not a freelancer if you work only for one company. And that makes it a bit harder to do that because they actually would need to kind of jump from company to company just to not be a permanent employee in practice. And there are some ways around this, some legal ways also, as far as I know. I'm no lawyer, so don't quote me on how to do that. But I have the experience that there are freelancers who, for this reason, jump more between jobs and therefore try not to stay in the same job for a very long amount of time. While a fully dedicated developer, there's usually less of a problem like that because there's no legal limit to this. But as I mentioned in the beginning, I've seen both for freelancers and fully set up developers who only work with one company all the time. I've seen both in both cases where it worked out or where it didn't work.

Oleg

I've ever noticed the problem of commitment and dedication from freelancers because, from my experience, working with freelancers is more challenging. Why? Because they consider this job as a temporary opportunity for them, and sometimes they even have permanent job, and they work on the other job on just temporary freelance basis. That's why you cannot get fully dedicated engineer committed to delivering the result.

Daniel

And I think that's something that you need to then basically also check for your hiring. So for example, in our case, we work a lot with ensemble and pair programming, which means that the developers we have need to, anyway, spend four or five hours each day in video calls because that's how you work together if you ensemble as your pair. And if you only can work on things on the weekends, you wouldn't apply to that position because you already know it won't work out. But yeah, I can imagine that this also flavors, which freelancers I talk to because I don't get in contact with freelancers who don't apply, obviously. For those who are interested in working on things in the evenings or on the weekends, for example, I think that wouldn't even show up in my organizations usually.

Oleg

In your experience, what criteria do you prioritize when selecting outsourcing partners, and how do you ensure alignment with your project objectives?

Daniel

So, for working with outsourcing partners, one thing that is really important to me usually is to make sure that I can more or less treat the people working there as my employees in practice, which means having them at the company retreats, having them over to off-sites, giving them the same opportunities. For example, try to give the same vacation days that we have in Germany, also in other countries, just so that everyone has roughly the same contract and there's no feeling like people are different depending on where they come from, or that there's a difference between people, whether they are freelancers or not, but everyone feels like they're just part of the team. And that's one important discussion for me to have because it also relates to a thing that you sometimes hear where you get sold a certain engineer, and then a few months later, the company swaps them out with someone else. That doesn't work in our case because I need to actually spend a lot of time to onboard people, and I need to interview them individually. So, that's one other thing that I take consideration of when working with an external agency.

I would also say that because there are quite a few out there, and it's really hard to predict what will work out, what will not work out, it's also a bit of a networking thing. If I know people, if I work with people, if I talk to people, it's more likely that I will work with them in the future because I made good experiences. Or if I didn't make good experiences, I will not work with them in the future. And the same is true for people that get recommended to me. If I talk to other CTOs, and they mention, 'Oh, this actually worked really, really well,' that is more likely for me to work with them. Then, if the only way that they reach out is that I got an email that landed in my spam, for example, then chances are pretty low that we will actually ever work together because I get a lot of those. I get a lot of emails from outsourcing partners who would like to work with me. And the best way to stand out is if there's a personal connection or recommendation that helps me to realize, 'Yep, they actually know what they're doing. And this could make sense.'

Oleg

Do you anticipate an increased reliance on IT outsourcing? What's your opinion in general on the future of outsourcing?

Daniel

I don't know, to be honest. I feel like outsourcing is a topic that has been growing a lot 10, 20 years ago, and then has been actually going back a bit over the last years, not in absolute numbers, because overall software development has been growing a lot even over the last years, even with the reductions we had in the market and all the people getting let go over the last years. And I feel like this might also mean that now there's again more outsourcing happening. It feels to me a bit like this typical curve where we pass through the valley of tears now and realize, 'Okay, outsourcing isn't the solution for everything, but if you know what you're doing, if you do it right, then it can be a great way to augment.' And it can also be a great way to solve basic problems. You just need to know is your problem a problem that can be better solved by outsourcing or by insourcing. And then you need to find the right solution based on that.

And I also feel like especially more and more people getting entrepreneurial, more and more entrepreneurial endeavors being based on software that will also be more and more outsourcing there because, for very first initial prototypes, that can make a lot of sense to just get something out quickly. It can also make sense to just try to get started somehow and then start to slowly in-house it. Or it can also make sense once you have something that is stable. that gets to a point where you know team doesn't run into new trouble all the time, and you don't need as close as collaboration as you might have needed before than to outsource more. I see that there are different scenarios, which could come to pass with more or potentially a bit less outsourcing.

Oleg

Okay Great. As we wrap up our conversation, what advice would you give to business leaders considering outsourcing as part of their growth strategy?

Daniel

I think my main point of advice here is if you think about outsourcing, you really should start with the problem you're trying to solve. So, don't start with the solution. But start with what you try to solve. Is it a cost problem? If your main thing is that everything is going well, but we are just spending too much money, then that's one way to think about should we outsource here. If your problem is, 'Hey, we can't get any people. We try to hire, and we need more people, but the way that we do it, we can't find them,' then outsourcing can potentially help because that's just another pool of talent that you can tap into. The other way around, if you don't understand the problem yet, it can also be dangerous. So, you might think you have a cost problem, but your actual problem is not cost, but it's outcome. It's that your IT departments or your product departments don't actually create value as much as they could. And then just reducing the costs and changing to outsourcing most likely will disrupt the existing flow even more and will just reduce the value that you get out of it even more. Instead of trying to reduce costs, you should first try to increase value that you get out of it. A long message in a short sentence: when you think about outsourcing, start with what problem I actually try to solve here.

Oleg

Daniel, thanks for joining the podcast. I think it was very informative and sometimes technical discussion, which our auditory will find useful. Thanks for having your time and sharing your thoughts, advices, and your interesting approach on cross-functional teams.

Daniel

Thanks, Oleg.

Oleg

If you enjoy our discussion and want to stay updated on future episodes, don't forget to subscribe and hit the notification bell. That way, you will not miss on our latest insights and conversations from Devico Breakfast Bar. See you in a week!