In teamwork silence isn’t golden, it’s deadly. So let’s get talking with Viktoriia Honcharova, ETEAM’s Head of PMO, on how to successfully manage software development teams.

Viktoriia is a certified Project Management Professional (PMP) ® with expertise in Agile methodologies. She has over 10 years of experience in the tech industry, with a proven track record of managing software projects, optimizing business processes, and building high-performing teams.

So, without further ado, let's get started!

Q1: How is managing developers different from leading any other type of team?

In a way, managing developers isn’t much different from managing other teams of professionals. A healthy, transparent work environment is just as important as it would be for anyone else. On the other hand, there are some characteristics I found that make development teams unique.

Developers do a lot of problem-solving, so it’s important to allow them time for deep work. Interruptions and unnecessary meetings can take them out of this creative flow. Ultimately, developers are knowledge workers. This means they are smart and curious by nature and project managers need to match this level of intellectual prowess.

“Because I say so” just doesn’t work with development teams. Sure, as a project manager, you are assigned a certain level of authority. Still, this assigned authority means nothing if you cannot speak the same language as developers and show them that you are both capable and willing to understand and support their work.

Q2: Development teams are increasingly spread across time zones and countries. What does effective management look like in this context?

Globally dispersed teams are the ultimate test for PMO practitioners. Small issues get magnified x10 when distance is involved. That’s why managing this type of team requires solid communication. Most of the work is done asynchronously, so you have to make sure everyone can complete their tasks even if they cannot be online at the same time.

I cannot stress enough the importance of documenting your processes and setting ground rules everyone can refer to regardless of their location. This ensures both clarity and accountability, two aspects global remote teams struggle with the most.

What we found works for us is setting a standard time for availability. Regardless of time zone, we make sure there’s at least a small overlap when everyone can be available for communication. We also use a handbook to document everything from communication channels and tools to good practices to follow when giving feedback or scheduling virtual meetings.

Q3: What are some key principles or practices your team follows to successfully deliver software development projects?

I think values are an overlooked part of project management, although, in my opinion, they are the fundamental basis of collaboration. In my work, I follow ETEAM’s values and the PMI (Project Management Institute) guidelines of equity, agility, and continuous improvement.

So what does this mean in practice?

First, all development projects, regardless of size, scope, or budget are equally important and deserve the same level of commitment. As the Head of PMO, I make sure resources are allocated fairly and every client request is treated the same in terms of service quality.

Secondly, agility doesn’t only mean you should be ready for change. It also means you should be skilled enough to implement change without creating chaos.

And, last but not least, you cannot successfully deliver development projects without learning a lot along the way. Continuous improvement is a must in this field.

Q4: Between managing client expectations and managing software development teams, what is more challenging in your work?

I enjoy building relationships both with team members and clients, so I don’t see it as a challenge. I think the actual challenge is aligning the different definitions of success and finding a balance between client success, team success, and company success.

I think the best companies are the ones who involve developers in their strategies, so they can see how their day-to-day work contributes to the overall company's success.

Also, clients have their own understanding of what a successful project looks like, which might not always be the same as how the team sees it.

It’s my job to create a shared understanding of success. Traditionally this means a project that is on time and on budget, but there are a lot of other aspects you need to balance. You can have the happiest clients in the world and the unhappiest team, or a company that consistently delivers projects and is still not making a profit.

Q5: What makes a good Head of PMO and what would you recommend to help project managers grow?

As a Head of PMO, you need to be a lifelong learner. Some of the best practitioners I know are constantly taking courses in different programming languages, UI/UX, or QA methodologies. Not because they will ever work in these professions but because they want to really understand and support their teams.

Similarly, I would advise project managers who want to take the next step in their career to invest in certifications and industry-related activities. Becoming a member of PMI and the PMI Ukraine community contributed hugely to my professional development. I am lucky enough to be part of a great network of project management professionals who support each other with recommendations and advice.

At ETEAM, we are also putting together an educational program for project managers looking to transition from middle to senior positions. Based on a competency matrix, we developed a curriculum project managers can complete at their own pace.

Q6: How do you identify and tackle obstacles during development before they turn into blockers?

The earlier you catch an issue in development, the less likely it is to turn into a blocker. This is why we prefer to assign one project manager per project, so they can follow up closely with the development team and handle challenges as they arise.

I’ve recently written an article on this topic where I explain that in software development work rarely comes completely to a halt. Most of the time blockers act more as drag factors than show-stoppers. This can make it more challenging to pinpoint the real cause of an issue. 

