How to gradually decrease my involvement at a project for our client?

Question

I am a senior lead developer at a project for one of our clients at a financial institution. In the foreseeable future, I am going to be removed from this project to work for a different client. This decision was made by our company and it is immutable.

Theoretically I am responsible only for the technical side of the development.

In reality, I am responsible for

• the release management
• BAU-type daily jobs
• architectural decisions
• since there is no PO on the project, I partially do his job
• I advise the Business on how to specify the new development requests

The PM at the client has absolute confidence in me, he builds on me, which is my problem. Regardless of the PM's preferences, I am going to be moved to another client.

I would like to gradually decrease my involvement in the project, so that my transition does not shock the client. This is exactly, what my direct supervisor asked me at my company, and I understand why he asked me this, it is perfectly in alignment with what I want to do. How do I do it, if there is no one to pass these jobs on to? The other developer and at the Client (and other colleagues at the Client) are not capable and trained to handle what I currently do. These people sit in the office and read the online newspapers, instead of working. If they are not reading newspapers, they are talking about abstract theories on agility and scrum. I understand that it is really unprofessional to say this, but these people are a joke.

Should I gradually stop answering letters? Should I remain silent at decision points when people expect me to lead? If I do this, I expect to see damage to the project, which again: is not something I would like to cause. When someone comes to me in need of help, as I am seen as trustworthy, do I refuse it? What should I do?

Answer 1

The first step in any transition is defining who is responsible for each of the items you are passing off.

Take your list of responsibilities and have a meeting with the PM. For each item, ask them who is going to take that over. Then sit with those people and explain what you do for those specific responsibilities.

Once that is done, do NOT speak up or give direction about those areas unless you are directly asked. Even then, give an opinion and deflect to the person who should now take over that section. If someone talks to you directly about those areas, point them to the right person that is now handling it.

Answer 2

This is needs a proper transition strategy that's communicated and aligned with all parties involved.

Your own suggestions are likely to make things worse, so I would recommend getting help. I would lean hard on your own management to work out an official plan, communicate this to the client and set proper expectations on what will happen going forward: what work you will (or will not) be doing, for how long and for how much money.

I strongly recommend against "gradually fading away". That's just going to frustrate everyone (including yourself) and will generate a lot of friction of trouble.

Answer 3

You only have part of the information. You know that you will be moving away from this client onto something else within your company (at your request, it sounds like) but you don't know what has been communicated to the client already about this, if anything ... you don't know what the transition plan is, or whether your company has thought about that.

Clarify with management

Whoever your "management" are -- whether that's a project manager, client liasion person, programme office or however it works in your company -- the people managing the relationship with that client are the person/people you need to talk to about this, and figure out from them how you need to proceed.

You are the development lead (as well as wearing many other hats, it sounds like) but it seems that you are not in charge of the client relationship as such -- especially in relation to your comment where I asked if you are being replaced with another developer or your company just won't be involved with that client any more, and you said that you don't know that. (Which is fine, but just indicates you don't have visibility of that side of things!)

Identify whoever that person is, who manages the client relationship. Speak to your boss if needed to find out who it should be.

What to communicate to the client

This will depend on the guidance from the "person who manages the client" identified above.

In general... don't just go silent / less forthcoming / etc on catch-up calls without any context as that will most likely be perceived negatively. On a day-to-day basis carry on being the 'lead' doing whatever you've been doing so far.

I re-read your letter and it seems that there may be "another developer" in your company who also works with this client? (but unclear so I've asked in a comment) If that's the case, or if there is someone else in your company who can pick up your stuff... maybe their intention is that this 'substitute' developer could/will take on the work with this client on their own?

If it's the case that you are handing over to the developers at the client and there isn't a direct replacement for you (which I feel like it is, but this is just an intuition so don't take it as fact) I would suggest you:

• document everything you can about your current processes. What do you do to carry out a release for example? What do you do if you get "this error" during this step? etc etc.
• Not everything can be put into a "if then else" checklist, especially architectural decisions and stuff like that. But you can document why specific architectural choices were made, things to be aware of, gotchas, future considerations, etc.

In any case you need to know what is going on from your side, before sharing anything (or changing anything you do) with the client.

I wouldn't proactively share any of these things (i.e. documents, checklists, etc) with the client until you have clarity from the person who manages the relationship with the client, but have it ready to go.