Awesome Conferences

Survey: What makes joining a new team difficult/easy?

The last time you joined a new operations/devops/sysadmin team, what make it easy or difficult to get started?

For example... if procedures aren't documented, it can be very difficult to know how to perform them. The rest of the team does them by memory, but you are spending your time asking for help, or guessing your way through them. Well-documented procedures (or even tiny bullet lists) make it easy to be self-sufficient quickly.

What have you found made assimilating into a new team difficult? What have you seen teams do that made it easy? What did you wish a team had done to make it easy?

Please answer in the comments.

Posted by Tom Limoncelli in Survey

No TrackBacks

TrackBack URL:

10 Comments | Leave a comment

Lack of proper documentation, and a culture that espouses "our time is too valuable to write docs". A 'closed' culture where "if you're not automatically an expert, you must be an ignoramus too stupid to work here" doesn't help either.

Lack of documentation in my complex environment was the biggest problem. Second was not knowing when to say something or ask something. Is it politically smart to speak to people other than my boss?

Always documentation, even in environments where SOPs and SWPs were documented, there are always gaping holes that someone thinks "are just the way is done, everyone knows that." Much of the time that was due to.understaffiny because the moment they were done setting something up, it was off to the next fire, documentation can be done another day.

I was also dinged early on at that place for asking someone who I didn't directly report to after being told to "just ask anyone whenever you need something."

It's always documentation, I'm forced to dig on piles of archived emails and PST files to find something useful, combine that with knowledge hoarders :/...

Also the non existence of an unboarding process , this does play a role in the first 2 weeks

What absolutely kills me is a lack of Role-Based Access Control. It's so easy to delegate authority based on groups, but time and time again, I see places who go a long time between turnover events struggling to remember, "wait, what do you need access to? How do we do this?"

1. Lack of documentation or documentation, which is not up to date/incorrect (not sure, which one is worse) makes things difficult.
2. Lack of general friendliness as well as basic planning - been to companies/teams where the whole introduction to work and team was like this:

- Hi, here is your desk - sit down and do your stuff
- Thanks, but can I get a laptop or access to any computer?
- Actually, we forgot to order one for you - please wait few days, sorry... (I'm glad that I had TPoSaNA ebook with me, so I managed to survive few days waiting for a laptop, sitting in a 4 person cubicle, where other guys only said 'Hi' and that was whole introduction process)

3. Too many (e)-learning courses required to be able to start any real job. In one place I had to spend more than week to do about 50+ courses (mostly irrelevant to admin job) before I was allowed to do any real work - of course, it was difficult to remember all the details included in these when they were so condensed over a short period of time.

1. Where there is a process to onboard new people
2. In one company, there was a role of 'buddy' who had to spend some time with new employee, show the premises, show how most common tasks are done (in addition to a documented process), etc
3. Where a team is friendly, organises taking out the new member to lunch/breakfast/drinks or any kind of informal get-together.

complaining about no documentation is one thing, equally bad is documentation that is formulated overly abstract and full of ITIL speach, up to a point that it's no longer helpful and you need ages to match all the abstraction to the real world you have in front of you.

Another nerve wrecking thing is to have team that only has one "special matter expert" per topic, and ones that person is away for whatever reason nobody else can support that area of expertise. Often encountered in pair with ignorance about the area of work other colleagues work in (not my topic, pester someone else!).

Now the last time we had some new hires we prepared a three week long introduction period. For everyday we defined topics to talk about and for half of the day someone would give some kind of lecture on the whiteboard to introduce our infrastructure step by step. I'm not sure how nerve wrecking that was for the new colleagues but it seems to me that it wasn't the worst starting experience.

it was hard to join the team 'cause of:
* as always a lousy documentation of complex systems
* big heads thought they were pros, but in the end no system was really finished (missing backup jobs, missing metrics, missing security)
* loud, louder, the loudest wins
* no onboarding
* lack of security at all

After some organizational changes I'm now the head of it - and with that a lot of changes which leads to a much performancing IT world with less outages. IT ops cost lowering by nearly 20% by staffing up.

And the loudest left first.

One more comment regarding documentation - I think hiring a new person is a good opportunity to test documentation as a part of onboarding new person.
We used to do it in one place - if a new person was able to follow documents and perform troubleshooting/deployment/change (using test environment) - it meant that documentation is good enough (and new employee also learned something). If a person was confused or found pieces using internal jargon - we just identified room for improvement.

I should also mention that general attitude/atmosphere is important, as first impressions matter. It is different when one is greeted by somebody saying, for example: "we sometimes have to stay longer hours, sometimes it gets really busy, but we do AWSOME stuff and company is happy with our performance" than by colleague, who on your second day says: "you know, I work here for X years, but I hate this job, I cannot develop any skills here, there are a lot of idiots in the company, it is constant uphill struggle" (after some time it appeared to me that this guy is just like that and he was quite happy with his job/life).

So I think it is not the best idea to send the most gloomy and grin person in the team as the one who will induct new team-member ;)

Good stuff: Technical documentation on all 7 layers of the OSI in a secure wiki, and then more notes on layers 8-10, maybe somewhere else.

Bad stuff: not having any of the good stuff

Leave a comment