Brace Their Bones

The second week of Management Excellence at Champlain College was last Friday, and it continued several of the themes from week 1 while moving from the intrapersonal to relationships with others.  We used our Myers-Briggs results to move into successively smaller groups, initially breaking out as E’s and I’s, or Extroverts and Introverts, respectively.  We started by brainstorming what were the elements of a successful team meeting.  (I took notes for this and all the successive groups that I was in as we pared down to more specific types – which figured into how my groups reported things…more on this in a minute.)

Our group of Extroverts outwardly focused on the basics of any good meeting – visibility in the form of a published agenda, ending on time, everyone getting time to speak, no phones/laptops, good faciliation, and specific action items.  As people took turns speaking through their ideal conditions, there were a number of items that were not explicitly said but came out as subtext or were actualized by the group members themselves. I captured those as well: humor, presence, validation, respect, energy.  As our group’s scribe, I was the reporter when it came time to report our findings.  At that point I explained to Sean Collins (same facilitator as Week 1) and my group that I had captured the words that were spoken by the group in describing their ideal meeting, and that I had also written some of the larger themes that I had *detected* during the discussion.  This generated some laughter, with the “N” in my type coming out, apparently.  As an “N”, or an Intuitive Type, it is definitely in my personality to keep a log of unsaid values during the brainstorm, logging them for future use.

We segmented ourselves again by our second type letters, into “EN” and “ES” next, and discussed how we would want to learn a new job.  This exercise showed the contrast to the “IN” and “IS” groups across the room – where the approaches were markedly different.  The EN types were all about jumping in, possibly with some bit of demonstration, but basically willing to figure it out on the experiential level.  Having ‘context’ was important – knowing where we stood in the organization, the values and principles by which we should operate, and the system by which we would be evaluated.  The essense of “Why” outweighed the “How” for us.  What struck me was how ‘IN’ types listed many of the same ideas – knowing the big picture, where they fit in, understanding the “why”.  Where they diverged from ‘EN’ was the means of gaining this information – they favored a mentoring or document-based learning path.

The “S” groups were all about gathering data and using a structured approach. The “ES” group wanted to iterate through the job, gathering data and incrementally improving their work as they went.  The IS types wanted to begin with manuals and due diligence, perhaps performing an audit of the procedures for the job they were going to learn.
It started to become clear on where Sean was taking us.  I  remembered back to when I first started at Reading Plus – and how I wanted to begin with a comprehensive view of the technology infrastructure.  My first project for the then-sysadmin was a series of questionnaires, in essence a Due Diligence.  It was painful to gather and categorize all that information, but it paid off immensely in the months that followed.  And it hit me, listening to the IS group talk about how they would go about diligently gathering all the information about their new job: I could have really used someone who would  *relish* working that way.  This was all about having different types on the team, and leveraging their strengths when possible.

We continued the exercise in one more configuration, the first 3 letters, to discuss the final question: What is your major contribution to this team?  By then I had already begun to think of the high-performing teams I have been a part of over my career, and how those groups fit together in ways that made the most of everyone’s temperaments even as they fit each other’s skillsets.  Two teams in particular stand out, both because the team members’ skills and personalities were diverse, and the accomplishments of each team exceeded what I would consider the “what’s possible on paper” factor.

Had a great side conversation today during our management seminar, about job postings.  A colleague was looking for ideas on how to post a description of a job without the laundry list approach that tends to the be the usual fare.  I mentioned that a few months ago, I had written up a post that was meant to tackle the issue less by itemizing the skills and responsibilities of the person I wanted in list form, and more by describing actual experiences I expected the person to have had, and to have once they joined us.

It turned out that we didn’t need a UI Developer as we had originally anticipated, so I never posted the job description.  I’m going to send it to her but wanted to post it here to see what people think.  Let me know how this lands.

—

Stop Building Websites that Sell Widgets.  Change the World.  Seriously.

Your workplace…
Reading Plus®/Taylor Associates is the leading producer of silent reading assessments and remediation solutions.
We offer unique, patented products, technology, and implementation strategies that build the foundation for academic, vocational, and real-world success.
We are dedicated to producing research-based products that help students of all ages become better silent readers and independent learners.

Your teammates…
We are a passionate group of technologists that work to support the students who use Reading Plus, the teachers who administer it and the Research and Instructional teams who design our products.
We build interfaces that support our core pedagogical intent while gathering metrics to inform design decisions.

Your days…
Daily stand-ups to sync with the rest of the Team.
Working with the Product Group to understand goals and requirements from User Stories.
Using JIRA to organize your workload.
Writing Code.
Working with other developers to make design and engineering decisions.
Writing Unit Tests.
Collaborating in front of a whiteboard.
Checking code into SVN, triggering builds on the Continuous Integration Server and watching your tests pass with flying colors.
Refactoring your code.
Stepping back to plan the next set of interfaces with the big picture in mind.
Writing more code.

Your skills…
* Strong coding of JavaScript, JSON, HTML, CSS
* Cross-browser / cross-platform interface development experience
* Ability to communicate with technical and non-technical teammates
* Strategies for debugging
* Familiarity with JQuery or other JS frameworks

Your education and work experience…
You have a CS degree and at least three years Web development experience, or five or more years producing code and interfaces.  Most of your work has been developing Ajax-driven applications and sites.  You know your way around tools like Adobe Photoshop and Illustrator.  You understand HCI, and love designing meaningful interfaces that streamline interactions for users.  You know enough about IA, IxD and UX to be able to apply them to your daily work.  Agile development is something you have done before. If we say ‘beep’, you think ‘Responsive Web Design’.

Is that you?  Send your CV, LinkedIn profile, or a link to your portfolio to careers@readingplus.com, and put “UI Developer” in the subject.

—

Would be interesting to compare this with a more standard approach.  Or maybe this isn’t that much of a departure after all…