Leader Spotlight: Championing prioritization and pragmatic change, with Viktor Chuiko
Viktor Chuiko is Vice President of Project Management (PMO) at CARiD, an online auto parts retailer. He began his career as a PHP developer and team lead at ICM Consulting before transitioning to Webmasters International. Viktor then founded a development agency while working at FFW as a project and program manager. Before his current role at CARiD, he served in various PMO leadership roles at CarParts.com and CarLotz.
In our conversation, Viktor talks about his experience implementing prioritization frameworks into an organization for the first time and how he handles the resistance and hurdles that come with that. He also shares how he leverages change management to increase team efficiency.
Leveraging technical fluency
Early on in your career, you worked as a developer. How did that impact your journey, and do you feel your background gives you an advantage when communicating with engineers?
I started in development in the early 2000s, and at the time, there was a lot of excitement about tech. Being part of that was very inspiring and provided me with a lot of opportunities to grow and learn. I learned about different technologies, what they do, their limitations and constraints, and specific development concepts. I learned about databases, how they interact with the servers, and what logic is involved. Those are often things that PMs usually hand off to developers to figure out. Having a solid understanding of what’s under the hood has helped me a lot in my career.
Also, having a bit more of a technical understanding enables me to ask good questions. My point is never to argue with developers’ concepts or ideas, but to help validate that what we’re doing serves the right purpose in terms of completing the project on time and with the right functionalities. For example, when we create estimates or build architecture, I can pinpoint common pitfalls because I’ve experienced them personally when I was doing dev work. I’m able to catch red flags early on and mitigate issues in project planning.
Is there an example you could share when your technical fluency helped you identify a misalignment or red flag and, by doing so, saved the project?
When I worked as a developer, I had to wear multiple hats. I had to think like a business analyst, a UX specialist, an architect, a quality assurance person, and more, and those skills never left me. We would have a sprint completion or a demo to send as a soft deliverable to the client. I would personally QA and test it, because I not only knew how those things are typically built, but I could also imagine the edge cases. I’d go and test them, send things back to the dev team, and we’d fix them. That approach saved a lot of future client frustration.
There was one time when a developer was building a system for managing webpage content. It was supposed to be a scalable approach, designed so that non-technical users could easily spin up new pages and modify the content. When we were partway through the design and build, I thought, “OK, let me check how these things will look for the end user.” I had some suspicions that something might be off based on the way we were building it.
I saw that we were building the system in such a way that it could only be used by developers. Nontechnical content editors would not be able to use it, and that wasn’t helpful at all. Our developers hadn’t seen a problem with that — they thought it would be easy for a content editor to just paste in the HTML and change some simple code. We ended up redesigning the system and set new expectations with the client.
The importance of prioritization
You’ve had a fair amount of experience mentoring and scaling teams that are dispersed geographically, and that certainly comes with its own set of challenges. Can you say more about that?
I started working remotely long before COVID. I’m originally from Ukraine, and in the early 2000s, I started working almost exclusively with US clients, and all of that had to be done remotely and with remote teams. Through a lot of trial and error, I came to the conclusion that it’s not necessarily about the tools you use. There are so many out there that do similar things, but what is always most important is building relationships with the team.
I want the team to operate as one unit. Regardless of individual roles, we have a shared responsibility to reach our target outcome in whatever we’re working on. I want to promote a culture that emphasizes that every role is respected and essential, and that builds accountability. If a person is inspired and motivated, you don’t necessarily need to constantly check in with them because you know they’re invested in their work.
I believe in being transparent and taking time to explain what we’re working on and why we are working on it. Don’t just assign tasks; instead, explain why they are needed for the product and strategy. It also helps to collectively brainstorm. This provides an opportunity to bring in other perspectives, it gets people more engaged, and often leads to better ideas.
What is your approach to prioritization, specifically through the lens of cross-functional initiatives?
There are many prioritization frameworks available, and they differ in the amount of data that you need to collect for them to be effective. ICE and RICE are popular ones, and both are well-suited for product development and understanding how different features will impact a subset of users.
In my last few jobs, we noticed that frameworks that require a lot of data can be difficult to use. If you put the wrong data in, you’ll get unreliable outcomes. I came to understand that you have to first have realistic expectations around the amount of data that you can get for each project. For example, for some prioritization frameworks, you will need to gather data for each of your initiatives to calculate the score. And it’s not just the validity of the data you need to consider, but also how much time it will take people to go and collect it. You need to be realistic about what’s possible.
I like to figure out the balance — what works for the organization, whether we can collect two data points or three data points, and if we can apply a framework like ICE. It’s always a learning experience, especially if you’re trying to introduce these frameworks into an organization for the first time. In that case, try it out for a period of time, like a quarter, see how it works, and then add to it or simplify it from there.
If the framework needs a lot more data than you can provide, simplify it. In the end, you’ll see what worked, what didn’t, what the outcomes were, and whether you will benefit if you collect more data. At the end of the day, collect the data that will help you understand which projects are most important.
How do you handle cases where the data tells one story, but your gut doesn’t agree, or when leadership already has an idea of what direction you need to go in?
These situations actually happen quite often. If you’re working in an organization that doesn’t follow some sort of prioritization framework — and I’ve been there before — then the loudest voice usually wins. Whoever believes most in an idea will push for it, and if they’re in leadership, people will generally listen. It’s a good idea to understand what’s behind that and then collect data to try to validate it.
I’ve seen many instances where the idea looked good on the surface, but we needed to run the numbers to verify it. In those cases, we’d usually spend another week or two doing that. Sometimes, this exercise confirms that we should proceed, but other times, it reveals that we forgot a critical piece.
Storytelling and alignment
What techniques do you use to present that story to non-technical stakeholders?
Firstly, it always helps when you have somebody on the team who’s confident with how to get the data and what data to get, as well as how to assess the value of a project. I usually try to gather data and run it by our data science team since they know more than anyone about what data points we need to collect.
Sometimes, it’s enough to just tell them, “Hey, for this project we’d like to understand what the value is and how it’s going to impact our business.” From there, they can give us data and a dashboard. Then, we can work with them to figure out what story the data tells, translate that into numbers, and develop a good presentation to give to leadership.
When stakeholders aren’t entirely on board with an initiative or alignment is off, how do you work to get it back on track?
It’s common for misalignment to happen when there are too many things on the table from different teams. I’ve never seen a case where you can work on everything that everybody wants. Usually, there are trade-offs, but prioritization frameworks exist to help you narrow down what you need to work on.
Let’s say a large business has 200 projects for initiatives on the table; obviously, each one is important for a different reason. In cases like that, I’ve found you can get alignment by helping stakeholders see how all of those things relate to the strategy and the vision. Do we need them right now? Is this a good time? Do we have the right resources to do this? Are they all equally impactful and helpful to us? When you start asking these questions and aligning to the overall strategy, some of those initiatives will naturally fall off, at least for the time being.
Sometimes, you need to go back to the leadership and confirm the immediate, mid-term, and long-term strategies. Then, you then try to place initiatives into those buckets. That helps with organization-wide, cross-functional prioritization.
Championing change management
You recently led the PMO during a post-bankruptcy transformation and doubled revenue in the process. What role did storytelling play in rebuilding trust after the turnaround?
It played a huge role. Of course, it was a collective effort, but when you come in and try to operate in the post-bankruptcy phase, there are lots of concerns from all parties involved — especially those outside of the company, like vendors and investors.
Storytelling is an important tool because it enables you to get the right attention and drive the desired outcomes, but to be effective, it needs to be a realistic and achievable story. For example, in our case, we had to tell our investors and vendors how we planned to get out of this difficult situation.
It’s always a slow process; trust is not built easily or quickly. You have to be diligent, patient, and also confident in the strategy you’re following and the story you’re telling. From there, follow through and be honest and quick to react if things don’t go the way that you intended. You should also have a plan B, and be ready to shift to it as needed.
How do you get buy-in for change management initiatives and ensure they are helpful instead of just creating extra work?
I think the key, in any change initiative, is to truly understand the problem you’re trying to solve. With an org-wide change, like when we onboarded teams to use different tools, you need to ask whether or not the initiative is actually helpful. What does the change do for the company, and what is its benefit?
If you don’t know the problem that you’re solving for and you’re just making a change because you think it’s right or because somebody told you to do it, then you will probably face a lot of obstacles along the way.
Another important element for success is buy-in. You need to be able to show people that you’re helping with something and delivering value. For example, if you’re introducing a new tool, people need to understand how it will aid their daily work. Once people see the benefits, you’ll have their support along the way.
Lastly, what advice would you give leaders who are grappling with how to introduce change management techniques to team members who have different perspectives, perhaps because of their background or function?
I would say to have patience. With my developer background, I understand the technical nuances of most initiatives, but I respect and appreciate that teams have different levels of technical expertise. Some teams might use 10 tools a day, while others may still work primarily in Excel.
If you see a better way to do something and want to introduce it in those teams, be patient. Realize those teams will need support and time, and make sure you have realistic expectations around how long it’s going to take them to adopt that change.
Also, be there for support and remain flexible. If there’s a hard cut-off date, it can leave the team feeling like they’re out there on their own. That can be scary to a lot of people — thinking that they will have no support afterward and being afraid of breaking something. People will feel more comfortable if they know you’ll be around to help with whatever breaks. Let people know that this is not just one and done — we’re going to do this, and then we’ll see how it works. This approach will alleviate some of their concerns.
Lastly, make sure to engage them in the decision-making. You need to work with teams to really understand what they are doing before suggesting a change. This will make them feel like you’re making decisions alongside them and valuing their input, and will ultimately help build their confidence in the entire change management process.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.