The most important rule here is to constantly monitor progress to catch early signs of trouble. This includes silent blockers that might be chipping away at your team’s productivity in a more subtle manner. By conducting a risk assessment before each sprint, we can identify potential bottlenecks and dependencies, and decide if a user story is ready to be implemented.

Q7: There's been a lot of debate about whether you can measure developer productivity. What is your take on metrics?

There’s an analogy I really like called the “watermelon effect”. Just like a watermelon is green on the outside and red on the inside, stats can be all “green” on the surface, but when you look in-depth things are not going as great. You cannot rely on numbers alone to tell you the whole story.

A strictly quantitative approach burns out developers and pushes them to write low-quality code to meet their quota. Rather than counting lines of code or the number of daily commits, you should look at the quality of the code and the outcome.

Does the work lead to increased user satisfaction, less code to be rewritten, or more successful deployments?

Also, in Agile we don’t look at individual productivity as much as we look at team success. Let’s say you have a developer who codes less but whose contribution is essential to others’ work. You would never be able to recognize this if you didn’t look at the team’s activity as a whole.

Q8: Companies often reach out to you to augment their existing skills. How do you approach working with clients' in-house teams?

Staff augmentation is an increasingly popular option among companies looking to add outside developers to their teams. In this scenario, it’s important to create an environment that works both for internal teams and external collaborators. To do this, I follow a few simple steps.

First I sit down with the in-house team to discuss expectations and responsibilities.

• Will they be acting as consultants or supervisors?

• Will we be working on the same application simultaneously?

By establishing roles very clearly, we make sure there are no overlaps. 

This also allows us to set ground rules. We discuss and agree on collaboration terms, including what channels we’re going to use to keep in touch and which side will handle project management and planning.

Of course, no rule is set in stone. By asking and providing feedback we can review and adjust as needed.

Q9: What advice would you give to someone managing a product development team without having a technical background?

I’m sure a lot of non-technical SaaS founders will relate to this as well, not just project managers. You’re in a meeting with your product development team and someone mentions how PHPCS detects PSR-12 violations. You quickly write everything down to look up after the call. In the early days of my career, Google was my faithful assistant in decoding such confusing abbreviations.

What I’m trying to say is that you don’t need a technical background to manage software projects, but you do need a strong desire to learn. Software development and leadership require different skills, so no one expects you to be a tech wizard. But you do need to master the basic concepts and have a good grasp of the stages of the development lifecycle.

We recently started working on a technical playbook for project managers and non-technical team members in leadership positions. It covers a lot of the definitions and abbreviations that send executives running to Google :) Our goal is to provide the stakeholders with a collection of useful articles on software development, going from simple to complex.

Q10: How do you see AI influencing product management and development?

People usually think of AI in terms of chatbots or self-driving cars, but AI is also becoming part of the process through which these products are created. Developer assistants can inspect code, highlight errors, and even write code snippets themselves.

When it comes to customer feedback, a lot of companies still rely on structured data. AI will make it increasingly possible to tap into unstructured data like social media and comments on forums to understand how customers feel about your product.

And then, of course, we have project management platforms like Jira and ClickUp incorporating AI prompts to create tickets more easily.

These are just the first examples that come to mind, but there are dozens of other ways AI is changing product management and development. What’s important to remember is that AI supplies the tools, but it’s up to us to make the best decisions.

Q11: What are your thoughts on 2024? What will be the main trends, challenges, and opportunities in project management?

Since we already talked about AI, we’re likely going to see it used more and more in project management, from simple things like creating meeting summaries to very specific tasks such as reviewing acceptance criteria for user stories.

The last few years have been particularly challenging following a global pandemic, the war in Ukraine, and now rising tensions in the Middle East. I feel like the days of innovation for the sake of innovation are gone. Going forward in 2024 and beyond, digital products will focus more on social impact and making a difference in the world rather than coming up with whimsical features.

I’m talking, for example, about digital platforms providing accommodation, employment, and mental health support to refugees or reconnecting displaced people with loved ones. Diversity, Equity, and Inclusion will play a key role in project management and so will accessibility in product development.

Q12: Let readers know something personal about you. Do you recall a memorable or funny experience from your career?

Outside of my work at ETEAM, I am quite passionate about project management education. I am the VP of Academic Outreach at the PMI Ukraine chapter, I mentor project managers and give presentations relatively often.

Given my interest in lifelong learning and education, people find it pretty funny when I tell them that I almost failed my second year of university. I like to joke that I’m in good company since a lot of Silicon Valley tech billionaires don’t have a college degree.

For the record, I did finish university but to this day I prefer hands-on learning to having a diploma for the sake of a diploma.

You can follow Viktoriia on LinkedIn.

Make sure to also follow ETEAM for more behind-the-scenes insights on software development!