Martin Tarhanič: The ideal projects work iteratively and don't have meaningless deadlines

You have so many years of experience, can you describe your journey, and what different positions did you go through?

At my first proper job, I started as a junior software engineer. Throughout my first years I managed to rise on the career ladder and became a senior dev. Unfortunately, later one of our most important clients discontinued collaboration and many people left. In the end, only a core team stayed which created a base for the following company I used to work for. There, I started as a senior and became a leader real quick.

I had an opportunity to work within the technical direction and also a chance to work as a project manager was offered to me. They wanted me on various projects, my doors were truly open. I never got tired of the job as I kept progressing during the entire stay.

The last position I had in the company was Head of Practices in Slovakia. In this position, we were working on 15-20 MVP projects per year, which introduced innovation and cutting-edge technologies (ML, VR, AR) into our proposals or ongoing projects. I really loved the position, until my daily job as a Project Manager took its toll and I decided to quit the company. One day Jozef reached out to me and that was the beginning of my journey in Sudolabs.

You haven't been with Sudolabs for so long yet, can you tell us when did you join and what is your current position?

It was almost a year ago. A vision of how to define my position was a project manager, but then the Product Lab (a department within Sudolabs that focuses on initial phases of product development such as product discovery, user research, and validation) was created and the structure was diversified. Currently, my position is called Engineering Manager. I'm taking care of people and their development throughout my career. Considering the fact I have a technical background it helps me to work with projects and understand the pain points.

Besides having a position, one can have different roles on the project - mine is Product Owner and Scrum Master. In this case, my job is to align with our client on what we need to work on next and what is the expected result. As a Scrum Master, I set the flow of the project throughout the different phases. It’s not only about morning meetings where we plan daily tasks, it’s also about the situations “what do we do now” when I need to facilitate the next steps. Practically, I organize work on the project but at the same time I don't have to strictly define who's gonna work on specific tasks, that's something tech leaders do. I only say what part of the project we need to deliver at a specific.

What are you currently working on?

Currently, I'm working on two projects - The Expert and Faros. I used to have 6 projects at the same time, but it was really overwhelming so we decided to reduce it into these two.

Do you have any favorites among these projects?

Faros is very close to my heart. It was the first project I worked on in Sudolabs and, paradoxically, was presented to me as the hardest to deal with due to non-existing project management processes on our side. However, within three weeks it worked perfectly once I figured out that the primary problem was lack of communication with our customer. My relationship with the client is perfect as well, it's not a large project but works like a charm.

What were the biggest challenges you needed to cope with when you came to Sudolabs?

Most of the problems were related to the communication with our clients regarding a project's daily work, impediments, and our involvement. It showed up on all of the projects. You can say that I'm the kind of a person who sees a glass half-empty rather than half-full and I don't necessarily claim that things have to be topnotch, but everything needs to work well. If I have a project that works but something is missing, I feel an urge to make it better, more professional, and effective so everyone can be more comfortable doing their work.

What would an ideal project look like from the project management point of view?

A thing such as an ideal project doesn't exist.

A good project starts with a customer who has clear and realistic expectations.

It's also helpful if a client has someone with a technical background on their side, this makes communication and understanding much easier. And of course, an internal team that cooperates together well is a great bonus.

Can you tell us what is the most important aspect of project management?

The first one would be to help our dev teams remove any blockers or impediments during their daily work on the project. Whether those are daily problems, anything within the team, personal, technical, process process-related, the manager is responsible. Most companies raise their own managers, usually former developers, so they possess a certain type of skill set. If this person is also able to lead and move forward with others it's just a win-win situation.

The second aspect of any work in IT is transparent communication. If the communication is not clear the entire project is not working as it should. Often when communication collapses, the same applies to transparency. Technical background is also quite useful, you know exactly what your team is building and you can help them with decisions if it’s wanted or necessary.

Estimates are a significant part of your job. How do you create them, or how should they be ideally created?

I used to work with time-based estimates (hours of work) but that never worked well. Even the most skilled people weren't able to truly meet deadlines set by this system and many projects were not delivered on time as promised.

