Skip to content

Instantly share code, notes, and snippets.

@swinton

swinton/transitioning-to-innersource.md Secret

Created June 27, 2016 20:11
Show Gist options
  • Save swinton/cc1e7a62b312133172a04b8b777fc547 to your computer and use it in GitHub Desktop.
Save swinton/cc1e7a62b312133172a04b8b777fc547 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
transitioning-to-innersource.md

TRANSITIONING TO INNERSOURCE

Cedric Williams, PayPal

  • Bringing people closer together, when the structure of the business environment is keeping them apart
  • Floppy disks
    • Anyone have disk #17?
    • Community of floppy disk sharers
    • When people help each other out
  • Exercise #1
  • FoodCamp intro
    • Name, organization, 3 hashtags
  • Morning community
    • Connections: military, ruby, places, companies. 1000 ties in this group already
  • Inner Source is about change
  • Software systems as they change take on structure of org that build them
  • Problem with teams, collaborating, underlying problem that needs to be addressed
  • What Innersource isn’t
    • Regional team, contributing to core team
    • Core team sits on regional team contributions
    • Guy in regional team gets yelled at
    • Bosses of respective teams have lunch
    • Team caught in the middle rewrites it
  • What Innersource is
    • Cut the cheese cycle
    • A team contributing’s barriers:
      • Lack of knowledge
      • Lack of bandwidth on receiving team
      • Contributor lack of visibility into process (things that others know that aren’t documented)
    • In a healthy system (Open Source):
      • Thanks for your contribution
      • Here’s what I need you to do before I can accept this change
      • Adoption of new contributors is a key metric for health of an open source project
      • An org that shuts down contributions creates division between orgs and teams
    • How do we make orgs work like open source projects? Attack the culture:
      • Recognize the problem
      • Willingness to take risks
      • Air cover / ground cover (people that have your back)
      • Evaluate org / culture honestly (What are we blind to? What are we good at? Where are we shutting down people’s voices? How are we rewarding our people? What kind of rewards systems do we have? How do we measure success?)
      • A messaging plan, built on the above
    • Recognizing the problem
      • Structural barriers to collaboration, communication
      • Lack of empathy, the ability to put yourself in someone else’s shoes, means we spend a lot of time solving the wrong problems (wash.io)
      • If we can put ourselves in other’s shoes… Then we know we’re building what needs to be built
      • An org past a certain age… Different people have different resources, we can’t share because I don’t have enough to do what I need to do
      • Too much complexity, driven by short term revenue (product/feature driven), focusing on the small
      • Forced competition (3 black box teams)
      • Acquire a small, fast company (often because of the people, but then the people aren’t happy in the new org)
  • Exercise #2
    • Describe your problem
      • Way too much complexity
      • Takes too long to ship anything
      • Path to production not trusted
      • Not invented here syndrome
      • Lack of trust, communication
    • What data do you have to convince the un-aware
      • Release process
      • Budgeting process
      • Internal politics, egos
      • Slow growth
    • What’s your role?
      • Champion of the cause, change agent
  • The risks of change agency
    • Sine wave: love / hate / hopefully love
    • Resistance from people doing their best to do the right thing
    • If you are risk averse, you’ll need some solid team around you to do this change work
    • If you ❤️ risk, you’ll love this kind of work, maybe think about doing this repeatedly
    • So much need for this in so many organizations
    • Being a change agent as a woman, very challenging
      • Bias drives evaluation of change, rather than the change itself
      • Intentional or not, it’s unacceptable
      • People will try to get you fired
  • When people start taking credit for your work, is when you know you’re winning
  • Typically, as a change agent, you won’t get the credit
  • Are you devoted to the organization enough (to its potential) to go through all this hassle? Is this your fight?
  • Risk mitigation strategies
    • Make sure this rollercoaster ride is for you
    • Network
    • Innersource commons, events, talk about what you’re trying / learning / what’s failed
    • Innersource commons Slack channel
    • Mindfulness
      • Have a mindfulness practice, this is high risk, emotionally intensive work
      • Practice meditation, juggling at PayPal, get out of your head, back into your body
    • Be talking to other companies, have an exit
    • Public persona, encourage your company to talk about its achievements
  • Air Cover
    • C-level sponsorship a mandatory requirement
      • Maybe a group of senior directors / VPs who are willing to put their careers on the line will suffice
  • Ground Cover
    • Not hard to convince (most) engineers that they need to collaborate
      • Most engineers have learned, to solve hard things, they need to work together
    • No rocket gets launched based on the efforts of one individual
    • No programming language gets launched based on the efforts of one individual
    • Have to be able to collaborate
    • Air cover from the top, groundswell from the bottom, crunch in the middle, some run with it, some won’t
  • Exercise #3
    • Attitude to risk
      • Evaluate your personal appetite for risk
      • Evaluate your capacity to lead a team through risk
      • What is your plan to mitigate?
  • Grassroots (bottom-up) vs top-down
    • Need C-level buy in
    • Also need grassroots support
    • The folks in the middle are the real challenge, need to see how much collaboration gets them, instead of what it costs them
  • Homework
    • List your allies
    • …
  • Cultural evaluation
    • How old is your org
    • What is the style of your engineering (engineers, vs admins, vs devops etc)
    • How is talent brought in? Acquihire?
    • Do people have safe environments?
      • Sitting with a lot of people behind you feels unsafe, for example
    • How old is your code
    • Do you have real code reviews?
      • Political rubber stamp, or real?
    • How much of your code is continually integrated?
    • Switching code reviews around to be a learning experience for both submitter and review, is a hard change for an org to make
    • How much free time to people have?
    • How are your engineers / product team / managers measured?
    • How modern is your HR team?
    • Mentorship vs. guardian
    • Conversation between someone submitting code, and someone accepting it
    • Does your org have the ability to capture conversations?
    • Does your company respect remote workers during in-person meetings?
  • Exercise #4
    • Do a cultural evaluation for your immediate target
      • What are the 3 cultural barriers you need to address
      • Waterfall process
      • Ancient code, systems
      • No code review
      • No tests
      • No automated path to production
      • No collaboration, code sharing
    • Do another another one whole organization
  • Why cultures obfuscate
    • If I tell you the secrets, you’ll be able to take advantage of me
    • Security through obscurity doesn’t work, if there’s a vulnerability, someone’s gonna find it
    • Indispensability is a hard thing to dig out of a culture, fear of being replaced, afraid of learning, you have a bus factor of 1, you’re in trouble
    • Ownership culture: You wrote this, therefore it’s your fault (blame)
    • In a pull request culture: Whoever merged it, owns it
    • At PayPal, had to negotiate that the donating team is on the hook for 30 days after feature ships
  • Reason vs emotion
    • Open source flips the paradigm for a lot of things:
      • People don’t (necessarily) get paid
      • People might spend more time working on open source, than paid work
      • Purpose-driven activity
      • When people resist, listen to where they’re coming from
  • Exercise #5
    • Who are your holdouts?
    • Why?
    • Imagine your most difficult manager or your least sharing engineer
    • Now sit with the person next to you and answer the questions “what are you afraid of” and “what are your pinpoints”

  • Book: Drive, Daniel H. Pink (the surprising truth about what motivates us, the ability to work on something personally meaningful)

  • Innersource works because it lets people work on what matters to them

  • Our organizations are not built to support the cool, awesome work that we’re all capable of doing

  • Metrics

    • Don’t measure lines of code (obvs)
    • Beware of compound KPIs

  • Build vs buy

  • What we care about

    • Increase in collaboration, what we get: increase in quality, increase in employee happiness

  • Messaging plan

  • Skills you need for a successful Innersource transformation

    • Instigate good code review
    • Get tech leads, architects on board
    • Stakeholders
    • Facilitators (aka therapists), people act badly when they feel threatened
    • Tools folks, for workflow change
    • Data heads
    • Marketers to get the word out
    • Exec. sponsor

  • Resources

    • Innersourcecommons.org
    • Slack channel
    • O’Reilly eBook
    • Checklists, worksheets, more in pipeline
    • Academic interest
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment