Download to read offline
Uploaded byMauro Servienti
On working in Particular
Mauro Servienti discusses the challenges and strategies of working in a dispersed company, emphasizing the importance of trust and effective communication among remote teams spread across various time zones and cultures. He outlines the company's transition from traditional management to a mentorship model, focusing on disciplines rather than roles while implementing tools like Slack and Zoom for collaboration. The document highlights the need for flexible work practices and the advantages of a distributed team in building a reliable messaging framework and providing global support.
More Related Content
Similar to On working in Particular
More from Mauro Servienti
On working in Particular
- 1. On working inParticular A dispersed company.
- 2. Mauro Servienti Solution Architect@ Particular Software [email protected] @mauroservienti //github.com/mauroservienti Microsoft MVP Visual C#
- 3. Agenda •Once upon atime… •Dispersed != distributed •No-managers != flat •Communication •Daily tasks •Trust is the key
- 4. Conway's law organizations whichdesign systems ... are constrained to produce designs which are copies of the communication structures of these organizations
- 5. What if… Organizations whichdesigns systems need to be organized as the systems they design
- 6. Once upon atime… …in the west (cit.)
- 7. Particular Software • In2010 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. 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. Dispersed != distributed Distributedis not what we are.
- 10. Distributed • People co-locatedin 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. Dispersed • We areall 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. Challenges • You arealone 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. No-managers != flat Anarchyis not the best form of democracy.
- 14. Management • In atraditional 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. 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. Reboot • We removedall the managers introducing mentors • We removed all the roles introducing disciplines
- 17. Disciplines • I canput 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. Mentorship • Mentors areinterested 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. Do we havea 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. Communication Alone but atthe same time all together
- 21. Smooth communication • Reducee-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.
- 23.
- 24. Slack • Powerful chatsystem • 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.
- 26.
- 27. Zoom.us • All internalmeetings 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. Daily tasks From entropyto order in the universe, tools to rule them all
- 29.
- 30. GitHub • If it’snot 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. What GitHub isnot (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. Waffle.io on topof GitHub Disclosure: it is not the real one :-)
- 33.
- 34. Let me recap… Weare dispersed BUTWe need to work together as a team
- 35. What could ateam 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. 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. But we don’thave 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. Task Forces • Voluntaryformed 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. Assumptions • There isthe 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. “pbot pig me” Bythe way: we automate as much as we can
- 41. Trust is thekey To trust or…to command and conquer…this is the question.
- 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. Thank you! If youhave questions join us at the booth