What does j-labs do?

Delivery Manager as a key to successful outsourcing operation

Article | Case Study

Deep insight into the role of a Delivery Manager but also into the culture of software development as a whole! 

The cooperation in j-labs is based on three models: augmenting the existing clients’ teams with additional developers from j-labs, dedicated teams or complete managed services. 

What all the models have in common is the presence of Delivery Manager, who acts as manager for the engineers, and as direct additional link between the clients’ managers and the developers at j-labs. 

Today, I would like to conduct an interview with one of our Delivery Managers to go in-depth into the specifics of his function, and how/why it is important for successful cooperation with our partners. 

Martin: To start, can you describe who a Delivery Manager actually is? 

DM: Delivery Manager is a person whose main purpose is to make sure that the job gets done, or to put in politically correct wording, that the service delivery goes smoothly. Clientss come to us to support them in particular projects and, as such, the Delivery Manager becomes their right hand, the person responsible for making sure that everything that they need will happen in the office in which they are not in person – in their perspective in the remote office. 

You are a problem solver/doer/superman! What then is your daily set of tasks? 

My engagement is versatile, depending on the point in the cooperation process with the client. In the beginning, I am involved in technical discussions with the client, to understand what kind of engineers the client needs, what competencies are required, how the team is right now (when supplementing single engineers), and I am responsible for actually selecting and creating the team. The team, which I can add, I will be later on managing on our side (each DM stays with the client from the first call throughout the whole cooperation). 

So it is in your best interest to create a team that is as problem-free/effective as possible, right? 

Exactly, yes. Of course, it requires cooperation with our recruitment team; as they recommend new engineers or consider existing engineers who are changing projects – I still need to discuss with them suitability to join this particular team/project. That happens of course together with ongoing sync with the client, who shares expectations, and who also, later on, verifies the suggestions coming from the Delivery Manager. 

What you are saying is that the work of the Delivery Manager has two aspects. One facing the client, and the other facing the team. So OK, once the team has already been created, then how do you actually work with the client during the project? 

So, assuming that everyone is in place, and knows when they start the project – the Delivery Manager from the first days remains in constant contact with the client. So all areas are agreed upon beforehand: who to contact, what communication channels to use – to make sure that everything works. And later on to gather feedback from the client if the team is performing as expected and if anything can be improved. Later on, this becomes routine – so periodically I meet with the client, and we exchange reports. I ask how visible the output coming from our engineers is to them, and discuss engineers separately. From the other side, the DM provides feedback about the team, how the engineers feel, what their feedback is. 

It would seem to me that the client’s daily contact remains more with the Team Leader, so how do you actually work with the TL himself. Or maybe from another angle, how does the TL work with the client, and where do you join in? 

So in principle, all of the TL’s working for the client have and need to have direct contact with the client – all information concerning the project and tasks itself is exchanged directly and the DM does not need to be part of that. Still, the DM is always next to the team, to check if everything works, if the TL receives clear guidelines, and can share them well with the rest of the team. The fact itself that I am with them in the office, and they have completely open access to me gives a lot to the engineers. From the other side, the contact between engineers and the client usually takes place via webcam/mic, not everything can be conveyed in this way. Things like feelings, morale, etc. are something that the DM monitors. 

Can you actually say that the DM is the “boss” of the particular team members? 

I would treat the DM more as a caretaker than a boss, taking care of them in order to make it as convenient as possible for them to conduct their tasks. Of course, he also deals with typical management stuff: increase in wages, holidays, sick leave information, etc. 

Yet, when it comes to the direction of the actual project work, then it is not directly your responsibility by design (though I guess it can happen), but the Product Owner on the client’s side? 

Yes, it’s the PO on the clients side who brings to the team the business and domain knowledge and who knows what the end goal should be. We supply more the culture of the software development – socalled best business practices, and not knowledge about particular business area. 

We are talking all the time in general terms, yet could you give some examples of projects, without specifying any details under NDA, where everything works perfectly, in other words, the best-case scenario, and later on some example of a project where your engagement was needed more than usual? 

I don’t think I am able to give an example of a project where everything ran flawlessly from the very beginning, though there are, of course, examples of teams where my engagement can be smaller. Problems and tension always appear when people are engaged in their work, it just has to happen, so a DM is always needed to be there for them even just to talk and discuss everything. 

From the other side, thinking of the most critical and difficult projects, then it is the most challenging when the client doesn’t listen. And that is both to the engineers who work for them, and also to the DM. Then, a problem appears, as the developers become frustrated, as they would like to have some influence, they would like to conduct their tasks to thbest of their abilities and create an overall very good product – and they face a wall from the client who thinks they know better. 

You touched on something very interesting here – the motivation and engagement of the engineer. Maybe it could be a good idea to describe the type of personality we usually have among our developers? 

Of course, each member of the team is slightly different, but if I could choose any common traits, then I look for people who I feel will be motivated, and who will take responsibility for the project and their work. Of course, they need to have a technical skillset on a certain level, yet the personality always wins in the long run. Of course, it’s not always possible for each and every person to be 100% engaged, that’s the reason we create the teams to complement each other. In a team, there is a leader who is responsible for the output of the whole team. 

What I was aiming at is that, by design, we always strive to create a deeply engaged team that wants to deliver real value to our client. Yet it is possible that the client doesn’t understand that, you used the word: wall. What does it mean to “hit the wall”? 

An example, I am and have been working with a client that is heavily sales-oriented. To put it simply, when he negotiates with a new client who expects additional development in order to start cooperation, then our client usually promises additional functionalities which simply cannot fit into the backlog – it’s simply too much, too fast. This causes stress among the team. For example, the team would like to “pay off the technical debt” which has been amassed over time, but it is not possible as new specifications always come, for yet another and yet another end client. 

Can I then understand that an engaged engineer complains that there is too much work to be done? Or is it not so simple? 

It would be too much of simplification. If you compare it with building a house, then once in a while you need to clean after yourself, cause if you don’t, you are working surrounded by mess, which could be easily cleaned if there was time for that, but there is no time as the investor is telling you to build faster. 

We are talking here about a culture of software development in which the client cannot find time for paying off the technical debt, as he is so fixed on developing the company, and bringing in new customers that he doesn’t realize that the problems will come to the surface eventually, and probably at the worst possible moment. But hey, aren’t there usually developers on both sides? I mean, our clients in the majority of cases have their own developers, so does it happen that our team sees things differently than they do? Or do they usually share a common engineering view? 

The developers usually speak in the same voice, they understand very well things like paying off the technical debt and understand the dangers of not doing so – that the developer becomes in that way more expensive. 

What do you mean more expensive? 

Well, when things are not cleaned, it can take much more time for a developer to make some changes later on. Things that should be done in 5 minutes can take 1 day – it really happens! 

Wait a minute. So do we inform the client directly about the situation? 

Yes, most definitely. 

So the communication from our side is always there, but in the end, it is the client’s decision about the direction the development should be taking, and we follow it to the letter. 

Yes, exactly, for better or worse. We are professionals who always respond to our client’s needs. 

I would like to move on to some other topics. Do you visit the client onsite? 

Now is impossible because of the Covid-19, but before yes, it happened, but rather on rare occasions (yearly planning, etc.). Personal meetings were much more frequent between the client, the client’s developers, and our developers, so workshops, etc. It also happened more often than they came to us, our office is prepared for that, so we have had a few situations where we even had 3 different workshops being conducted at the same time. Moreover, we all went out in the evening at least once during the visit – business is business but there’s no harm in a little fun as well.

Still, the communication between you and the client is always there. 

Yes, we set it up every time depending on the team size, team status (if its growing, and how fast), project status, etc. In general, I can say we have bi-monthly sync up. If there is anything urgent then we do not wait for the planned meeting, but the less urgent issues are dealt with exactly in those intervals. It is still important they do take place, as we tackle those less important problems/issues before they have a chance to grow later on. 

And during those sessions, it is you and the client’s representative (PO usually), so the team members and the TL are not there, right? 

