"Processes in development are important. Now I'm not just talking about someone saying they're doing SCRUM. That one is so generic that its application is different in every company and wrong in almost every company. I'm talking about processes that start from pre-sales, through definition, validation, tracking, performance, design, product, testing, etc. This is the only way to guarantee a flawless product."
Processes. A word that gives a lot of people pimples. It's just that without them, it only lasts a little while. Punk, so to speak. But once a company grows, without processes, punk is just chaos. And it's usually a pain to straighten out processes at that point.
But there are also those among us who have their processes fine-tuned before they have their first customers. Even that's extreme. But it paid off here. Today, at Martin Stojka's Jimmy Technologies, many customers learn how the company should implement and interconnect processes. That's why I invited Martin to the microphone to interview him and find out ...
🔸 Why are processes important in a company? And where do they start?
🔸 How does synchronization between business and delivery work?
🔸 How to link processes across the company in a meaningful way?
🔸 What are the benefits of a clearly defined specialisation?
🔸 Who is Engineer 2.0?
WHAT ARE THE BENEFITS OF A CLEARLY DEFINED SPECIALISATION (INTERVIEW TRANSCRIPT)
Martin Hurych
Hello. I'm Martin Hurych and this is Zahžeh. Today's Ignition will be about production planning in an IT agency and we'll touch on artificial intelligence in programming. If we have enough time and don't run off somewhere else, we'll also look at the advantages for a software agency to specialize in a few niche markets. I'll be discussing all this with Martin Stojka. Hi, Martin.
Martin Stojka
Hi, Martin.
Who was the last person he shot and why?
Martin Hurych
Martin je co-founderem společnosti Jimmy Technologies. Když jsem se na tebe připravoval, tak jsem zjistil, že střílíš, že si velmi pravděpodobně chodíš vyčistit hlavu na střelnici. Koho jsi naposledy virtuálně zastřelil? S kým sis vyřídil účty?
Martin Stojka
I wonder how you found that out, because I'm not exactly outwardly saying that. I'm not shooting to imagine someone, I don't think I'd even get the gun if that were the case. It's a super stress reliever though, I'll give you that.
So there wasn't some disgruntled customer you wanted to deal with at the target last time?
Martin Stojka
I went because of some dissatisfaction or some more stressful situations from work, but not that I imagined anyone there, not really.
What was his path to Jimmy Technologies?
Martin Hurych
I always ask the guests here to show their abbreviated life journey as part of the show, because it seems to me that the life journey then explains the points of view that we will discuss here. So can you tell me how you got into Jimmy Technologies?
Martin Stojka
My whole professional life has been influenced by the fact that I played professional hockey from about 5 to 19. I was basically used to getting up at 6 in the morning from about 5, 6, a few times earlier, training twice a day in my later years and having a game twice a week. That taught me some discipline, team spirit, and most importantly I hate losing, so a winning attitude. I also met my first co-founder at the hockey game, and we decided not to go to college after graduation. We designed and partially programmed our app instead of studying. Since then, for the first time, we skipped that sort of saga of working and learning somewhere because we jumped straight into entrepreneurship. That was on the one hand good, on the other hand bad, because we were inexperienced, but we learned a lot from it. Then I took a step back, where I went to a development agency, where I was a project engineer, and I picked up the experience that I was missing in our own startup. At the same time, I was already able to bring experience from that business and help clients with some things there. Then I went to work as a consultant at Skoda, Volkswagen Group, and that's where I met my other co-founders and we started Jimmy Technologies.
Is it better to go out into the world before starting your own startup?
Martin Hurych
In your opinion, it is better for Honza alias Martin to go out into the world before he starts his own business?
Martin Stojka
I wouldn't change it, but when I talk to someone like that who is in college and thinking about what to do, I always say it's good to go through something. Having been through a smaller company, my own startup, and then a corporation, I saw how things work in those companies, how the processes work and don't work, and then I took that with me and applied it to my business. Of course, you have to adapt it to how the business develops. I also saw there, for example, what kind of boss I don't want to be.
Why are processes important in a company? And where do they start?
Martin Hurych
I think I know where the wind is blowing from, because as I mentioned at the beginning, we are going to talk about processes today, I am going to give a little background. We've talked a couple of times here at Ignition about how to plan a production or delivery software studio. I know about you, you're very much in Jimmy Technologies prides itself on the way you have your processes set up and because we haven't known each other for a short time, we've known each other for a while, so I know that clients appreciate it too. If you don't mind me asking, I'd like to look at processes and what that actually means because we were talking before the shoot that the importance of processes for you is not just in the company itself during delivery, but it starts much earlier. Can you clarify that in any way?
Martin Stojka
We have really been committed to these processes from the beginning. We had processes before we had clients and that's where we're getting to, that the process already starts in some sales or presales. What I've seen in companies and clients in agencies is that a salesperson came in, talked to the client, the client had some need, some knowledge, but more of an ignorance of what they wanted to build. Of course the salesman wants to make the deal, which is great, without deals these companies wouldn't be going, but the problem is the wrong set of expectations. Promising a client that something will be delivered in a certain time, for a certain money, in a certain quality, or even certain requirements that are not realistic is wrong. Without some consulting with the delivery team, a deal is signed, the salesperson then proudly goes to the team, hands it over to them like this, they look at it and say they're not going to deliver. At that point the project hasn't even started and the team is already in some sort of crisis mode where they have to deliver either on time or something unrealistic. Now, of course, there's the opportunity to have fun with the client that it's not possible, but most companies won't do that because it hasn't even started and we'd already be telling the client that it can't be done when we promised. So there are already compromises in quality, quality of people or size of team. Then if there are no processes involved in that delivery, it's a bummer. We're not just talking about agencies, we can talk about companies that have their own product that don't have that delivery underpinned. There's a huge misunderstanding by most people here that it's not enough to hire four developers and give them a job and the job will be done. Those guys would have to be great, they'd have to talk to each other, one would take it on, set up the architecture and oversee it. There has to be some process set up, some infrastructure of that project. Now I don't mean server infrastructure, but some process automation, quality control and so on. So it starts with sales, where we primarily do sales as co-founders. We have a sales pipeline, and in that pipeline, I already have that in the second and third step, I pull in the client's CTO, the technical person. If he's not, it doesn't matter, I still pull in our CTO or solution architect who looks at it from that technical perspective, gets those technical requirements, but also has insight into the product ones. A lot of times the product ones are not clear at all. Most projects are agile, time and material, there's an idea at the beginning, what it looks like at the end, the core might be the same, but it's a little bit different. That helps give more clarity on what's going on. For example, we found out three quarters of a year ago that I had to include design. Before, I didn't include design at all and we were getting to the point where it was 20% design and 30% projection. But that's not the case at all, every project is different, every client is different, needs something different, so I include the CTO, the solution architect, the designer, now we include the product owners to just maybe put some product stuff in. Then we sit down, analyse it properly, set the right expectations with some estimates and then those estimates are passed on to the team. We have a process for how to build that team, obviously it depends on what kind of people the company has, seniors, mediators, juniors, how they build that team. We specifically have a framework that is built on scrum, where we have defined even in detail some of the things that we have to do. That team then already knows the process of how they're going to work, how they're going to work with the client, how they're going to work with the product owner, with the designer, with the solution architect. They don't have to learn any new process and they can immediately create that value for that client. Then, of course, there are various procedural things tied to that, quality control, making sure our bags don't rot in Jira, because more than two days in progress is wrong. That either means that the team has under shot it, because the task should ideally be done in one or two days, or there is some problem. Now it depends on whether the person that has the problem hasn't responded or is waiting for someone to help them. Then pull requests, for example, we want to do a cold review right away, approve it, make sure the code doesn't rot, send it automatically to staging and test it. The client can look at it, different code snippets are tracked, we have Data Studio where we track the performance of that team. Some people say it's wrong to look at the performance of an individual, but if I want to deliver a great service, I promise that to the client and I want to guarantee it, then I have to look at the performance of the whole chain. I'm even able to see, because of that, that the team has estimated 5 story points on this user story. It's usually not estimated in times that something takes two days, but it's estimated in some story points that reflect some complexity. We know from past sprints that 5 story points will take us a day and a half, and suddenly I see that this user story took 5 days. We're already looking at it, product owners, solution architect, delivery managers are looking at what happened. We can take some lessons learned from this, we've shot it down here and this way we can continuously improve the process as well. That's what we're built on, but above that there's some transparency where the client can see into it. He's coming to these ceremonies with us, he's in contact with the team, we have a shared Slack and those people appreciate that a lot. They're able to learn a lot from us in that process because not many companies really have a delivery process that's tuned like that. For example, we were building a big platform for a client right now and they came in and said they learned a lot. It's just because we have it set up, but at the same time we let him in. Our philosophy is that you can't build a good product without the business being involved. Like, the client hands you the requirements, you close the door, you're cranking something out, you open it up three months later, you hand it to them like that, and they're looking at it and saying that's not exactly how they wanted it. That's what we want to avoid. We schedule a sprint with the client, during that sprint they see, they have access to task management, they have access to code, which we did once and it didn't work out. Because the client didn't pay us and he downloaded the code because there wasn't some treatment from GitHub so he couldn't download it. But if the client is normal, they will appreciate the transparency. We plan something, we give him a demo in 14 days, we have to deliver it at the end of the sprint, we show it to the client and the client sees what he has planned with the team and what he has invested money in and he can react immediately. Suddenly you can build a great product, so the process is not just to be able to deliver something, it's to actually build a valuable product with that client. That's how we've built it and so far it's working for us. Of course, that transparency doesn't pay off when you have a client who doesn't appreciate it. There are always going to be some mistakes during the process and by having access to it, he sees them. If he wants to, he can take advantage of that and come up with a way to not pay for it. But if he's normal, he'll find that it's all worth much more to him. The fact that a mistake has been made, it has been made, he'll talk to us about it in a retrospective, he'll give his opinion, we'll say something about it, but we move on because he knows it works. That's how we have it set up and then of course the people you have on that team have to fit in.
How do the processes bring benefits to the business?
Martin Hurych
You said at the beginning that you had your processes fine-tuned before you had clients. I see more of this misplaced agility in IT, that even internally we're rushing into something that we don't yet know ourselves what's going to happen. So what do you think are the benefits of having your processes aligned like that? Why should I, after this podcast, maybe have a little bit of a conscience and say to myself that I'm in chaos, that I'm going into things too fast, and maybe I'm largely creating these planning problems myself? What to do about it?
Martin Stojka
It depends on what your goal and vision for the company is. If you have a business and you're all about getting clients, delivering something and getting a paycheck, then you're probably fine and don't have to worry about quality. But if you want to deliver a solution where the client is really excited about it, and if you don't want to be stressed about the delivery, then you the processes will help. Of course we are stressed too, I am also stressed many times when I see that the velocity of a sprint has dropped compared to another. However, in the 3.5 years we've had the company, we've only had to ask the guys twice if they can do overtime. It was absolutely common in past companies and I know it's absolutely common in other companies. Those processes are exactly what help you to be able to deliver quality and value, just a valuable product. One thing that has always bothered me about IT is that it's not tangible. You build an application and it doesn't work in 5 years. If I build a house here, it's going to stand for a long time and I feel great about it. But the thing that bugged me the most was that we'd spend three quarters of a year working on something with a team and six months later the product was unusable. Whether it was from the company writing it wrong or the business just going bust on putting most of the money into IT. We want to build products that are here for the long term, that make sense and have some value to the business and to the users who use it. You have to have processes built for that. It's not like you say we got a deal, we're going to put four people on it, the project manager is going to set up the process and they're going to deliver it. One of the drivers for why we started the company was that as clients we had a problem with suppliers. We thought, well, we can do it differently, plus we found a new business model of being full remote. There was a thing where we were talking to a friend from Sweden who had a very large IT outsourcing company, which then turned into SAP, but he sold it for big money. He said you always have to have a delivery manager over it. That project manager will manage it for you on a daily basis, but you need to have a representative of that business of yours there and whether what you signed with that client is being followed and how it's going. How many times do we know that in those companies the designers are still junior, they are being cut back on, yet that is the most important role. It's the bridge between the business, between the client and the development team. Once that bridge is rickety or has holes in it, the development will not deliver the value that the business needs. So the processes have to be built, but of course we are also constantly improving. We didn't have the Jimmy Framework right at the beginning. We had a process, but the Jimmy Framework came about a year and a half later just as an experience where you see what kind of people you have and you can build it for them. It helped us a lot, we grew to 30 people in three years. If we didn't have the processes it would have been a total mess, we just wouldn't have been able to deliver that. But we've always had a process for it and we were ready to take that next bigger step, to jump from that body shop to custom development after a year. You've got to balance it out, of course, it wasn't 100%, but it helped that we didn't have any big problems in delivering low quality. But it's interesting, for example, that we have the process built for big projects and it doesn't quite work as well for small ones.
How does the synchronization between store and delivery work?
Martin Hurych
So hire Jimmy Technologies straight away for big projects. I'd go back to the beginning of the process. As someone who is interested in business, does that mean that at least the more business- oriented technical part of the company has access to the CRM? How does the synchronisation between the business work, what's coming up, what are the close percentages, how do you plan for longer term capacity and how far ahead do you actually see?
Martin Stojka
We're probably using CRM wrong, let me be clear. We have access to it as funders, we have access to it as the board, but we don't really have any detailed information in there because the information we get from clients is on some drives. So, we go on a drive and the moment I get a client to invite a technical person on a call, I already know that there has to be a technical person on our side as well. I want that technical team of ours to pick it up right away and then if that doesn't happen, I'll still include that CTO in the second round to meet that client. He then finds out
if they have a preferred language, what their business goals and visions so we know how to design the solution. We can't look at the fact that we're doing a project for 6 months now, we're going to build it somehow and this is how we're going to deliver it to the client. We have to look at the fact that in two years he wants to maybe turn that platform into a franchise and we can't build him a solution now and he comes back in that year and a half and he wants to build a franchise and we have to rewrite the whole thing because it's not scalable. So we're doing it just for that reason alone, so that the client can then take it over and develop it themselves or they can develop it to be flexible to their business requirements.
Martin Hurych
I understand that, but let's move on a little bit, one thing caught my eye there. You do some analysis, the technical people listen to what the business intentions are, they can adapt to that, however, you know yourself, because you're responsible for the business, that then there's a relatively long phase after the offer is made. A lot of companies do analysis and at this stage the technical people are involved. What happens then is total deadlock, absolute non-communication between business and production, even if you don't like it, and then it's a big surprise when you need to start immediately. How do you manage that?
Martin Stojka
We have regular bi-weekly sales statuses where we involve the CTO or tell him about the news. He's also in our sales channel, so he sees what's going on and we're not such a big company that we have to keep that separate. We sit next to each other, we tackle those things together, and we don't do as many projects. We don't have 20 deals at a time, we have like 7 deals at a time, so it's easier to remember. Of course, if we do more bids, we probably have to talk about it more, but at the same time, we don't go out to tender, for example, and that saves you quite a bit of time and worry. The decision making process is quicker there and if it takes longer, then I as a salesperson am still getting in touch with that client, what it looks like and then I pass that information on to the team. We have a capacity planning tool, we have a capacity planning tool for that and usually those developers are from that department. They don't really care if there's going to be a deal here, they care that if they see in that tool that their capacity is going to end in a month, if they're going to have any more work. We're in contact with them at that point of course and with the product owners as well, they kind of know what's coming up.
How to link processes across the company in a meaningful way?
Martin Hurych
If I wanted to compare my own processes, or the chaos in my own company, can you put together some 5, 7, 10 points that I should be doing in that company to get at least light years closer to Jimmy Technologies? I can see that logically when you're running a company of a few people, there are some processes, albeit perhaps informal ones. But what I tend to see is that there isn't that core process from start to finish, that you have a fragment, a piece that's torn off where something is. Then I find a lot in IT that somehow focuses on planning within the company and then again something happens at the end. How do I tie that together in a meaningful way so that I have the benefits that you're talking about?
Martin Stojka
I would definitely start from the beginning, from the sales and it depends on what clients and projects you are targeting. For example, the Jimmy Framework wouldn't be completely applicable to a fix time fix price if a client came in and said they needed something specific for 2 million and 3 months. We, by going more agile, knew that to make it work, to set the right expectations at the beginning, we had to set the sales.
After the sales comes the delivery management, the preparation of the project from the tool, allocations and then the development itself. There are methodologies, agile development and in that some frameworks, kanban, scrum, extreme
Programming, there you have to say what you want to do or what is within your means. If it's some low budget project, he probably won't do extreme programming. It's also important to adapt to those people. To make this work in our company, we have what we call the Engineer 2.0 education program, where we want these guys to not just be at their keyboard, not just look at their code and be these coding monkeys. They need to really think about the fact that at the end of it, there's supposed to be a product that a human is using, and I'm part of the team and we as a team are responsible for whether it works or not. Then, of course, the design, testing, how to link the requirements process and at what point the design should jump in. A lot of companies design the whole design, then start doing development and just split it up, but that's waterfall. If you want it to run in parallel, then you're already thinking about at what point do I drop the designer in there. I'll probably let him in right at the beginning, but he needs to get the developers involved right away to see if it's even realistic. This is all linked to the industries that we do. We know that this works in sectors like mobility, fintech and automotive, but maybe it wouldn't work in healthcare. There's probably not a lot of room for agility and for mistakes, it has to be fine-tuned.
What are the benefits of a clearly defined specialisation?
Martin Hurych
If I understand you correctly, the whole sales and delivery process should be mapped to the customer's needs. You mentioned three niches you have here, mobility, fintech and automotive. I'm wondering what led you to those three in particular. Automotive I guess I understand given that you spent some time of your professional life at Skoda. It's getting better though as more and more studios are looking for a specialization, so what actually led you to do that and what are those specializations supposed to bring you?
Martin Stojka
Even though I worked for 2,5 years in Škoda, I am not that strong in the automotive field. I was in charge of new mobility solutions in Škoda and that was the mobility. The guys I have a company with worked at Škoda years before that. We have a guy who has a PhD in connected car, and so on. By being in that environment, seeing into it, doing something for it as well, plus the mobility, it came together. Automotive companies are now saying they're already mobility companies, so it's really interconnected. I hate to say it, but I don't think there's a more specialized mobility group in the country than us. The services that we built here some 5, 6 years ago, we're still building, we know the market very well, we know the users, we know the business models, what works, what doesn't work.
Martin Hurych
Can we say one, or are we under an NDA?
Martin Stojka
We can say what we built as Jimmy, which is for example the Citya service, it works. Most of the services we used to do work, but some of the services we used to do for Skoda, for example, don't work anymore. The fintech again came out of what my co-founders were doing before. It was again some background and it also came out of the fact that we saw a year and a quarter, a year and a half ago that the market was changing in some way. Three years ago, whoever had a development degree here got a job immediately. But as those prices went up, the economy went down, those companies started to figure out how much money they were putting into IT. Suddenly, developers from Ukraine and the Balkans are coming here, and we can't compete with them on price. For When the Indians come here, I get three messages a week from Indians asking if we want development, which is quite common in Britain or America. But we are not able to compete with them. So we said we were experts, but you can't be an expert in 20 different things. So what are we experts in? We're experts in development, but we know that's not good enough anymore because everybody says that. We are experts in the automotive, in mobility, in fintech, where we can transfer product knowledge, market knowledge and that business and operations, because we have operated some services ourselves. This is going to be our niche and maybe now we're not even selling that we're a development studio, we're selling that we're a product studio for automotive, mobility and fintech. We'll build you from idea to some post release stage product in those industries and we're able to pass on that expertise to you. It can be knowledge from what we've been through ourselves, or it can be lessons learned from our clients, what we see works and doesn't work. We help that client design that product and then we build it for them as well, rather than just being given a brief and having to learn about that market. Now a client in fintech told me that he couldn't let a normal developer, even a senior one, on because the developer has to know how the financial market works in order to design the product. At that moment I thought, that's exactly why we're doing this. The client hires us, they need development, but they know they need that fintech specialist or that mobility specialist. We're able to provide that added value and sell that and differentiate ourselves from maybe the rest of the market. It's not just about the development anymore.
How many programmers did he fire because of AI?
Martin Hurych
It is logical to buy the product and not the arms and legs. There has been a lot of talk now, and even here it has been Ignited, about how AI will eliminate the number of IT people in companies. I wanted to ask you, how many have you fired?
Martin Stojka
We fired a few IT guys, but not because of the AI. I'm not the one saying AI is gonna put us out of a job. It can happen somewhere, but probably not on any large scale. At the same time, I'm not really a developer to judge, but we already know that OpenAI, for example, works well for having a program in one language and wanting to rewrite it in another. It's not quite perfect, you still have to have a person come in to tweak it, but the time saving there is quite big. I know there are startups for this, but I don't see the use of building a more complex product with it yet. If you want to build a landing page and have a form there, it can work, but in the context of larger applications, like we are building, it doesn't make sense. There's already some architecture there, it has to fit the exact vision of the business and I don't quite believe in that. On the other hand, as it's already quite advanced, it's bound to develop further and if developers want to keep their jobs, they'll have to become Engineers 2.0 exactly. That's a person who thinks about it from a bigger perspective and not just the technical one, because in the end the code doesn't interest the end user at all, he's interested in what the product will bring him. The code is just a tool to build the product. If that developer brings that human factor to it, that he can connect that client's business, what that business needs, knowledge of that market, expertise, and build a solution on top of that, I don't believe AI can compete with that. If that developer doesn't do that, I don't think it's going to be enough any time soon. We have a developer who has been a senior developer at Revolut, at Deutsche Bank, at J.P. Morgan, and he'll come to a fintech project and say how should this work and where can there be a security problem. He's going to bring a whole different perspective to it than just saying it looks a certain way, he's going to program it and maybe it'll work, but he's really going to design the solution to the business. I don't think AI can do that.
Who is Engineer 2.0?
Martin Hurych
So the coder will stay in the cellars and if I understand correctly, the rest will change. Am I correct in understanding that Engineer 2.0 is more of a business consultant?
Martin Stojka
That's our term that we use. Our CTO calls it a t-shape, that he's not really just focused on his code, but he can communicate with the client as well. But he's not a business person, he's still an engineer. He can bring product knowledge to that technical expertise, or at the very least he'll think about it. I don't believe AI is capable of building this. It will make you some form and whether or not it's UX good is another matter. I think that's what a senior developer will be judged by now, not by how clean their code is. The juniors and medio will probably have it more difficult, they'll probably have to bring that consultative insight into it more and work on the quality of the code in the meantime. We'll see, but that's just my theory.
Martin Hurych
I wish you have a bunch of great projects on Jimmy Framework and may you get Engineers 2.0 and maybe somewhere else in the future. Thanks for visiting.
Martin Stojka
Thank you very much.
Martin Hurych
So you see, you can produce code efficiently. If you have decided to review your processes, and not only in IT agencies, we are glad that we have inspired you in some way. If so, be sure to like, share, comment, whatever is possible on the platform you're currently using us on. Definitely check out my website, www.martinhurych.com, where the Ignition section not only has this episode, but all the other episodes. There's going to be a bonus that I'm going to knock out of Martin after the fact. Thanks, have a great time.