Ilona: Hi! Welcome to another episode of the Design and Business podcast.

We are recording this episode as a trio. Joining us is Kamila Pendyk, who is the Head of Digital Transformation and IT Strategy Manager at Polish Airports.

Previously, Kamila managed EU projects related to open data at the Ministry of Digital Affairs.

Most importantly for our conversation today, Kamila has been working in IT for ten years, which means she will have a lot to say about our main topic: digital transformation.

‍

Radek: Yes, this is a particularly important topic for us because at Zima, we design digital products for companies that are undergoing exactly this kind of transformation.

It’s no secret that we had the opportunity to meet while working on a project for Polish Airports. We designed the websites for Warsaw-Radom Airport and Warsaw Chopin Airport, as well as their airport applications.

Some of these projects haven't been implemented yet, but I hope you'll see them soon. For us, transformational projects—if you can call them that—are a core part of what we do at Zima, and we really enjoy them.

Because we believe that transforming traditional services into digital products is absolutely vital, and it’s something that truly changes our reality. It’s something we need to take care of, and it’s not exactly simple either.

So, hi, Kamila.

‍

Kamila: Hi, welcome.

I can address what you just said right away. We actually met at airports, where we worked together on a project to design services and websites for the airports in Radom and Warsaw.

And this is extremely important, because when we want to transform aviation and airports, we need to have websites and applications capable of supporting the introduction of innovative products, for example.

‍

‍

Digital transformation: main challenges

‍

Ilona: Exactly. And speaking of this transformation, I was wondering how to approach the topic of digital transformation, because it’s a massive undertaking. It’s just huge. A difficult and complex subject.

And I think it would be great to start—especially considering your experience—with the most common problems encountered in these types of projects.

‍

Radek: What are those problems, Kamila?

‍

Kamila: I’m not sure if starting with the problems was a mistake, because we could easily fill an hour just with that. The podcast is only about 40 minutes long… so I don’t know. But I’ll try to keep it brief.

‍

‍

Staffing issues

‍

Kamila: The problems I encountered in public administration and in a state-owned company—and there are essentially no major differences between them—are primarily staffing issues.

The market for hiring developers is very difficult in general. And it's a real challenge because we want our services and what we produce to be of the highest quality, yet we have trouble attracting the best in the industry.

We relied heavily on the still very popular body leasing model. Both at the Ministry of Digital Affairs and here at the airports.

At the airports, this hadn't been practiced before, and I was actually the one who introduced the idea. I'm not sure if it was entirely the right move, but it worked perfectly at the Ministry of Digital Affairs.

I had entire teams of so-called body leasing there. Both in the Open Data+ project and the National Repository of Science and Culture Objects, whose portals we can already admire.

So that was the main problem—staff shortages.

‍

‍

Technical debt

‍

Kamila: But there is also the massive technical debt I encountered in both organizations. Especially at the airports, for various reasons, we had technical debt that we had to address. So that was the second problem.

‍

‍

Cybersecurity under fire

‍

Kamila: But perhaps the biggest issue I face on a daily basis is that I work in the country's critical infrastructure. I work at the national border. In these times, we are under constant attack, so our cybersecurity is under fire.

Critical infrastructure is highly vulnerable, and as a result, there are a number of restrictions I have to follow that significantly limit the development of airports.

Although we try very hard to prevent it, they might hinder development—that might be too strong a word—but they certainly slow down the pace of that development.

I think these are the main challenges I’ve encountered. I’ll start by mentioning those.

‍

Radek: What you’re saying is incredible, because these are problems that don’t just happen in traditional companies and products. We see a correlation: the longer a product has been on the market, the greater the technical debt.

Of course, if it’s a private company, there aren’t those same restrictions. The debt might be smaller or stem from different causes. But that’s a common trait.

But I understand that with government or public sector products, that debt is quite difficult… and the restrictions really impact the pace, right?

When it comes to constraints, we’ve felt and continue to feel them while designing solutions.

‍

Ilona: I think what you’re saying resonates across every layer of the digital products used in places like Polish airports.

What’s interesting to me is that this comes up every single time during project meetings. Even when designing a flow, we always keep it in mind. It’s not like we build the interface and user flow and then check for security at the end.

When we’re coming up with solutions, we brainstorm and, to put it colloquially, kill our own ideas. We challenge whether what we’ve done is good and try to put ourselves in a hacker’s shoes to see how it could be compromised.

It’s amazing that thanks to this project, we’ve all really adopted this prevention mode, where it’s better to make assumptions upfront than to check later.

‍

Kamila: It sounds like you haven't had more creative workshops than the ones with us.

‍

Radek: Exactly. It was a challenge that pushed our creativity to the limit. They say constraints are the mother of invention, and in this case, that was definitely true.

However, in this case—and I think in most cases—you have to maintain a certain humility. And here I’m thinking about the designer mindset…

As creators, wanting to build the most amazing, sexy products—and I’m being a bit tongue-in-cheek here—we really need to approach things with a certain humility, an understanding that these constraints exist. We have to accept them and build value on top of them.

‍

‍

Digital transformation: mistakes can happen

‍

Ilona: Okay. We admit that working with airports was definitely different from a typical project. Especially because of cybersecurity requirements.

But exactly… Because this project is so specific, it is very easy to make a mistake.

And I’m wondering, Kamila, if you could share some of the mistakes that are most commonly made or that you encountered during the digital transformation?

‍

‍

Example: Online Ecosystem

‍

Kamila: The project we worked on together, called the Online Ecosystem, was one of the projects within the entire digital transformation program. So, we made a few mistakes in that project, let alone the entire program.

The program included over a dozen projects. It even involved building competencies. It included IT operations, as we were implementing a new ITSM, for example. It was an entire infrastructure modernization. A huge, expensive project.

But it was also an Agile transformation. A transformation leading to agility in certain areas. Building IT governance — among other things, we implemented Sparks. And we managed corporate architecture and system architecture at a new level.

It involved building a value-added governance structure and a number of other projects, including those related to cybersecurity, which I obviously cannot mention here because it is critical infrastructure.

Ilona: And we wouldn't want you to mention them on our podcast either. Otherwise, they’ll take us down.

‍

Kamila: That’s how it would have ended.

So, listen… The problems were mainly management-related issues that I encountered. As for the problems or mistakes in the Online Ecosystem project, you can also mention them or remind me how things were back then.

But looking at the digital transformation I proposed for the airports from a bird's-eye view, I initially wanted to accelerate certain things. And I proposed a format… even though we were implementing all the projects using Agile methodology, I suggested setting up steering committees.

I thought that steering committees would speed up our decision-making process…

‍

Ilona: Could you also explain what a steering committee actually is?

‍

Kamila: It is a committee made up of decision-makers that meets once a month, every two months, or every three months. I proposed different formats depending on the project.

And such a committee deliberates on project changes. You can also propose steering committee meetings via circulation to make decisions faster.

Since it’s a state-owned company, I already knew from my experience in public administration what the decision-making process looks like. It is very drawn out. And I thought this would be a way to speed things up.

And that was my mistake, because it turned out that even though we had a vice president responsible for IT as the head of the steering committee—or the chair, as it’s called—we still had to take major issues to the board.

Which meant we still had to go to the board and consult with all the executives. And if it was an even bigger issue, we still had to go to the supervisory board and present the topic there after the board’s approval.

So I thought we could skip the board issues, but it turned out that the steering committee prolonged our decision-making process instead of shortening it.

That was a big mistake, and I admit it, but I simply thought the reality would turn out differently.

‍

‍

Communication problem

‍

And the problem that has existed for ages, since the dawn of time… is the communication problem. And that’s something you know perfectly well. I lacked your skills a bit, but so much was happening that, in some areas, communication just got lost along the way.

I thought that since we were talking about it everywhere, everyone already knew. We made sure to create a Change Leader Academy. We made sure to recruit change leaders and trained them in Change Management Foundation… it’s a change management certification, which I happen to have myself—it’s fantastic. I highly recommend it!

We trained them and gave them certificates. We thought these people would carry the change into their departments and teams. And to some extent they did, but it was nowhere near enough.

And I definitely didn’t communicate enough with the board. Today, I see that as a mistake. Because I made a lot of assumptions. For example, I thought it was obvious that we needed to implement certain things; that we had to buy a specific platform for digitization and process optimization.

I assumed that everyone else had the same knowledge I did. Listening to your podcasts, you often emphasize this… Thanks to that, I looked inward and realized it was a mistake, because I can’t blame everyone else for not understanding something.

And sometimes… due to a lack of time, out of frustration and the pressure to push things forward… to go faster, faster… but sometimes you just can’t go faster. Sometimes you need to stop, take stock, go back to the beginning, and explain everything step by step. And perhaps then I would have even closed some deals faster.

That’s how I see it in hindsight. I even admitted it on air for the first time in my life…

‍

‍

More about communication

‍

Ilona: Kamila, we have such an intimate atmosphere here that I think I'll confess something too…

