Does a long notice period hold back your organisation?

My last role had a long notice period of three months.  Although long notice periods are intended to protect an organisation, I think they can act as a detriment.

I remember being concerned when I took on the role that a three month notice period could make job hunting tricky as and when I wanted to move on.  I could easily imagine this being a deciding factor for a team that wanted someone to start as soon as possible, no matter how suitable I was.

"Don't worry, you can negotiate it down when you want to leave" ... I was told.  This didn't really console me as broaching this subject would reveal my intentions of leaving before the new role was agreed.  In any event, I signed the contract and agreed to the notice period.

When it was time for me to move on (after four great years at said company) I decided to hand in my notice before getting my new role agreed.  I also elected to work my notice period in full and did not ask to leave early.

I thought I could make the long notice period work in my favour and also gain more of a sense of control by setting my last day as opposed to it being up for debate.  Any extra feeling of control to help with the jump into the unknown of a new job felt good.  It was also good not having to sneak out for interviews, and being able to talk openly with colleagues about my job hunt.  The other contributing factor was that my new role was to be freelance which typically involves getting work at much shorter notice.  To some extent my hands were tied here

After completing my notice period and handing over my responsibilities, I've come to a few conclusions.

If the handover takes a long time - something is wrong that can't be fixed with a long notice period.

If it takes you more than a month to handover your responsibilities to other members of the team, it suggest to me that you might be a key man dependency.  This should be addressed with continuous knowledge sharing and proper collaboration... not long handovers.  Don't rely on the long notice period to fix this important issue.

Short notice period

Looking back, I'd argue for a short (one month) notice period for the following reasons:
  • It forces you to address the issue of key man dependencies because you can't fall back on the "get out of jail free card" of long multi-month handover sessions.  
  • A team member who wants to leave will never be as committed as someone who wants to stay.  Why keep them longer than absolutely necessary.
  • It might stop potential candidates from joining your organisation.
Discuss...

Comments

  1. Ben S6 December 2014 at 02:21

    I guess notice periods work both ways though - e.g. if you are made redundant you get three months to find a new job. Interestingly the first job I had, didn't want you in the office once you resigned - so you were sent home - with full pay for the notice period etc. Same with people made redundant.

    ReplyDelete

Post a Comment

Popular posts from this blog

Lessons learned from a connection leak in production

We recently encountered a connection leak with one of our services in production.  Here's what happened, what we did and the lessons learned... Tests and Monitoring detected the issue (silently) Our automated tests (which run in production for this service) started failing soon after the incident occurred.  We didn't immediately realise since they just went red on the dashboard and we just carried on about our business.  Our monitoring detected the issue immediately and also went red but crucially didn't email us due to an environment specific config issue. The alarm is raised A tester on the team realises that the tests had been failing for some time (some time being 4 hours... eek!) and gets us to start investigating. Myself and another dev quickly looked into what was going on with our poorly  dropwizard  app.  We could see from the monitoring dashboard that the application's health check page was in error.  Viewing the page showed us that a downstream ser
Read more

How to connect your docker container to a service on the parent host

Recently I needed a docker container to access a service running on the parent host.  A lot of the examples on the internet were very close to what I needed, but not quite. First off, docker's documentation provided an example that (as far as I can see) doesn't actually work.  The following (I think) is meant to inject the src ip address of the parent host's default interface: $ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'" $ docker run  --add-host=docker:$(hostip) --rm -it debian What it actually does is inject the ip of the default gateway on the parent host which doesn't help us. Michael Hamrah 's blog details the " gateway approach " of getting the parent's host ip from within the docker container.  This works great, although I wanted to inject the ip on container run and not have that logic within my docker image. Inject the src ip of the docker interface I think the best
Read more

Client Side vs Server Side Session

Image
We recently looked at replacing our legacy session management system with a new one.  During this analysis, we came close to choosing a client side session but eventually concluded server side was better for us.  Here's why... Client side session In this model, all session state is stored in the client in a cookie.  The benefits of this are you don't need to worry about persisting and replicating state across nodes, session validation is lightning fast since you don't need to query any data store which means it's super scalable.  The session cookie must obviously be tamper proof (to prevent people creating a session of their choice) which is achieved by signing the cookie using asymmetric cryptography. The signing of a cookie value uses the private key, the validation uses the corresponding public key.  Our idea was to try and keep the private key as private as possible by storing it in memory only.  Each node (4 shown below) would create a new private and public
Read more