20 Mar 2019 •
5 min. read • Read the comments
TL;DR
I believe there is both a positive and negative reinforcing feedback loop between appreciation, motivation and performance. And becoming aware of this simple model may help counteract the vicious aspect and strengthen the virtuous one.
If you want to practice using this model and see what other people can come up with, I invite you to join our next Kunlaboratorium. Oh, and here’s the loopy you can play around with.
Conception
The other day I woke up in the middle of the night and I had this urge to write down what I was thinking and see if my morning self also thought this was valuable somehow.
But first some context. I had been thinking a lot about Thinking in Systems recently and was sort of struggling with how to deal with some self-reflection insights I got at work.
This must’ve triggered this thing I had in my head all of a sudden.
Virtuous Motivation Cycle
When I feel Appreciated at work, I get more Motivated. Because I feel more Motivated, I do a better job and will push that little extra. You can say it has a beneficial effect to my Performance at work.
Then, because I’m noticeably more Performant, I’ll get more Appreciation from my colleagues and customers. And so the cycle continues.
Everytime this cycle restarts though, the strength of the positive reinforcement between Performance and Appreciation diminishes. Either because those little extras I put in at work will be expected from me, or because they’ll become less visible.
I’ll call this the Virtuous Motivation Cycle.
Vicious Motivation Cycle
However, there is also a Vicious Motivation Cycle.
When I don’t feel Appreciated by my colleagues or customer, I get Demotivated. Which in turn affects my work Performance in a bad way.
I don’t feel like putting in some extra effort, because it will go unnoticed anyways.
Because my work Performance (visibly) lowers, I will get less Appreciated (like a self-fulfilling prophecy). Causing me to feel even more Demotivated, etc.
Everytime this cycle restarts, the strength of the negative reinforcement between Performance and Appreciation increases. This is in stark contrast to the Virtuous Cycle where the Positive effect Diminishes.
If you’ve been nodding your head in agreement to what you’ve been reading I bet you’re dying to find out where I’m going with this. I was too when I woke up in the middle of the night and drew it out. And I thought I’d let morning self figure that out.
Usage
The next morning I looked at what dream self drew overnight and it still seemed to make sense. But what do I do with this knowledge of those reinforcing cycles?
When I arrived at work, the first thing I did after making myself a nice cup o’ joe, was to draw it out on the whiteboard next to the lunch tables.
After some impromptu conversations with some of my colleagues and having explained the model, it dawned on me that there are a bunch of different triggers to both cycles, by affecting one of the circles (Appreciation, Motivation, Performance).
For example, when I get positive feedback from a 360 review, this triggers the Virtuous Motivation Cycle starting with Apreciation.
Or, when we have to do rework on a feature because I didn’t test it properly enough, it might trigger the Vicious Motivation Cycle starting with Performance.
Interested in what other triggers my colleagues could come up with, I hung up a post-it asking for exactly that. I made an accompanying slack post with a photo of the model and my request to add moar stuff and waited it out.
Here’s what we came up with.
What we see here is an overview of who works at our company and :
- what (de-)motivates them
- how we can make them feel (under-)Appreciated
- and what they need (and don’t need) to do a good job.
Neat huh?!
Other usages
Aside from thinking what can trigger those cycles, you can also take a different perspective and think about what actions or things that can counteract a cycle.
For example, if I notice I’m within a Vicious Cycle, I can use the model to see what positive reinforcing triggers that I know of have an effect on me to start a Virtuous Cycle to counteract the vicious one.
Other things you can do with this is a way of gathering data for your retrospectives.
I’ll blog about that properly once I actually performed such a retro myself.
You could also provide this as a basis of self reflection to your colleagues and/or friends.
I’m experimenting with keeping the model up on my wall and every day posting a post-it to learn about how my day went and see if I need to counteract the start of a Vicious Cycle or whether I can make a Virtuous Cycle stronger.
Conclusion
Please keep in mind that the above is nothing but a self-made model. As far as I know there’s no evidence that this works, or research for that matter, that actually verifies the relations or the cycles.
If at any point you notice something wrong with it, I invite you to throw this model away or improve on it.
It’s helped me put some stuff in perspective and my hope is that it can be useful for you too, which is why I’m sharing this.
Thanks for reading to the end, champ! I’d love to hear your thoughts on this, so feel free to leave a comment.
09 Jun 2017 •
25 min. read • Read the comments
Last year I blogged as well, and this year, I’m doing more of the same! Hooray!
Thanks are in order
Thanks for the laughs and many inside jokes to my travel companions and colleagues Frans Guelinckx, Steven Op de beeck. Imanuel Rennen, Tom Briers and Nathan Vandecauter.
Thanks also go out to our employer, Cegeka, who paid for travel, accomodation and the entrance fee for —let’s be honest— a lot of people.
Thanks to the organizers, White October Events, who once again did an amazing job at making everyone feel right at home and safe.
And thanks to Meri Williams, with her witty announcements, for being the perfect host and an inspiring example to us all.
Scribblings of a madman
Once again I took some notes, where I based this blogpost on.
Day 1 - Tech Leads, Feedback, and what not
Patrick Kua - The constant life of a tech lead
Last year I learned that Patrick is great at doing keynotes, so seeing him again as first speaker on day 1 was no surprise. Especially since it was on the schedule ;)
Pat focused his talk around three main parts of a Lead Developer: Tech, People and System.
Tech
He showed this nice graph of how multiple languages arose over time (starting with cobol, ending with Go). Restating that technology will always change and so, learning new technology (e.g. languages) is a certainty in our line of business.
However, when learning new technology, it should be ones focus to distill the principles that a new technology holds, not just the superficial parts like syntax.
Because it’s the principles that are transferrable to another technology.
For example, even though pure functional languages are really different from Object Oriented ones, you can still benefit from proper modularization. Same goes for the principle of code smells.
As an even better example, he mentioned the relevance of this paper on information hiding:
On the criteria to be used in decomposing systems into ~modules~ services
In short (read: butchered), it’s about how you slice a system, will dictate whether or not you get the benefits of the flexibility.
Even though it’s been around for a really long time, it’s still relevant today. Because it’s supported by a principle.
So next time you’re learning something new you should be asking yourself What can I learn which I can use in a different context, in a different tool?
This tooooootally hit home for me. As it did in some other talks as well. This is the idea of Forwards and Backwards Reaching Transfer. Something that I did a presentation on nearly 5 years ago. I think it’s time I pick up this idea again and really do something with it.
People
Don’t be a maker, be a multiplier.
Accept your role as Lead Dev and don’t just focus on making stuff anymore. Pay forward your knowledge and mentor people, in order to multiply your ideas, etc.
Read about how people really differ: Strengthsfinder (2.0).
Hofstede’s cultural dimensions.
Simon Wardly’s maps. Pioneers, Settlers, Town Planners
He briefly touched on diversity as well. In that diversity in and of itself is not necessarily beneficial. It’s strength only works when you allow it.
I think what he meant by that is that creating a diverse team of itself isn’t enough. Your job is to enable and maintain a safe environment for the diversity to foster. So that diverse ideas pop up automatically. This is no easy task, there is a danger of stereotypes popping up, instead of thinking of archetypes.
System
I was glad to hear this being said out loud: There will never be enough time (to learn all the stuffs).
There is SO much information to consume, and knowing what’s worth it, is going to be half the battle.
To help us in our fight he shared with us the Eisenhower matrix for more efficient time management. And proposed setting a time-boxed and scheduled moment for consuming social media.
He then talked a bit about Double loop learning, but that didn’t sink in as good as it should I don’t think. It seems too simple.
Instead of some Action having a Result, where that Result feeds back into your next Action (Single loop), which is a very reactive way of learning about things. You should Act from a Mental Model, which Action causes a Result that then feeds back into your Mental Model again and your next Action.
It sounded like Think before you Act, and also his topic about reusing principles when you think about it. These principles are the Mental Model from which you try to Act.
Something important he added though, is that you can also improve Mental Models via coaching (being coached). It’s paramount for Lead Devs to get your mentees to that Aha moment, so they can improve their Mental Model.
Dominika Rogala - Things you wish you shared with your team before they agreed on that deadline
Deadlines are known to get missed. But is there a way to prevent this from happening?
Dominika asked us these questions, and I’d like for you to give answers to these as well.
How many days are there in a year? … How many in a week?
If you answered 365 and 7, you’d be wrong.
There’s about 250 workdays in a year, and that’s without counting holidays.
Same for days in a week, there are only 5. Now think about how much of one day you can actually get work done. That means focused, non-interrupted work. So absolutely no context-switches, no mails, meetings, …
This was eye opening to me, especially because it seems so trivial. She also gave a very clear example of the I’ll do it in the meantime myth. Something I intend to pay attention to next time I find myself responding with that very sentence.
There was also this fine example of how assuming that ordering electronics parts in China during februari is going to be fine. When there’s something like Chinese New Year and all shops are closed for 2 weeks. Specifically she called this the unpredictability trap. I think in general you can classify it under assumption. It’ll be easier to think about whether or not your assuming something.
Then she talked about this thing called common priority. For example, for Christmas dinner, everyone is always on time because there’s this common intent of being together. But when there is none defined, the default priority kicks in. This is an individual one though, which leads to more assumption and miscommunications.
For example, if you don’t communicate that you’d rather get the guaranteed delivery on a shipment, than the cheaper delivery, your team might think they’re doing you a favor in cutting costs. Where you might miss a deadline because delivery got delayed.
So next time you need to estimate something, make sure that the ones estimating know:
- what time they have
- what traps they can fall into
- and what the common priorities are
Make sure they know, what you know.
Adrian Howard - How to talk to earthlings
Adrian’s talk was really nicely structured, because I noted down SO much fairly easily.
He talked about having more effective conversations with your team(s), but I think in a very meta sort of way, it was also about having more effective conversations with your audience. :)
Adrian kicked things off with this quote by Mary Parker Follett - Management is the art of getting things done through people, as he added The managers job is to build the organization, not the product.
In order to do that, you’ll need to understand your teams problems, understand their goals.
And here he was, using principles he learned from UX research, and applied them to talking with people.
Biggest mistakes you can make to foul up effective conversations
1. Not listening
Fix it by shutting up (stop talking), and staying quiet.
Gaps in a conversation seem longer than you think, and people will naturally fill these gaps.
When someone stops talking, just wait four or five seconds. You might be surprised how soon people talk again and what you can discover.
2. Not hearing what was actually said
For example if someone mentioned that We’re having problems with QA and TDD, you could ask: Can you tell me more about the TDD problems with the QA group?. Instead of either ignoring, or starting to talk about something else entirely.
This shows that you’re actually listening and will allow you to dive deeper into the problem they described (using their words).
It also allows to redirect when veering off-topic.
Every clarification breeds new questions
3. Asking about the future
Bad: What would you do if this thing happened?.
Because the answer you hear is likely to not be good, because people are generally bad at imagining.
Good: Ask for stories
Can you tell me about a really bad day for you?
What happens on your worst day?
What was the best/worst day last week
4. Leading questions
Ask open questions instead.
Don’t: You think QA needs more training in TDD?
Do: Can you tell me more about the problems in QA?
5. Being disrespectful
Being disrespectful can mean a bunch of things, aside from stating the obvious, there’s one that Adrian highlighted because it’s not so obvious.
In one on one’s, people will know when you are bored. Bored of hearing the same problem 4 times in a row. This will show in your tone of voice, and your body language.
So don’t be scary. Don’t be an arse. Pay extra attention to good manners, e.g. in introducing yourself properly if it’s the first time you see this person in a one on one.
Pay attention to your own body language. Or rather, remember your body language. The nuance is that remembering emphasizes recognizing the trigger, whereas paying attention to implies something you just need to do.
6. Trusting your memory
In that, trusting your memory is usually not ideal.
Write up your notes during the conversation/meeting.
Write down the things you want to bring up later. Use it as a driver.
Write it down in a way that you’ll be able to understand at a later point in time. This is something I think I’m already doing. I write stuff as if someone else is going to have to make sense of it afterwards. And that might include the daft me in the future. :)
Another great tip he gave was to try and separate insights and observations: Insights are conclusions you’ve drawn from what people have said, whereas Observations are merely things based on assumption. So really, assumptions you might want to validate in later conversations.
Summed up
Stalk before you talk before you sell before you build
Be Alfred, help your heroes be better.
Books
Practical Empathy - Indi Young(eBook)
Interviewing Users - Steve Portigal
Katherine Wu - Ask vs. Guess Cultures
Katherine Wu taught me something new. Another thing-a-ma-jig to put in my Perceptions Toolbelt.
Ask Culture
People that are more ask culture minded will generally ask you for the thing they want or expect.
They’ll be direct.
Will you come to my birthday party in two weeks?
No, I can't. I already made plans to hang out with some other friends.
Ask Culture can be good, because it prioritizes efficiency, there’s no ambiguity and it’ll get you what you want in the short term.
However, it’s more open to conflict and can make people feel uncomfortable.
Guess culture
Guess culture could also be described as offer culture, because you will feel it out, be vaguely suggestive about the thing you want, and then hope others will pick up on this and offer the thing you want.
I haven't got many confirmed RSVP's yet to my birthday party that's coming up in two weeks. I could use some real friends there to help celebrate. :)
Guess Culture prioritizes not hurting feelings, you’ll come across as being more polite and it’s style is generally more expressive.
However, it’s highly dependent on a a tight net of shared expectations, can be hard if you’re bad at reading social cues and it can make you feel like no one is listening to what you’re saying.
Understanding the difference is useful to know how to get your message across to someone from the other side. Different styles can be more appropriate for different situations.
Strategies in dealing with opposite cultures
Ask culture person dealing with guess culture person
Make a close friend out of someone you know that is Guess Culture, it’ll help you acquire a different perspective and become more empathetic when communicating with other Guess Culture people.
Listen more closely to what Guess Culture people are saying, and maybe more importantly, it’s also about what people are not saying.
Just apologize when you realize you made an ambiguous interpretation.
Ask What questions do you have for me? instead of Do you have any questions? in an effort to be less aggressive.
Guess culture person dealing with ask culture person
Remember that people might be unaware of the rules [of guess culture].
Resist the urge to soften a No in an effor to be more direct.
Takeaways
Katherine brought an interesting and new perspective of (mis)communication between people. And I was happy to learn that it’s a spectrum rather than a polarity. Where do you find yourself? Me, I’m more of an Ask Culture type of communicator.
Maria Gutierrez - Time to focus on your goals
Rob Allen - 5 Features of a good API
Anjuan Simmons - Leadership lessons from the agile manifesto
Anjuan starts with recounting the greatest influence on his way of being a leader: The Hero with a Thousand Faces, by Joseph Campbell. This book is about the path of the hero through life. Based on the book, Christopher Vogler defines a model for the hero’s path. Anjuan summarizes it as follows:
- The Call to Adventure
- Extreme trials
- Transformation
- Road back
The call to adventure is often met with refusal because of fear or responsibility in the ordinary life. Eventually the adventurer meets a mentor. She gives the hero both wisdom and gifts to help the hero on her journey. The hero is emboldened to overcome extreme trials and level up to approach the final ordeal. Overcoming this ordeal transforms the hero. this is often portrayed by the hero receiving a reward. Next, the hero returns home, atoning for the conflicts that were left behind in the ordinary world. Finally she uses her experience and the reward to improve the ordinary world.
Anjuan compares this with his decision to become a software developer and the trials he had to face and the experience he had to gain. He received certain gifts like structured, logic thinking that he uses to be a better leader.
The part that drew him most to Campbell’s model is the hero–mentor part. He realised the mentor has completed the hero’s story and is now helping someone else do it. In a way, the mentor is passing the baton —her skill and experience— to the hero.
Anjuan has found that the thing that comes closest to a baton in his life is influence. If he can improve this skill, he feels he will become a better leader.
The law of influence
Anjuan refers to the book titled The 21 irrefutable laws of leadership, by John C. Maxwell. The key point in this book is the law of influence:
The true measure of leadership is influence. Nothing more. Nothing less.
You can be a leader that wields his title, or a leader that gets buy-in of the team by using influence.
James MacGregor Burns describes it in his book Leadership as transactional (carrot and stick) vs. transformational (charisma to influence) leadership.
How does one apply influence in his role as a leader? Anjuan takes inspiration in the values of the Agile manifesto:
-
Individuals and interactions over processes and tools. People build software, processes and tools don’t. How do you get and keep a team motivated? Anjuan has found that “Preserve dignity at all costs” builds team influence. You don’t have to all agree, but you have to respect everyone in your team.
-
Working software over comprehensive documentation. “Working always ships faster than perfect” means that you have to start with something, and improve it along the way. Focussing on getting things working, instead of on perfection, gains “build influence”. People will start to see you as someone that gets things done. This applies to anything in your role as a leader.
-
Customer collaboration over contract negotiation. Customers trust colleagues, not contracts, so treat your customers as colleagues. Nobody reads contracts, don’t expect people to read them. Communicate with people directly. But not all your customers are your friends. Cut toxic customers.
-
Responding to change, instead of following a plan. We can’t predict the future, so don’t make plans too far ahead. “Don’t fear surprises, fear inflexibility.” Iterate and improve. By doing this he improved his scheduling influence, because he started to be known as someone that delivers sooner rather than later.
Conclusion
By optimizing your influence with people, your build, schedule and customers, you will maximize your effectiveness. When in doubt, look to the agile manifesto for guidance.
Erika Carlson - Better Fearless Feedback for Software Teams
Erika Carlson came on to talk about feedback, like Dan North did last year.
Types of feedback
First she talked about the different types of feedback: affirmative and constructive feedback, which is either saying positive things, or saying or showing things on how one can improve.
But then there’s also passive feedback where one devalues or condones behaviour through inaction. To me this is less explicit though, and might align more with Guess Culture people.
She took some time to tell us her opinion on the Feedback Sandwich, which took quite some courage after Dan North’s talk last year on this exact topic. :) So, mad respect to her.
She thinks the Feedback Sandwich takes away too much of the actual feedback you want to give the other person. And I can see that. Some people will just cling on to the positive parts of the feedback your giving them and thereby not actually hearing the constructive feedback you tried giving them. Maybe this is another Ask vs. Guess Culture thing.
I imagine the Feedback Sandwich working better for people that are more Guess Culture.
Getting over fear of feedback
Giving and receiving feedback requires openness, maturity, self-awareness, courage and vulnerability. Think about whether these requirements are there in your current team/company.
If these are there, and you’re still experiencing fear when you’re giving or receiving feedback, ask yourself the following questions.
- What am I afraid of?
- What’s the underlying fear?
- What steps could I take to overcome this fear?
- What could I gain by moving beyond this fear?
With the other questions leading up to the last powerful question. What can you gain?
She also gave an excellent tip on receiving constructive feedback, where she told us to act as if the feedback is coming from someone you adore or idolize. We’re generally easier on taking advice from someone we look up to. But why would feedback from someone else be less helpful?
Nickolas Means - The original Skunk Works
So, I started writing stuff down and then promptly stopped when it sank in I was watching Nickolas Means.
Just watch his presentation when it’s online.
Day 2 - Failing, Diversity, and what not
Birgitta Böckeler - We’re Agile, we don’t do doumentation
This was a damn good talk by Birgitta, shining some light on the often misunderstood documentation.
Before enlightening us with reasons of why documentation is good, she also told us that documentation for the sake of process is just bad. This is also the stereotypical idea people have when they think about documentation.
So how can documentation be valuable though?
1. Create common understanding
When you’re working in a team, or really just collaborating with other people, put up each individuals’ understandings on a whiteboard. You can do that however you like, for example all together, or kick-off in groups and diverge, then converge and redraw every groups findings in one place.
Make a wall of common understanding.
At the Ventouris team where I work, we have this wall that we show whenever prospects are shown around the office. I’ve found that these visits are a means of keeping this common understanding wall up to date.
2. Surface and understand complexity
Make infographics, which might have evolved from whiteboard sessions.
These should explain complex things that you don’t touch frequently, but need to explain in detail every time you do touch it.
Creating these infographics helps you check if it’s accidental complexity or actual.
Make Widget Kits. Kits that are helpful in rebuilding tangible diagrams. Picture an envelope with cue cards containing keywords, domain concepts, … That you open up and re-order or remake the puzzle every time you need it explained. Excellent for kinesthetic learners.
3. Create empathy
Empathy between technical decision makers and developers.
Developing software without documentation guidance can be anxiety inducing. Usually this translates to having to ask yourself the question Why do I need to adhere to this framework in our code?. Is it because of something that’s historically grown this way? What are some of the constraints that the developers or architects of 10 years ago were dealing with, when they were making decisions for the project you’re working on right now?
There should also be empathy between product people and developers. And once again, documentation can help. This is why we share our C4 diagrams in our offers to RFP’s.
4. Documenting reasons why
Describe the problem, not just the solution. Add context, so people can understand better what you were dealing with at the time.
Read this 2011 article by Michael Nygard on Documenting Architecture Decisions.
Nat Pryce created tooling for this concept as well, which is worth checking out.
To help incentivize my team to write adr-like documentation we introduced a Captain’s Log markdown file in the root of the project.
Think Stardate … - the Klingons are being angry again. or Yarrrr, today we looted rum….
I think it’s because of this fun factor that my team is more inclined to write down the decision they made.
5. Creative problem solving
Documentation doesn’t exist all of a sudden. It’s iterative, brainstorming work. So temporary drawings are fine.
Do not worry about these staying up to date. Accept that they will become obsolete at some point. But try to make explicit that these are temporary. It’s important to not mix these up with actual documentation.
Book recommendation: The back of the napkin by Dan Roam.
A note on Guidance
- Guide your team in writing documentation as little as possible. Don’t take away their voice.
- Make it visible. You know, like the Wall of Understanding
- Include documentation in rituals. e.g. Grooming the diagrams in a codereview
- Create ownership through collaboration.
We try to do this last one by organizing Architecture sessions, where we review parts of our design, or higher level architecture by collaborating on diagrams in order to increase our shared understanding of the project we’re working on.
Carly Robinson - Mentoring Junior Engineers at Slack HQ
Up until a year and a half ago, Carly Robinson was a musical theatre actress, until she decided she wanted to make a huge career switch and become a software engineer. In this talk she tells her story of how and why she was able to achieve this goal at Slack HQ.
Impostor syndrome
Coming from a family of artists, she had no idea she would one day discover a love for software engineering and a drive to learn the craft. Starting off with with several coding boot camps like codecademy and hackbright (a women-only software engineering school in San Francisco), she felt the impostor syndrome creeping in before she even got started. We, as a tech industry, need a culture of empathy and inclusion in order to make sure no talent is wasted because of this.
What Slack does right
- Mentorship is a relationship. Make sure it is a good fit from the beginning.
- Ask questions and listen. Discuss communication style, set clear goals and expectations, be specific.
- Encourage self reflection. Define the mentee’s strengths and weaknesses and come up with a plan to address these.
- Discuss communication style between mentor and mentee (e.g.: no sugarcoating)
- Talk about learning style and teaching style (e.g.: throw-into-the-fire or a more guided approach)
- Set clear expectations and accountability. What is success? What is the goal in 3/6/12 months? Be specific and give regular feedback. Track progress and celebrate success. Do this for the mentee and the mentor as well.
- Hold code reviews rooted in empathy and respect. Try to understand why someone has done something differently and explain how you would have approached the issue. Spark a conversation about the subject and listen.
- Foster intellectual humility. E.g.: as a mentor, refrain from your initial idiot-reaction..
- Show belief in the growth and potentional of junior engineers by assigning them stretch projects after a month or six, or whenever they are ready. These are projects with high visibility and a fair chance of failure.
- Positive culture of learning.
11 Sep 2016 •
21 min. read • Read the comments
DareFest 2016
This year I got the opportunity to find out what all the fuss on DareFest was about. I went the full three days, from Wednesday the 24th of August until Friday the 26th, smack dab in the middle of a rare heatwave.
DareFest is a conference (but more of an unconference actually), with speakers, workshops and side activities, on diverse technological topics. To give you an idea, there was a BlockChain workshop, a VR try-out, talks on new organizational culture (sociocracy and management 3.0), BioHacking, and a lot of stuff on design (both in fashion and in future technology).
The way I picked which thing to go to, was purely based on title because there wasn’t a lot of other information.
KnightMoves
First thing I went to was a workshop on How we use gamification in service design. Dave Van De Maele from KnightMoves, showcased their game called Kingdom. We got to see the cards and play around with them on a hypothetical problem of fixing Antwerps mobility if no cars would be allowed inside the city.
Read more about it here.
DIY Bio
Then I went to Winnie Poncelet’s talk on DIY Bio, a movement that tries to opensource and democratize bio-engineering. Works well with home-made stuff like 3D printed containers etc.
They have a Code of Ethics.
Out of this movement some interesting initiatives have sprung up, like Epidemium, who have a program called Challenge4Cancer; opensourcing cancer research.
My biggest take-away was that if we leave bio-engineering to scientists only, we’ll dumb down society. Which will lead to delegating even more to scientists, causing a downwards spiral. And DIYBio is trying break the cycle.
Also: mushrooms as a replacement for all the things! (like leather, road-lighting, …).
Get your hands dirty at one of the labs in Ghent - Reagent (nl) or Namur.
Project Leven
Then I saw a talk on biohacking, or Human+, I’m not sure what the difference is.
Peter Joosten (@wpjoosten) talked about his life as a human labrat, all the different things he’s been trying out on himself.
Like various diets he’s tried, how he tried not ejaculating for a month, daily cold showers, … You know, normal, weird stuff.
He also demonstrated how to do a burpee for some reason.
He explained there are so many ways to measure everything about your body nowadays. For example you can send your poop to ubiome. Or find out what your DNA can do for you with 23andme.
After you gathered this data, there are some ways to improve as well. He was very excited that there are going to be human trials with CRISPr. If you haven’t heard of CRISPr yet, I urge you to listen to this RadioLab podcast right now.
He also mentioned Epigenetics, something I still need to look up, but it’s about modifying your environment to change your DNA or something.
Then he concluded by giving his 3 tips to do every day:
- Sleep enough (because you can’t gain back lost hours of sleep, and sleep deprivation is detrimental to your health)
- Get at least 30 minutes of sunshine/outside to recharge your body
- Hang (to stretch your back, and reduce lower back pain from sitting all day or even standing at your standing desk)
He also mentioned alternate breathing, a technique where you breathe in through one nosehole and out the other. It helps calm you down in stressful situations.
Visit his website to see if he’s still alive or how he has improved his life.
Slides
Guerilla Leadership
In the afternoon I went to a Guerilla Leadership workshop, hosted by Herwig Deconinck and Lisa Boelaert. It wasn’t really a workshop in that we didn’t get to do all that much actually, aside from one super awkward exercise where we had to lose the thing that was holding us back by marching straight for our goal. With someone literally holding you back by the shoulders.
The other thing that annoyed me was that the speakers were trying to sell this method.
In the end they gave us 10 commandments, which do make sense and they had nice examples to go with them.
- Unite around a shared purpose
- Focus on Chances and opportunities
- Make it Small & Make it Happen
- Confront reality & Create transparency
- Make people feel strong
- Make success possible & feed resilience
- Be authentic & trustworthy
- Talk straight
- Build the bridge as you walk on it
- Right your wrongs
We shared what action we were going to take, or had done already, related to one of the commandments.
Here’s what everybody came up with.
After the workshop I asked about how to feed resilience, more specifically how to combat demotivation. And I distilled the excellent feedback in to the following points:
- Define the common goal with your group.
- Prepare for negative criticism and setbacks. So plan them in, make this concrete with your group (of guerillas)
- Pull each other up when this happens. Every one in the group has a responsibility to be aware to this demotivation hitting the group. And you help each other get over it.
- Create awareness loops to help “plan” demotivation hits.
Too bad they put up such a show to share such valuable information.
Pulling in the same direction with autonomous teams
Easily the most interesting talk of wednesday.
Manuel Küblböck works at Stylight, a German company that grew from 4 to 200+ employees, but managed to maintain their 4-man values and way of working (they scaled autonomy).
According to Manuel, there are three practices that they do that make that happen.
They use OKR’s (proper ones), Sprint Planning, and UX Research that feed into each other and most importantly, into the clearly defined company strategy.
The Shared Understanding this creates, along with defining proper OKR’s, create certainty, and certainty leads to happiness.
Another tip he gave us was to NOT use OKR’s as a performance review tool because you’ll set too low of a bar for yourself. Because there’s a reward tied to it. This is true for any target setting.
And yet another tip was to not become too short-sighted. Doing those OKR’s weekly makes it easy to make only quarterly goals, and lose view of the bigger context.
He’s written a magnificent blogpost about it already, so go ahead and read that in stead of my mumblings.
Slides
Blockchain
I did go to some company sponsored talks about Blockchain which were mostly commercialisation attempts. But I also went to a workshop that made the bad aftertaste go away.
Bart Waeterschoot (@bytesizebart), the guy that hosted the workshop, recognized me from one of our Software Factory visits. He used to work for SDWorx, and now works for a KMO called bITe. Who apparently are doing stuff with blockchain tech.
His talk/workshop was entertaining, he himself is very knowledgeable, and is able to clearly explain problems and how blockchains work etc.
I learned a lot, and was able to ask all the questions I still had. AND he had a live demo. Very cool workshop!
Here’s the github repo that used Ethereum (or more specifically Truffle) to build a so called Dapp (decentralized app).
Slides
Happiness for Teams
In this workshop, excellently hosted by Frederik Vannieuwenhuyse (@vfrederik) and Dieter Dehaes (@dehaesd), we first drew a personal context map of our neighbor by asking questions.
Afterwards someone else at our table had to explain who someone was based on the context map. Pretty cool!
I also learned that not everyone has legible hand writing. :)
Then we did the Moving Motivators game from Jurgen Appelo’s Management 3.0. Which gives a lot of insight into yourself: what motivates me, and how do motivators change in some events.
My motivators are in the middle.
After event x happened. The Goal card is the baseline.
We finished up by giving feedback about the workshop to other people in the workshop using the Feedback Wrap. Which reminded me of course about Dan North’s How to make a Sandwich.
Slides
How to develop a creative culture within your organization
Presented by Pieter Daelman from Bedenk.
Alongside the university of Ghent, they have been doing research for 3 years, on how creativity works in companies. Which culminated in to some kind of framework that should help with instilling creativity in all layers of your company.
They call it CReative Organisation MAtrix or CROMA.
It’s basically a checklist in form of a matrix, check his slides to see what the matrix looks like.
This checklist, or rather radiator, gives a company an idea on how they’re doing in every quadrant (there’s 9 in total).
3 levels: Individual, Team and Company.
3 phases: Orientation, Idea creation and Promotion.
He gave some real life examples for every quadrant, so we could get an idea on how other companies or people improved that quadrant for them.
For example, aside from Colruyts Red Phone, where any customer can call them and tell them they saw a cheaper price at a competitors. They also have a Green phone, only for employees, that use it to share their improvement ideas with someone directly connected on the other side of the line.
It’ll get registered, and afterwards they get personal feedback on why it got approved, and if they’d want to join the implementation team, or why it didn’t get approved with a proper explanation etc.
That was an example of the Company + Promotion quadrant, where Decision making & constructive feedback live.
CROMA is based on scientific research, and basically works like any other organisation framework, like CMMI e.g.
Bedenk helps you create a matrix radiator, and facilitates actions etc., and they’re also releasing a book about it, coming this december. And we got the premiere about this new framework at DareFest.
My initial thoughts are that it seems like it’s overkill and might be a bit avant-garde at the moment, but that it might work very well to sell to higher management, while the working class reaps the benefits because most examples are about employee empowerment.
Education in the Exponential Age
Deepak Mehta (@deeeep) made me chuckle with his rant on Plastische Opvoeding (Arts & Crafts) in belgian schools: teaching kids important, artistic skills in 1 hour a week, which is perceived as relax-time without guidance, by the teacher that is the least motivated in the entire school.
With Exponential Age he is referring to the theory behind The Singularity (computer power is growing exponentially and will eventually outperform human brainpower).
Some issues he predicts:
- Should you learn x when there is google.
- Deepak thinks general practitioners job will be unnecessary in 5 years.
- No single job for life.
- Expect at least 2-3 job obsoleteness events
- AI and Robots will do everything better
- New tech will come and go faster and faster.
As a solution (in the field of education), he thinks that we should teach kids how to Learn - Unlearn - Relearn (Toffler). Read this.
21st century skills are the 4 C’s, Context, Container, Component and Class diagrams. No wait… Those are other 4 C’s. ;)
Deepak means Communications, Collaboration, Critical Thinking and Creativity.
We should also teach our kids Design Thinking.
And have them do peer-to-peer learning. Because learning from another kid increases relatedness, and teaching provides new and better insights.
The role of an actual teacher would then move more towards a coach and mentor instead of a know-it-all type of person.
He also said that schools are not going to be teaching this to your kids, so you should find alternatives. Such as TEDxYouth Flanders, or CoderDojo.
BioComputer
There was an interesting talk by Joao Gil, who made an art installation called BioComputer, that serves as a sort of assessment of future speculative technology.
It fit into the Speculative Everything… thing…
I do think it’s an easily underestimated step towards early feedback of novel ideas.
Things that Startups and VC investment have to deal with every day.
I also think it has the additional purpose of informing and slowly introducing new, groundbreaking, moral-changing technology to the general public.
Creating your future history: D-Day lessons for every day
Erin Meyer has been living in Belgium for half of her life now.
She set out to fulfill her dream of writing a book (instead of getting a Phd).
Through 3 questions out of her book D-Day lessons for every day, and accompanying exercises, she taught us about ourselves.
1. What is your current version of “impossible”.
Current, because after a while you’ll have reached what seemed impossible before. Let’s see how we get from Impossible to I’m possible.
Exercise: list what seems impossible for you at the moment.
2. What do you stand for?
Exercise: write down words that you think summarize your values, your idols, music, movies or series you love, concepts, experiences…
Then circle three of those that you will revisit in the next 3 weeks.
3. What makes you feel alive?
Honor the lives of the deceased by living your life
You contribute to the lives of others by doing what brings you to life
Exercise: Imagine that it’s now today + 3 years and you encounter the same people.
What will you tell them about what happened to you in the past 3 years. What did you achieve? What did you experience?
To me this workshop served as a mirror.
I reflected on the fact that I’m (still) not really doing anything with my life. Even in the last exercise I wrote I still won’t know what to do with my life, but I’ll have progressed in a natural way.
So it was an interesting self-reflection exercise.
Driver mapping - Sociocracy 3.0
Jef Cumps (@jcumps) from iLean, excellently facilitated a fun and insightful workshop on Driver Mapping.
Driver Mapping, I think, is a practice out of the Sociocracy 3.0 framework. It’s like Impact Mapping, but for organisational structure.
First we set out, with everybody in the room, to host a conference, and tried to figure out in groups what actors, or personas, are essential to a conference. And started to write down what their needs (sub-drivers) are.
Then we changed perspective by taking away the actors and trying to categorize all of the drivers.
And we created so called circles, groups with people that are motivated enough to deal with a driver/category.
Overlapping tasks can be dealt with using the delegation circle pattern from Sociocracy 3.0.
Slides
Future of good and evil
I also went to The Future of Good and Evil by Dr. Stephen Cave.
He talked about what we can do when (not if) our values and morals change in the future.
To be able to answer that question, he gave us a thinking exercise: What can we be condemned for by our grandchildren?
He also questioned whether or not we can use data and machine learning (the tools of today), to answer the question of What will our future standards look like?.
As examples of current data and machine learning:
- US Judges use AI to help decide on release on parole of offenders.
- Surgeons trying to decide whether or not to cut off someones leg also gets fed info from AI.
There’s a pitfall in believing in AI provided solutions though. He retold Plato’s story of Socrates and Euthyphro where a son wanted to prosecute his father (who killed someone), because the Gods’ word is good.
Just like in that story, where the Gods provide morals, we can have our morals provided by AI, but it doesn’t mean that we should blindly pursue the AI’s suggestions.
Other practical stuff we can already start doing so as to not be condemned by our grandchildren:
- Rights for future people. Decisions effect future people, so why don’t they have rights?
- Animal rights. Comparable to cannibalism: eating equivalent things (things that are worth the same).
- Opening up all borders. Comparable to sexism and racism. Don’t lock people up. Help them make better choices instead.
Every day there is more and more proof of intelligence in animals, yet we still keep eating, and basically torturing them in industrialized meat providing companies.
As a conclusion he turned his intro thinking exercise into a positive one: What might we be admired for?
As a user, I hate User Stories
Matteo Cavucci (@MatteoMced, Thoughtworks Berlin) had an interesting presentation too.
It was yet another reminder that user stories should be conversation starters, not requirements documents.
Do your Stories contain Acceptance Criteria, are created off of a Template (As a …, when I …, I want to …, so that …), or use User in their title?
Then it’s likely your stories are indeed requirement documents, and they are effectively hiding one of the most important values in Agile: Individuals and Interactions over processes and tools.
You could also easily make the case that Customer collaboration over contract negotiation is hidden as well.
He gave us some ideas on how to fix/improve:
Stop writing, start discussing.
Create shared understanding, instead of lists of requirements.
Don’t be a Template Zombie, tell a story.
If you’re unsure, you can use a placeholder in the text.
Avoid features, write down the user side of things.
Basically, don’t write down the solution space, write down the problem space. I think this comes down to writing down the Why? instead of the What?.
Use actual people instead of the mythical user. Because they can provide context, limit scope creep, keep focus and serve motivations and impediments.
Then he also shared a more novel idea:
Stories are not only small because these are easier to predict, but also because they’re actually small experiments (with hypotheses).
Your hypothesis must be small, right or wrong, and it should serve the purpose of learning, instead of amount of delivery.
To me this is a refreshing perspective at user stories.
A good way to move away from using Acceptance Criteria in your stories, is to come together (e.g. during kick-off or dev review) and to discuss what the BDD statements should be, together.
Slides
Virtual Reality - HTC Vive
I closed off the day, and DareFest, by trying out Steams HTC Vive.
Tanguy de Keyzer (@belgiumvr), your VR go-to guy in Belgium, loaded The Brookhaven Expirement, a zombie-shooter game. And I got to shoot at zombies. And whack them with my combat knife. And die a horrible death. Woot!
When you first put on the goggles (these did something!), you can easily notice the outline. Like if you use your hands as goggles, you can still see the outline of your hands, it’s just like that.
But after a while you stop noticing, because you’re continuously immersed in the 3D environment.
I think I spent about 8 minutes in the dark, gloomy, zombie infested (virtual) world. And I’m happy to say I didn’t shit my pants, or scream… too loud. :)
When the facilitator took off the goggles, my brain was struggling a little bit with reality.
It was weird knowing that a few seconds ago, there used to be a burning appartment behind me, and a busted car to the left, some oil cans and a camp fire on the ground etc. And now they’re suddenly gone.
It’s like, your brain accepts all these new orientation details, and now it has to override those orientation details with the current ones.
However, at the price of 900€, the fact that I’d still need to upgrade my desktop, and not the fact that there’s not that much content out yet, I’m going to wait for the next versions of VR hardware.
But it was a very fun experience! So thanks Tanguy!
Conclusion
On Thursday, in between presentations, I sat down across someone who happened to be Matteo Cavucci from ThoughtWorks (Berlin), before I knew who he was. And I got a chance to talk with him about the epic struggle with Legacy Software and applying DDD.
It’s stuff like this that make Darefest worthwhile for me. The interaction with (likeminded) new people has been great.
Most of the presentations themselves were too heavily sales oriented though.
It was all too clear that most speakers were there not to share their knowledge, but rather to sell their services or product. And that’s pretty sad.
As a conclusion, the first day I was disappointed, the second day less disappointed, and the third day I felt I learned a lot.
I had the feeling that a lot of the talks there valued promotion over knowledge sharing, and I really disliked that. I think it really deteriorates your learning experience.
DareFest organisation itself had a lot of issues too.
Because of the smoldering heat and lack of facilities (no airconditioning, not even ventilation), it was too hot to bear, most of the time.
Add to that a bunch of catering issues, complete lack of route signage, no sound isolation, no updated schedule information. e.g. I waited 10 minutes for a presentation that was cancelled; the drone racing was also cancelled (I think), and lack of information of the talks (I only had the title to know whether it would interest me or not).
I think it could’ve been done so much better. I also don’t understand how all these issues could happen, since this isn’t the first time that they organized this conference.
Everyone I talked to said that last years event was way better. They attributed the issues related to presentation content, to the topic diversity being too broad. I don’t know about that, I liked learning about shrooms, and then learning what other organizational structures are out there.
After re-reading all my notes and in writing this blog post, I did learn some valuable things in those 3 days. In the end I would’ve ideally just visited on the last day.
I think I made the mistake (?) of comparing DareFest to The Lead Developer conference. And they’re simply on a completely different level.
So… #WorthIt? I’m still unsure, but I am glad I once again had the opportunity to go to this conference.
15 Jul 2016 •
1 min. read • Read the comments
I blogged about Day 1 and Day 2 of The Lead Developer conference in London.
The videos have been released today, so here’s an easier way of watching all the presentations I recommended in those previous posts.
05 Jul 2016 •
24 min. read • Read the comments
The Lead Developer - continued
The Lead Developer conference, or at least the one I went to, was held on the 23rd and 24th of June 2016, in the Queen Elizabeth II Centre in London, during the Brexit vote.
This is a post about all of the talks of Day 2, and I’m sorry that this one is considerably longer than Day 1. I don’t know what happened. :)
Day 2
Michael Lopp - Leadership by the numbers
So Michael Lopp, @rands, is a guy with a HUGE amount of knowledge. I’m very glad he was so generous to share with us.
He guided his talk somewhat weird and I didn’t fully understand what the stuff he was saying had to do with Leadership by the numbers, but the content was great.
He started off by testing the skills of the people that were captioning the entire conference by saying out loud Ok I gotta test this real quick… Supercalifragilisticexpialidocious. After the word appeared after 1-2 seconds, the crowd went wild. :)
These guys really did do an amazing job. I found myself checking to see what was said when some of the presenters went a bit fast for me to keep up with my notes. So thanks again guys!
Team Communications
I would be jealous to be in his team, because @Rands takes 30 minutes every week, no matter what, to have a 1 on 1 meeting with every member of his team. Just to check in, and have a feeling of what’s actually going on that week with his team. In contrast to the Performance Evaluation timeslots everyone dreads because it feels so forced.
He also has staff starting points, little 1 hour meetings to set the tone for the week. If you can’t easily fill an hour, something is wrong.
He then started talking about the long term costs of not saying the hard thing at the right time.
The obvious cost is that when you don’t say something, work isn’t getting done, team morale is taking a hit (and more importantly the toxicity spreads), and your sanity takes a hit as well.
The less obvious cost is that your credibility as a leader is taking a hit, and that there’s impact on folks you do not know. Their sanity is taking a hit. Michael has learned that everyone is replaceable.. I learned that when you work for Michael, Rands, or whatever his name is, and he shows you a slide of corn, you’re about to get fired.
Diversity, delegation and leading by example
Again, Diversity made an appearance on stage. This time in the form of the Asch Conformity Experiments, where the experiment shows that you can easily get influenced by other people. Again, be aware of the bias that you probably hire people like you and that wanting a diverse team is a no brainer. And also that as leaders, we should be a diversity allies.
This phrase fired a bunch of neurons in my brain You set tone and cadence… all the time. Just like kids who watch you do stuff and repeat your actions you do subconsciously. He gave an example of his own daughter using redirection to a new game she saw at games convention E3, when she saw him enter her room all ready to lecture her. He realized that she learned that from him.
As an easy change, you could simply start and finish meetings on time, and show you respect peoples time. This can set the tone for the whole company to do the same.
Watch his complete talk to find out what you might be horrifically bad at, and how you might direct yourself to a path of learning how to become better at it.
Also delegate when you’re in a stressy situations (e.g. the site is down). You know how to do it so let someone else do it and learn. Another great quote:
Delegation is a great way to grow a team.
Be unfailingly kind
He finished with a bit that hit home for me.
He talked about how he plays the videogame Destiny, an online shooter where you need to finish missions with a (random P_ick _U_p) _G_roup. Since there’s a huge variation of skilled people online, you’re lucky if everyone knows what to do and knows their role. And a lot of frustration and toxicity can originate from these situations.
But he plays this game with a friend who is Unfailingly Kind. It doesn’t matter how toxic other players are, or how little they know about the game. This friend has a lot of patience.
This was such a recognizable situation to me, and I strongly believe in being this Unfailingly Kind guy. But it’s really difficult to always be like this. I’ve got MAD respect for Michaels friend. And I’ll do my best to help people out in the friendliest way possible again.
Great keynote to start off Day 2 if you ask me. The tone was set again.
Slides / Notes
Ryan Alexander - Hacking verbal communication systems
Ryan (@RNAlexander) Alexander took us on a deep dive into conversation.
I learned that a group conversation or brainstorming session is like a race. Where everyone that’s trying to talk next is at a starting line, holding their positions, waiting for the starter flare to go off (the one talking to stop talking).
But that there might be people in the conversation that follow the rules, waiting in their position. And that there are others that don’t, leaving the rest behind, before the starter flare was even fired.
This is sort of a semi-conscious, complex algorithm going on in every participants head. And exactly because it’s an algorithm, we can hack it.
I never thought about discussions or conversations like this, but it makes SO much sense.
Then I learned about the Occupy Together hand signals. Where you can announce your intent, without interrupting, to the participants in the conversation. Click the image for a clarifying explanation, or watch Ryans talk.
Seems like this would work WAY better than a simple “speech token”.
To facilitate everyone getting their chance to speak/communicate, the hand signals are more friendly to neurodiverse individuals. Moreover you can decide who’s next to talk on the basis of whether or not they have spoken, this is called Progressive Stack.
Great little talk with a boat load of information. Definitely worth your time!
Slides / Notes
Yan Cui - Tour of language landscape
I’m sorry I didn’t write down all that much in my notes about the stuff that Yan Cui (@theburningmonk) taught us. But it’s because as I was sitting in the audience, it soon became apparent that this talk was gonna be a ridiculously interesting one and it would deserve my full attention.
Here’s the stuff I’m able to recollect though.
After a short introduction on the impact of language on the way we think, he showcased some really excellent examples of how features in certain programming languages can make your code more expressive. He took a bunch of features of F#, Clojure, Rust and Idris and explained how they could make your code less error prone and more expressive at the same time.
If you’re in to DDD’s Ubiquitous Language, there’s no doubt that you should watch this talk. Even if you have 0 experience with the languages Yan mentions.
He closes off his talk by encouraging everyone that didn’t know the programming languages he mentioned. He did this through debunking Malcolm Gladwell’s “10,000 hours to master something” rule, with Josh Kaufmans correction that says you can already be “good” at something after the first 20 hours.
Really, interesting talk, hitting all the stuff I love. Would highly recommend.
If you’re not into watching a presentation, read. his. blog! This guy is a library of himself!
Yan Cui, if you’re reading this: Thank you!
Slides / Notes
Crystal Huff - Dealing with Impostor syndrome
Crystal (@crystalhmhuff) replaced another presenter at the last minute, and her presentation was very interesting nonetheless.
Impostor Syndrome is not a disease, unlike the term suggests, but rather a state in which you think you feel underqualified but when in reality you’re really not.
It can have real consequences such as being less effective as collaborators (because nobody wants to be seen making a mistake), getting fewer promotions (because an impostor feels unworthy), etc. In the end the negative impact comes down to being marginalized and being silenced.
It gets fed by sentiments like Fake it until you make it, when if successful, you actually will have been an imposter. Other things that feed into it are phrases like Women are bad at math. Even worse is when you give in to those stereotypes where you say for example Math is hard, let’s go shopping.
Other important, notable things that might trigger it are comparing your worst snapshot to someone elses best snapshot, and the Being Liked vs. Being Competetent dichotomy.
There are ways of combatting it though. And as usual it involves gaining more awareness. For example by asking your colleagues or friends about your strengths. Or by realizing your heroes struggle with this as well, and picturing the iceberg (illusion) of success.
Preventing Impostor Syndrome involves watching out for certain things that you say e.g. I’m not an expert, but…. If you repeat that phrase often enough, you’ll eventually believe it.
Compare yourself with yourself. Compare your past self (on your own personal scale of where you want to be in life), to your current and future self. Instead of comparing snapshots of your worst self to snapshots of somebody elses best self. This made a lot of sense, but it’s something you just need to hear more.
Crystal also inspired us to help each other prevent it by critiquing with kindness. Compliments are better when they’re personal. A good compliment is positive, not physical, specific, and honest. See Dan North’s “How to make a sandwich” presentation about feedback.
When you notice someone else struggling with impostor syndrome, help them remind themselves of their happy thoughts and experiences.
I did reach out via the company Slack channel for someone to tell me 3 awesome things about me and here’s what I got.
You speak your mind, even to people you don’t know that well.
You’re not scared (you don’t show it at least) to try out new things.
When you’re enthusiastic about something, you shine your ray of enthusiasm onto other people. (you pull them along)
So thanks for helping me combat Impostor Syndrome!
Slides / Notes
Gil Zellner - How to not burn out your monitoring team
We switched to a more ‘techie’ track with Gil Zellner (@heathenaspargus) giving tips on how not to burn out your monitoring (operations) team.
But before he did, he reminded us that the cost of hiring a new employee is 1.5 to 3 times their salary. So you might wanna retain those guys at ops by helping them as much as you can.
Caution
Do NOT watch this presentation or the slides if you haven’t seen Game of Thrones episode 9 of season 6 yet, there’s a massive spoiler in his slides. :)
Easy changes you can do to help (takes days to implement):
- Mandatory half day off after night production issue.
- Allocate weekly time to resolve or automate issues that kept us up at night.
- Wider rotation (more people on call).
- Follow the sun (if you have multiple timezones).
Medium changes you can do (things that might take months to implement)
- ALERT ALL THE THINGS leads to alert fatigue.
- So only alert on symptoms, not suspected “causes”
- Only alert on actionable stuff
- Only alert on business breaking stuff.
- Direct alerts to relevant parties.
- LOG ALL THE THINGS can tremendously help the team that gets woken out of their beds at night, but can lead to overwhelming stuff, especially if you also log success.
- Connect detection scripts to correction scripts.
- See Facebook Auto Remediation.
For the hard things (that might take years) he mentioned some AWS stuff I didn’t pick up on, but maybe you will so check out his slides (if you have seen Game of Thrones!).
Slides / Notes
Monika Piotrowicz - Lessons from growing a team
Monika Piotrowicz (@monsika) talked about her experience of growing into a leader of dev leads.
A lead will have some combination of
tech knowledge and skills,
understanding of the business and product,
and trust from their team.
All so they can help develop their team.
And you can’t build a version of someone in only one day that has all those qualities. So what you want to do is encourage those traits in your entire team and see who picks ‘em up.
You can do this first of all by simply asking who’s up for becoming a lead (in the future), then talk about what it involves, and create opportunities for those candidates.
To help your colleagues and yourself grow, fill in the blanks
Most impactful thing I can do today is …
Right now I’m not great at …
In a few months I want to try …
Remember to Make Space for your candidates to grow. I trust you to do the right thing - here’s a list of things you should do is not how you make space. :)
This was all pretty great advice, but this one I felt like sharing with our current coach.
Every time you think you’re protecting your team by going to a meeting yourself, delegate to the team instead.
Slides / Notes
Thomas Lobinger - Working backwards from the customer
Thomas Lobinger (@tlobinger) works at Amazon and talked about their (literally) backwards approach of aligning a team on values and creating a shared vision.
What I mean by backwards is that they’ll start with the end goal and work backwards from there.
So what they do is first they create a mock Press Release that shows, among regular stuff like title and summary, a quote of the customer and the team.
This helps them in not only creating a shared vision and understanding, but also a shared motivation. It’s what we usually try to do with a Mission statement of a project team. But I think it goes much further than that, because you’re imagining what impact your end result will have on the users or your clients.
After they’ve written this, they’ll create a FAQ document from the perspective of customers and stakeholders.
During the creation of the Press Release the team will have come up with a bunch of questions that you might be able to include in the FAQ as well. I think I can compare this to trying to figure out non-functional requirements during an RFP.
Then they’ll create Mockups of what their product/solution will look like.
It should tell the story of how a user would use the product they’re going to build.
I’ve noticed that, much like Simon Brown’s (@simonbrown) C4 Diagrams, with this approach they’re effectively zooming in to their product, but from a less technical perspective. Every level of detail seems to put more focus on the users perspective. You know… the one we’re actually making this thing for.
Of course Thomas doesn’t just write these documents once and then be done with them. They iterate over them, so when they come across questions or more insight that should go in their Press Release, they put that stuff in there and update the rest accordingly.
So really what they’ve done is come up with a sort of Living Documentation that is able to continuously provide a Shared Understanding and Shared Values on a team.
If you’re looking for more information about this, it seems Werner Vogels (@werner) already wrote a blog post about this exact method back in 2006. Or simply watch his talk.
I do believe that it’ll work better for products you’re making yourself and innovations, rather than projects you do for clients, because there are no feedback loops from clients. But it’s easy to imagine asking the questions or verifying the assumptions that will come up when creating these documents.
Maybe it’s a great additional method to working on RFP’s or starting teams around a new project.
Slides / Notes
Penny Wyatt - Overhead, not downtrodden
Atlassian’s Penny Wyatt (@pennozewyatt) gave us a bunch of tips when working in Quality Assurance.
- Embrace you’re in an overhead team.
- Broaden your view, work towards the company and customers goals.
- Cost is not value.
- Leaders are overhead too, so focus on where you can add value.
She told an anecdote where she spent 3 extra months testing stuff because the devs didn’t catch a lot of edge cases. At first she felt great because since it took her that long to thoroughly test the application and improve the quality of it. She felt like her role got validated because of this. Of course those 3 months were not perceived as extra value, but as extra cost.
There were better solutions to build in quality in to that team, like working more closely together with them. And focusing on installing quicker feedback loops.
They moved closer towards this goal by putting more accountability on the Quality Assurance team, so they wouldn’t just be accountable for quality, but also for development speed.
This caused them to work in close cooperation with the development team. And eventually get renamed from the Quality Assurance team to Quality Assistance team. Moreover because they were helping the dev teams become more accountable and more interested in quality.
Even though this caused her to do less Q&A, it produced more value in the end. She made the comparison to how management can also be considered overhead.
Instead of trying to get better quality by adding more developers, they can be able to get more value AND better quality from a smaller team, by letting the team improve their performance.
Slides / Notes
Melinda Seckington - How to succeed at hiring without really trying
Melinda Seckington (@mseckington) made a compelling analogy of choosing between a closed box that had the label strawberries on it, or a transparent box where you could actually see the strawberries along with a label containing nutritional value etc. to choosing a company you want to work for.
Then she explained how at FutureLearn they’re making the transparent box, by focusing internally on helping colleagues write and speak, authentically.
The idea is that by doing this, you turn developers in evangelists for their teams (and by extension for your company).
The amount of support devs at FutureLearn get for this goal is staggering, and FutureLearn’s culture absolutely embodies this knowledge sharing and evangelism mindset.
To me personally this was eye opening. Because I’ll notice one of my colleagues has accomplished a great feat, and I’ll ask them to blog about it, but they never actually do. Usually they’ll come up with stuff like I’m not an expert, or I can’t write, I’m too nervous, I’m not a good speaker, Nothing I do is worth speaking about, …
From now on, I’m going to try and change my approach, by offering to help them write or prepare for a presentation. Try to help them take away their fears and blockers.
In any case, Melinda’s talk is a presentation you should show to your HR colleagues and/or your guild leads.
Slides / Notes
Laura Czajkowski - How to deal with the cultural divide and internal advocacy within distributed teams
Laura Czajkowski (@czajkowski) works from home, for Couchbase. She was so kind to share her experience doing this and some pro-tips to help deal with the typical problems.
If you ever did some remoting yourself, you’ll recognize a lot of her descriptions. Most notably missing social talk and work discussions because of the absence of a watercooler (or coffee room), and lag (delay) issues with VOIP tools.
Watch her presentation for some pro tips on dealing with these situations.
If I ever work remotely again I’ll be sure to try out her tip on bringing your morning beverage to the friday mornings stand-up, and talk a bit about your weekend plans. This helps in getting to know your remote colleagues a bit more.
Slides / Notes
Camille Fournier - Rebooting Culture
To close off this years The Lead Developer Conference, Camille Fournier (@skamille) talked about her own experience of bringing a Culture of Fear to the team she managed the first time she became a leader, noticing this and how she changed it around.
This was my first time experiencing Camille, and I don’t know if it’s because of her background as a developer, but all the things she pointed out, is very near to my heart. And she was talking about these things with such a passion… Validation feels great! So thanks Camille! :)
Speed
First she talked about Speed.
She reminded us that engineers like to ship, and be a part of something that matters.
Making sure your team can work as fast as they can is one of the most important things you can do. So remove resource constraints (e.g. code freezes), and be impatient with things that seem to take too long.
Structure
Then she explained how good Structure helps you get context quickly, and that Structure comes from failure. Failure in structure usually leads to getting rid of that structure, which isn’t always an appropriate response.
This reminded me of a story someone at our LeanCoffee shared about a team that had visible bottlenecks in their scrumboard, and decided to stop doing scrum.
Ambiguity is a bias factor, or how vagueness in job or role descriptions can be interpreted in a way that suits you. What you want instead is transparancy.
She showed this really quick example of an excel sheet with DnD traits being used as measuring points. Take a look at this once her slides are up.
Here’s another nod to HR and people tasked with doing performance reviews. If you keep changing the interpretations of vague roles
Structure is not how to detail instructions on how to do it. If you find yourself doing this, ask yourself if you can’t automate that instead.
Vulnerability is the opposite of a culture of fear.
If I remember correctly I think she meant that when there’s room for feelings of vulnerability, i.e. there’s a safe environment to experiment and fail, both emotionally and technically, it empowers people.
Like how Kerth’s Prime Directive makes for great retrospectives.
Related to Vulnerability, you need to have Healthy Conflict.
Not because you’re Tina Turner in Mad Max Beyond Thunderdome, but because it draws out important data.
What I’ve noticed is when conflict is avoided all the time (as is common in Belgium), nothing can be learned, and it can lead to passive aggressive behavior.
Here’s another tip for leaders. Telling people You can’t criticize if you can’t come up with solutions yourself is a bad thing.
Instead, ask them to really articulate their criticism. It’s more effective to replace feelings of conflict with curiousity.
She also shared this fun definition of meetings:
A meeting consists of a group of people who have little to say - until after the meeting.
Empathy
Because Camille felt like we hadn’t been given enough gems, she closed off her talk by telling us that Empathy is a learnable skill.
This is such an important statement actually. Much like how Responsibility is generally considered a trait, so is Empathy. But they’re both not.
How is it learnable though? Camille told us it’s as simple as asking about how somebody is doing, and really listen. Even if you don’t really care all that much, just do it. In time, you will care about Peter hurting his knee.
In hindsight, her talk was the culmination of what I expected from this conference, and at the same time it was a summary of what all the presenters before her had been saying.
What I’m trying to say is, watch her presentation now!
Slides / Notes
In conclusion
Writing these blog posts have been great to recollect the abundance of shared knowledge and I’m glad I did, even though it took me quite some time. Hope you readers were also able get some use out of these posts.
I’m so glad Jan Sabbe recommended this conference to me last year. It really was an inspiring two days, full of new knowledge to share.
Thanks again to everyone involved! Hope to see you next year!
Vicious and Virtuous cycles of Motivation
