BobJonkman: Reformat

2017-10-13T00:42:13Z

Reformat

BobJonkman: BobJonkman moved page NPSA Meeting Notes for 2016-09-19 to Smooth Succession/Meeting Notes for 2016-09-19: Meeting Notes go below Meeting Announcement

2017-10-13T00:23:38Z

BobJonkman moved page NPSA Meeting Notes for 2016-09-19 to Smooth Succession/Meeting Notes for 2016-09-19: Meeting Notes go below Meeting Announcement

BobJonkman: Categorized: KWNPSA Meeting Notes

2017-06-13T19:46:57Z

Categorized: KWNPSA Meeting Notes

BobJonkman: Draft page for Meeting Notes: Smooth Succession

2017-01-13T08:27:13Z

Draft page for Meeting Notes: Smooth Succession

New page

Smooth Succession
=================

### Future session: Documentation
- What do you document?
- What tools do you use?

### Future session? Coming up with time/effort estimates?
- How do you be realistic but efficient
- How do you justify unanticipated difficulties

### Questions

- Have you taken over from another person leaving? What was helpful? What was frustrating?
- What preparations have you made so that future people can successfully transition into your work?
- What barriers and challenges are there to smooth succession?
- How do you transfer institutional/oral culture?
- What best practices are there for documentation?

Our IT hats
-----------

- Schoolteachers: often one person gets picked to wear the IT hat
50 staff, 300 students
+ He deals with tech support questions
+ The board has a regular IT department but the ratio is high: 1 person for thousands of users
+ Tickets take a lot of time to resolve from the IT department
+ Teachers often have to pick up the slack
+ The IT staff they get in now are younger
+ The software stack seems to work better now
* Software compatibility would break when deployed
* eg a network game would break everything else
* Now they test deployments better
* But this reduces spontaneity
+ What about interaction with the school boards? How do documents get passed around?
* This is more centralized now
* They were going to give all kids their own email accounts
* Schools have logins for their kids now
+ Some school boards do BYOD (Bring Your Own Device)
* This is cheaper for the school boards, which can't keep up (and budgets are tight)
* They use the same number of IT staff for the Catholic school board as they did for the entire high school system
* This probably implies web interfaces for everything

- Small non-for-profit, 25 staff
+ Prior to joining his director was the primary IT person
+ They signed a contract for hardware/software support
+ Now there is an IT committee
+ He made the mistake of admitting that he "knew about computers"
+ The organization decided to move to a cloud based service (Sharepoint) with a data migration
* This was somewhat painful because the outside supplier did not tell them about their slow upload speeds
+ He does software/hardware problem solving
+ He does software upgrades: Office 2013/Office 365
+ Does training on the Sharepoint move
+ They are trying to transfer knowledge from the director's head to the collective
+ They have a local server
+ They also do BYOD
+ Getting information for connecting computers to the server is tough
+ How can staff do their jobs day to day
+ Do people prefer Office 2013 to Office 365?
* There is more functionality in Office 2013
* eg they have a room booking spreadsheet that has pane-freezing problems
+ Do people have problems with file versioning?
* Not really
+ They have had communications problems with outside tech support
* Even doing hardware audits and internet connections was tough
+ Getting people up to speed in Sharepoint is a big issue
+ People have problems adjusting to change
+ Where is the storage? It is all on the Microsoft cloud
* How do you deal with shared documents on Google Drive?
* You can map your own drive to a drive letter but cannot access shared drives
* OCAML FUSE driver under Linux for Google Drive
* https://github.com/as...

- Approaches to succession at a large company
+ There were procedures that were documented in a lot of detail
* Important for time-sensitive stuff (eg batch jobs)
* People did document well
* You could search a spreadsheet for jobs to diagnose
+ Disaster recovery testing were documented in a lot of detail
* He participated in disaster recovery one year
* A coworker then started the next year, and he gave pointers
* The documents were well-written and a good guide
* Reviewing the documents well before is important
+ Management was invested in making sure that documented were well done

- Another co-op job was not as smooth
+ A small one-person operation was not documented well -- much of the knowledge was in this person's head
+ Maybe this person should have done more documentation
+ The boss was very time-conscious, so he documented only the most complex issues
+ Writing things down is a good buffer for dealing with remembering stuff that is on screens
+ Is commenting code financially efficient? There is a short-term/long-term tradeoff.
+ Implementing better error tracing can be used by future people

- He was working for a small startup where the emphasis was getting things as soon as possible with no succession of any kind
+ There ought to be good handoff procedures
+ This can be an issue with Google Summer of Code: people hang out for four months and leave
* But sometimes there are good changelogs

- Succession horror stories (small nonprofits)
+ He would like people to assign administrator access
+ Most organizations are staffed by nontechnical people

- When going to new organizations
+ He had to explore how things are hooked up and why
+ Naming conventions were weird
+ He changed some of the printer names and got into trouble because it messed up the network documentation
+ Other places have been decomissioning jobs
* He had to document everything before shutting things down
+ City of Toronto had a good disaster recovery plan
* Nobody should have to think in order to get things back up
+ Problems: system change and then documentation goes out of date
+ One on one training is better than doing no documentation

