It was a Friday night here in Portland, Oregon.

Dinner in PDX with no reservation can be an adventure. Thankfully for me and my wife there are dozens of restaurants that leave room for walk ups. We made our way over to Southeast Portland to check out the Country Cat. The hipster hostess offered us a seat at the chefs counter.

Now this isn’t the first time I have sat at a chefs counter. I have sat at my share of chefs counters as a Portland foodie would. This time though I observed a few things about how successful teams operate.

Before I jump into those I want to touch on my philosophy of development teams.
Development teams live and die by the collective sum of their parts. A development team that fails to operate as a team is a team destined to fail.

My wife and I were were mesmerized sitting at the chefs counter. A team of four chefs were cranking through a crazy Friday night dinner service with ease. We began to wonder how is this even possible. I can’t even boil pasta and make a sauce at the same time. Let alone cook three other meals and chat it up with my friends like it’s no big deal.

From where we sat we deduced the following three things about the team in front of us.

1. Communication & Trust Separates Functional From Dysfunctional

The chefs from left to right. Fried chicken and appetizers station manned by one guy let’s call him Rick. Meat station was Carl. The seafood and vegetable station owned by Gary. The guy at the counter, head chef, director of chaos, and also creator of desserts was Bob.

A typical order would go something like this.

1. Waiter/waitress walks up hands ticket to Bob.
2. Bob reads off the entire order to the other three on the line.
3. Fried chicken or appetizer, Rick responds with “heard”.
4. Meat entrees, Carl responds with “heard”.
5. Seafood or vegetables entrees, Gary responds with “heard”.
6. Bob adds the order to a running line.

Each chef, Rick, Carl, and Gary are listening for the parts of the order they are responsible for. They must communicate back to the head chef that they heard what they are responsible for. Bob never second guesses them, and he trusts that each chef heard what they are accountable for.

As the order cooks, the head chef asks each chef where they are at with their part. The chefs communicate the time left for their dish. The head chef, Bob, then orchestrates the chefs to make sure everything in the order is ready at the same time. By continuously communicating about where they are with a dish, Bob is able to steer the ship. He is able to keep everyone in sync so the order goes all together.

The chefs all trust that Bob will keep them in sync with one another. They must also trust one another that they will be accountable for their part of the order. They do not stand around and second guess one another as doing so introduces delay.

In development teams, communication doesn’t have to be a developers top priority. It does need to be somewhere in the top five, and preferably in the top three. Zero communication leads to lack of visibility which is a fast lane to distrust.

Development teams crumble when there is a lack of trust. Nothing ruins a development culture more than tension and walking on egg shells. Thus, members of a team must be able to trust one another to do the right thing. If you want to put your development team at a stand still, introduce tension and distrust.

Continuous communication keeps everyone on the same page. Allows everyone to have a voice in the conversation. Communicating ideas, problems, and questions allows everyone to buy into the culture of the team. This increases the knowledge of the team, produces better processes, and builds a healthy culture of innovation.

The communication doesn’t stop with members in the development team. Often times there are outside stakeholders that need communication as well. Don’t lose sight of them. You want them to be able to buy into the culture of the team as well.

2. Small & Connected =Â Cohesive

The chefs are connected both professionally and even outside of work. It is clear that they have built a cohesive culture where they all know each others strengths and weaknesses. If this was a team of ten chefs it would be hard for them to maintain that cohesion and comradery.

Sitting at the counter eating my fried chicken and not thinking twice about it. Bob asks Gary about the start of Trailblazers season. Gary talks with Steve about what to do after dinner service. I notice that the chefs likely hangout outside of work. Small talk about families and sports are common on the line.

The size of the team is key here as I find it hard for them to have this cohesion if there was ten chefs on the line. They know one another and don’t mind working together each night for dinner service. It’s important that they enjoy working together. I would rather not have blood in my mashed potatoes from a fist fight in the kitchen.

Building cohesive, self managing, and tight knit teams is easier with fewer people. The ideal team size is somewhere between 4–6 people. Keeping the team small makes communication easier. Knowledge sharing simpler. Thus, fostering a tighter culture.

Smaller teams are more likely to self manage and hold each other accountable. One member of the team is not above another member. They buy into the success of one another and cover for each other to keep the machine moving. This helps the team grow and function at a healthy level. Still allowing individual developers to feel proud of their work.

In my own experience this has allowed my career to advance dramatically. By working in smaller teams you have to be accountable for things outside of your comfort zone. This pushed my own boundaries and understanding to new levels. Terrifying but also rewarding at the same time.

3. Self Managing Accountability

Each chef owns their station. They manage it for each order and they are accountable for producing their dish for it. This makes each chef the manager of their own domain. They must be able to self manage even in the absence of Bob, the head chef.

Others step in to lead the line when Bob steps away at dinner service. There is no politics around it, someone just does it. Orchestrate the others to make sure the team is still delivering every order. They are a self managing group of collaborators that recognize they are only as good as the sum of their efforts.

There must always be a leader in a development team. Someone to be held accountable for the delivery of the team. The team must also be accountable to one another. This level of accountability often empowers teams to self manage themselves.

Conclusion

As a developer and software engineering manager it has been easy to get caught up in the tech bubble. Their are other processes to apply and experience to learn from. Taking a step back and getting rid of technology gave me a different perspective. Sometimes you need a new perspective of the problems you are facing.

Not all restaurant chef counters are synchronized. In fact even the Country Cat probably has an off night every now and again. So it is OK if development teams have an off day. As long as the pillars of a development culture are present an off day can be easy to recover from.

Next time you are faced with problems in your own teams consider observing how others are handling similar problems in their own domains.

Hungry To Learn Amazon Web Services?

There is a lot of people that are hungry to learn Amazon Web Services. Inspired by this fact I have created a course focused on learning Amazon Web Services by using it. Focusing on the problem of hosting, securing, and delivering static websites. You learn services like S3, API Gateway, CloudFront, Lambda, and WAF by building a solution to the problem.

There is a sea of information out there around AWS. It is easy to get lost and not make any progress in learning. By working through this problem we can cut through the information and speed up your learning. My goal with this book and video course is to share what I have learned with you.

Sound interesting? Check out the landing page to learn more and pick a package that works for you, here.

This was post was originally published on my Medium blog.