DEV Community: Elmar Schippers

How does your team make pizza?

Elmar Schippers — Sat, 04 Feb 2023 09:59:36 +0000

Everyone in your team know how to make a pizza, but what happens when you ask each person in your team to make pizzas to feed everyone?

Josep is classic foodie and does everything from scratch. He will make his own dough, make his own sauce and grate his own homemade cheese.
Ewelina loves a hearty vegetarian pizza and will stack it with every possible vegetable under the sun. The thicker the pizza the tastier it is for her. All her pizzas are topped with fresh cottage cheese.
Francesco can’t get enough of pineapples on pizza. No matter the pizza, it need some pineapple.
Antti is a fan of simple pizza. Cheese under the sauce, a couple of pepperoni on top and that’s it.

They are all capable of making pizzas and they all achieved the requirement of feeding the team to various degrees of success (pineapple pizza anyone?). However none of the pizzas are similar nor are they ways the pizzas were made.

This might be okay in some scenarios, like feeding your team, but doesn’t really work when your team works with complex projects or complex systems.

Minh is new to the team and doesn’t know how to make a pizza. While Minh is an excellent cook is his home country and makes a mean spicy noodle soup, Minh is brand new to western food and has never really had pizza before.

No one has enough time to teach the entire process, the entire team is already busy (that’s why you hired Minh). So Minh is tasked to learn a little bit from everyone.

Josep will say that everything must be made from scratch. Antti will say that the cheese goes under the sauce. Ewelina says tell Minh, a good pizza needs 4 varieties of vegetables and topped with cottage cheese. Lastly, Francesco will proudly state that pizza toppings are required to at least 1/3rd pineapple.

Minh slaves away, trying their hardest to make the team proud. What the team receives is a plate of dough, layered with cheese, sauce, potato, pumpkin, carrots, bell peppers and half a pineapple. Topped with a healthy amount of cottage cheese.

Most people are not going to react favorably to an uncooked pizza with a mismatch of toppings. Minh listened to everyone and tried their hardest but ultimately failed. Is this Minh’s fault or a flaw in how the team functions?

No one had mentioned a pizza needs to be cooked in an oven. Everyone had just assumed Minh would know.

Being consistent within your team isn’t just useful for getting a repeatable result. It helps ensure new team members are able to get up to speed and productive quicker and more successfully.

This example is a fairly simple one, but try asking your team how they do their jobs.

How consistent is your team?
Do they use the same tools and processes?
Are they consistent in their order of steps?
How well is this all documented?

When a new person arrives, will they be able to read (and re-read) a clear set of instructions on how to write code in your team or will they be left to get bits and bobs of information from your busy team members?

Sometimes its important to take a step back and getting everyone on the same page with your processes and ways of working. In the long term your existing and new team members will be better off for it.

What makes for successful communication? Pt. 1 - Requirements for communicating

Elmar Schippers — Thu, 17 Nov 2022 20:07:50 +0000

Communication, it's the thing we do constantly. We are continually transmitting information to people around us, both synchronously and asynchronously. We do so by talking, writing and signalling using body language. Our bodies are designed to constantly convey information to those around us, letting them know how we feel and think. Communication helps us form the foundation of our society, our social connections. So why then, if our bodies are designed to communicate and we do it all the time, does it feel so hard to communicate some days? And why, with ever more ways to communicate, does it seem harder than ever to communicate in the workplace?

In this post I want to explore the complexity of communication, breaking it down to understand how we successfully convey concepts and ideas to another person. In part two, I will build on this and discuss why conveying concepts or ideas in the modern hybrid or fully remote workplaces can be so difficult.

Breaking down communication

When we communicate, we are attempting to convey a concept or idea to another person. Successful communication occurs when the receiver understands the concept or idea in the same way that we understand it. Very rarely do we have the time or ability to communicate a concept or idea completely.
We have learnt to get by on communicating just the relevant new pieces, harnessing and building upon the existing knowledge shared by the participants. This has greatly benefited us, by enabling the discussion of more complex concepts and ideas.

At its core, concepts and ideas are forms of information. For simplicity, the rest of this post I will use the term, information, to collectively group concepts and ideas.

This sharing of just the relevant pieces is fundamental to the way we share information. But how do we know if that piece of information was successfully communicated? Let's take a look at 3 requirements of successful communication:

Technicality
Criticality
Quantity

Technicality

Our concepts and ideas are built upon other concepts and ideas. When we attempt to convey information to others, there will be a requirement for the other person to already know the concepts and ideas the new information is built upon.

It is relatively easy for humans to share information with each other on common topics. A person can relatively easily tell another person they want a haircut without even needing to speak the same language. Pointing to or pulling on our hair and motioning a cutting action, is enough to relay the idea.

