Monthly Archives: June 2019

Jeanne is a Java Champion!

Posted on by
Reply

On Tuesday 6/23//19, I became a Java Champion. If you aren’t familiar, there’s a good overview of the program. To me, it’s an amazing peer recognition award! As of right now, there are 287 Java Champions. (Andres Almiray maintains a list of Java Champions)

One of my friends took video of the announcement. It was fun. I was the track lead of the Modern Java Innovation track. When I got up to explain the track, Wes (the MC) said there was a mistake on the slide. He then explained the Java Champion program and announced me as one.

Shortly after that came the official tweet

You might be wondering what I did to become a Java Champion. Many things including speaking, writing, volunteering with a robotics team, community contributions like CodeRanch and more.

A year ago at conferences, I started getting asked if I was a Java Champion. I was not, but it motivated to organize my accomplishments. I stood up a Google site to list what I’m most proud of: http://jeanneboyarsky.com/. Time to add Java Champion to that list! (and yes, I know how to make a website; I choose google site so I could focus on content)

[QCon 2019] High-Performance Remote and Distributed Teams

Posted on by
Reply

Randy Shoup @randyshoup

For other QCon blog posts, see QCon live blog table of contents

Remote

  • You to not often interact face-to-face with the people that you work with
  • Models- single site, multi site, remote first
  • Anti-pattern; Centralized HQ control. Most things and all decisions done at HQ. Others get work doled out to them
  • Anti-pattern: Site + Satellite Remote – One or several site where people work every day and one or two on own
  • Remote first – everyone on video and slack. Model that Ok to interrupt b/c net slow

Benefits

  • Larger talent pool
  • Take advance of localized supply and demand
  • Parallel hiring – can grow teams in parallel. Not tied to a recruiting team. Each site can hire in parallel
  • Geographic hedge – can hire more in one region if things slow down in one
  • Diversity and inclusion – flexible location/hours, geographic/cultural, neurodiversity (b/c communication styles vary)
  • Retention – can live different places, employee satisfaction, productivity
  • Little/no commute
  • Flexibility
  • Personalize work environment
  • If at HQ and work with remote people, more flexibility because your teammates are remote
  • Ensure each team full stack so not relying on team in another country for communication
  • Follow the sun. Round the clock triage, on call handoffs
  • Close to customers. Local presence, customer empathy, local implementation/customization

Challenges

  • Local laws (hire/fire/severance)
  • Local recruiting norms
  • Local compensation – pay everyone as if at QA or by local market. But must be consistent
  • Local currency – do you pay in US dollars or local currency
  • Local regulation – laws, taxes
  • More travel. Problem to never see teammates
  • No commute == no exercise
  • Solitude/isolation
  • Time management. Easy to keep working
  • Best to be single site or remote first. That way don’t have onsite conversation and inform (Or forget) remotes later
  • Don’t have one site dole out work. That’s outsourcing
  • Managing time zones – respect time zones over others. Watch DMs off hours. Trade off inconvenience. Use overlapping hours well

Onboarding

  • Possible to do remotely, but better to bring in a bunch in person
  • Bond with cohort
  • Instill company/team culture
  • Mentor/buddy system – ideally two role/team and culture
  • Structured onboarding that can do at own page – ex: recorded training

Workspace

  • Video
  • Audio
  • Internet Connectivity – mifi hotspot good in rural areas
  • Comfortable desk/chair/etc or coffee shop or co-working space
  • Quiet/child proofed space

Timing

  • Maker’s schedule – want chunks of uninterrupted time. Try to have meetings close together to preserve time.
  • Manager’s schedule – mostly meetings
  • In a remote environment, blocks of time mater more
  • Block out calendar, office hours

Management

  • Good to have remote manager. Sets example, shows career advancement possible, empathy
  • Clarity on goals
  • 1:1 are sacrosanct, not a status meeting, praise in public (can be slack)/correct in private. Don’t have management by walking around so won’t see implicitly

Trust

  • The half life of rust is 6 weeks
  • An interaction reinforces it

Tools

  • Video
  • Chat
  • Collaborative docs

Communication

  • Be really explicit about “what is the problem you are trying to solve”
  • Clartify the “why”
  • Straighforward language
  • Repetition – a lot
  • Culture of “ask in public” – remember to model this
  • Also model “when in doubt ask”
  • Be open to feedback when write doc and be specific about the feedback want
  • Clarify the purpose of meeting
  • Pre-reads. Or read doc together if can’t do before. Feels weird first time, but gets everyone on same page
  • Template agenda for common meetings
  • Cancel meeting if no agenda
  • Have senior person moderate to stay on topic
  • Allow time for chatting/social bonding

Summits

  • Did quarterly
  • Primary goal was social bonds and connections
  • Do high bandwidth communication
  • Planned well in advance
  • Rotate locations
  • Spent a day learning together
  • Prioritizing fun and team building
  • Hackathon with theme
  • Internal Conference
  • Structured activity about coding

My impressions

This was great. I’ve heard much of it before, but hearing it again helps reflect. And there were some that were new to me

Note: Randy mentioned his collegue’s 2017 QCon presentation a few times. Here is a summary

the effective remote developer – live blogging at qcon

[QCon 2019] Navigating Complexity – High-performance discovery teams

Posted on by
Reply

Conal Scanlon

For other QCon blog posts, see QCon live blog table of contents

Discovery vs Delivery

  • Delivery: completing lots of tickets, points completed, happy team
  • Discovery – different goals
  • Two types of work; two different ways of thinking
  • Dual track agile – discovery is for learning. Inputs into delivery track.
  • Discovery will happen whether planning to do it or not. ex: bug report
  • Can change % of tie on discovery vs delivery over phase in project

Cynefin

  • Welsh word
  • Complex/Chaotic/Complicated/Obvious
  • Also box in middle for when don’t know which in.
  • Complicated – can use knowledge to see what to do

Key areas of discovery work

  • Maximize learning – accelerate discovery, MPVs
    • Want to encounter problems as quickly as possible
    • Learning is messy and doesn’t easily fit Scrum process
    • MVP goal – maximize learning while minimizing risk and investment
    • MVPs can be paper prototype or a single use case
  • Better ideas – idea flow, collective intelligence
    • Levels: Psychology safety, dependability, structure & clarity, meaning, impact
    • Validate with people outside team
    • Closer relationships with specific customers so can see reaction as progress
  • Alignment – OKRs, Briefs, Roadmap
    • OKR = objective and key results
    • Think about where want to go and how get there
    • Should understand why vs an aspirational goal
    • Alignment and autonomy are orthogonal
    • Product brief – map from strategic level to feature going to build. It is not a requirements or architectural doc
    • Roadmap – show on larger ranges of time
  • Metrics – 3 levels, correct category (delivery vs discovery)
    • Business, product and engagement metrics.

My impression

I like that he provided an outline with the key points up front. The OKR section was detailed with examples. I like that there were book references/recommendations. And it was certainly interesting. I think I expected it to be about something else, but I’m glad I came. I would have liked more on examples of discovery projects specifically.