Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

On working in Particular

772 views

Published on

Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.

Published in: Leadership & Management
  • Be the first to comment

On working in Particular

  1. 1. On working in Particular A dispersed company.
  2. 2. Mauro Servienti Solution Architect @ Particular Software mauro.servienti@particular.net @mauroservienti //github.com/mauroservienti Microsoft MVP Visual C#
  3. 3. Agenda •Once upon a time… •Dispersed != distributed •No-managers != flat •Communication •Daily tasks •Trust is the key
  4. 4. Conway's law organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
  5. 5. What if… Organizations which designs systems need to be organized as the systems they design
  6. 6. Once upon a time… …in the west (cit.)
  7. 7. Particular Software • In 2010 Udi Dahan decided to create Particular; • Should he have created a traditional company? • Or given the systems we design, a distributed one would have fit the bill? • Distributed means: • Access to the best people from all over the world; • No relocation costs and troubles; • But challenges as well…
  8. 8. What we do… • build NServiceBus and the Particular Platform • A reliable messaging framework • A set of tools to develop, debug and manage a distributed environment • have customers all around the globe • We provide remote services • provide enterprise level support • Up to 5 hours response time SLA • Given customers distribution and support constraints having a distributed team is a clear advantage
  9. 9. Dispersed != distributed Distributed is not what we are.
  10. 10. Distributed • People co-located in the same space -> teams • Teams are distributed across: • The country • The continent • The world • Usually a team works on the same thing • Cross-team communication exists • Intra-team communication is a key aspect
  11. 11. Dispersed • We are all remote: there are no co-located teams • Some of us, such as me, are alone in their country • Some of us live in the same city • Still, work from their home offices alone • We are spread across ~17 time zones • From California to Australia • There are people that never meet over work hours • We speak a few different languages • We have very different cultural backgrounds • Diversity is a key aspect
  12. 12. Challenges • You are alone at home • People you need to work with: • Are in a different time-zone • Speak a different language • Have a different cultural background • Your manager may be in a different time-zone • Respecting yourself can be an issue • Work hours • Device notifications • …etc…
  13. 13. No-managers != flat Anarchy is not the best form of democracy.
  14. 14. Management • In a traditional org chart you have one manager; • You have one manager because you have one role; • My day is generally composed of: • Pre-sales calls • Solution Architecture consultancy (remote and on-site) • Coding • Blog posting • Docs writing • Support • …and more… • Is it sustainable that one manager can manage me?
  15. 15. Management (take 2) • Managers are interested in results • Results may be influenced by luck or bad luck: • Causing a manager to be sad when shit happens :-) • Since we are alone in our home offices: • We need to trust people that they’ll do their best • We need to remove luck/bad luck from the judgement • Managing a dispersed group of people is a mess…
  16. 16. Reboot • We removed all the managers introducing mentors • We removed all the roles introducing disciplines
  17. 17. Disciplines • I can put several different hats • Engineer -> solution discipline • Solution Architect -> domain discipline • Support -> troubleshooting discipline • Etc… • For each discipline I can have (or can be) a mentor
  18. 18. Mentorship • Mentors are interested in the process • A mentor asks questions doesn’t give answers • Is a friend not a consultant • drives you in the right direction doesn’t judge results • Anyone can be a mentor if they have strong skills in a discipline • If the process is done right when results are influenced by bad luck it is not a problem
  19. 19. Do we have a flat org? no • From the Org Chart POV: all at the same level • Mentors are side-by-side, not someone to report to • We are setting up a feedback process: • Will kick-off next week • We are setting up a consultant figure • more on this later
  20. 20. Communication Alone but at the same time all together
  21. 21. Smooth communication • Reduce e-mail usage at the minimum: • A full inbox creates pressure • A mail thread is hidden in the participants inboxes • If an inbox/account is deleted history is lost • We want async/hassles free communication: • History needs to be preserved • A new member needs to easily catch up • We want scoped and open groups • Not necessarily private ones • We need sync communication as well: • An async meeting does not work very well
  22. 22. Async
  23. 23. Slack
  24. 24. Slack • Powerful chat system • Public channels • Direct messages • Private channels • Posts with full markdown support • Partial markdown support in chats • Integrates with everything (mainly via WebHooks) • All Google things • GitHub and many more • Apps for all the devices • Supports custom integrations and bots
  25. 25. Sync
  26. 26. Zoom.us
  27. 27. Zoom.us • All internal meetings are handled via Zoom • Most customers calls are handled via Zoom • Unless the customer prefers its own tools • It scales to several users with no issues • Screen sharing and white board features • We record nearly every call: • and share via Goggle Drive through Slack • Time-box and strict agenda!
  28. 28. Daily tasks From entropy to order in the universe, tools to rule them all
  29. 29. GitHub
  30. 30. GitHub • If it’s not in GitHub it doesn’t exist • Opening issues is cheap • Issues • transient tasks • used to track something we are working on • They have at least 3 states • Artifacts (Markdown files) • Persistent documents • e.g. process descriptions, or definitions, etc.. • PRs (Issues) are used to change artifacts
  31. 31. What GitHub is not (yet) good at • There is a one-to-one relationship issue / assignee • Discussions on issues are a mess • As an OSS project with private and public repos: • Backtracking works not that well • Managing public issues and private ones does not work • Non-dev people get crazy pretty fast • Train them, but the effort is very high • Lack of overview with multiple repos
  32. 32. Waffle.io on top of GitHub Disclosure: it is not the real one :-)
  33. 33. Scrum, Kanban, XP…oh my!
  34. 34. Let me recap… We are dispersed BUTWe need to work together as a team
  35. 35. What could a team look like? • It’s a group of people • We identified 4 as the magic number (in our context) • 5 can be good as well + avoids impasse when voting • A team is composed of Pigs (Scrum) • A team can be joined by chickens (Scrum) • Members are not time zone co-location • European + Aussies • Aussies + Americans • Americans + Europeans
  36. 36. Teams work on… • We identified 3 high level concepts • Processes • Platform Development • Hiring • Support • Etc… • Issues • That belong to a process • That aim to change a process • Cross cutting concerns (not necessarily tied to a process) • RabbitMQ know-how • Productivity • Presentation skills • Etc…
  37. 37. But we don’t have teams • A Squad is a team that supervises processes • Lifecycle: tied to the process • May open issues to handle process changes/updates • Causing a task force to be created • A Task force is a team that handles issues • Lifecycle: is the same of the issue • May report back to the squad if they identify friction • May consult with a guild on cross cutting topics • A Guild is a team that discusses cross cutting concerns • Lifecycle: long lasting • May contact a squad to suggest process improvements
  38. 38. Task Forces • Voluntary formed to handle an issue • Zoom call to triage the issue (~15 minutes) • Create a dedicated channel on Slack • Public but joined only by task force members • Drive the issue • from backlog to ready • from ready to done • Ready does not mean that it will be done.
  39. 39. Assumptions • There is the need to prioritize • A different process/squad does that • Definition of ready and definition of done • Commitment • Who opens the issue is not committed • Working on the readifyng does not imply commitment • Does a task force play well with GitHub?
  40. 40. “pbot pig me” By the way: we automate as much as we can
  41. 41. Trust is the key To trust or…to command and conquer…this is the question.
  42. 42. We are dispersed • Obviously “control” and “command and conquer” have no way to provide any value • We trust ourselves • Unlimited Vacation • Flexible hours • Hardware policy • Conference attendance
  43. 43. Thank you! If you have questions join us at the booth

×