Getting Things Done the Giant Swarm way

If we believe in something, we believe it all the way: our people, our customers, and our potential. We believe in the microservices architecture so much that we replicate it everywhere. Our team structure is case and point. In essence, large applications (goals) are separated into smaller independent parts (teams), which have their own autonomy (roadmap) and responsibilities yet work together towards a shared vision. This isn’t an entirely unique approach; however, we don’t prize novelty (only when it comes to our Giant Swarm Swag). We prize commitment, hardcore focus, and the ability to iterate. 

While microservices might be a useful framework for getting all theoretical about team structure, let’s not distract from what’s at stake. When teams really don’t function, nothing does. In the long run, all the commitment and hardcore focus in the world can’t win against poorly organized teams. Don’t get me wrong, we wouldn’t be a people-first company if I didn’t champion the power and potential that people intrinsically hold; however, to really tap into any of that, you have to create the right environment, and in a work setting, the right environment, the day-to-day life, the real stuff — it all happens on a team level. 

TL;DR: Good teams are our best bet for getting things done (the right way), so I thought we would view them through the lens of the Getting Things Done (GTD) approach created by productivity consultant David Allen. 

Capture

The GTD approach first starts with what is best described as a brain dump, or, writing down everything that clutters your mind. After all, the mind is good at solving problems, not keeping tabs on problems. There’s actually scientific evidence that writing down your tasks moves them out of your head and calms you down. In terms of thinking about teams, here’s a high-level peek at our brain dump:

Our strategies

While we connect our strategy to our roadmap, a large part of creating our own destiny is around resourcing the teams around a subject the right way. Putting our money where our mouth is, or to put it differently, putting teams of the right size for our ambition on the subjects we care about. 

Our customers 

Our customers’ goals, our customers’ challenges, and our best predictions for what our customers’ goals and challenges will be in the future inform our strategies. We don’t like creating in a vacuum but through informed decision-making. Of course, decisions that have an impact in two years are sometimes strange and come back to haunt you, but you have to try. 

Budgets (ours and our customer’s)

While we do not have real budgets internally, we align the pool of assets we have with the money available and then distribute staffing, which is 80% of our costs, to the right avenues of focus. We also directly work with our customers or outside partners to co-fund (with money or people) certain projects to increase their priority. There are some interesting new concepts brewing here; stay tuned. 

Our people (those we have, those we want)

The teams then have needs, and we staff on a team level by now, even knowing people will move around inside Giant Swarm. Approaching the 100-people mark, we also have to account for churn and slight over-hire. But the company is built to last a hundred years, and we want people to have the option to grow old here and evolve within Giant Swarm, especially because much of our knowledge is apprenticeship style and that knowledge is hard to share. So, we put a lot of effort into keeping the right people, probably even more so than hiring them, knowing that the more people like working here, the more people will want to join.

Our values 

The other important item is our values. The teams work on a roadmap, but the customer always comes first. That sometimes drives people nuts because there is constant distraction within teams. We are building systems and processes to keep that distraction to a minimum, but to a certain extent, we actually want that distraction because we are not building for a vacuum but for our customers. Customers come first. Everything gets a postmortem and a root cause. We build for the long term and don’t want to hack where it can be circumvented.

But if we take a step back, we can also add our general mantra: People, Product, Profits, Plans. 

Without happy people, you do not build a good product, and you won’t create happy customers and profits, which makes any plan futile. 

Clarify

Now that everything is laid out, the "clarify" step aims to take the brain dump and put it into a workable structure by deciding, for example, what’s a project and what’s a task, or in our case, what’s a team and what’s a Working Group (WG) or a Special Interest Group (SIG). You can find more information about this in a wonderful post by Anna, our Glue Person for People, right here. 

Rather than "divide and conquer", let’s define and conquer. As mentioned, teams have roadmaps and goals, and that might be product teams (Kubernetes on AWS or Security) and more non-product teams like Teddyfriends who take care of customers with our Account Engineers and Area Solution Architects. Things that would be overarching teams, go into SIGs or Working Groups.

Organize

This step is about putting everything in its rightful place and, in the case of our teams, determining what’s urgent and important on a team level. This is done through daily rituals and feedback processes. 

As we adopt a customer-focused approach, this tends to get chaotic from time to time. However, we’re aware of this and so continuously working on getting it as organizable as possible. 

There are four avenues of things entering a product team's mind share. 

1. If there is a customer support request, we’ll try to solve it then and there through whoever is on support at the time. 
2. If it gets more complicated, we’ll include the Solution Architect of the specific team responsible.
3. If they can't solve it right away, they take it into their team standup, where they can either choose to do something within the week or talk again in the next planning session the following Monday. 
   
   
4. From there, there are two options:
    
   1. Tackle it that week and get it done.
   2. Or, the customer request becomes a roadmap item and goes into the general planning of the team, and the customer is informed that it will take more time, and the Account Engineer takes care of tracking it in the customer board. 

Similarly, if something comes in from one of the biweekly customer meetings, it pretty much goes the same way through the Solution Architect. 

Additionally, we ensure that we host the following each week: 

• A customer planning session where the most important things for customers are discussed.
• A general product SIG meeting where all the Product Owners gather to look at the more long-term roadmap and inter-team dependencies. 

Of course, unexpected ideas and discussion topics also come from team members, and these tend to go through the product SIG. 

Review

Termed the “critical factor for success” by Allen, reviews aren’t just checkboxes that give the appearance of productivity (although they do that too) but rather (if done right) ensure that the right things are being done rather than simply going through the motions. 

Reviews in the GTD process help to identify trends, implement improvements, and reflect on your process and progress — reviews within a team do much of the same. These reviews can take the form of periodic team retrospectives. However, this inside view only looks at the team from within the team and so a mechanism to review all teams from an external perspective is also required. This can happen organically, or it can be built into the system in a way that demands a critical review of teams and the broader team structure in general. If a structure is built on solid ground, then it should withstand being poked and prodded. 

Beyond the team-implemented retrospectives, which aim to take care of team health and productivity, we have also started to encourage more cross-functional feedback, which aims to take care of company knowledge-building and sharing. In these informal sessions, anyone can ask for feedback from anyone on any topic that’s of interest to them. This, we hope, will embed a culture of mutual learning and growth as well as lateral thinking. 

Engage

Abraham Lincoln famously said: “If I only had an hour to chop down a tree, I would spend the first 45 minutes sharpening the ax.” All the organizational work to put in place effective teams that work internally and collaboratively is the sharpening of the ax. The chopping down the tree is the "engage" phase of the GTD method, which is basically doing the damn work. What’s more, if you build your teams successfully, they are not only in a position to do the important work but also discern in the future what counts as important work. 

To ensure the important work flows, we champion a few things:

• GitHub: our one source of truth
• Slack: our one communication platform 
• Transparency: the underlying tenet of all our interactions, especially in a remote context 
• Rituals: Real-time syncs and standups, Onsites, Jourefix, team retros

The GTD method is about becoming more productive and less stressed, and that’s something we work diligently towards on a daily basis. We are constantly iterating and evolving and so "Getting Things Done" often includes the less-spoken-about Getting Things Wrong, but we try to view our mistakes as research and keep it moving, it’s Getting Things Done, after all, not Getting Things Perfect, and we wouldn’t have it any other way. 

I am looking forward to your feedback anywhere you can find me.