In our project, regarding such "obvious" things, it was obvious to me that if we are working in Figma and we are creating this Figma for you. The project scope included, for example, preparing a design system… The request itself was phrased in such a way that you wanted this design system…

And from my perspective, it showed a very high level of maturity that you even knew what it was. We educate our clients and tell them that it is worth creating such a design system. And "worth it" is a bit of an understatement, because you have to do it to maintain consistency.

And I knew from the beginning that you wanted this design system, and I just assumed that you were truly aware and knew how this Online Ecosystem should be built. Or what parts it should have.

But it didn't occur to me to tell you that the tool we are building this in, which is Figma, is a SaaS (Software as a Service) tool. Where you have to purchase the license.

There was an awareness in the team that we would have to buy something, that we would have to do something, but unfortunately, we didn't get around to it in time. And as you mentioned yourself, these decision-making processes are very long.

And we were at the very end of the project, when we were handing it over… And to officially hand over a project, we have to transfer the files. So, we download the files from Figma and pass them on to you.

But you also need to have Figma purchased on your end. You need to have your own license to check these files and accept them from us.

And that was also something we theoretically could have taken care of earlier, but because of these communication aspects… Sometimes, as specialists, we think something is obvious. And all signs point to everyone knowing about it because of their level of maturity…

And one minor thing… which isn't even related to our department, because someone in procurement has to approve it… ends up delaying the project.

‍

‍

Understanding the decision-making process

‍

Radek: I would like to bring up one more important point regarding communication.

What is very characteristic of these projects is that the team we work with directly… who makes the strategic decisions during project meetings and provides feedback on the design… is not the final decision-maker who can give us the green light right then and there.

The decision-making process is a bit different than in, let's say, standard projects or digital products.

You mentioned the board. There was a steering committee. So, there is an entire network of decision-makers who simply need to be satisfied, informed, invited into the process, told the reasoning behind certain decisions, and have their feedback or their own needs and goals taken into account…

I think that was the case with this particular project. It was very interesting.

And I think that every project team that ever takes on such a project must keep in mind that the decision-makers and the entire decision-making process are a little different. Longer and extremely important.

It has to be good, it has to be satisfied at every stage.

‍

Kamila: And not just needs, but in such state-owned companies… Airports were the last state-owned enterprise in Poland. They are no longer. We are already a company…

But in such companies or in public administration, politics also comes into play. And all decisions that are made are also politically driven.

So, perhaps we cannot always be guided by what seems right to specialists like you.

Are you running an IT business and noticing a market slowdown? Do you want to lean out your roadmaps or make a pivot? Or perhaps chaos has crept into your organization?

‍

Business realities require readiness for rapid change, which is hard to predict. Download the Business Hero Cards tool — How to grow your business in a crisis, which will help you quickly check the health of your business, identify growth directions, and inspire action.

In the PDF, you will find:

• check-in questions to ask yourself during difficult times
• crisis stories of well-known brands
• solutions like soft skills and canvases to apply during a crisis
• tips from our experts, such as Dr. Aga Szóstek, Szymon Negacz from SellWise, and Damian Strzelczyk from Tutlo

In other words, by entrepreneurs, for entrepreneurs.

To download the PDF with the hero cards, go to designzima.com and click the link in the top menu.

‍

‍

We need to show a different perspective

‍

Radek: I remember a very good meeting with the vice president. We clashed a little bit. His way of looking at the project… he has a slightly different perspective, right? I would say he looks at certain things from his own ivory tower, so to speak.

And our perspective as designers, who must look out for the passengers' best interests—because in this case, our user is the passenger—it was great to have those discussions about which concepts or solutions should be implemented.

And we would ask ourselves: “Well, Mr. Vice President, will this really meet the expectations of the passenger who will be using this site?”

It was great that we were included in the discussion process with him and that we had the opportunity to help him see things through the eyes of the end user.

It was great, but again, it ultimately extended the work. So that is really something worth paying attention to.

‍

Kamila: Exactly, and I wanted to say that in the end, it actually sped up the work, because involving the vice president was a turning point. It turned out that we had imagined some things differently, and when the VP came in, it turned out he had yet another vision.

It is super important to involve key decision-makers, but as we know, they have no time. Absolutely no time. So that was a specific moment.

‍

‍

A case study on strategy implementation

‍

Kamila: But I also wanted to tell you… Radek, you mentioned passenger services earlier. And the way I approached digital transformation in general… I think this is interesting…

At the end of 2021, I was handed the digitalization strategy for the state-owned enterprise—which was still an airport operator at the time—for the years 2022–2025. And I was told: "Kamila, now implement this. Make it happen."

