If you’re a technical person and you find yourself leading people, it might be worth leaning on what you know: What if we were to understand your team as a distributed system? Even if your team isn’t distributed, it can act like a distributed system.
2. ✘ Give a detailed architecture for your team
✘ Give strong opinions on process
✘ Include any more bullet points
This talk will notThis talk will
Explore ways of thinking about your team
Provide broad themes for scaling your team
Possibly be affected by jetlag
What to expect
Hi! My name is Andrew, I’m the CTO in Residence in Sydney. I get to work with our ScaleUp program companies to help accelerate their growth, and help them scale their systems and teams to support that growth.
I want to talk a little bit today about scaling your team. I’m drawing on my experience from working in various sized teams, leading technical teams in startups and observing startups.
Let me tell you a little bit about myself. For years I worked as a developer. I was an individual contributor – I had my time as that young, idealistic developer who railed against management and generally was a problem for my manager — I like to think I’ve matured a bit since then.
I’ve worked in big companies and small companies. Successful startups that ended up getting acquired, and less successful startups that went down in flames.
Somewhere along the way, I found myself running tech for a startup. At first it was just me, then me and a contractor, then all of a sudden I found myself managing a team. I was out of my depth. I was no longer just able to sit and code. I was no longer only worried about the product, but about the team who were building it.
I had to ask myself, was I going to become this guy? I was no longer equipped, either from years of self-teaching or from any kind of formal education, in how to manage these people.
I suspect this is not a new story for a lot of people here – either as a founder, or an early technical hire, as your startup scales, you find yourself with grappling with transforming what was once a small group of people, easily coordinated to something which is rapidly getting more complex as the problem, and the people required to solve it scale.
You see it starts out simple enough, with a few people with an idea. They bring on another person and there’s some extra complexity, and another, but it’s not too bad.
Suddenly though, things start to get out of hand. More and more people come on board to help scale the business, but how do you scale an organization in the midst of all this?
People don’t throw stack traces or helpful error messages when things are going wrong. They often silently error while performance degrades until they SEGFAULT and leave suddenly.
As someone technical who found themselves leaning people, I reached both for resources available to me - books, former bosses I who had persisted with me, conference talks… And I began to combine some of the understanding I’d gained about teams and how they work and combined it with something near and dear to my heart: distributed systems theory
If you’re a technical person and you find yourself leading people, it might be worth leaning on what you know: What if we were to understand your team as a distributed system? Even if your team isn’t distributed, it can act like a distributed system.
Let’s start with a working definition for a distributed system.
Borrowing from Sukumar Ghosh in the aptly titled “Distributed Systems”, he defines a distributed system as having four properties.
Multiple processes – we have multiple people working on our product.
Inter-process communication – we at least hope that the people working on our product talk to each other
Disjoint address space – Each person has their own understanding of what they’re working on
Collective goal – hopefully we’re all working towards the aim.
So if we can all agree that at least by this definition your team is indeed a distributed system – even if they’re all in the same office. Are we roughly agreed on that? Okay, let’s test this out by trying out some of what we know about distributed computing on our team.
One of my favourites is the 8 fallacies of distributed computing. It originally came out of Sun Microsystems and describes the false assumptions that programmers inevitably bring to a distributed system. In our case, it’s the false assumptions that we can bring to our teams as we scale them. Hopefully we can learn some things that we can apply to the
On a network you can’t assume that every message sent is received, or within a reasonable time frame.
Similarly with people, not everything you or someone else says will be heard. Not every email you send will be thoroughly read. Some instant messages will get lost in the mass of notifications.
Even with the best teams, our communication is not 100% reliable. This is even more more true when you’re scaling your team. In the midst of the scaling, things get lost. They get missed
Neither our ability to produce work or our ability to communicate is infinite.
Inconsistent state is inevitable. We need to manage conflicts. We need to get people on the same page and work to bring them back there when things get weird.