What turned out to be the most effective way, was to create the estimates based on the issue's complexity, therefore we utilized story points in our planning methods. It starts with a team selecting an easy task as a reference. Then later during the estimation session, the team can compare other tasks to the reference one and to each other. It’s not that important to estimate them precisely, that's why it's made in the Fibonacci sequence meaning that you are just saying whether the task is more complex (harder to deliver) than the other. As a result of this method, you can say how many story points the team can deliver during a specified period of time (the sprint). Because you know how much work can be done in one sprint, now you can plan for a longer time ahead, let’s say months. It might be hard to retain the same metric as it's changing in one's mind after a couple of months, but that’s the time when you need to stop for a while, adjust, and continue.

What is the best practice when it comes to setting up deadlines and how to approach them?

Let me start with a little bit of theory. All projects in general have only three important variables you can work with: time (how much time we have to deliver the project), budget (how many people can work on the project), and scope (what needs to be done). What usually happens is that client wants too much work to be done in a very short time, and sometimes even don’t want to pay much for it. That’s why good management (project/product) is important to mitigate those requirements and come up with a feasible solution acceptable to both parties, the client and us. As a result of this exercise, an MVP project is often a solution, a short-term project with limited resources focused on delivering the basic, but usable, functionality to the final customer. That’s where you put your team together and start working on it, find the team velocity, know your team better, and accommodate a working relationship with the customer and their teams. When you have all of that done, you can plan for the future phases or features and it enables you to set more realistic deadlines if necessary.

To get back to your question, I still think that the best project doesn’t have any strict deadlines. The team should be working iteratively and delivering good work in the form of well-designed and tested (by product and engineering) features that are published to the final customer and their clients continuously. In the end, everything depends on communication which creates trust that allows us to enjoy freedom and possibilities.

On a daily basis you communicate with clients, what do you usually talk about and what does a meeting look like?

I always strive for direct communication with a client, it’s more effective and I can get all the answers to currently important topics. The standard is to have regular sync calls to keep the client in the loop - to present what we are working on, explain any blockers, emphasize team needs, discuss basic operations, and plan for future tasks or new features. These calls might also include a discussion about output from our internal team retrospective meetings.

Everything has to be properly communicated. There are no assumptions in this business, you can't rely on partial information, even if it's obvious, it has to be communicated clearly. All the outputs should be documented in form of notes, comments, or action points for future execution.

How should a client prepare himself in order to simplify collaboration with us, what does he need to know, or what does he need to deliver?

It mostly depends on the project setup and what kind of project competencies we have on our side. If we have the product owner in the team, obviously we need less to be done by the client. If it's the other way around, we need more information, for example, defined epics, user stories, or tasks. Also, it depends on who owns the technical stack, if there are any legacy systems we need to cope with, etc.

It's always about the agreement and setting “rules of engagement”.

The client has to secure a person who will be our contact and define the scope, what should be included, how it should work, and what should be an outcome. It has to be communicated clearly at the beginning who is responsible for which part in order to avoid any gaps in competencies.

The most common mistakes, that clients make?

The biggest mistake would be even before the project starts and it is a lack of understanding about what should be the scope of the project and why they want to build it this way. It often results in wildly switching project priorities and vast scope changes. Then sometimes the client considers one feature as the most significant, yet the next month they change their mind to do something completely different or even opposite. The result is a not working, expensive, and meaningless product.

We want to build great products, and our job is to lead the customer through the whole process from the idea to the working solution. As a team, we have a lot of experience and our mission is to help our customers to avoid any kind of mistakes.

What is the next challenge you see at Sudolabs that you would like to resolve?

The transition to a well-structured, professional, market-leading company.

When talking about this transition, creating new processes or rules, but also benefits and new opportunities, a lot of people here are afraid that Sudolabs is becoming a corporate type company. Although, not many people here even worked in any corporation before so I think it is of great importance to explain that all those changes are not meant to make their life worse. On the contrary, there is a lot of reasoning behind the change and it makes our projects more scalable, more projects or teams means more possibilities to grow in various areas, and better benefits together with a great workplace lead to more skilled people coming in and all of this will make our work easier and more fun.

With that being said, I think there are many and there will be even more challenges, so I think I’ll just be picking one after another and try to deal with them so we can turn back in a year or so and say, job well done!

What changes did you experience since working at Sudolabs compared to other companies?

I love the drive of the people and very open-minded thinking. Things are moving really fast forward and it’s really great to be a part of this progress!