I took that digitalization strategy and simply decided that the best way to implement it would be through a program. I was a project manager for many years and handled large-scale projects, such as Open Data with a budget of around 30 million, and the Chronicle—the National Repository of Scientific and Cultural Objects—which was about 20 million.

So, I more or less already had an idea of how to map it out. And I actually created over a dozen projects. I packaged them into a program that we grandly named the Digital Transformation Program.

But what I’m getting at is… I looked at it this way partly because of you, Ilona, since we talked about UX a long time ago and you told me a lot about it. In fact, it’s thanks to you that I even learned about this topic.

I approached this by looking at the digitalization strategy from both a UX and an EX (employee experience) perspective.

So, on one hand, there is what we can design for the external user, meaning our passengers traveling through the airport. And on the other, what we can design and provide for our employees.

Naturally, in a company with significant technical debt and where we are lacking many things—to put it diplomatically—most of these projects were EX-focused, aimed at our employees.

The main flagship project is, of course, paperless, because we are just about to implement a platform for digitizing and optimizing processes. We are going to eliminate paper.

So, UX was even included in the design of the entire digital transformation program.

‍

Radek: What you’re talking about is the UX mindset. That is, the mindset of thinking about the experience of the person who will be handling something, operating something… who will be using something.

It’s great that more and more people have this mindset. They are interested in it and are implementing it in places where this mindset or way of thinking didn’t exist before.

‍

‍

Paperless project

‍

Ilona: I’d like to ask about the details of the paperless project you mentioned. Where did the idea to do something like this come from? Did you start with a problem? Did you start with a need? How was the idea born to make this happen?

‍

Kamila: It seems quite obvious to me, but maybe not for every company. We simply have almost everything on paper. Electronic signatures are circulating somewhere, so it’s not entirely… we already had attempts like that.

But this idea had been circulating in the company for some time, so paperless was a natural project. We just had the idea to do it in IT because that’s where we had the most expertise. Paperless should probably be implemented in the business side, but we did it in IT.  

The business owner is the Management Board Office, so we joined forces. We approached the paperless topic… actually, the initial idea was to implement the platform immediately. Buy licenses for everyone and start with the most painful processes.

It’s no secret for us. It was the pass process. The pass process… for those who don’t work at the border, it’s an interesting case… it’s difficult. It requires tons of paperwork and approvals.

And sometimes you really have to wait a long time for a pass. A month, for example. There are even record-holders who waited longer.

We wanted to start with that right away. But that would have involved purchasing licenses, and these platforms—probably all of them—have a business model where you pay for the license. The main cost is the licensing fee.

So, after digging through it all, we decided to start with a pilot project. We’ll test it out. And that’s exactly what’s happening now with smaller, less complex processes.

We are optimizing them and implementing the same platform, but with fewer licenses. After this pilot, we will decide whether to continue with this platform or switch to another one.

‍

‍

Is true Agile possible?

‍

Radek: Kamila, ever since we sat down and you started talking, one question has been on my mind. Is true Agile possible in the organizations where you have worked and currently work, one that isn’t just waterfall dressed up as Agile?

I have my own thoughts on this, but I would like to hear your opinion on the matter.

‍

Kamila: I am an absolute Agile enthusiast. Just what I said about steering committees already suggests… Steering committees are a product of Prince2, I believe, though perhaps other methodologies as well, since I only have certifications in Prince2 and Agile.

Because you have to know your enemy, so I also got a Prince2 certification so that I wouldn’t be speaking empty words when I criticize it. Every methodology has its advantages.

And indeed, while it was much easier for me at the Ministry of Digital Affairs to introduce a change that was also large-scale… Because that involved reporting and task management in Jira. And implementing a tool like Jira into daily work in general…

However, at airports, when I arrived with my usual enthusiasm, it was actually much harder. But listen, do you know why?

Because it was hard for me to argue against the point: Well, why don’t you build us the airport in Radom with your Agile then? And it actually could have been done. For Agile enthusiasts… I really do know people who have managed construction projects using Agile. And it really is possible.

I could talk about this for a long time, because Agile isn’t about having a construction worker log into Jira. That’s not the point. But their manager or someone else… You can set up any workflow that can also be agile.

But it’s also hard to introduce this to—let’s be honest—a less mature organization, which airports are. And I’m not insulting anyone here, because we are constantly changing and there is a great willingness to do so.

And the board is actually forward-thinking, wanting to keep up with the times and open to new technologies. It’s just that many things need to be explained, as we discussed earlier.

And I’m not saying this to curry favor, because they certainly won’t be listening to this. At least, that’s what I think…

