Seattle:Helping Techies and Non-Techies Communicate and Cooperate

From Penguin Day
Revision as of 20:01, 18 December 2015 by Miriam (Talk | contribs) (Created page with "Examples of difficulties we've had at the interface of technical and non-technical: * People tend to pretend to know a lot so they don't look stupid, within tech culture. * p...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Examples of difficulties we've had at the interface of technical and non-technical:

  • People tend to pretend to know a lot so they don't look stupid, within tech culture.
  • poor interface between techies and non-techies.
  • it's a continuum
  • it's so specialized - no one is super-techy at everything. the database person might not know anything about the server it sits on. those two specialists have to learn each others worlds.
  • the organizational decision maker is often not the most technical person, and often doesn't understand the urgency
  • in non-profit culture, there's also the problem of lack of funds, so the person who doesn't get tech also doesn't get the reasons to spend $ on it
  • there usually aren't absolute answers with people, but not with people.
  • there are always choices to be made by an organization. it can't always be the technical person who makes all the choices for them.
  • its useful to have people who have a foot in both worlds - people who get both the business model and the technology
  • tech consultants often don't give all the options - biased to begin with. they don't necessarily know it's the best tool for the job but they know it and so the org goes with it
  • consultant does a piece of work and leaves, and then its hard for a volunteer to pick it up
  • documentation is a big issue - too much of it is unreadable to non-techies, or even to techies who come in after the fact.
  • consultants who get in and get out and leave them in the lurch
  • how do you communicate what is fair to expect?
  • cheat sheets - documentation for how to do the things, found in the right places (instructions taped to the server, for instance)
  • http://cyber-yenta.org
  • the right question project - http://www.rightquestion.org/
  • the challenges of convincing a whole sector that technology isn't evil and is in fact essential to their mission - Kaliya
  • non-tech people need to be taught to prioritize technology more, or perhaps need a process around WHEN to call tech support, and who to call
  • communicate to people that their is a dollar value to this stuff
  • common complaint of techies is that they get called lots when it's not necessary
  • troubleshooting training is needed before you cut people loose. teach people how to figure out what's wrong
  • escalation plan - an order for who you call. first an internal person, etc. stop people from panicking first and picking up the phone.

SOLUTIONS!

  • Active Listening - repeating back what you heard, in your own words
  • "Show me what the problem is" - perhaps they really are having a problem because they're doing something differently than the way you do it, which works fine.
  • Even for seemingly simple proceedures, make check-lists. Document everything.
  • Trouble-shooting documents - use these resources available online. http://lasa.org.uk
  • when talking to people about why they should care, Relevance is key. Find what is relevant to people. Grandparents will learn how to use a computer when they get that it will allow them to send an email to their grandchild.
  • SHOW people the things you want them to get excited about
  • "inter-faith dialogue" - approach it not as evangelism but as learning about other people. figure out what their organization is trying to do, and then figure out what is relevant to them.
  • the flipside of relevance is relationship.
  • "relevance, relationship and rigour."
  • accidental techies need to document the things that they are doing! if you are spending time helping others do basic things, make sure your organization knows
  • put time into your workplan for the tech support you do.
  • when is the break-even point? when will the change you're making actually start saving you time and money?
  • shifting from "let's blame someone" to "let's team up against the problem"
  • techies have a responsibility to reduce the anxiety and defensiveness that non-techies sometimes feel.
  • instead of saying "so where do you keep your off-site backup?", ask "do you have a system for doing off-site backup - it's okay if you don't?"
  • we need a communication bridge.
  • accept that sometimes you aren't going to convince people.

THE THREE BIG ONES:

  • active listening, documentation, the importance of relevance

USEFUL LINKS: