1

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?

  • 1
    When you say you will be moving away from this client and moved on to a different one -- will someone else from your company be working with this client in your place, or is it more that they will have less/no involvement on the development (release, architecture, etc...) side from your company any more once you are moved? – seventyeightist Aug 10 at 18:26
  • I really do not know this yet. – Gábor Dani Aug 10 at 18:27
  • I'm afraid this is a pretty key question that you need to get figured out with your management as that will drive how it's communicated. If your company is no longer supplying "someone" to help the client then that needs to be managed differently than if it's just a handover where you personally are moving onto some other client, but 'Bob' will be taking over your work with the original client..... If your company is no longer supplying any kind of dev/release/architecture/whatever support then this will have to be worked out at a high level between management of the companies!... – seventyeightist Aug 10 at 18:29
  • ...and if that's the case, how you communicate and deal with that client would be guided by your senior management e.g. whether you mention the transition, gently excuse yourself from meetings, etc. I'll write this up as an answer as "answers in comments" are discouraged. – seventyeightist Aug 10 at 18:31
  • 1
    So, big question: What was the BUS planning in place for this project and client? As in "if you get hit by a bus tomorrow morning" what will happen? – Solar Mike Aug 10 at 20:57
2

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.

1

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.