In this FinTech Me This episode Daniel Parming, Head of Engineering at Kantox, tells us how he approaches developing engineering skills in his team. We talk about setting goals for individual developers, spotting soft skills, and why you have to provide engineers with complex challenges. Check out the full episode!
Listen to the full episode here or on Spotify, Apple Podcasts, and Google Podcasts.
FinTech Me This: Episode 2 with Daniel Parming, Head of Engineering at Kantox
This episode’s guest is Daniel Parming, Head of Engineering at Kantox, a leading company in currency management automation software for automating foreign exchange workflows. Before Daniel became Head of Engineering, he was an Engineering Project Manager, responsible for creating a lean environment for his technology team. In his career, he also worked as a Project Manager for a startup incubator and a retail technology provider, and he was also a Head of Data Governance at Telematel, a business management solution company.
Engineering management as proxy programming
Magdalena Grzelak: How did you get involved in engineering management? Did you always want to go into team management?
Daniel Parming: Let’s say yes. I just didn’t know it in the beginning. One of the most difficult parts with management in an engineering environment is that programmers don’t really want to go there. They prefer to build their world. I usually compare programming with writers actually, because when you are in there, you are creating this small little universe that you control. You set up your own rules, you set up your own boundaries. And it’s difficult to go away from that.
I’ve seen this several times. People usually go up to management as a team lead, maybe a bit more, and then they bounce back. I see it differently.
Maybe that’s why I’m here as a Head of Engineering. I see it as proxy programming. I am still doing the same things. I just made it a bit more complicated for myself. A bit of an extra challenge because when you are programming and the machine does something stupid, it’s your fault because the machine just follows orders. When you are a manager and something bad happens, it’s your fault too, but figuring out exactly what you did isn’t so straightforward. You just put up a debug console and see, “If I type this, this comes out.” It’s a lot of trial and error, and trying to find out what works and what doesn’t, and what works when, with who, how and so on and so forth.
I’m still a programmer, I would say. I would like to see myself as such. What happened is that I was offered a place to become a Project Manager for a particular project. And I liked it very much. I didn’t know that it would be like this, and I just continued on the same path with less and less actual programming tasks. When I joined Kantox, I was completely cut off from the programming itself. I am an ex-programmer now. Officially, I’m four years clean. Trying to get by. But in secret, I am a programmer, still.
Magdalena Grzelak: What do you mean “in secret”?
Daniel Parming: It is the way I see [it]. It’s getting the same projects done, but through proxies, through another form of programming, let’s say. As a manager, you have a much wider reach and you have a much less detailed view. It’s a balanced offset from when you are a real programmer.
Magdalena Grzelak: I like this simile to writing, but also thinking of managing as a type of programming still, just with a lot more variables.
Daniel Parming: Exactly. Once humans come into the equation, the complexity of variables goes sky high. If you are a programmer and you think that you know everything, try management. (laughter)
Magdalena Grzelak: What are you exactly responsible for in your job? Because management is a very vague topic if you think about it. What exactly do you do?
Daniel Parming: It’s a very good question, actually. And it’s very difficult to put your finger on it. If you go by any job offer and look at the explanations of what is required of this position, that is not really what it is most of the time. It’s just the most important parts. What a manager—at least a Head of Engineering—is supposed to do is to make things work, whatever that means.
Sometimes it is helping those two guys that are behind, that are not meeting deadlines. Sometimes it is coaching a team. Sometimes it’s just holding projects and making sure that the left hand knows what the right hand is doing. It is very different day-to-day.
What you’re supposed to do in the management position is bring value. You’re not programming. You’re not the firefighter that is putting out the fire. You are the guy behind.
What can the guy behind provide to the guys in the fire, in the burning building so that they can work better? What kind of logistics do you need to approach? What kind of technical maintenance, what kind of communication problems can you solve so that the guys in the fire can work better?
Magdalena Grzelak: You’re looking at the bigger picture that someone right in the middle of programming might not see. How big is your team?
Daniel Parming: Right now, we are 42. Actually, 44. I think two guys joined recently.
Magdalena Grzelak: It’s kind of a big team.
Daniel Parming: It should get better. We are just getting up to nominal values. We have been understaffed for a bit and 2020 has been a very difficult year.
Magdalena Grzelak: I think it’s true for a lot of companies at the time.
Daniel Parming: We still closed 2020 with 2% increase from the previous years.
Magdalena Grzelak: Wow. Congrats. That’s great.Daniel Parming: After having the entire hotel and travel business collapse. We had plenty of clients in that sector. Recovering them, going out in new sectors and landing contracts and getting money the same year—that was a huge feat by the sales team.
The systems every software company needs
Magdalena Grzelak: What kind of tools or organisation systems do you use for your day-to-day management tasks?
Daniel Parming: Jira as a ticketing system. I’m not a big fan of Atlassian in general, and I’m not a big fan of Jira. It has a lot of quirks. It has a lot of weird bugs and difficult things, but once everything is set up, everything is working great. But you can apply that to any ticketing system.
What is important is to have a ticketing system because that’s going to be the base of your operations. If something is not written down, it doesn’t exist. That’s how things work, even when you are a team of two. Now imagine a team of 42. You’re going to have the same kind of problems, but permanently. Everything must be written down. And tickets are for the tasks that are supposed to be done.
Then you are supposed to have some sort of wiki. We’re using Confluence, which is from the same Atlassian group, to write requirements. You have the product team writing requirements of how things are supposed to be working. Then there is a set of reviewing; the full extended team that is involved: UX, product design, front-end, back-end. Everybody reviews the requirements. And when they are accepted, that’s when the tasks are created. At the very least, I would say that any software company needs a ticketing system and a wiki system.
Magdalena Grzelak: Especially if they’re growing, because with two people on the team, you can keep track of it. But the moment you start scaling, all the problems you could have worked around, they become real problems. And they’re going to become very visible.
Daniel Parming: I completely agree with what you say. The growing adds more communication need, the bigger you are. It’s quite contrary to what you would think, that now that we are that big, we can relax a bit on the communication part. No, you actually have to work much harder, spend a lot more time just to do the same kind of reporting every day.
Simple reporting in a startup—let’s say you are three guys. You stand up in front of your computers. “I did this, I did that.” That’s it. When you are working in a bigger team, that kind of daily reporting should be written as well so that other people that could not participate in the meeting—or for example, myself—can go through all the teams and read everything that they are doing to stay up to date on what is going on on these nitty gritty details. They are sometimes the important part.
The devil is in the details. You catch one of these things and you can save hundreds of work hours. “Oh, but that thing is already developed and that team can just take the same thing, we adapt it a bit and it will work.” Just catching those things, you need to wade through a lot of information.
But what happened on the developer level? Before, when the developer was working in a startup, there was this 10-15-minute standup. And that’s it. There were no other meetings. And then suddenly, you join Kantox and you have to go to the meeting, you have to talk with your teammates. And then you also have to write down a detailed report of what [you are] doing. “I’m doing this because that, and that because this.” And let’s be honest, it’s frustrating. And it takes time away from what you really like, which is, in this case, programming. It’s just bullshit bureaucracy.
But without it, we’re going to miss a lot of things. We’re going to discover this situation: “Hey, what is that team doing?” “Oh, I don’t know.” And that is a big warning call. You have a full team of engineers that are reporting to each other but you don’t have the insight. We had to work really hard on this kind of things during the pandemic, especially because everybody had to work remotely.
We use Slack as a central communication tool. And there was a lot of pressure on getting this reporting thing right. It’s frustrating for people. And I understand it. When we have a meeting, I write the minutes. And it’s frustrating for me to write the minutes. But I know that there are people out there—for example, my boss and other stakeholders in the project—that are really interested and get a lot of value from these minutes. They come back and add comments like, “No, no, this is not how that thing works.” Or, “Can we add these other things?”
There’s a lot of discussions after the minutes that usually happen. That shows that it’s important. Communication is something that must be worked [on] more, the more you grow.Even if you are, let’s say, a foot soldier. You just do your tasks. You don’t care about management at all. You just want to sit and program, that’s it. As the company grows, you’re going to have more work in communication, out of nowhere. And you’re going to feel like, “I have been always doing this thing the same way. Why are things changing?” They are changing because we are growing. And as we are growing, we lose sight. We have a lot more fog of war that takes much more time to gather all the information together. You said a very valuable thing here. More size means more communication effort per capita.
Engineers want to solve complex problems
Magdalena Grzelak: Speaking of growing, I’d like to focus today on planning the growth and development of your team in terms of their skills. Because I think in FinTech, we often talk about innovative products and technology and innovative teams behind it. But I think it’s worth considering how to foster actual growth and drive towards innovation in your team.
How do you approach planning the growth of your engineers in your team? Is there some kind of a formal, uniform process for it or does it depend on the individual you are working with?
Daniel Parming: A hiring process has a filter built in where we check for, let’s say, the typical programmer. A typical programmer wants to have complex problems to solve. Programming is like making puzzles. Once you master the four-by-four puzzle and six-by-six and 20-by-20 puzzles, you want to have something really ridiculously difficult.
You buy yourself a 5,000-piece, pitch black puzzle. There are people that do this. This is sold on Amazon. It’s all black. You can’t even match them by colours. You have to manually check every connection.
This kind of people like challenges in terms of difficult problems to solve. We have difficult problems to solve. When they see our presentation, our solutions, and what is in there, they get hooked. And this kind of people, they are self-learning by themselves most of the time.
This really saves a lot of attention for my side. I don’t need to go and say, “Hey, why don’t you study this kind of thing?” I just go there and ask, “What do you want?” And they usually have two, three things in mind already. “Oh, I would like to learn more about cloud technologies. I would like to have an AWS licence, a certificate.” Okay. I just give it to you as a goal. That part is easy. That part is ridiculously easy if you hire the right people.
Magdalena Grzelak: Basically, you check for people who like challenges and who are looking for difficult solutions to build, right?
Daniel Parming: That’s your stereotypical programmer. Honestly. The filter does exist to just pick away people that want to have a high salary and do easy stuff and never really get into the learning part. But I think that we’ve applied that filter two, three times in our selection process. Programmers are like this. This part is easy.
Magdalena Grzelak: What’s the challenging part? What’s the difficult part, then?
Daniel Parming: Well, the challenging part is, first of all, finding them. And second of all, they are happy with their jobs. That’s the biggest problem. How can you hire somebody that’s already satisfied with his job?
Magdalena Grzelak: Yeah, we’re going back to the fact that it’s difficult to find engineers.
Daniel Parming: It’s difficult to find engineers. This is the main problem in general. It’s very difficult to find specialists in pretty much any area, I would say. But programming is one of those professions that never really had a crisis since it was invented. It has been growing in an explosive manner and there are still too few hands to get.
Why you need to enable programmers to develop their engineering skills
Magdalena Grzelak: That’s true. You can see basically every year new tech companies and startups pop up and so on, and they’re all looking for great engineers. I can imagine with these many companies, it’s difficult to find engineers. Plus, engineers have a lot of options to choose from. You have to stand out from the crowd of all the other companies.
Daniel Parming: Exactly, exactly. And the other part is retention. How do you retain somebody that can get another job like this and go and work happily in another nice project? They should have what they are looking for in their everyday life. Salary apart. That’s one thing, it should be on the market level. It should be what they deserve, but they should be engaged with difficult problems.
They should be provided with all the courses and, I would say, entertainment. For programmers, it’s more like, “Oh, look how fun this is. Another language to learn. (laughter) Oh, finally, I can get to learn something.” Normal people don’t think like that. The engineers are bit whackos.
This kind of entertainment: what do you want to read, what do you want to learn? What kind of certificates do you want to have? Just provide them with that. And at the same time, giving them a sense of satisfaction, completing really complex, really big projects. If you have that, they’re not going to leave. You fail one of these, you are in the red zone. You fail two of these, they go. If your guys are not satisfied with their job, somebody else will hire them very quickly.
Magdalena Grzelak: The key from what I gather is giving engineers—You said entertainment, but those are opportunities to learn basically. And just keep, again, developing their skills.
Daniel Parming: Yeah. You like puzzles, here’s another puzzle. There is a Spanish song that I like very much because it’s one of the few coherent songs in the last few decades: “A ella le gusta la gasolina, dame más gasolina.” She likes fuel, give her more fuel. That’s it. That’s straight to the point. What do they like? Give them more. (laughter)
A roadmap that provides perfect challenges for engineers
Magdalena Grzelak: Okay. I get the principle, but how do you come up with all those new challenges? Are those things that come up as you develop new products for the company? Or are those mainly the things that the engineers themselves have in mind? Because you come up to them and they tell you, “Oh, I want to learn this thing, or I want to learn this thing.”
Where do those puzzles come from? Even though your engineers have some idea what they want to work on, are those decisions still impacted by what the company’s product needs? Or do you sometimes have to come up with something new?
Daniel Parming: It may seem, from how I presented [it], that our guys just sit and play Mario Kart all day long and they are happy, and that’s how we are maintaining our happy attitude. We are actually working and we are working most of the time.
These courses have a date. In the 40-hour week, let’s say, two to four hours are spent on other things that are not directly work or meetings or things related to that. We have a roadmap. And all the teams know which project they are working on, which project is next. And sometimes, the project after that. We know what is going on. We know what kind of projects we have. And it’s the day-to-day working and delivering this kind of complicated projects. They come from the roadmap. The roadmap comes from all the heads of the company, depending on the internal needs, external needs, what we can do and so on.
But on the other hand, we are in a very fortunate situation in Kantox because we are operating on the tip of the spear.
In some areas where we get stuck, we have nobody to ask, “How are these kinds of things solved?” because we are the first ones to do them.
The kind of things that we produce, they have never been tried in the history of mankind.
I’m not boasting or anything. It’s just the way it is. I usually say in the recruiting interviews that Kantox is a boring revolution in terms of currency management and currency management automation. It’s like a semaphore. A semaphore is not really exciting, isn’t it? It’s just a box with three lights. But if you set them up correctly, you can control the transit. You can do marvellous things with this box with three lights that are interconnected.
The same way, we can do a lot with the products that we have. We can make a major overhaul of the financial situation of a big company, of how they trade, what they can do, what they can achieve and what other clients they can reach. This kind of combinations has never been tried before. We are trial and erroring. Well, it’s going quite well, actually.
And these puzzles come from the market. We do more and more complex stuff. We have never tried this kind of difficulty before. And then again, you also have the additional part that you cannot lose a message. A message inside your system can be an exchange of €5 million to some other currency. You miss that, and you will have big problems because first of all, you’re going to have a pissed off client. And then how you handle that pissed off client and how you reimburse the pissed off client and so on and so forth.
So you cannot lose a single message. That adds an additional layer of difficulty on everything that we do. It doesn’t matter if you are adding a simple form to add a new business rule. But how can you add this business rule if in the moment that you click to add the business rule, the system fires and places an order? You have to build in into the form the ability of checking the current situation, taking it down from watching the market, applying the changes, and then putting it up on the market again. And this should be a process that, if interrupted, can resume automatically.
We have so many puzzles, we don’t know what to do with them. When somebody asks for something, we just [go], “Here.” They can try. That part of the job is easy too.
Engineers are usually curious by nature. They are usually interested in having bigger, more difficult puzzles. And we have a whole stash of puzzles that we can deliver to them.
It’s a perfect match in this case.
Sometimes, they are asking for something specific. That’s good. And if they’re not asking for something specific, we still have the roadmap. And the roadmap contains quite difficult stuff on an everyday basis.
Setting goals to develop engineering skills of individual team members
Magdalena Grzelak: You have engineers who want puzzles, you have a lot of puzzles to assign to them.
Daniel Parming: I am just a matchmaking agency of sorts between engineers and the puzzles that they want.
Magdalena Grzelak: How do you go about matchmaking them? If someone comes up to you and says they want a certain kind of puzzle, do you have to go through some kind of assignment process, make decisions whether that person is right for this job or they should do something different?
Daniel Parming: First of all, I’m not a wizard. If you are asking for something to change right now, that’s not going to happen because we still have the roadmap. We still have the things that we need to do.
If you are asking for something like, “I want an AWS certificate,” that is easy. We just put it up somewhere as a goal for that person and ask them to take and plan a certain amount of time that they will not be spending on the roadmap. They will be spending [it] on their certification. That kind of thing is fairly easy to do.
What you are probably asking is if some engineer says, “Oh, I would like to work with that language.” Being an expert in the language they currently are and being a newbie in that other language. What do you do then? That is a more difficult question because [when] taking off a senior and creating a junior, you lose speed. You lose momentum as a team.
You can do it progressively. First of all, you have a goal. You have to pass this course of learning the other language. Then, the next time we have a new application that is built in that language, you will participate or you will do something or, if it’s really small, you will do it. Or your team will do it.
We had those situations where we gradually introduced a whole team to a new language because they were all interested and they built an application. It is not running in production yet, but it’s there, it’s constructed. They had a teacher, a senior from the other language that was following them and doing all the code reviews and correcting them.
That’s another case of where we can provide engineers with additional knowledge that they are looking for. The only thing is that it’s not instant. And as long as we are adults and we understand that things take time to change, that’s fine. Within a year you will have it, but not right now. And maybe not next month, because first we need to finish ABC. And because C has a deadline because that client, etc., etc.. But after C, we can do D and you can do it with that other team. You can go to the other team for a while, spend two months there and then you come back. How about that?
Magdalena Grzelak: You mentioned goals for engineers. Is it something that you assign to each engineer or is it something that they choose for themselves?
Daniel Parming: They can choose it for themselves, but the way it works is that the goals should be established by the manager, trickling down from the CTO, according to what they perceive the best needs of their managee is. Now, it is not easy. This is not something that has been solved by Big Tech either. It’s very difficult.
It’s notoriously difficult to set up KPIs on engineering because the work is so full of variety. It’s easy on sales, for example. You can say, “Oh, if you sell above this value, you are a plus. If you sell below, you are a minus.” We cannot do that in tech because the quantity of projects doesn’t mean anything. Projects can be long. Projects could be short. Tasks could be long. Lines of code are misleading because you can type a lot of bullshit and it will not be worth anything. Or you can make one line that creates an algorithm that solves a particular, very difficult problem. Our KPIs are more about what an engineer can learn.
Here we come back to the first questions that you were asking: How do you know what an engineer wants? Well, first of all, you could ask. And if you already see that, oh, look, there is a potential for this engineer. She has a critical mindset of looking into the details of the things. Why don’t we go and we add a goal to work with quality assistance?
Quality assistance is about this kind of critical mindset. We call it healthy paranoia. I mean, just because you’re not paranoid, doesn’t mean that they are not after you.
Just because you’re not paranoid, doesn’t mean that there is no problem in your engine. Being paranoid up to a certain degree is healthy in software development.
You go and work with these guys and criticise code—in an analytical way, of course—understand projects, how they can fail. Imagine the worst kind of scenario. For example, in the car engine, every moving piece will fail. It’s a question of time. Nothing is forever. It will fail. Even if you have a super duper, ultra quality Rolls-Royce, in 500 years’ time, things will start breaking. Sometimes in five, sometimes in 50 years.
It’s going through every step and imagining that this step breaks. We are trying to contact the bank. The contact doesn’t work. Or we don’t get the message back, or the bank does something wrong. Or the system that received the message from the bank fails. Imagine every step on the road in the mechanism failing. How would you design a way that probably reduces the impact or maybe build a system to alert? That’s a mental skill. It’s not even programming per se. It’s just imagining bad stuff happening.
If you see that somebody in particular has this kind of skill, why not move over and work with the professionals in that area for a while? It’s going to do you a lot of good. It’s going to help them out. And you’re going to come back to your position and you’re going to be stronger in a new area. If you see it as a manager, that you can apply this and that’s going to be good for that person, oh, fantastic. There you go.
If the engineer in question is asking for something: “Well, I would like to work with that team for a while.” Oh, you have a goal. Before August, you have to log 40 hours on tasks belonging to that other team. Solve it.
How managers can spot and develop soft engineering skills in their team
Magdalena Grzelak: You talked about seeing that one engineer is strong in a certain aspect of their work. I like that you chose a soft skill like critical thinking, because I think it’s a bit more difficult to spot it.
Daniel Parming: Critical thinking, this particular soft skill is one of the big downsides of us programmers as a breed. Programmers are pathological time optimists, for example. They imagine everything is going to work fine. I, myself, am included in this example.
When I program myself, “Oh, this stuff’s going to take five hours.” And then I sit and I hit some weird bug that comes from the combination of two versions of two libraries that I’m using that nobody else but me has ever had. And then, it takes two day to solve. This kind of ability of foreseeing, padding time, being critical of your own code, it’s very difficult because we are optimists. Everything’s going to be fine. This problem is going to work perfectly great.
And as soon as I notice that somebody is like, “Oh, maybe we should take a bit more caution with this application in case it goes down,” [I’m] like, “Oh, yes. Good, good, good.” It’s not a minor thing. This soft skill is a major thing. A part of being good at programming, this is the second in tow skill that you should have as a programmer.
Magdalena Grzelak: How do you spot those soft skills that could be brought out in engineers? Because with critical thinking, okay, you could spot it, I guess, because someone says, “Oh, we should be a little bit more cautious.” Or they probably, as you said, have this ability to divide a pretty big issue into smaller sections and they can question them, and so on and so forth.
But if someone wants to learn a certain technology, it’s a little bit easier or maybe more straightforward than if you want to develop some soft skill or evolve some soft skill in an engineer. As a manager, how do you go about spotting those soft skills that could be brought to their full potential in someone?
Daniel Parming: That’s a good question. I do have the answer, but the answer is more work. People that would like another hard skill, another language, another certification, they usually come up with that and say, “Oh, I would like that.” Sure.
Soft skills, how do you detect it? By being in all these conversations. I would not have a clue what soft skills you may or may not have without talking with you at all. If you’re going through the manager path as the absent manager, you’ve lost that battle entirely.
Back to communication. The way that I see that people communicate in Slack, in person, in code reviews shows a lot about how they think, what they value and what they prefer. And that gives a lot of hints. Sometimes it’s not hints. It’s quite obvious.
It gives a lot of information on what would be best to work on. How is it done?
As a manager, your main tool is communication. A manager doesn’t really need to know this stuff that is being worked on. A manager is supposed to know what questions to ask when.
I entered the FinTech area four years ago. I didn’t know about finance. And I got the question in the interview: “How are you supposed to know what we are doing here if you don’t know finance?” Does the machine know what it does? Yes. I can read the code. I will know. It’s a question of time. But when I joined, I had to go around and ask a lot of questions. How does this work? Show me this, show me that. What is the idea behind this product? So on and so forth.
Another way that engineering in general is different from most other professions is that everything is in the open. Imagine if we sit in a meeting, me and, let’s say, the five most senior engineers we have, and we talk about a severe, critical bug that we have. And we are trying to find ways of solving it. If I say something stupid, everybody will just turn on the simulators in their head and look at me like, “What? What did he just [say]?” And the same way, if I, for some reason, say something really smart, everybody will say, “Huh.” They run the simulation in their head, like, “Oh yeah, that will work. Why didn’t I think of that?”
Everything is in the open. By simply engaging in this, simply listening, you have all the information you need as a manager in the engineering area. It’s much more difficult to find out who is saying the right things, let’s say amongst the politicians, teachers, doctors, where there’s a lot more variables in the air. How would you judge a teacher? These children are happy, but is it something empiric? Could you repeat the exact same thing with 20 other kids or not? Maybe it is this group that is well balanced and not the teacher that is so superior.
Just by reading all these reports, by participating in a meeting, seeing what people like, seeing what people are trying to do, you get a fairly good understanding of what their strengths and weaknesses are. And when creating goals, it’s just picking and choosing.
Magdalena Grzelak: It all comes down to communication, as I predicted at the beginning of our conversation, that we would circle back to it.
Daniel Parming: Yes. It’s what I said. It’s an easy answer, but maybe some people will not like it because it’s actually a lot of work. There are a certain quantity of words per minute that the brain can assimilate. If you have 42 people, you have to read a lot of data.
Magdalena Grzelak: To be honest, it’s not just communication, from what you said, because it’s about being present, paying attention to what other people are saying and how they’re behaving. And thinking about how they are thinking and seeing some patterns in that.
Daniel Parming: This is the other programming that I was talking about. This is exactly the second programming that I enjoy.
Magdalena Grzelak: Yeah, that’s true. I’ve never thought about it before, but it could be seen as some sort of programming, just much more variables because it’s people. You can’t fully expect what they’re going to do next.
Daniel Parming: Fully, no, but you have a fairly good understanding. For example, in one of my previous jobs, we had a team where there was one guy that was really eager to learn new stuff. And he went out and he read all these libraries and he read the code and he did a lot of tests. But then, when he was programming, the quality was so-so because he was very optimistic, like I said before. You thought, “No, no, he’s going to be working.” A slightest thing that was off-centre made his code crash.
And there was another guy that was very, very square in terms of testing things, building things correctly. But he was, let’s say, reserved to the research on new stuff. He had his comfort zone: “This is what I know. This is what I’m good at.” It’s a question of just putting them together and sending them out to build new stuff.
The explorer will go first, [he] will assimilate the knowledge, educate the other one. And the builder will make sure that the explorer actually makes normal code and doesn’t do a lot of fluff that will not work. Once you see more or less the personality, you can just put them together where they compensate each other. And everything I say applies to myself as well. I live what I preach. I have some gaps and I try to work together with people that compensate for those gaps.
Magdalena Grzelak: That does foster the kind of place where you can see that people want to be better. And they know their strengths and they want to play into them, but they are not ignoring their weaker points. I think that’s very valuable to be in a place like that.
Daniel Parming: Yes, and this is something that makes me quite happy.
If you have an engineer on deck that wants to be a better engineer, how can I say no?
From a personal point of view, of course, you want to help them. And even from an egoistic corporate point of view, the benefactor of this is the company. We have all the incentives in place to help them as much as possible with whatever they want to learn.
Don’t be wrong; be right
Magdalena Grzelak: What’s the most important lesson you’ve learned since you started managing technology teams?
Daniel Parming: Tough one to answer. There’s so many things. Well, let’s try this one out. What I discovered is that a manager manages functions. A leader’s function is not to be punctual or to act in a certain way or be helpful or any of those typical things that you can read in books about leadership. The function of the leader is to be right. And how you achieve that, that is the bigger question.
You won’t see that mentioned in any book actually. I read quite a lot. I watched a lot of presentations of Simon Sinek and all that. They never mentioned this crucial, important part. Because if the purpose of your existence as a leader is being right, and being able to provide this service to the team, in the good old times in the cave making the right decision meant life or death.
Now it means life or death, maybe in some cases, of their corporation. Not the personal one. But the principle is still the same.
If your purpose is to be right, how would you act? Who would you talk to? How would you build the logistics behind your decision making? That is the more interesting part of leadership.
It’s a completely different world.
Magdalena Grzelak: Sure. I guess it’s something that you have to mostly learn through experience because it depends on the company and on the team that you’re working with and the products.
Daniel Parming: Oh, no, no. This part doesn’t depend on anything. You can be an asshole and as long as you’re right, people will follow. But if you are wrong and you are a nice guy, people will abandon you. And I cannot have a streak of errors. I must be right in every decision that I make or maximum possible. 100% is very difficult to attain, but let’s say 95%, to be able to function in my role.
Magdalena Grzelak: I was thinking about how you get to the place where you’re right, all those things you have to figure out to have this certainty. I guess it’s not the question of certainty, as you said. It’s the question of being right. I was thinking that this is something where you have to get through experience and trial and error a little bit.
Daniel Parming: Yes. That too. But as long as you know this, it’s going to be much easier. I didn’t think about this before this interview, but this would be a nice takeaway. For people that want to look into a management path in FinTech, anywhere actually. Be right. Don’t be wrong.
This transcript has been lightly edited for clarity and brevity.
FinTech Me This: Engineering Management is a podcast where we sit down with engineering experts to discuss the ins and outs of leading effective, driven, and happy technology teams in FinTech companies. The podcast is hosted by Magdalena Grzelak and produced by Code & Pepper, a software development company providing data engineering services, among many other solutions.
For more conversations on engineering management, subscribe to the podcast on Spotify, Apple Podcasts, or Google Podcasts, and let us know what you think on our social media on LinkedIn, Facebook, or Twitter.
