Tuesday, March 24, 2009
Crossing Functional / Technical Divide
Yup - this is what communication across projects looks like.
Nice blog for linux folks on the site.
My takeaway: Scroll down and take a look at the baseline assumptions. They do a nice job of making those assumptions apparent.
I personally do a lot of translation between the two groups. Have for most of my career.
Everyone should play nice with each other. Really. Makes my life easier.
Presentation: Crossing the Functional Technical Divide
Presenter: Dainia Plitkins- Denning & Greg Huseth Georgia Institute of Technology
Dainia – International Student Advisor. Handles fsaAtlas and Banner function
Greg – Technical person. Supports fsaAtlas and other stuff
Total student population on student visas – 3,426. 121 countries
Big gap in language / expectations
- Set the expectation that “things are going to be OK.”
What is the Divide?
- Very different terminology.
- Same word – different meanings.
- Be aware to be careful with terminology when working with others.
- Modes of communication – what is preferred on the other side? What are they used to?
+ Particular formats?
+ Particular expectations?
+ Make the effort to make those formats and expectations clear.
- Frame of Reference
+ In office – can make base assumptions. Communicate same
+ When working outside the office – gotta back up and make sure each party understands. Cannot make the base assumptions you do when talking internally
+ May take a couple of conversations
-- (May not know that until you see a prototype / model)
Conquering the Divide – One solution may not fit all challenges
- Open the communication lines
+ Who is who?
+ How do you like to communicate?
+ Do you have different business practices?
- It’s OK not to “know” your counterpart’s job
- You speak different languages
+ Build time to create understanding into tasks
- There is stuff you won’t know between you
- Another set of eyes - multiple perspectives valuable
- Sorting out the Chaff
- Better not to fly solo
- Accountability and Responsibility - across all parties
- Full disclosure
+ When miscommunication happens
+ 6 hardest words to hear: "I didn't think it was important"
+ Gotta dig it out sometimes.
+ 5 most expensive words: "While we are at it...."
10 Things you need to know
- 5 functional / 5 technical
From functional perspective
- I am not technical and will not understand a lot of stuff, but I can learn what I need to
+ Speak in metaphors and analogies
- A lot of my tasks are tied to Federal reporting regulations
- I am concerned that the reports I make can have a serious impact on our student's futures. (Concerns for the client and the organizaiton)
+ I imagine that my counterpart is concerned with security and data integrity
- I'd like to be as self-sufficient as possible
+ Let me do stuff
- Ease of use is important to me.
From technical perspective
- I am technically oriented and want to apply technology to solve problems or requirements that you have
+ I like solving problems. I'm usually solving the same problems every day. Love if you give me something different.
- Technical solutions / options require various levels of expertise and effort
+ "We can do that" often comes with the caveat of "within available resources"
- Pre-existing technology choices sometimes limit options
+ I usually focus on "logic and reasoning to identify the strengths and weaknesses of alternative solutions, conclusions or approaches to problems."
- Technical complexity is challenging to convey
+ Patience is needed to search for the best way to convey these ideas.
- Production availability is like cash. It is king.
+ My goal is to keep production up and available, even though it may not have every feature that was ever desired.
+ Tech guys hate hearing that "The system is down."
+ We are trying to develop the things that you want.