How we daily manage and work in a dispersed company: Particular Software
Download as PPTX, PDF0 likes145 views
The document discusses the challenges and advantages of working in a dispersed company, particularly emphasizing the need for effective communication, trust, and collaboration among remote teams. It explains the distinction between 'distributed' and 'dispersed' teams, highlighting the unique dynamics and management structures required for remote work environments. The author, Mauro Servienti, shares insights on organizational design, mentorship, and tools like Slack and GitHub that facilitate productivity in such settings.
How we daily manage and work in a dispersed company: Particular Software
- 1. On working in Particular A dispersed company.
- 2. Mauro Servienti Solution Architect @ Particular Software mauro.servienti@particular.net @mauroservienti //github.com/mauroservienti Microsoft MVP Visual C#
- 3. Agenda •Once upon a time… •Dispersed != distributed •No-managers != flat •Communication •Daily tasks •Trust is the key
- 4. Conway's law organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
- 5. What if… Organizations which designs systems need to be organized as the systems they design
- 6. Once upon a time… …in the west (cit.)
- 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. 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 Distributed is not what we are.
- 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. 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. 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. No-managers != flat Anarchy is not the best form of democracy.
- 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. 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 removed all the managers introducing mentors • We removed all the roles introducing disciplines
- 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. 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. 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. Communication Alone but at the same time all together
- 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. Async
- 23. Slack
- 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. Sync
- 26. Zoom.us
- 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. Daily tasks From entropy to order in the universe, tools to rule them all
- 29. GitHub
- 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. 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. Waffle.io on top of GitHub Disclosure: it is not the real one :-)
- 33. Scrum, Kanban, XP…oh my!
- 34. Let me recap… We are dispersed BUTWe need to work together as a team
- 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-located • 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’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. 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. 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. “pbot pig me” By the way: we automate as much as we can
- 41. Trust is the key 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 you have questions join us at the booth