As to our yearly tradition, we were present at DevopsDays Amsterdam.

At DevopsDays we do not only get to listen to great minds sharing their experiences with us on the main stage, but also get to share knowledge between attendees during openspaces. It is in those openspaces especially that we've found much of the knowledge that stuck.

Both are focusing on culture building, soft skills and wellbeing rather than about tooling. As this is the actual hard thing that often takes the longest to implement, but potentially delivers beyond expectation.

The conference being single-track, also avoids the paradox of choice issues that can be had at other multi-track conferences.

The first day of the conference started out with various workshops.

Become a person of influence - workshop

Sadly the full 30 people beat us to the 'Become a person of influence' workshop. We identified our root cause to be the queue for a delicious coffee, sponsored by nice people of Greater, to get our day started. ☕

Efficient Peer Code Review - workshop

📄 Program description

Luben gave us a quick rundown of why an organisation needs peer reviews and best practices, with QA during the intermezzos.

One of the important notes Luben made, was that whilst there are many books and blogs on the subject, these are not to be taken at face value. Do not take book methods at face value, see what works but adjust them according to your teams needs. So use the following as guides, not as rule set.

Why

If more software engineers review the code, there will be less bugs and in general the maintainability of the code will be improved. [study]

• reduce bugs
• improve maintainability of the code
• improve knowledge sharing
• improve ownership distribution
• helps onboarding new colleagues

Good reviewee practice's:

• practice good commit hygiene
  • write a clear title
  • write a short title
  • write a clear commit message with proper casing and punctuation
  • explain what the commit does and why it is there in the commit message
  • include the ticket/issue number that caused this commit to exist
• assign anyone in the team as reviewer
• never self-approve a commit
• divide an conquer: use small and cohesive MR/PR
• ask feedback before starting a major change to avoid disagreement too late in the flow
• functionality tests should be in the code
• describe how the change can be manually tested

Good reviewer practices

• do I understand impact and value of this codechange
• are the changes covered by enough tests
• are there no errors in the logic
• is the code readable and maintainable
  • ask yourself 'do I want to own and maintain this code'? The answer should be yes
• spot non-functional requirements
  • look for security issues
  • look for scalability issues
  • look for performance issues
• is the code compliant with rest of the codebase's style?
• avoid reviews from growing into personal arguments
  • be nice in comments
  • also propose solutions when encountering an issue
  • leverage pair programming
  • differentiate between personal preference and real world problems
  • be in time to pull in the team and let the group decide

Requirements

Luben noted that there are some requirements for being able to do code reviews properly. Having good team relations mixed in with proper team culture is paramount as bounced reviews can sometimes feel personal, with conflict and tension as risk. Whilst investing in these can require quite some effort, it is well worth the investment, as companies that do use code reviews are more likely to become successful.

Algorithm for adding code reviews to your workflow

1. agree on and define what constitutes as 'done'
2. require a code review in that definition
3. discuss the value of a code review within the team
4. do it for some time
5. reevaluate with the team

It is important to note that starting with code reviews is not a top to bottom decision, and should never be. The value that it brings should be shared in a way that it becomes a clear desired value by the engineers. If it is enforced, one might get artificial reviews where changes are just being accepted without being properly reviewed.

Pitfalls to avoid

• only tech lead does code review
  • every member should be a reviewer
  • up-skill members so they can do it faster
• arguments about code formatting
  • agree on format/style
  • use linters to automate this
• new members can feel intimidated
  • explain it is a process, just to help, not to ostracise
  • if you like something, also comment on it
• code reviews take ages
  • smaller PR/MR
  • ask for feedback before working on big changes

From the Q&A

One of the participants requested Luben's thoughts on AI for code review to which he responded with a clear:

I am not convinced yet, let's see what the future brings.

Someone requested whether it is possible to do peer reviewing with remote teams

Code review can be done both in sync or async. With async it is easier to overcome time-zone differences.

Steven noted that he's applying Conventional comments as to clarify his intent in reviews.

At Silverfin

Within the infrastructure team at Silverfin, we have the habit of asking peer reviews not only for code (IAC) changes, but also for run-books, documentation changes and blogposts. The main value we get out of this is the verification of our concocted solutions and eliminating the bus-factor by spreading knowledge and keeping everyone in the loop. We would not have it any other way.

Dude, where's my data [in k8s]? - workshop

📄 Program description

Andrew Hill prepared a nice hands-on workshop for us to experience the capability of the Portworx toolset.

We each got two EKS clusters that were running the PetClinic spring app, that holds some stateful data.

• first we did cordon the whole node that was holding our database pods
• then witnessed the database with modified data to be available on the newly generated nodes
• then we did a disaster recovery failover from one cluster to a separate cluster (that had async replication from Portworx scheduled)
• and verified the data to be replicated to the other cluster

It boils down to the Portworx abstracting a lot of complexity with block level replication that makes it easy to use. It succeeds in this by leveraging Stork - Storage Operator Runtime for Kubernetes in combination with their own Kubernetes StorageClasses.

An open source alternative to Portworx that was mentioned, but not evaluated was Longhorn. Andrew noted that whilst he has no hands on experience with Longhorn, he expects it to offer less services, such as the disaster recovery methods provided by Portworx.

For people that want to see this in action, it is possible to do so without installing through their interactive tutorials.

HTTP fundamentals - workshop

📄 Program description

Michael Arenzon went over the history of the HTTP protocol as a whole, and had us think about the amazing fact that HTTP has been serving the web since 1990 and is still operating whilst keeping backward compatibility.

This was a refreshing way to look at the anatomy of a URL.

He followed up by inspecting the request and response headers and the individual function of each of the lines.

Example of response headers:

HTTP/2 200
age: 170169
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Mon, 26 Jun 2023 10:14:15 GMT
etag: "3147526947+gzip+ident"
expires: Mon, 03 Jul 2023 10:14:15 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (dcb/7EA3)
vary: Accept-Encoding
x-cache: HIT
content-length: 1256

Most of us are probably pretty familiar with these, but have you ever written your own webserver to send the appropriate ones?

That's exactly what he did in the hands-on part of his workshop. He presented us with 9 levels of challenges, where it starts to get interesting from level 6. Be sure to try them out yourself.

So rather than having you read through each and one of those, I invite you to go out there and do the challenges. Tip: check out the other branches if you're stuck.

There was no recording of this talk, but quite resembles the one they did in Tel Aviv in 2020, which was recorded.

Come and play! Learn how to deal with resistance!

📄 Program description

Mark Heistek organised an interactive workshop where we started to play a game. This was quite confusing at the beginning. My feeling went from "What's this bs good for?" to "I don't really care, I'll let others play it and just watch" all the way to "What am I doing over here, I wish I could just leave.*".

And then suddenly the workshop leader presented Theory U. It is a change management method that explains how we perceive or deal with changes in our life.

We move down one side of the U (connecting us to the world that is outside of our institutional bubble) to the bottom of the U (connecting us to the world that emerges from within) and up the other side of the U (bringing forth the new into the world).

It is the process of understanding the old and the new (which is supposed to be better) and letting go of the old. This is a repeatable process.

If there's a change in our life (eg moving from technology oriented teams towards product oriented, from startup to beyond scale-up,...), we tend to push back, reject it or even consider resigning over it.

This is an universal problem. I have experienced it in a previous job. The company grew quickly from 5-10 employees to well over 200 employees, and resistance arose. After a couple of year I talked to my friends and former colleagues, and they explained that those changes actually worked out in the end. That particular company even performs better than before. Did you see the U? Found the move to performing phase?

And here comes the point! Maybe, letting people know that negative feelings are expected, and eventually they will open up to the change and embrace it.

Keynote - Long live the imposter syndrome!

📄 Program description

Julia Sullivan also known as the author of Geeks Guide To Work and from that Become a person of influence workshop we missed, gave a talk on how we can conquer our fears and use our humanity to create stronger relationships with our peers and ourselves.

And whilst this is a keynote, it felt more like we caught up to her workshop. It was one of those interactive talks where the audience was involved. And not in the way we're used to, shouting answers to someone on stage... Noooo, we had to go 1:1 with the audience member that was sitting next to me.

Julia started out by sharing some of her fears to turn it around and proclaim that every single person is being confronted with daily fear. Even moreover, the more people try to hide their fear of X, the more they are showing that exact fear. A well known example is the persona David Brent from the office.

She had the audience turn to one of their neighbours and talk to that person about one of their fears they once had but turned out to be completely unjust. She then had them reverse the roles, and listen to the other persons worst baseless fear story. From this experiment, the audience could conclude that 'something' is happening. When people talk about their fears and listen to others sharing their fears, those fears start to fade. We make room for humanity to shine through.

She noted that we always look at life from the inside to the outside. All what we see, is going through a filter, making our thinking unreliable. We have these biased ideas as a result.

And on that note there was another interactive session. A stand-up 1:1 like before, and just staring each other in the eyes for 30 seconds straight. I can reassure you, 30 seconds equals eternity at that point. Julia then asked to talk to each other about that experience. How did that make you feel.

It succeeded in its goals, it created awkward situations where people are trying to divert their eyes, start laughing, or just want to sink in the ground. It takes people out of their comfort zone.

Imagine doing this with a random stranger. Really, try your best and imagine being there. Staring in a stranger's eyes. Feel it already?

But at that point, where you get to talk and share your experience, the awkwardness had left the room. It was replaced by humorousness. Voices were exited. You could feel the newly found energy.

Which all can be summarised as how understanding and admitting your fears can be the start of evolving your fears and improve on a personal and professional level.

Here is a step by step to conquer those fears in your day to day life. Approaching them in a conscious way is much better than facing them reckless.

1. admit when something is not working
2. question 'How am I hiding my fear?'
3. question 'Do I want to continue hiding my fear or grow?'
4. set a purpose for which you'll leave the comfort zone
5. invest in learning and growing.
   - this will require commitment courage and sincerity
6. Am I able to deliver?
   - the fear will still be there, but less.

The Art of Turning Incidents into Opportunities

📄 Program description

Busra Koken came to us with a talk resolving everybody's favourite events at work. The incident response.

If you have ever had the pleasure to be at work during an incident, you might remember that these incite quite some non-positive feelings such as chaotic, stressful, confusing. But surprisingly enough, also some rather positive ones: stimulating, togetherness

• chaotic
• stressful
• confusing
• stimulating
• togetherness
• ...

All engineers have a 'that time I broke production' story, as she shared hers. She broke something and had to tell people that she did something, and needed them to help her fix it. This was not a great moment to have.

But as the incident progressed, she started to feel calmer as she started to realise that she was not alone in it. They were just as surprised as she was that her actions such an outage. They were genuinely happy to have found a gap to fix.

She explained there are distinct periods to an incident:

When shit hits the proverbial fan

• this is when an incident needs to be resolved
• not the moment to figure out the root cause
• not the moment to argue
• have a clear lead commander that triages tasks and responds to queries from outside

When things are chill

• make some of the unknowns known
• documentation is not the same as practice
  • compare it to reading the manual of a new board game versus playing the first 'demo-round'
• declare test incidents and play around with tools (in shielded environments)
• learn to coordinate
  • Busra's team have a Pokémon like card-game that teaches exactly this. I could not find anything on this online, so if you the reader know more, please inform us!
• test services before the outage to figure if they scale and what depends on them
• create a shared understanding of incidents

In a nutshell, we can identify some learnings in a controlled manner outside of the incident, and even before an incident took place already.

The point is not if we are learning but what we are learning

Incidents are unplanned investments; their costs have already been incurred. Your organisation's challenge is to get return of investment on those events.

We do not need more tools, we need more comfort during incidents.

Coordination

• have a lead commander to lead the response
• share responsibilities through roles
  • Make sure everybody is handling the incident at their area of expertise

Events will always be messy... We can just make them less messy after the dust settles.

Do not go write boring grey Post Mortem's. Tell the story like you'd tell your friend. It makes it more juicy and includes frustrations. Say things like 'I was glad Gary was on-call, as he is a master in this area, someone else would not have been able to resolve this as quickly'. This is a near miss, which is important to track, and would be lost in a templated Post Mortem. The human side of the incident is lost in a templated Post Mortem format.

The main takeaway here is to not focus on processes and tools. Focus on what works for your organisation and what makes people feel more comfortable during incidents. We do not need numbers for everything. We can just talk to each other.

Learn Sociotechnical Systems The Hard Way

📄 Program description & slides

Andrew Clay Shafer came to us with knowledge from the 50's coal mining industry.

Andrew loves to dabble in Dr. W. Edwards Demming literature and is here to share some of his awesome quotes.

One gets a good rating for fighting a fire. The result is visible; can be quantified. If you do it right the first time, you are invisible. You satisfied the requirements. That is your job. Mess it up, and correct it later, you become a hero. - Dr. E. Demming

Trist and the Tavistock Institute

Eric Trist visited (the Haighmoor seam) a coal mine in Yorkshire where they used to be working according to a combination of Max Weber's bureaucracy and the principles of Scientific Management by Frederik Winslow Taylor. As their conventional way of working did not let them reach all places of the mine, and made it unsafe, they started self-organising into multi-disciplinary teams to solve some of these problems. Trist was amazed by what he found:

He wrote the 'Evolution of socio technical systems; a conceptual framework and an action research program' Trist took the learnings, and started applying it to other areas of production, as his findings did not align the interests of coal barons.

Long wall vs Short wall mining

In long wall mining they used to work each shift on a single task. One shift would be tasked with moving the conveyor belts, another loading the coal and so on. Everyone was working on his own small task, and no one saw the whole process.

In short wall mining they would divide the long wall up in different smaller sections, and put teams of various technical backgrounds together to complete the task from start till end, independent from the other groups. They would get to organise how to work on their part of the wall on their own.

On paper, the Longwall mining system should be much more productive than the short wall system. In reality the expected productivity never happened.

The quality of any organisational system can only be understood and improved if 'social' and 'technical' are both considered as interdependent parts of a single system.

Trist did work out some principles around this:

1. the work system, which comprised a set of activities that made up a functioning whole, now became the basic unit rather than the single jobs into which it was decomposable
2. correspondingly, the work group became central rather than the individual job-holder
3. internal regulation of the system by the group was thus rendered possible rather than the external regulation of individuals by supervisors
4. a design principle based on the redundancy of functions rather than the redundancy of parts (Emery, 1967) characterised the underlying organisational philosophy which tended to develop multiple skills in the individual and immensely increase the response repertoire of the group
5. this principle values the discretionary rather than the prescribed part of work roles (Jaques, 1956)
6. it treated the individual as complementary to the machine rather than as an extension of it (Jordan, 1963)
7. it was variety-increasing for both the individual and the organisation rather than variety decreasing in the bureaucratic mode

Does this resemble something you've heard of already? This was created in 1981.

Where did it go?

So why did we re-invent the wheel, you might wonder.

Short answer; The Divisional Board did not wish to give it any attention.

The Divisional board feared the power change that would be consequent on allowing groups to become more autonomous at a time when they themselves were intent on intensifying managerial controls in order to accelerate the full mechanisation of the mines. The whole project was regarded as not meriting continuation. Granting more autonomy was not popular. The autonomous teams were reset to the conventional system by special pay for operators of new equipment and bonuses for various classes of workers. As the coal industry was being taken over by oil, no one wanted to wager any changes to their system.

Innovations were not likely to survive, unless the organisation as a whole changed.

Introducing MTTLC, Mean time to leadership change.

Focusing on DORA metrics? Flow metrics? There’s a critical metric you may not be considering, MTTLC. Mean time to leadership change is a critical metric to track. If you have an improvement effort that will exceed MTTLC, you should reconsider starting that effort. Odds are the priorities will change and the most important people, those actually doing the work, will get frustrated and leave. - Bryan Finster

The only reason we know of Deming now is because he went to Japan

Some history on this Edward Demming in short:

• Demming worked in wartime production during World-War II
• he was moved to Japan where post WWII could use his expertise more then the US
• he trained hundreds of engineers, managers, and scholars in SPC and concepts of quality
• his message to Japan's chief executives was that improving quality would reduce expenses, while increasing productivity and market share

Japanese industries did not only send their engineers to his lectures, the executives themselves would also show up to learn about his teachings.

No Deming, No Toyota, No Lean, No Devops

With the likes like Toyota, Sony, and many more it was clear that his theory was the correct one. But the US industry did not recognise that. They were heavily investing in automation and mass production, rather on focusing on quality. When their executives went to Japanese factories, they thought the Japanese were hiding the truth.

Lowland Socio-Technical systems design

A system design created close to home (NL conference) in the 70's by Ulbo de Sitter.

Some principles (de Sitter, den Hertog, and Dankbaar 1997)

1. According to De Sitter, any organisational design should start from the point of reducing the structural complexity and increasing the flow capabilities.
2. Organisations must transition to the state of having a simple structure with complex jobs to be able to deal with uncertainty, complexity, and environment changes
3. Optimising flow is the work of smoothing the boundaries between tasks and teams.
4. Optimisation results from ‘Productive Conflict’
5. Ongoing negotiation to establish Common Ground enables the emergence of shared practices

The socio part builds on collective narratives. Everyone want to be a hero in the story.

We have the tendency to attach identity to tasks and when these tasks changes, it can feel as if our identities are being erased.

Hermeneutical Injustice

This is a concept introduced by philosopher Miranda Fricker in 2007.

If people can't find themselves in the stories that are considered important, they are at a disadvantage because they can't use those stories to understand and explain their own experiences. Which in turns causes people's stories not to be trusted or included in conversations. These marginalised individuals are disadvantaged because they can't fully contribute their ideas, knowledge, and stories to the society they are a part of but not acknowledged by.

The devops everyone want

• reliability
• availability
• scalability
• operability
• usability
• observability
• all for free
• without changing anything

Because everyone knows that performance almost always goes down before going up!

Takeaways

I took these verbatim from the slides as I could not make it better or shorter:

• autonomous teams outperform command and control, but only when supported
• joint Optimisation with the Socio maximises the value of the Technical
• everyone doesn’t need to do everyone else’s job, they just need to value the interdependence
• change is hard. It was hard for Demming and it was hard for Trist
• it is not a technical or people problem
• it is a problem we'll have to solve together

A bad system will beat a good person every time. It is not necessary to change. Survival is not mandatory. - W. Edwards Deming

Planet earth as a stakeholder

📄 Program description

Marjolein Pilon pitched how she as a Scrum Master is lowering the carbon footprint of her teams work.

Datacenters are estimated to be using up 1% of global electricity. The IT sector as a whole is estimated to about 4%. These numbers are predicted to grow exponentially.

She leaned in to the Green engineering and discussed ways to reduce the carbon footprint of their projects.

This can range from big to very small changes to reduce wasted resources. Thinking about turning down systems when they are not in use, reducing replication where it is not mandatory or even just disabling the webcam during zoom calls.

Find tools to measure the environmental impact of your services. For example the Azure Emissions Dashboard, AWS Carbon Footprint Tool, or Google Carbon Footprint Dashboard.

She advocates for taking up the earth as an extra stakeholder when building your projects. By placing it as a stakeholder in your epics and templates, it should be taken in to consideration on all levels.

She noted that having a sustainability sprint can be held to tackle all your low hanging fruit.

By all doing small steps together, we can make a positive change for our planet and future generations.

Ignite talks - Day 1

Ignite talks is a great concept for the talks that did not make it to the main line-up, or for people that want to do a short talk without having to be on the main line-up.

You get 20 slides.
You get 15 seconds a slide (automatically progressing).
You get a total of 5 minutes on stage.
It is just you and the audience.

SOS, please someone help me!

📄 Program description

Daniel Bodky explains to us how he has been chasing the many tools out there for years. The plethora of tools leads to the paradox of choice, giving you the ever lasting choice of picking the wrong one. This leads to frustration because of the lack of result.

He argues that persisting your findings and to try to learn something about everything, not everything about something, is the way forward.

Accessibility for everyone

📄 Program description

Laura Kalbag

Some people are faced with limitations as to which they are left to navigate the screen guided by screen readers and a keyboard. It is no exception to find user experiences that are already sub-optimal for people that do not have a disability.

In her talk Laura explains what developers can do to help making the web more accessible for others.

• accessibility should be planned for
• label all your forms and buttons properly
• add proper keyboard navigation with tab-indexes
• know that good accessibility leads to good usability

Circling back to the foundation - from CALMS to KALMS

📄 Program description

Thiago de Faria is seeing more tools and less people related topics pop up. He wants to counter by adding a talk about focusing on the human part.

These are some of the things he want you to do to reach a more kind devops:

• kindness is important
• be positive
• share in a trustful way
• share your vulnerability
• ask for opinions
• listen actively
• earn and share respect in a team
• be more human

He would like to revisit the Culture part of CALMS and bring how Kindness should be the active common sense.

Developing a pipeline is like raising chickens

📄 Program description

Hans Broeckx comes to us after a bit of a wager between himself, Chris Buytart and Floor Drees

He drew many parallel between chickens and our jobs. The crowd went crazy.

• Food - code - egg
• Code - agent - artefact
• More chickens : load-balancing
• Testing: visual check of egg or sniff-test
• Packaging: packages
• Deploying: chug egg in recipe bowl

Which ones would you be able to come up with?

DevOps Meditation, maybe

📄 Program description

Daniel - phrawzty - Maher came up to the podium, sat down with his sunglasses and cap on.

His slides compromised out of scenic Zen images.

In a calming voice he start to speak...

• 'Devops wisdom'
• A boy asked me: 'what is devops?'.
• 'Devops is calm'
• 'No more Jira tickets'
• Gets hyped up as phone appears to be buzzing
• Relaxes again
• 'Years of guesswork'
• 'To come up with complete answers to incomplete questions'

and to which point my hands were too relaxed to continue any more typing.

As he suddenly speak the following wise words:

• 'But trust me on the sunscreen!'

Openspaces - Day 1

Peer devops

A group revolved around the notion of peer devops as a follow-up to the workshop the day before.

Someone shared that they enforce people to pair on an issue if their code is bounced for the 3rd time in review, and it resonated with me.

Uninterrupted focus is required. It is OK to put blocks where you pair as unavailable in your schedule, and block out all distractions. This includes notifications and phone calls.

Some teams apparently do code reviews during their daily standups and include all their team-members. It is a rather interesting approach, and I think it is a luxury if you can afford to do this.

Someone suggested using AI for proper commit messages. Now there is an idea worth exploring.

Some people seemed to have issues with reviews taking several days or do fall outside of their sprints. We believe this can be fixed by forcing reviews on context switching. In short, we label issues that are ~w4::review as such. We do not specify anyone to review. The deal is that everyone within the team should pick up the waiting tickets on context switches. Say, someone comes back from the toilet, or from grabbing a coffee, or walking their dog... As the context switch has already occurred, it is the perfect moment to start pulling stuff from the waiting tickets before going back to their own focus ticket. When MR/PR's are small enough and commits are properly formatted, reviews should not take several hours. But we could write a whole blogpost on how we work... and perhaps we will.

That time I broke production

As a follow-up on her talk, Busra Koken told us that after sharing her I broke production story, she wanted to hear ours and more so what we learned from it.

One of the takeaways here is that when you have an outage, it can be useful to state a timeframe in which you'll provide an answer to stakeholders. This allows you to resolve the issue without constantly having to update several stakeholders. A notification such as A follow-up status will be provided in 30 minutes gives some breathing room.

Having someone as a commander that gathers the status and makes sure the right people are tracking the right hints can be useful.

Humans are not to be trusted and flawed, failure is normal.

Book tips from this open space:

• Safety I and Safety II
• Engineering a safer world

Devops & Audits & Regulatory stuff

Someone wanted to talk about how other tackle Audits and regulations.

There was a common agreement that audits are a pain, and can vary widely between auditing firm/auditor. Being operational in several regulatory zones makes it even worse.

The regulations are vague in their stipulation and keep the exact implementation for the implementor, which the auditors can then disagree on. Even if technically the implementation does exactly what the regulators wanted to cover with the regulation.

It helps to have someone knowledgeable in the field to be present during audits. This can elevate many pains, and potentially extra work after the audit, as the auditor can get a complete and in some cases technical rundown.

It is all about providing the processes and having timestamps. Why some of the auditors still request screenshots with timestamps as proof, was something no one could explain.

Keynote - There are no soft skills: making empathy actionable

📄 Program description

Sharon Steed grew up as child with a stutter. As many children outgrew their stutter, hers was there to stay.

As a child with stutter growing in to adolescence she grew to become an active listener in conversations. But as she had to enter the workforce, she figured she'd have to talk to people at some point. So she figured to pursue public speaking to 'get it done and over with'.

But as she progressed, she landed a gig to give a course at LinkedIn. Having a team on site in a studio to prep her, the sound, the lightning, and all the other things required for the recording, she felt like Beyonce.

It was up till the moment where she entered the recording studio, and noticed the teleprompter. It is hard to come across natural without a speech impairment when reading from a teleprompter, but impossible for someone with a stutter.

After crashing at the horrible experience of having people suggest 'someone else to give the course', and lots of crying in a hotel room, she suggested all the folks in the studio to leave. The team understood, reorganised so that everything could be done from a bit away. She then, relieved from the pressure, continued her course.... and it worked. It was the team that came together and understood her position in the end that made the recording possible.

And this is what is important in teams. Be emphatic and pivot to make someone else comfortable.

• companies with high employee engagement are 23% more profitable
• 90% of people are more likely to stay at a company that empathises with their needs
• it is in the role of Devops to promote empathy - Viktor Farcic

How to make empathy actionable

Patience -> perspective -> connection

Using the term Soft skill devaluates the importance compared to hard skills. These skills are not easy.

• Active Listening: Steed promotes active listening as a crucial component of empathy. By actively listening to others, we can better understand their perspectives, experiences, and emotions. This understanding forms the basis for taking meaningful action.
• Perspective-Taking: Empathy involves putting ourselves in someone else's shoes and trying to understand their point of view. Steed encourages individuals to cultivate a mindset of perspective-taking, which helps us consider different viewpoints and expand our understanding of others.
• Verbal and Nonverbal Communication: Steed emphasises the importance of clear and effective communication. She encourages individuals to use their words and body language to express empathy and create a safe and inclusive environment where people feel heard and understood.
• Emotional Intelligence: Understanding and managing our own emotions is crucial for turning empathy into action. Steed helps individuals develop emotional intelligence by recognising and regulating their own feelings, which enables them to respond empathetically to others.
• Collaboration and Problem-Solving: Empathy becomes actionable when it leads to collaboration and problem-solving. Use your empathetic understanding to work together, find common ground, and address challenges in a constructive manner.
• Inclusive Decision-Making: Empathy is vital for creating inclusive environments and making decisions that consider diverse perspectives. Ensure that all voices are heard and valued.
• Remember: It's not about You!
• Repeat and rephrase what others said to you back to them, this will create clarity and minimise bias.
• Each interaction will improve or worsen your experience, act accordingly.

Every conversation is the beginning of your further relationship (with friends, colleagues, etc..)

Stop Chasing Unicorns and Rainbows: The Dangers of Survivorship Bias in Tech

📄 Program description & slides

Lou Creemers introduced herself with her love for 80's music. She went over all the music she likes, such as The Pointer Sisters, TOTO, Madonna, a-ha, .... and then went over to music she does not like so much.

You guessed it... Full screen rick-roll!

But she had others lined up that were truly awful such as the Birdie song from The Tweets and Agadoo from Black Lace.

So we tend to say we like 80's music, but make logical errors and fall right in the trap of survivor bias.

We tend to forget failures.

The same goes for shiny new tech hypes. It gets selective attention and affect entrepreneurs, conference visitors and social media users.

In the land of Entrepreneurship, we encounter the same survivor bias. We hear a lot of success stories online and there seems to be new succes stories on a daily basis.

However, 9 out of 10 startups fail and only 1% of the startups become unicorns. Even HOT companies get unlucky and are never heard of after. Think of brands such as Blackberry, Nokia, Evernote

Prevention

Online users should be wary of algorithm hype. It is not there to inform you, it is there to keep you engaged. People online want attention, and people want money. All of this leads to survivorship bias.

Conference visitors should not take the speakers word for it. Be sure to try the shiny new thing they promoted. Be sure to ask questions during Q&A. Ask for failure experiences, future plans and compatibility. Ask for examples of non-compatibility, risks and limitations.

Look for the bigger picture. Look for unbiased blog posts, check user reviews on Reddit or ask people in your network.

Start tinkering. By tinkering with it, you can figure out its usefulness and gather new knowledge.

Unmet expectations

When you fall for the last new shiny, you might have lost time, money or get trapped in the impostor syndrome. All these other people succeeded with that, but you failed. Over and over again.

How we use Data to Ignite Action

📄 Program description

Julie Starling introduced herself as coming from Wales which according to her is a city, not an animal.

She made this statement, to which I can only agree.

Software delivery is uncertain. Believing otherwise will loose a lot of time.

But then begs the question, how do you estimate time?

And her answer to that is 'Guess!'.

Q: what is 'late? Mismanaged planning!

When you tell people that there is an 85% probability that 30 items get done by a certain date, they'll hear that their specific item will be done by said date. This is normal, people look for certainty. It is our task to make clear that it is a guesstimation.

Estimating time is done by humans and is taking up lots of time and energy. Forecasting on the other hand is done by computers, and fairly cheap.

So what if we could forecast estimates for 'done' like we estimate the weather. It'll probably be cloudy by Monday in 2 weeks. But the closer you get to that date, the more that message can start to differ from the original forecast. And this is also true for software goals. The further you plan in the future, the less likely it'll be correct.

Better to be approx right than exactly wrong.

When you can have data based conversation on when a scope of the project changes, you can make that conversation more tangible. Presenting data and having guesstimations made a thousand times over to narrow down the probability, can show the impact of actions that took place.

Julie shared her graphs of where they introduced WIP limits, and its impact clearly visible on the scatter plot.

Story points are not meant to set planning expectations, but are used as such.

I found this talk very informative and can't do the talk any justice without the slides being shown. So make sure to check out her full talk!

Giving for your own good: How volunteering improves your career and well-being

📄 Program description

Ivan Milchev comes to us with how his volunteering in the podkrepi.bg project has helped hem progress on both personal and professional levels.

First of all, he shared with us the concept of podkrepi.bg. You can see it as a go-fund-me from Bulgaria that was founded after all similar platforms ended up creating a bet reputation for public funding.

Ivan had a burnout and was vocal about it. This led the community to reach back to him and get him involved in several projects. By meeting both online as in real life, it helped Ivan to get out of the burnout.

Being involved in the projects gives him the opportunity to better his skills with tools such as Kubernetes, and meet very interesting people.

He did a special shout-out to all open source projects that made the platform possible.

Openspaces - Day 2

Vacation with kids

As a quite recent parent of 1, this poked my interest.

Someone is going to Tessel. Over there you can do a pirate ship tour or visit a seal rescue.

General recommendations to do with teenagers:

• Go Camping once they are 4 years old, they go nuts over it!

Travel tips:

• make sure there is appropriate music
• give them an old tablet or phone
• FOOD! Bring food and drinks!
• Get your kids tired before getting them on the airplane

Remind yourself: You are not their entertainer. It is OK for kids to be bored.

One of the attendants arranges holidays where he takes half days off, so that he works in the AM, and uses the PM to play with his kids. This way he doubles the amount of vacation he has. This does not work for everybody as some need to disconnect completely.

One of the attendants tipped sending kids to camps (Where they stay a longer period of time, and also over night), and book city-trips for yourself and your significant other. This way you get to see the cities that the kids won't like.

As far as taking kids on a motorcycle goes, shorter trips should start to work out at 7 years of age. But keep in mind to dress them for the slide. Wearing a jacket that allows them for easy grabbing on to, is a huge plus!

Scale up to enterprise survival

This one is from yours truly. ☺️

As a business grows it goes through the stages of going from startup to scale up and then to enterprise level.

Each of these levels comes with different requirements and structures.

How do you survive the period where a small high performing team suddenly has to deal with many new things that seem inherent to moving beyond scale up? Suddenly there are many managers that start to manage. These all have questions and require metrics to govern. New systems are being implemented. People might start to dislike the new course and jump ship. How do you navigate a team, and your personal wellbeing through these storming waters?

I personally approach this from an angle of interest. Many things will be tried, some will work, others will not. Valuable lessons will be had.

But what is a good way not to drown in the many extra meetings and requirements?

Whilst there were many people attending my open space, there was no real solution at hand.

People that came from a more managerial background suggested vouching for having someone (like a PM) to shield us from the meta things. I personally fear that this would feel like yet another manager.

Another person suggested to vouch for someone higher up in the food-chain that aligns with our values. A chief exec of infra or something. But this in my opinion also just adds another layer.

Several other people present said that this is inherent to scaling up and there is little to be steered. There is either top down a decision to not disturb functional departments, or you're in for quite the storm.

Ephemeral development environments

Someone that is working at a company that has many separate services running was wondering how to do proper ephemeral services.

Many solutions were proposed, going from mocking to vCluster. But it took a while for someone to suggest moving to the developers and requesting what they needed before starting to work out the solution itself. I applaud that person for not getting dragged in to the 'I have a hammer and every problem is a nail' kind of discussion. Being able to step back and go back to the essence is a true skill.

Concluding notes 📝

Whilst the conference program was a tad too 'soft' to my appetite, I had great talks with various people. The HTTP workshop and open spaces were amazingly fun.

A special shout-out goes to the organisers that, once again, delivered one of the best conferences I have been to! And to the sponsors for keeping the cost of attending as low as possible.

You can find the two full days of presentations on Youtube for when you have a couple of hours of time to kill.