Yes, those are usually one-2-one meetings. So they allow for more open discussion about the performance of the developers, their motivation levels, etc. 

Great stuff so far, actually that’s a lot of material to cover! Let’s try to head towards the end. I have just 2-3 more questions for you. What do you need from the client in order for the cooperation to be successful? Well, one for you, and the other what does the team need – those can be the same but do not necessarily have to be? 

The most important aspect is actually the openness of the client. What I mean here is that the client does not simply receive from us software developers, but the whole culture of development, the engineer’s experience not only from the technical side but also very often the business side as well (experience on how the project should be run). So if clients are open to my and the teams’ feedback, then they will gain a lot from us, as the development will be of better quality and quite often even faster, so actually cheaper. 

As for the team, being listened to makes a huge difference in their motivation and engagement. 

That sounds simple, greater engagement and motivation = better quality + less rotation. So are you saying that the team is directly interested in helping the client to be successful? 

Yes, I would even simplify that: everyone wants to see the effect of their work and to be proud of it (that it is in production, and it actually matters for the company). 

I will challenge you on that point then! What you are saying is that all of our 300+ developers are deeply engaged and motivated? That we do not have so-called “code monkeys”? People who code from 9 till 5 and then go home and do not think about it? 

Heh, well, let me try to think of someone who fits that description… 

…actually, I do not think there are such people. Even for some who try to be perceived as such, they still care if their work matters in the end. 

Great stuff! Let me get back to my previous question – what is needed from the client for the team to work well? You mentioned openness, are there any more specific details? 

What I would start with is a generally well-managed project, the engineers need to see a clear vision of where we are going and why, they need to know the steps/milestones that are planned ahead. So that’s exactly what we need from the client: domain knowledge, business context, and vision. 

Wait, I am surprised that you did not say here: a well-prepared significant backlog of tasks in Jira! Isn’t it needed for the engineers to know what to do? 

No, this is not needed as much. We need a clear vision, and if that is translated into Jira tasks – great! But sometimes a few tickets are enough to describe a lot. I have seen teams that close 2-3 tickets per day, and teams which close 1 in few days, and all of them were very effective. The number of Jira tickets is just a representation of how granular and detailed the tasks are. 

The last question then! What does the career path look like for engineers? You are directly taking care of them, so I guess it is a big part of your role. 

Yes, most definitely. So what I do is schedule one-2-one meetings to have a proper discussion with them. Thanks to that, I can listen to them, offer my guidance, suggest some possible courses and training (we have training budget available for everyone), or even think of roles/projects which will allow their growth plan to happen. So, for example, find a way for backend developers to do more frontend work as they want to become full-stack. 

Thank you for that! It was an excellent insight not only into the role of a Delivery Manager but also into the culture of software development as a whole! 

 

Author: Martin Konieczny, Business Development Manager @j-labs

The questions were answered by one of our Delivery Managers. Previously, a software developer for 10 years, using mostly Java but also with some experience with Scala and Ruby. During his time at j-labs, he decided to take on the role of Delivery Manager as a natural next step in his career.

◰ j•labs

Rejestracja na wydarzenie:

Delivery Manager as a key to successful outsourcing operation

Wolisz z nami porozmawiać?

ENZostaw kontakt
do siebie, oddzwonimy.

    Dane






    Informacja dodatkowe

    Administratorem danych osobowych jest j-labs sp. z o.o., ul. Montwiłła-Mireckiego 25, 30-426 Kraków. Więcej.

    Wyrażam zgodę na przetwarzanie moich danych osobowych w celu otrzymania informacji o wydarzeniach organizowanych przez j-labs sp. z o.o.

    * Pola obowiązkowe

    Twoja wiadomość została wysłana!

    Dziękujemy za skorzystanie z formularza kontaktowego, odpowiemy tak szybko jak to tylko możliwe.

    Nasze serwisy używają plików cookies. Klikając "Akceptuję" lub korzystając dalej z serwisu, wyrażają Państwo zgodę na politykę prywatności i cookies j-labs.