It is much more difficult to share information about the latest advances in machine learning algorithms. Not only is a shared language essential, a high degree of pre-existing shared knowledge in the field of machine learning is required.

When the gap in shared knowledge is small, additional information can be shared in order to fill the gap before providing the primary information. However this can only go so far before the requirement to share additional information outweighs the benefits of sharing the primary information.

Criticality

The importance or criticality of information can greatly impact how accurately the information has to be received for us to count it as successfully communicated. The more important the shared information is, the more we will also do to ensure it is accurately received.

Certain information has very low criticality and we don't really care if it was not perfectly received. Greeting someone with "Hello, is it raining outside?" and receiving "I'm good thanks" shows that the receiver partially misunderstood what was being attempted, both a greeting and seeking information. The greeting was successful, but finding out if it is raining was not. However it is of no great loss as you can simply look out the window and get the answer in another way.

In contrast, during a surgery, a doctor and his staff must continuously relay accurate information without mistakes. Failure to do so could result in disastrous outcomes for the patient. Bad handwriting, misheard statements and confusing diagrams/visuals are unfortunately far too common of a reason for patient complications in hospitals.

This is why critical function teams often ensure that they speak with a clear set of rules on communication, ensuring shared information is replayed back to the sender for confirmation.

Quantity

How much communication is needed to successfully convey information can be a big blocker to success. The higher the criticality or technicality, the more we are willing to accept larger quantities of information.

Providing too much or too little information will heavily impact the success of communication. Provide too much, and you risk overloading the person or drowning out the core message in a sea of other information. Provide too little and you risk having the person misunderstand or misinterpret the information.

Recipe websites are a great example of both too much and too little quantity, leading to unsuccessful communication. We typically do not care about the 500 word life story that got the writer to the stage in life where they wrote the recipe. (high quantity, low criticality). But we do care for clear and detailed instructions in the recipe. Nothing is worse than getting half way through a recipe and scratching your head, trying to decipher what to do next. (high criticality, low quantity).

It sounds complicated, but we are really good at it

Every communication we attempt has elements of each requirement, and without successfully navigating all three a communication isn't able to be successful. These apply not only to direct interactions between two people, but anything attempting to convey information around us from Wikipedia pages to dinner menus and street signs.

While this may all sound quite complicated, whenever we attempt to communicate our brains are making split second, subconscious decisions about these requirements. Luckily, we are really good at making those decisions and have learnt when to dial up or down the needs of each requirement as we communicate. Sometimes we do get it wrong, and we can be left wondering just what went wrong.

As our world (especially our workplaces) continues to get more complicated, our methods of communication are getting more complex too. In the next part, I will dive into the mediums we use to communicate and how we can use them to successfully share information.

Final note

In this blog I spoke specifically about technicality, criticality and quantity. These are the 3 requirements to any communication. However, different forms of communication may have additional requirements. Emotional and bodily expression are two requirements for successful verbal communication between two face-to-face people. Not all communication requires or can provide these, for instance a street sign is unable to convey an emotion (even if it does elicit one to the reader).

Who is responsible for that? Visualizing team responsibilities.

Elmar Schippers — Wed, 26 Oct 2022 18:36:18 +0000

I have always enjoyed utilizing the DevOps topologies website. Its simple explanations of the various patterns and anti-patterns common in the industry is a great starting point for discussions. However it left me struggling to have deeper, more concrete discussions. Over the last few years, I have started to adapt some language common in the vernacular of our cloud overlords the "Shared Responsibility Models".

Shared responsibility models give a clear and easy visual understanding of who is responsible for specific layers of an application stack. AWS does a great write up on this and shows off how different types of infrastructure services will impact who is responsible for particular layers. Check it out here. These visuals have been immensely useful when discussing the benefits (and downsides) of using cloud managed services with customers.

By making our own version of the application stack, we can similarly delineate which teams may be responsible for certain layers.

Having a visual aid like these, can make having conversations much easier. Displaying your production environment as a series of layers built on top of each other, shows off the reality of how we build cloud services today. It can also help discuss individual functions and responsibilities.

Does your engineering team own the application configuration in production or is that the responsibility of the operations team? How about ensuring the customer data doesn't get corrupted or deleted?

Typically when I use such models to discuss responsibilities, one inevitable question will arise, "What does having responsibility for a layer even mean?". It means that a team has full ownership and authority over all aspects of that layer. They can decide how to build, run and monitor it etc. It also means taking on-call duties for any alerts or incidents related to that layer.

If an engineering team is responsible for building your application, but does not take the on-call duties, it can be said that they have a shared responsibility with the operations team. Those two teams will then need to decide how to manage that relationship for that layer specifically. The higher up the stack, the more difficult it will become for an operations team to effectively remediate production issues without assistance from the teams that built it. Conversely, the lower down an engineering team moves down the stack, the further they move away from spending time developing your product.

To take the concept a little further, you can take the idea and look at the whole development pipeline. Mapping out who is responsible for various aspects along the pipe from development environment, through CI/CD and testing environments to production.

Having discussions about responsibilities can be difficult. Next time you are having conversations take the time to map them out using a shared responsibility model to break down the conversation into smaller conversational units.

The examples I have used in this post are overly basic to show off the concept. In reality these models are often more complex and specific to a companies particular setup.

Breaking the ice with Lego; a lesson in good engineering practices

Elmar Schippers — Tue, 10 May 2022 20:34:39 +0000

TL;DR: This is a little tale of how we broke the ice between our employees, got to play with lego, and still managed to squeeze in a lesson or two on good engineering practices.

Our company is growing, fast! With exploding from 150 to 370 strong team new in the last year, there are continually new faces to try and meet. As we are a highly remote company, meeting new faces can be a daunting and Donut filled task. So when the opportunity to meet everyone, face to face, presents itself, you have to make the most of it.

During our recent all-hands event, 140 people from our technical orgs came together for a day of mingling and connecting. 49% of the attendees were within their first 6 months of being at the company, with a whopping 80% of attendees being with in first year. With so many faces in one place, it can be intimidating for the tenured folk and a complete sea of unfamiliarity for the newer people.

Lego Ice Breaker Challenge

In order to relax everyone and have a bit of fun, we kicked off the day with a Lego "ice breaker" challenge. Team of 8 were formed, consisting of 4 people with less than 6 months tenure and 4 with over 6 months tenure. After giving people a moment to say their names and mingle, the teams were split into two sister teams.

Part 1: Sometimes we get to create a model masterpiece

For part 1, each sister team was provided one of two instruction envelopes and half a box of # 10698 lego. The "A" team was tasked with building a model house, and the "B" team with a model cafe. Each instruction set included choosing from a list of options, creating the structure and furniturishings.

Team's were given 15 minutes to build as much of their model as they could. Trading of bricks was encouraged, in case one team had too many of a particular type of valuable building materials.

At the end of the 15 minutes, teams were asked to step back from their creations and we asked a few questions through a show of hands and audience response:

Did your team self-organize or plan first or did it jump straight into building?
Did any teams change their plan during the build?
Did any teams trade bricks with other teams?
Is there anything your team would do differently next time?

Nearly everyone managed to get over 80% of their model built in the time frame, with about a 1/3rd of teams trading for bricks. Most teams jumped straight in and designed as they built, with only about a quarter designing before building.

Part 2: Sometimes we are maintaining someone else's creation

While building something from scratch is great fun, some days we are tasked with maintaining and improving someone else's creation.

Teams were handed a second envelope that included changes and upgrades to the models. Before teams were allowed to open their second envelope, and without prior warning, teams were asked to switch with their sister team. Teams would now have to open the second envelope and improve their sister teams creation. (Note: If you are planning on running such an event, keep the switch a surprise. The collective groan from a large audience realizing what just occurred is :chefs kiss: )

The second set of instructions included modifications to the original plans, and another list of possible extensions to add. Teams were required to ensure that both the first and second set of instructions were followed. Most teams were left scratching their head to what stood in front of them, while some teams quick to realize they could still communicate with their sister team and get some knowledge handover.

Teams were given just 10 minutes to modify the creation and ensure both Part 1 and Part 2 were complete. Team's learnt from their first round of building and were incredibly crafty and creative in solving the design problems with the limited remaining bricks.

Upon the timer ringing out to stop, we walked around with a mic and asked one member of each team to answer two questions for us:

What did your team do well and not so well?
What could your sister team have done to make maintaining/modifying their creation easier?

The most interesting responses included:

Most teams found it difficult to figure out what the original team had built.
Some teams worked in much closer collaboration for round two, resulting in a high level of information and block sharing.
A few teams had sorted the lego by block type and/or color, making it easier for the next team to get in and start building.
One team gave high praise to their sister team for building on top of a design drawing with labels to what each room was, leaving them with clear documentation of the design.

All a bit of fun, with a bit of learning mixed in

The whole exercise took less than an hour to complete, but it broke the ice between people with a level of success that we hadn't expected. The room was alive with chatter, people were laughing and making new connections.

Even though teams were playing with lego, they ultimately saw the link back to software development. Building something new can be fun and exciting, but we should endeavour to create cleanly and keep good documentation for we never know when our creation will unexpectedly by handed to another team (or we get handed someone else's creation).

If you want to try this exercise with your team, you can find the instructions for the teams here: https://github.com/ESchippers/Lego-ice-breaker