- He worked for an insurance company. Their disaster planning was based on insurance.
+ This is called "key man insurance"

- Worked for a university press
+ He kept the job for 30 years
+ He had a lot of autonomy in writing his job descriptions
+ Early on they had their own UNIX system and some people on Windows using UNIX tools
* User training was not difficult because typographers know how to type to get stuff done
+ But in 1999 things changed. Kids these days! They only know how to use word processors
+ Passing on old skills was hard
+ When he went on leave he hired a friend who knew the same skills
+ When he was getting closer to retiring there were a lot of meetings about the stuff he did. Other people were learning this but others didn't think they could handle the whole thing.
* The people who took his job have good communication skills and could change things to their preferences
* He found that his meetings were collaborative and good for problem solving
+ Things are going well but are slower
* eg there are fewer spreadsheet manipulation abilities
+ There is documentation in wikis. People can read them but not write to them easily.
+ Have others dismantled your work since you left?
* Yes
* They were thinking of shutting down the Linux servers
* They were going to migrate the functionality to a virtual machine
* The server ran for a year without being rebooted and continued to work
+ Working with text files on local servers can be simpler than the cloud, because of black boxes
* He had a lot of discipline to the structure of the data
* black box: you have a promise of input and output, but you don't know what is happening inside
* If the input data changes then everything can get messed up
* Can you troubleshoot problems when they come up
* Black boxes mean you can change the inputs and examine the outputs, but this is trial and error

- Is there good software for putting bounding box information on EPS information. He found a script that worked that was made of Perl and shell script.

- At TWC
+ Lots of complicated infrastructre
+ Some of it is documented but documentation goes out of date
+ People come and go
* Understand everything about everything
+ Oral culture (both positive and negative)
+ Documentation is like survivalist training
* Documentation that gets used stays up to date
+ Some documents are used frequently
* Write down passwords in a shared (encrypted!) document
* Multiple people working on a door system means documentation gets written
+ Documentation that is hard to write and hard to update does not get written (or gets written and is useless)
* Text only
* No screenshots unless absolutely necessary
* Trivial update mechanisms
* DRY : Don't repeat yourself
* Trivial to search
- OneNote
- Plain text
- Documents with good search
- Email (yes, really)
+ Write documentation as you go
* Too much documentation is kind of better than too little
* If you learn things twice then document carefully the second time
+ Some people consider lack of documentation as job insurance
+ HOWTO files can be helpful
+ Make things as self-documenting as feasible
* Drop README files in source folders
* Inline comments
* Documentation as file names
+ Log files and version control are forms of documentation (if you have the discipline)
* etckeeper is good for Linux systems

Best Practices
--------------

- Mind the bus factor and stay away from public transportation
+ Don't store documents in someone's personal folders

- Having good documentation is helpful. How does it get created?

- Never admit you know computers

- How do you keep documentation up to date as things change?

- Make documentation accessible

- Get good at trawling other people's work

- Do regular training for staff and volunteers
+ Forcing people's hands can help

- Start people small if you can
+ This way you can assess their skills and commitment

- Make new people do documentation as they work
+ This helps them learn the systems

Worries and Challenges
----------------------

- Being the person who gets hit by the bus
+ How do you spread information?
+ Continuous learning by staff -- raising everybody's level of knowledge
+ Management may not be on board
+ Do people understand that not having long-term planning leaves them vulnerable?
+ You can't boss around volunteers as much

- People think that the cloud solves backups and IT administration

- How hard will it be to step into a new position?
+ When we are unemployed because we don't have the tools
+ Money becomes a huge issue
+ Getting access to hardware is an issue

- How many times will you be called after you left?
+ Will you remember your old work
+ There is a sense of liability -- who is responsible when things break?

- Choosing the wrong successor could be a disaster

- Finding time/resources to transfer knowledge
+ Sometimes you need to be inefficient to be effiencent
+ Letting other people do the thing even though you could do it faster and more efficiently
* Letting other people do the thing in ways you would not do it
* Giving people good base levels of knowledge helps

- How do you learn the system while being careful and not destroying everything in a burning ball of flame
+ How do you make a good impression and getting things done both quickly and correctly

- Sometimes contractors get commissions with promises they cannot keep

← Older revision		Revision as of 19:46, 13 June 2017
Line 239:		Line 239:

	- Sometimes contractors get commissions with promises they cannot keep		- Sometimes contractors get commissions with promises they cannot keep
		+
		+	[[Category:NPSA]]
		+	[[Category:KWNPSA Meeting Notes]]

← Older revision	Revision as of 00:23, 13 October 2017
(No difference)

Smooth Succession/Meeting Notes for 2016-09-19 - Revision history

BobJonkman: Reformat

BobJonkman: BobJonkman moved page NPSA Meeting Notes for 2016-09-19 to Smooth Succession/Meeting Notes for 2016-09-19: Meeting Notes go below Meeting Announcement

BobJonkman: Categorized: KWNPSA Meeting Notes

BobJonkman: Draft page for Meeting Notes: Smooth Succession