‍

‍

Awareness of change

‍

Radek: I might not reveal my own stance just yet, but let’s remember that we are talking about digital transformation here. We are not talking about a digital revolution.

So this transformation must have its own time to get acquainted with these new things. Time to try new things and try to adapt them. To try to connect existing, functioning processes. To change some of them…

So it is normal that certain new methodologies for things like product development are implemented slowly.

In my opinion, it’s worst when everyone around the company thinks they are doing Agile, for example, or that they are working according to some methodology, when they aren’t at all… They are dressing up an old system in new clothes, which is a kind of deception and a game.

What you just said about the airports, I feel, demonstrates a certain maturity in the context of the organization.

Because if there is an awareness that we aren’t there yet, but we want to be, it means we aren’t pretending that we are. And that is already a huge plus.

Kamila: Yes, definitely. I also see the maturity of the airports in the fact that the main methodology adopted for managing projects at the airports is Step, based on PMBOK.

It’s also a methodology that requires extensive documentation and leans more towards PRINCE2. Among other things, it was used in the construction of the airport in Radom.

But a nod to the airports, which shows their maturity, is that they allowed IT to introduce a different methodology. And that was great, because it really sped up the work.

There was no pretending or building bridges, like doing a bit of PMBOK here and a bit of Agile there, hoping it would all just work out. No. The PMO simply separated the two: IT project implementation goes the Agile way, and everything else follows PMBOK.

However, we still see a lot of rigidity in this methodology. We just don’t like it. It causes a lot of trouble, which is why the Agile transformation project was created.

We’re also not forcing Agile now, and we aren’t going to build airports using Agile. We’re not biting off more than we can chew. But, for example, I suggested that we start by implementing my beloved… it won’t be a surprise… Jira.

Confluence and Atlassian products in general, which we already use in IT, of course… I want to smuggle them into the rest of the organization.

This was met with great approval from the PMO and the board as well. And now we want to report to the board. We want to create dashboards in Jira. We want all projects to report in Jira, regardless of the methodology.

It turns out it is possible. You just need to prepare separate workflows for Agile projects and for those PMBOK-based ones, so that the PMO ultimately receives reports in one tool.

So that everyone could use a single tool. So that project classification could take place in one tool.

Because until now, our project classification was done in Excel.

‍

Ilona: The immortal Excel.

Listen, it’s going to be immortal for a long time to come. And as long as I live, I will fight against it. I’m declaring this for all to hear.

‍

Ilona: You, Kamila, are fighting against Excel, but I love Excel. And I believe that when all the software fails, only Excel will remain.

‍

Kamila: That's true, unfortunately.

‍

Radek: When the power goes out, all that will be left is Excel.

‍

Kamila: Yes, Excel will always work.

‍

‍

Changes are needed everywhere

‍

Ilona: But I agree with you that it's worth testing new solutions. And what I like about what you're saying is that you aren't closing yourselves off by applying the same framework to everyone; instead, different departments can test and check what works for them.

‍

Kamila: What's more, we created an experience lab… I just made that word up… but what I mean is that we created a group of people, change leaders. And I think that was a great idea.

We will continue this project because we learned about many pain points in departments like operations… the baggage area… that I had absolutely no idea about.

I work in IT, so I have my own world. But setting that aside… I also walk through various administrative departments, HR, finance, the executive office, training, personnel policy…

But an airport is, after all, the baggage handling area, it's cooperation with cleaning companies. Or aircraft ground handling, not just passenger services… These are often very complex systems.

The airport itself has about 300 systems to maintain. 300 systems. And it turned out there were many things I didn't know about.

By bringing in a few employees from every office and every department, we learned a lot of interesting things. A lot of use cases.

And that was actually when I got a headache, because I thought I had everything covered with the digital transformation program. It turned out I could have planned that strategy for the next 15 years.

Which, of course, makes no sense because the world is changing too fast. But it turned out there are so many problems to solve.

‍

‍

Transformation never ends

‍

Radek: It seems to me that digital transformation is characterized by the fact that it’s a long-term commitment. It really never ends. We could say that as a summary to wrap up our conversation.

‍

Kamila: Yes, exactly. That even came through in your last point.

I think I’ll have work for a long time because it’s that kind of topic. And besides, it’s such a fascinating subject precisely because it never ends.

Because things are constantly changing, I’m always learning something new. I’m always doing something new. And essentially, there’s no end to it, just as we were saying.

And considering that the world is changing—which is a cliché, of course, but very true—it also allows me to stay up to date personally.

‍

Did you enjoy this episode?

‍