Difference between revisions of "Seattle:Helping Techies and Non-Techies Communicate and Cooperate"
From Penguin Day
(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...") |
m (Protected "Seattle:Helping Techies and Non-Techies Communicate and Cooperate": Excessive spamming ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
(No difference)
|
Latest revision as of 23:13, 18 December 2015
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: