1. Managing Outsourced Vendor Staff
There are challenges unique to managing outsourced staff that go beyond those of your own people because there are many more risks you need to manage to build and retain a capable, stable, and knowledgeable team. The extra degree of separation and contractual mechanism between you and your outsourced staff introduces challenges in attaining this goal, and I’ve witnessed many a company struggle to manage the fallout of incompletely managed resources and vendor relationships.
Relationships with offshore software engineering vendors generally fall on a spectrum that encompasses three main engagement types. At the highest level of commitment and risk for a customer is that of outsourcing almost the entirety of product development to an offshore vendor, save the product ownership, infrastructure, and release management functions (wholistically speaking). At this end of the scale there is little day-to-day management of development activities assumed by the customer. In the middle of the range is a managed team including a scrum master, developers, and quality engineers, with perhaps some development management oversight provided by the vendor. The benefit here is the vendor guarantees to provide a team and relieve you of the mechanics of keeping the team fully staffed. At the least committed end of the spectrum is of course straight-up staff augmentation with token oversight provided by the vendor, and daily management of committed resources expected to be retained by the customer.
For the purposes of this section, I’m going to discuss the most common engagement type I’ve worked with, being the staff augmentation model, as for all intents and purposes these people really are your people. Even in a managed team model, you invariably have many of the same management considerations in play anyway; they’re integrated into your organisation and so you need to make sure they are well treated and motivated.
1.1. The Two Main Problems with Managing Outsourced Engineers
The risk assumed by the vendor is inverse to the risk assumed by the customer; at the product development end of the scale, they have a lot of skin in the game, but almost no skin in the game with the staff augmentation model. In staff augmentation there is very little pain caused to them by rotation of a resource, but as the customer who needs to manage knowledge transfer, velocity, and deliver on expectations to the business, it is very painful. As a service provider it should be incumbent on them to manage this risk, however vendors do this to differing degrees of effectiveness, and I’ve experienced deficiencies here that have resulted in painful and immediate impact more often than not. It is common for vendors to move resources into newer, higher priority projects, with token regard given to existing customers and no effective way to mitigate the damage they create in so doing.
The second main problem a staff augmentation customer has is that a customer generally has no way to be responsive to changes in the employment market where the staff are located, and if resources start dropping because they’re leaving for more lucrative opportunities then contractually there isn’t a lot you can do to prevent or remedy it (unless you build that mechanism in, but we’ll get to that). For your onshore resources you can manage this, budget permitting and all else being equal.
Now, referring back to the ITIL definition of a service, at the end of the day and outside of relief from the HR burden of your offshore resources, there aren’t a lot of risks that the staff augmentation model is really managing for you. Therefore, left to you, you have to manage these people yourself, you need to be able to treat them as your own, and you need to have mechanisms built into the vendor agreement to give you the flexibility to motivate them in the same way you would your own people.
1.2. Stipulations in Vendor Agreements
1.2.1. Anti-Rotation Clause
To reiterate, a way is needed to make it unappealing for a vendor to remove a resource from your project. In the case of offshore outsourcing, the value proposition of a cheaper rate can be quickly offset by the side-effects of replacing core resources. At a minimum, other resources need to take time out of their sprint to help onboard a new resource, the new resource is not fully productive for some time, overall velocity drops, and promises to the business become harder to keep.
The idea is to implement a penalty for moving a resource out of project for whatever reason except outright loss of the resource from the vendor’s employ. This could be in the form of a free or heavily discounted rate for some period of time until the new resource is up to speed and productive at a minimum acceptable level. Over a three month penalty period, for example, this would represent a sizeable dent in the vendor’s receivables.
In the event that the vendor decides to take this course of action anyway, they should be required to continue to provide the resource on a strictly managed part-time basis to prepare and onboard their replacement. This is not an impossible outcome; I had to do this with two rockstar resources that I was going to lose one way or another if they weren’t promoted within their company with commensurate pay raise; they were both red in the career progression category and very attractive to other employers. As a result of the risk of leaving assessment, not only did the vendor identify this issue soon enough to stave off talent loss, but the resources got their promotion and pay raise, and I got to keep them part time for another several months to help transition, over which time I got their replacements for free. It still wasn’t an ideal outcome, but had they chosen to leave outright, I would have had no chance for mitigation at all. There is too much risk to not having a stipulation to protect you in this scenario.
1.2.2. Risk of Leaving Assessment
Require the vendor to perform a periodic “risk of leaving” assessment activity, and to report results to you so that it puts the power in your hands to mitigate potential risks in knowledge loss, and to help drive incentive planning. The assessment should seek to uncover, at minimum, the drivers behind each resource’s employment and in their current role, such as desire to get deeper into a specific technology stack, desire to move up into a higher, more challenging role, desire to work in a certain industry or within a certain mission-set, and compensation. Have the vendor rank them in each of these dimensions on a scale of green, yellow, and red and deliver these results to you on a 3-6 monthly basis. For example, a red in the technology stack category might mean that their departure is imminent on account of their not being aligned with the stack with which they want to work, or that they’re not being used in a senior enough technical role to be challenged.
Integration of this assessment into your management plan is powerful because it gives you visibility into what is otherwise a black box, and your resources may not necessarily be prepared to give you this opportunity if left up to their own devices. This information can be used to drive a couple of different outcomes depending on what you learn about an individual’s drivers. In any event, the course of action comes down to understanding the alignment you need to try and create to make them want to stay.
The first outcome that this information enables is alignment with their technical and seniority goals. In one instance I had a resource that was simply aligned with a stack that didn’t excite them. I had asked the vendor for a Java resource, but I knew no better because it wasn’t in this resource’s nature to advocate for themself. Moving them from Java into node.js (we had a polyglot platform) made the difference to their desire to stay. This was one of the easiest fixes I could hope for. In another instance I had a resource who desired a more senior technical role that I didn’t immediately have an allocation for, but it enabled me to have an open conversation with them about the ways in which I could coach them from a skills perspective, even though the formal role wasn’t in the org chart. They wanted to stay because they saw someone had an interest in their career progression. These outcomes are simple to create if you know what you’re working with, and it sure helps if the vendor knows it’s expected of them.
1.2.3. Staff Incentive Clauses
Over one period of time I had to manage through a rapid drain of offshore resources from my team due to their being poached by US firms that had cottoned on to how talented developers from this particular region were, and from one specific vendor in particular. The firms were offering to engage them directly without middlemen and were offering them several multiples of their current take-home to entice them to leave. Unfortunately, I lost a handful of front-end developers over the course of a couple of months to this.
After this started happening I reached out directly to my number one mission-critical offshore resource to see if they had also been approached, and sure enough, they were receiving compelling offers. I immediately went to my vendor manager and told them I would offer the internal title of Associate Architect within my project and be prepared to significantly up the hourly rate I was paying for that resource, as long as they agreed to pass that increase along to the engineer. It had to be immediate and compelling. Such was my relationship with that vendor that they promoted the resource in title and pay, and to my surprise they did not even pass on an increase in billable rate to me. The resource themself was beyond excited and was even more highly motivated than before.
This outcome taught me a lesson; in the future I needed a contractual mechanism to recognise and incentivise highly performing resources within my project; the vendor would need the capability of divorcing their compensation from whatever internal pay structure they typically work with. And if that would turn out impractical for a vendor, I would at least need a way to pass large individual incentive payments through to highly performing resources.
If you build these clauses into your vendor agreements, you’ll mitigate risks that you cannot traditionally manage otherwise.
Next Up
Overall, this series is not about the specifics of how you perform the technical tasks required of your department, but it does speak to those tasks' governance. Naturally, managing and building the platform requires a deeper level of technical contextual awareness than general leadership and management, and the way in which your organisation and people map to those tasks and the ways in which you take care of the platform itself are very much in the area of interest of this series. The series will therefore take a turn now and start to drill into those areas.
You can pick up my next post titled "Managing Technical Debt" here.
No comments:
Post a Comment