Here are 3 thoughts that emerged from my reflection on the conversation:

• Empathy is essential, as we may not grasp each others’ experiences
• Recruitment needs companies to reveal themselves to overcome reluctance to change jobs
• Meaningful change requires decision-makers with diverse perspectives, by becoming one

About empathy: “You don’t know what you don’t know”

Empathy is fundamental to understand the experiences of others and overcome misunderstandings.

Let me illustrate this with a simple yet revealing story.

I have spent many years doing pair programming, where two people work together on the code implementation.

During a session with a female colleague, we encountered one of those tiresome captchas. The task was to “pick the dresses” from a list of images. My colleague selected two images, and as she was about to submit, I called out a bit too late “wait, you missed one!”

Sure enough, the captcha failed and we had to respond to a new question…

She rolled here eyes 🙄 and sighed with disappointment “oh, this was made by men, for sure. That one was not a dress, it was a blouse.” 🫤

Me calling out the “mistake” was in good faith, with intention to help a joint task. But it could be easy to perceive me as arrogant, trying to correct a minority who knows much more than me about the subject.

But we cannot know what we don’t know. We cannot see what we’re blind to. This scenario highlights the potential for misunderstandings and unintentional insensitivity. Had we not been working together for a long time and built a trusting relationship, I’m sure that would have been the case.

Only sharing our different mutual realities, with patience and understanding, can we recognise our limitations.

About recruitment: “Better the devil you know than the devil you don’t”

Recruiting candidates from underrepresented groups can be an uphill battle.

It’s very common for companies to offer “referral bonus” for bringing colleagues into the recruitment pipeline.

In my experience, it takes me 10 times more effort to convince a female former colleague to apply for a new job opportunity than a male one. And with much less success in getting them to do so.

This highlights the reluctance to change that many individuals, particularly minorities, often feel.

Especially for employees from underrepresented groups, the switch to a new company can be daunting. In their current company, they’ve already established themselves at great cost. They feel comfortable navigating the existing challenges, and understand where the “dragons” lie.

The idea of having to start over that struggle and the possibility of having even more pronounced challenges, can be intimidating. This fear makes the idea of staying in a familiar, albeit imperfect, environment more appealing than venturing into the unknown.

To overcome that, companies must reveal what it’s like to work there, for real. This involves getting representative people to share what it is like for them to work in the company. To share both the positives and the areas that need improvement. To be straightforward about the reality of the work environment they foster.

This way, companies can make a stronger case for why it’s worth taking a leap into the unknown. By making it less “unknown”. By making the “devil you don’t know” seem less intimidating.

About transformation: “A seat at the table”

Real change in diversity and inclusion requires more than well-intentioned advice. It needs decision-making power.

For many years I have worked as a consultant. Among other things, we would do digital transformation for clients in software development. One of my former colleagues, now serving as a director of engineering in a product company, shared a valuable insight…

When he was in a consultant’s role, he could only offer guidance and suggestions and lacked the authority to enforce changes. Transformation was slow and full of mishaps, especially when leadership got misaligned.

In contrast, as a director of engineering, he could influence the teams’ incentives and structures in a direct manner. It led to quicker and more effective transformations than when we was not as empowered.

This same principle applies to diversity and inclusion efforts. We need people with diverse mindsets and perspectives sitting at the decision-making table. Otherwise, attempting to drive change from the sidelines will be much more frustrating and less effective.

Doesn’t matter what the reasons you have to lack enthusiasm on a particular social gathering. You can be a shy person. Or an introvert¹ that is needing alone time to recharge your batteries. Or even an extrovert² that isn’t keen on being with a particular group of people.

These tips can help you survive such situations…

First things to remember are the following guiding principles:

• Look busy
• Avoid eye contact
• Move around
• Everyone cares about themselves

Look busy

Most encounters in social gatherings happen when someone sees you idle. People don’t like to interrupt. So don’t be idle. Read a pamphlet, scribble notes somewhere, pretend to send a text. Your phone is an excellent tool to look busy and avoid people approaching you.

Avoid eye contact

At all costs! For real. This is the main invitation signal for people to approach you, even if not immediately. Allowing eye contact, nodding, and other common social rituals, are an open invitation. Close those doors.

Move around

A moving target is hard to hit, so always be moving. Be slow, pause for a bit but don’t stay for long in the same place. If you stay put, you’re creating opportunities for other to approach and engage. It’s harder to talk to someone who is going somewhere. People don’t like to interrupt and you can always say you’ll be right back.

Everyone cares about themselves

Since everyone’s focused on their own experience, no one cares what you are doing. People remember the interactions they’ve had, not the ones they didn’t. Who they talked to, not who they didn’t. This opens ample opportunities to survive a party by “walking between the raindrops”.

These guiding principles apply is many ways and to many situations. Here are some examples…

— In a walking around cocktail-style event —

If you see someone approaching, don’t try to identify who it is. Curiosity killed the cat and you’ll end up creating eye contact by accident. Turn away in a slow page, as if you didn’t notice and go look for something else to do, like choosing what to eat from some tray.

Never join an area of the table with lots of people on it. You might end up eating the less popular food but you need to prioritise avoiding people. That’s what’s more important!

Going to pick up some food but someone anticipates you and gets there first? Pretend something distracted you (a painting on the wall, a flower on a vase, your shoelaces) and buy time. Approach it again only after the person has left. Nothing opens the door to conversation like deciding who gets the last croquette.

Always have food with you. If someone is entering the danger zone looking to chat, start eating, look away and walk out. People tend to not interrupt if your eyes are on your plate and no one expects an answer from someone chewing.

Another option is having a drink with you. Doesn’t work so well (taking a sip is too fast compared to chewing a bite) but can be better than nothing.

Are you seeing movements for social games like “musical chairs” or, god forbid, a “conga line”? Great timing to step outside for a smoke, go look for the bathroom or answer some “urgent” messages on your phone.

If someone catches you on the way out and insists you join the “fun”, answer with “yes, I’ll be there right after”. Saying “no” will only make it worse. You become a challenge and will engage their evangelisation impulse. They’ll try to convince you with “it’s so much fun”, “you must join”, “it’s not the same without you”, etc.. Answering “yes, later” fulfils their desire to gather people around and buys you time. Time after which you’ll have no intention of following through, of course.

Don’t stay outside too long though. If you abuse it, people will worry where you are and be more motivated to approach you asking if everything is ok.

— In a sitting down conference-style event —

Joining a restaurant where you’ll have a group meal together? Make sure to be in the middle of the pack. This way there’s already enough people seated when you join the table to let you read the room. Yet, there will still be enough seats available to let you choose the most pleasant or quiet people to sit next to. Don’t be the first ones to sit since you’ll have no control who sits next to you and it’s awkward to move away once you’re seated. Also, don’t be the last ones to sit since all the good places will be gone and you’re now stuck with the group’s leftovers.

Is it a place where everyone’s lined up in chairs, like in a cinema, for a talk or to watch some family holiday pictures? While everyone is setting up things, go grab a beer or sneak into the toilet. Let others occupy the seats first. When you’re back, skip the chairs and stand at the very back against the wall. You’ll be safe from happenstance conversation about what you’re watching.

Does someone take a wall spot too close to you? Be discrete but be quick (as if you’ve just realised something) and go pick something else to eat or drink. Then stay around that area and don’t return to where you were on the wall. Remember, it’s more important where (how isolated) the place you’ve pick something from is, than what you picked up.

Sitting down is risky because it affects your mobility but if you want to sit, avoid clusters of empty chairs. An empty cluster might be appealing because there is no one there. But since there are so many free seats, it’s very risky. Someone outside of your control can sit right beside you and start a conversation.

Choose a chair at the end of a line and pull it way from the others if they are movable. Never sit in chairs in the middle of a row: too many chances to get people on either side of them.

If you can stomach the noise of children, and there are some around, pick a chair next to them. That keep most of the other people at bay, especially guys. If you sense someone approaching, look at what the children are doing as if you’re interested. Give a faint smile and focus on whatever they’re doing or chatting about. This will send a message of “being occupied” and people won’t want to bother you.

— At the end of the event —

Never be the first one to leave the party. You’d have to say goodbye to everyone and explain each time why you’re leaving “so early”. Plus, you’ll have to deal with all the “ooh, already?” and “why don’t you stay longer?” departure rituals.

Pay attention to the first people to leave, and take a “ride” with them. Let them take the blunt of the departure ceremonies. Wait for those to finish and the ones staying get tired and give up trying to convince them. Then you can nudge the hosts with a shrugging “I need to leave as well 🤷” and walkout together with the first people. Timing for this is critical but the resistance will now be minimal. You can finally take yourself out of there, into freedom.

Being invisible in a crowded party is a subtle art. Present and mingling with people, while absent without engaging, and without raising suspicion.

Hope these guiding principles and tips can help you survive such places without harm.

Take care.

And realise this is a work of fiction, doesn’t necessarily have any parallels with reality… kinda 😏

via GIPHY

There are several structured ways to help us shape our message for others in a way that helps people receive it well. Unfortunately, some of them are useless and even disrespectful (e.g. the “shit” sandwich, and others).

The following frameworks are ones that I’ve found more useful and helpful.

Common feedback frameworks

NVC - Nonviolent Communication

by Marshall Rosenberg (CNVC)

An approach to communication based on principles of nonviolence. Was developed by clinical psychologist Marshall Rosenberg beginning in the 1960s and 1970s.

This is a very popular approach, with lots of books, articles and training going around for it.

• Observation — Facts we are seeing, hearing, or touching, as distinct from our evaluation of them
• Feelings — Emotions or sensations, free of thought and story
• Needs — Universal human needs, as distinct from particular strategies for meeting those needs
• Requests — Distinguished from demands in that one is open to hearing a response of “no” without this triggering an attempt to force the matter

SBI+I - Situation-Behavior-Impact + Intent

by Center for Creative Leadership (CCL)

A more niche approach written in 2022, from a nonprofit organisation focused on leadership. Their goal is improving the understanding, practice, and development of leadership.

• Situation — Clarify and describe what happened, when and where
• Behavior — Describe the observable behaviour, without assuming what the person was thinking
• Impact — Explain what you thought or felt in reaction to the behavior
• Intent — Inquire about their original intentions, to clarify the gap between intent vs. impact

CORE - Context, Observation, Result, nExt stEps

by Kim Scott (Radical Candor book)

From the author of a best seller in the business category, published in 2017. This method makes sure you’re not criticising someone’s personality when delivering negative feedback (or even praise).

• Context — Cite the specific situation
• Observation — Describe what was said or done
• Result — What is the most meaningful consequence to you and to them?
• nExt stEps — What are the expected next steps?

A simple mnemonic to remember

As you can see, there’s plenty to study and choose from. I recommend you look through the methods in more detail and see what you can relate with more. Practice it whenever you have a chance…

In reality though, situations that bother you and demand these tools happen in real time. Quite often, the timing to say something is in the moment and it’s hard to remember all the above rules.

Unless you’ve practiced enough for these concepts to become unconscious competence (i.e. have an intuitive level of familiarity with these tools), it can be hard to remember how to say things on the spot.

While still in the conscious competence phase, this simple mnemonic has helped me recall how to structure my feedback:

• 👁️ … talk about what you Observe
• 🔨 … talk about what was the Impact
• ❓ … then Ask a question as follow up

This is because there’s a natural overlap between the methods. They emphasise different parts of the conversation. The authors chose different terms for similar underlying principles. But human nature is constant.

Here’s how this mnemonic maps to the frameworks shown above:

One more thing…

Start, Stop, Continue

Beyond the scope of “negative feedback”, we are sometimes asked to provide general feedback about other people. Could be about a new hire during their probation period. Could be preparing for a “speedback” session with team members. Could be many other scenarios.

What should we say? What can we talk about?

An easy way to identify topics to talk about is to brainstorm using the “start, stop, continue” pattern:

• Start — Think whether there are things the person should do, which they are not currently doing
• Stop — Think if you can see anything that the person should not do anymore
• Continue — Think about if some of the person’s current behaviours they should maintain

All this is, is a guide to think about different “things to say”:

• You don’t need to be exhaustive in covering the 3 aspects
• You can have several things to say for the same aspect
• You don’t have to follow this specific order
• You can mix and match different aspects, as it feels more natural to you

Happy feedback 🙂

“The business”

This is a pet peeve of mine, for sure. But beyond that, it’s important we stop covering decision makers behind “The Business” curtain.

There is no such entity called “The Business” in companies.

“The Business” isn’t a job function or role or group of people.

“The Business” is everyone in the company.

So what is happening in reality, behind “The Business” curtain?

It‘s quite frequent that “The Business” is shorthand for “I’m only doing what someone asked me”.

Quite often it means the request came through a chain of so many people, no one knows anymore who asked it and what for.

Behind this expression there’s always people: someone who wants something for a reason. They need a problem solved, an opportunity to explore, an experiment to try.

People are the link to context.

To be effective in our jobs, we must know who are the people at the source of a decision or request. It’s the only way to sidestep all the “broken telephone” effect that exists in any chain of requests.

Being able to ask clarifying questions to the source is essential to get an accurate context. And as we know, context is everything for the decisions that affect us and requests we’re asked to fulfil.

Next time someone says “The Business” asked, decided, demanded, etc. follow these 3 simple steps:

1. Ask “Who was it that did that?”
2. If you didn’t get a real person, repeat the question applied to that answer
3. Continue as often as needed until you get to names of real people

Well, it’s actually only 1 step 🙂 — Keep asking who’s the person until generic groups or terms becomes actual people names.

It never ceases to surprise me how hard it is sometimes to get to the names of the people who are making some decisions. It gets worse the larger the company is.

Be prepared for the possibility of some interactions to become something like this:

X: “The Business” decided to use Foo for everything
Me: Who made that decision?
X: It was at the board level
Me: Who in the board was deciding it?
X: Oh, that was done in the steering committee
Me: And who’s part of the steering committee?
X: VPs, C-level and our main stakeholders
Me: Who are those stakeholders?
X: Jane from Bar and John from Baz
Me: And who from the VPs and C-level belongs in the committed?
X: VP of Tech and VP of Product, and now the CFO and CEO as well
Me: Ok, thanks [*sigh* I guess I can get those last titles from the org chart now]

Now we know who to ask for clarification on the rationale behind the Foo decision. I’d bet that decision is more nuanced than the “use Foo for everything” you got at the start.

Why go through all this trouble?

Because context is everything…
Because people are the link to context…

So, remember to always ask:

Who is “The Business”?

When there are several things to choose from, the Enumerate is the only one to support it, so that’s clear.

But what about when you have two things to choose from? There might be some confusion between both data types since either of them supports handling binary choices.

The confusion arrises in particular when you want to add the choice of a new behaviour, on top of an existing one. For example:

We’re torn between adding a boolean called supportsBarMode or having a more descriptive model with an enum that lists all the supported options [FooMode, BarMode].

The enum solution feels a bit YAGNI at the moment, but we’re open to suggestions. What do you think?

Don’t tie yourself to whether you’ll need more options in the future or not. Instead, look at how you can communicate intent the best way possible.

The mental model for encoding these binary choices is to identify which of these scenarios we are in:

• Switch something on/off — e.g. enabling or disabling an extra option
• Select mode of operation — e.g. choosing between ways of doing things

Boolean = Switch something on/off

A Boolean fits the 1st scenario. A light switch is either on (have light) or off (don’t have light). When it’s off, there’s no “default alternative behaviour” associated with it: the thing we want to turn on just isn’t there.

Enumerate = Select mode of operation

An Enumerate fits the 2nd scenario. A coaxial selector is either on position A or on position B. It lets you choose between two options. There is a clear meaning associated with each position.

In the example above, the Enumerate data type would be the right choice.

… an enum that lists all the supported options [FooMode, BarMode]

Even if we never add other options to that Enumerate, it is not a case of YAGNI. The Enumerate could have only 2 options forever that it would still communicate the correct intent.

One thing I have experienced to work well in the recent past is to have a technical/design kickoff with other team members when starting a feature: we trade ideias, discuss options, and align on a way forward

— https://twitter.com/hugocf/status/1116437142010507266

When the time for code review comes it’s a) obvious who should review it, b) easier to review because people have the context already, c) quicker to review because it becomes more focused on details and easier things to correct

— https://twitter.com/hugocf/status/1116437755670740992

Over the years I’ve worked in many software delivery teams under a multitude of working formats:

• Sometimes working collocated, others as a remote satellite worker, to completely distributed¹
• With people having very different skill sets and levels of experience²
• Dealing with many different geographical and cultural backgrounds³

Under very different types of pressures,

• Greenfield projects with strict deadlines
• Rescuing huge legacy codebases
• Long running product development

All these experiences forced me to reassess some of my long held assumptions about ways of working.

In particular, the dichotomy between pair programming and async code reviews⁴ started to feel too strict and “religious” at times. There are many situations where people don’t want the burden of lengthy code reviews for which they lack context. Many other cases where continuous pair programming is not even possible (e.g. large timezone differences or appalling internet connections).

Pair programming is not for everyone

Photo by Alvaro Reyes on Unsplash

This story started during a project with a tight 3 month deadline. We had to be very strict with our scope and be fast on how we ensured quality in the delivery.

All members had years of exposure to pair programming, so they chose to work like that, as a way to deliver faster. By bouncing ideas and reviewing code on-the-fly, we could evolve the code base as a team in an organic way.

One colleague was struggling though. They couldn’t adjust to the format under this particular context and delivery pressures.

Either due to personality traits⁵ or personal preferences⁶, whatever it was at the core, the team felt the need to embrace it and make some adjustments on the way we worked.

There are many ways around personal differences to make pair programming work. In fact, this is a common practice in pairing since no two people are alike. But sometimes those differences are irreconcilable and this was such a case.

We all agreed that several people looking at the same piece of code was essential to ensure code quality. So, our initial change was to use the most common alternative in the industry: async code reviews.

The problems we faced with async code reviews

Code reviews are easy, right?

1. The team kicks off a story
2. A developer works on it on their own until development is “done”
3. Some team members review it

and then… well, then what? Then that’s where our problems started.

Setting aside how hard it was for a reviewer to get up to speed with the code to review, due to the lack of detailed context…

Setting aside that, since it required quite a significant mental effort to do the above, finding the time to review was also a problem…

Once a code review was in though, the type of issues we caught would fall under 3 categories:

1. Finishes and polish

   • Stuff that’s simple and easy to change: better names, move something around, extract a method, inline a variable, etc.
   • It was easy for the author and reviewer(s) to discuss and align these changes. It improves the code base a little and the cost is very low.
   • ✅ Small benefit
   • ⛔️ Small cost

2. Marginal better structure

   • The change to the codebase is not wrong or unworkable. We could improve something and bring marginal benefits but it is not trivial to change at this stage.

   • These changes ended up not happening. They were hard to justify at this stage with the perception was that the benefits were small. It was also hard to overcome the arguments of “but it’s already working”.

   • ✅ Small benefit

   • ⛔️ ⛔️ Medium cost

3. Wrong implementation approach

   • This is where something was “lost in translation” completely. This might not be that frequent but we’ve seen it happen enough times to hate the experience.
   • Catching severe misconceptions in the implementation approach at such a later stage has a very high cost. This means lots of rework, lost time, and waste. Regardless, we must do it.
   • ✅ ✅ ✅ Large benefit
   • ⛔️ ⛔️ ⛔️ Large cost

The first category of issues (#1) is a no brainer and hardly a contentious point. This is an obvious benefit of code reviews to improve code quality.

The last category (#3) is very painful and quite a blow to the team. To throw away and rework all the investment at such a late stage is painful. It’s a necessary evil that everyone can agree and, again, a clear benefit of code reviews.

The biggest problem and what concerns us the most were the middle category (#2) of issues. These missed opportunities lie only on the fact that the team caught these issues too late.

There reason these changes are so important relate with the broken windows theory. There’s the perception that these benefits are marginal, but they compound over time. They end up becoming a tangled web inaccurate abstractions, faulty approaches and bad code. These are not straight forward to solve, especially in a time constrained project.

Catching issues too late is a good summary of the key problems we faced with code reviews.

Pair programming gives realtime feedback, since discussions happen as people write the code. Being used to that, all the waste illustrated above was more that the teams could handle.

Our guiding principles

When we have conflict between people due to practices we deem fundamental, where do we draw the line?

All this adds tension and complexity to our ways of working. Working through these differences and find effective strategies, requires compassion between team members.

More than specific practices, our focus should be in the immutable principles behind those practices. They set the stage and give context for the team’s choices.

These are the key foundational principles that were guiding our directions:

1. Team-based ownership of the entire delivery
   • At the technical level, this means more than one person understanding and caring for each piece of code written.
   • Not only the technical aspects (codebase, pipelines, observability) but also including roadmap, backlog, priorities, etc.
   • Several people together think better than a single one. Over time, this reflects in an increased quality of the code base.
2. Include all the members of the team as equals
   • It is usually said that whenever someone leaves or joins a team, it becomes a new team altogether.
   • Being a cohesive team implies welcoming the participation and voices of all its members.
   • Seek for “consent” and “acceptance” from the group, rather than aiming for the elusive “consensus” or “agreement” from everyone.

A positive mix between both approaches

I think both techniques are clearly a net good, although they each have their particular pros and cons.

I don’t think it’s a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you’ve written

— Jeff Atwood in Pair Programming vs. Code Reviews

How could we leverage the benefits of pair programming and avoid the flaws of async code reviews? Something that incorporates some of the learnings and key strengths of both approaches:

• Develop code with collaboration built-in from the start
• Avoid building a wasteful inventory of code changes pending review
• Make the review experience engaging and straightforward, with reduced cognitive load (as possible)

So we started doing what you can call a “sandwich” of both approaches:

• Start with a pair programming session for technical kick-off and code design/exploration
• Continue with individual async development and implementation
• End with a pair programming session for code review and discussion

In more detail, the story development workflow became:

1. Story kick-off with all the team’s disciplines⁷ involved (UX + PO + QA + DEVs)

   • Here we shape the user story acceptance criteria and scenarios.

2. Once it’s over, the DEVs (a pair or trio) would stay on for a technical kick-off

   • Here they discuss the actual technical design and implementation approaches
   • This implies going over the code base and exploring alternatives
   • Discuss modelling options (e.g. extend a class vs extract an interface), explore potential new patterns or structural refactoring, etc.

3. The solo DEV would move on and do the development as discussed with their colleagues in #2

4. Once it’s development finishes, it’s time for the code review

   • It’s now trivial to identify who should join the code review: those that were in the technical discussion in step #2

   • They join the DEV implementing to walkthrough the code changes and discuss them

   • Depending if the changes are quite simple, if it remains aligned with the initial direction, then this could an async step

Notice that step #3 implies a good level of maturity from the solo DEV implementing the story. They need to reassemble with the people from the pairing kick-off in step #2 whenever the direction diverges:

• They face a roadblock or start entering a rabbit hole
• They realise the initial ideas are no longer valid with new discoveries
• The direction becomes impractical or turns out more complex than expected

The main takeaway is that the team must discuss technical approaches together, and the earlier this happens, the better. This approach promotes those discussions to happen much earlier than in async code review.

So, does this mean more meetings?

No, definitely not. These are work sessions. You start, work together, and finish when the group understands they’re in a good place of understanding. It takes 30 min or several half days, depending on the complexity of the work at hand.

Then it’s only for complex stories?

Not at all. Do it for every user story, no matter how simple it seems at first.

While complex stories need to involve the entire DEV team, simpler stories should only need one other developer. And if the story turns out to be very simple, them it’ll take only a few minutes and you’re done.

The most important factor is to build the habit muscle of doing it always. This will help you catch and avoid several blind spots and assumptions. Sometimes behind that seems simple hides a crucial decision when you start trading ideas with others.

Does splitting up and coming together increase Work in Progress (WIP)?
(by Gerald Benischke)

It’s the same as if you’d be in an “async code review” model where each dev picks up a story individually.

If you switched an entire team doing pair programming into this model, then yes, WIP would increase since you’d now have single devs coding stories instead of pairs.

In our case though, we applied it only to the single dev mentioned in the story above. The two other pairs continued to do pair programming, so there was no significant change in WIP.

Benefits of the “pairing code reviews” approach

To start with, the focus of the reviews became all about the “1. Finishes and polish”. Easy refactoring, practical renames, etc. which code reviews well suited for stayed.

The problems with “2. Marginal better structure” and “3. Wrong implementation approach” disappeared from the reviews. They’d either be all discussed at the start or along the way, close to when they became relevant.

Pairing at the time of code review also helped with the fluidity of the review. Since all had context, it was much easier to discuss and change the code as we went along. Much better than dealing with a lengthy back and forth of asynchronous interruptions.

It lifted the weight of constant pairing, for those who had difficulty with it or which the timezones did not permit. Because it happened only at clear distinct milestones in the development lifecycle,

Also, it removed the feeling a being “evaluated”. It added a more collaborative mindset of working together, of building something together.

There are no silver bullets for most things in life. Everything is a tradeoff. With this, you have one more useful approach to consider when your context needs it.

Especially in consultancy, “context is everything” is a famous adage. What is true in one company, almost never applies directly to another. We always need to do major adjustments to the new context and the different realities.

But what if I told you that we can take this idea even further? What if I told you that nothing has advantages or disadvantages, only characteristics?

At first, this might seem like a strange notion. After all, we are so used to consider pros and cons when comparing different products or services.

Take, for example, someone in the market for a home safe. Most suppliers will brag about how resistant to tampering theirs locks are. An advantage, right? After all, that’s what all homeowners will be looking for: protection.

But what if we are talking about a burglar? Now, that same characteristic is a big disadvantages when looking for a home to target.

Still with a burglar in our minds, what if they are looking for a safe to take home and practice breaking into? It’s the same person but now that same characteristic is again an advantage.

We can see many more examples like this in the software development industry. It’s common to find technical analysis of frameworks, libraries, or programming languages. They are usually filled with positive and negative evaluations, advantages and disadvantages.

But what context are the authors using to assess them? Most of the times this is absent, which can lead to controversy and people talking past each other.

What the above examples illustrate is the implicit context we all have that is very often not said out loud. Not clarifying this full context is the most common pitfall of comparisons.

It’s the implicit context that “the purpose of safes is to protect”. It’s the implicit context that “frameworks should be stable”, or “performant”, or “easy to use”. Same goes for programming languages, where implicit contexts are many and sometimes contradictory. If we dig a little deeper, we will find that all these comparisons are only meaningful under some context.

Everyone has their own implicit context in their minds. In society, within cultures, we share common implicit contexts. This all bleeds in when we talk to each other.

So, what’s the solution? We need to make the implicit context explicit. Even if it seems redundant! Even when “everyone knows this”.

Always question yourself and be aware of the context you bring to every conversation. This include your goals, your constraints, past experiences and values. These are the “tinted glasses” you see the world through, and everyone else has their own.

Be curious about how other people’s implicit context differs from yours. You can gain a better understanding of their perspective and work better together.

If you analyse something by yourself, the danger of misunderstandings isn’t there. Implicit and explicit context tend to mix since it’s all internal. But looking for that implicit context might surprise you and shed new light into the “why” of your choices.

When analysing with someone we know very well, relying on a shared implicit context is possible. Misunderstandings are less likely but can still happen. Be very attentive and default to clarifying and making it explicit at the first sign of trouble.

Not relying on implicit context becomes crucial when working in larger collaborative groups. It’s impossible to rely on implicit context because everyone has a different one. This is especially important when working in multicultural environments, which bring even wider implicit context differences.

So, when preparing for a group discussion by yourself, start by gathering the different characteristics of the topic. Aim to do it in an impartial way, devoid of context. Then, with the group, define together which context to assess those characteristics under.

If you’re in the middle of a group brainstorming going sideways, go back to ensure that the context aligns. Clarify what is the agreed-upon context and, if there’s none, define it. Give everyone a shared frame of reference to assess the different solutions.

Next time you think about pros and cons of something, take a moment to consider the implicit context.

Remember that nothing has advantages or disadvantages, only characteristics. We can assess them under different contexts, and yours will likely differ from someone else’s.

Make all context explicit and be curious about other people’s perspectives. This way you can make work more effective and make better decisions together.

Update 2023-05-17:
(via Andy Kemp)

Interesting research supporting this notion of implicit context in the Scientific America article People Differ Widely in Their Understanding of Even a Simple Concept Such as the Word ‘Penguin’:

“The probability two people selected at random will share the same concept about penguins is around 12 percent,” Kidd says.

The reason is people’s different life experiences:

For example, “people disagree about things like whether penguins are heavy, presumably because they haven’t lifted a penguin.” Here, Kidd hints at where a lot of these differences likely come from: they boil down to a person’s life experiences “If you’ve spent time watching penguins walk, you’re maybe more likely to think they’re heavy from their waddle,” Kidd says. “If you’ve spent time learning about anatomy, you’ve maybe learned birds have light skeletons and so think penguins are light.”

And the differences can be quite numerous:

…the team’s results suggest that at least 10 to 30 quantifiably different concept variants exist for even common nouns such as penguin.

Update 2024-04-19: Add illustrative images to the Context section, including info on Rivers, not buckets.

Update 2024-02-13: Introduce headings for easier navigation and highlight the core problem with messaging apps.

Update 2023-10-17: Replace simplistic “Channels/Someday” channel organisation with a MoSCoW-inspired sections structure optimised for fast processing.

Context

Lets start by recalling a few old principles about processing large volumes of information, and then define the core problem with modern messaging apps, as I see it…

📥 Inbox zero

“Inbox zero” is a pivotal concept to deal with the constant influx of information of modern life. Merlin Mann coined it in 2006, during a series of posts on 43Folders.

That “zero?” It’s not how many mes­sages are in your inbox–it’s how much of your own brain is in that inbox. Especially when you don’t want it to be. That’s it.

— Inbox Zero (Internet Archive 2011-07-12)

It was not about “perfection” but rather a way for us to take back control of our time and avoid being reactive. To do that, you triage messages to focus on what matters:

1. Take fixed times in the day to go through your inboxes — close or ignore them outside of those times
2. Make decisions, not actions — triage fast and act later, so you’re not derailed into a long essays

Once you’re done for the time slot, you can get out of that “new/unread” mind space. Go back to doing your actions, according to whichever criteria you think fits best.

At the time, this concept appeared to deal with the problems of overwhelmed email inboxes. Its core principles expand beyond email though. They are essential to get out of a reactivity loop and quite generic that they apply to other areas or our life:

Accept that almost everything in your life is an inbox

— Natasha Bernal on Everything you thought you knew about inbox zero is wrong | WIRED UK (Internet Archive 2024-02-25)

⛲️ Rivers, not buckets

Dave Winer id one of the creators of the RSS specification and a forefather of blogging. He started advocating the concept of a River of News in the early 2000s:

They call them streams, lifestreams, etc, but they’re all the same basic idea. Park yourself on the riverbank and watch the news flow by. If you miss something, not to worry, if it’s important some new story will refer to it.

Since then, the “stream of information” concepts have spread to most online experiences. There’s prime examples in all the social media applications, newspapers, aggregators, etc.

Oliver Burkeman expands on this concept and urges you to treat your to-read pile like a river. In this approach, you cherry-pick the most important things that stand out, and let the other ones drop:

To return to information overload: this means treating your “to read” pile like a river (a stream that flows past you, and from which you pluck a few choice items, here and there) instead of a bucket (which demands that you empty it).

There’s also an underlying need that is worth highlighting, and it might not seem obvious at first sight. We must be able to identify which of the pieces of info floating through are important to us.

💬 Messaging apps problem

Nowadays work happens on instant message applications, not email. These types of applications are quite bad in letting us apply the above concepts:

• Their structure revolves around immediacy of synchronous messages and responses
• Their core unit to manipulate is the channel, not individual messages

Slack, in particular, is one of the worst offenders in this matter. Many of of their design decisions reinforce the notion of immediacy and having to “keep up” with it. For example:

• The frequent “X is typing” notices
• The inability to read recent messages and keep older ones unread for later

Solution

⏱️ The gist of the solution

The goal is to apply the “inbox zero” concepts outlined above and mitigate the pressures to “respond immediately”.

The realisation is that sections can become a pseudo-inbox of channels that need reading (as opposed to considering messages the unit to manipulate).

This is how I setup my Slack channels sections to make them behave more like an inbox:

• Show channels with Unread messages only
• Sorted By most recent

🗂️ Organise for fast processing

In practice, the most granular unit you can manage your “unreads” in Slack is the channel, not the message.

Depending on how far back I am with the backlog of messages channels to read, I want to be more flexible to decide where to stop (i.e. I’ve seen what’s important) and “mark all as read” the rest (i.e. “rivers, not buckets”).

As for which sections to use, I’ve ended up with a MoSCoW-inspired list where I essentially answer the following questions for each channel:

• How directly related to my work/role is it?
  • ✅ Yes, very
  • ☑️ Meh, kinda
  • ℹ️ Not really
• Am I keen on reading/seeing new messages on it?
  • 👀 Yes
  • 🙈 Nope

The decision matrix for where to save each channel then becomes something like this:

In practice, the order of those sections in Slack changed a little bit over time and now follow what is roughly two sets of “traffic lights”: 🚥

• 🔴 Must, 🟠 Should, 🟢 Want — Allways read, and read regularly
  • (if on a very tight time crunch, “Want” might be skipped)
• 🔵 Nice, 🟡 Could, ⚫️ Maybe — Read sproradically, depending on time and energy
  • (good candidates for the context menu action “Manage” ➤ “Mark all as read”)

Putting it all together:

This is now the most battle tested setup I have stayed with for many months. Most past setups broke down on the “coming back from holidays” huge backlog of stuff to read.

This setup lets me manage my time/energy more effectively and use the “mark all as read” more often, once the core channels are cleared.

📨 Processing inboxes

With this, my daily process becomes, at specific times during the day:

1. Deal with Direct messages
2. Check for Threads updates
3. Process the updated Channels in the first section 🔴 Must
4. Continue to the second section 🟠 Should
5. If time permitting, continue going down to the 🟢 Want section

When I have some more relaxed time, usually at the end of the day:

6. Skim and cherry-pick from the remaining sactions channels some messages that spark my curiosity
7. Shift-Esc to “mark all as read” and have an clean slate for next day

🚧 Full setup

The sidebar consists of the following sections, in this order:

1. Starred default section
   • Sorted Alphabetically and showing All channels
   • Expanded all the time
   • Contains conversations that I want to remain “pinned” on the top of the sidebar for a short time, regardless of read or not
   • Used for ongoing group messages or temporary channels with an active conversation for a few days or so
   • Direct messages of @Slackbot (notices and some mentions) and my own user @me (for scratch notes) are always starred here
2. Direct messages default section
   • Sorted By most recent and showing channels with Unread messages only
   • Expanded all the time
3. Temp custom section
   • Sorted By most recent and showing channels with Unread messages only
   • Collapsed all the time
   • Like temporary solutions tend to last forever, so the same happens with temporary channels
   • This collects temporary channels so I can the person nagging to archive them when they’ve served their purpose
   • I usually set a reminder on a relevant message as a trigger for when it’s time to archive
4. 🔴 Must custom section
   • Sorted By most recent and showing channels with Unread messages only
   • Expanded all the time
   • This section contains only the channels that are essential to my day-to-day work, as described above
5. 🟠 🟢 🔵 🟡 ⚫️ the other custom section
   • Sorted By most recent and showing channels with Unread messages only
   • Collapsed most of the time
   • The remaining less critical channels end up in these sections, as described above
6. Channels default section
   • Sorted Alphabetically and showing All channels
   • Expanded all the time
   • This section is usually empty
   • Only temporarily, it can contain channels I’ve just joined and have not yet been sorted into their right section, as described above
7. Apps default section
   • Sorted Alphabetically and showing All channels
   • Collapsed most of the time
   • Easy access to apps I use on occasion but not so often that I remember their name

Information

💡 Tips and tricks

Navigation alternatives

With this approach, channels and conversations disappear from the sidebar once we read them. There are few options to navigate around and finding previous channels or conversations:

• Shortcut CMD-K to find and jump to a specific channel
• History 🕒 view to go back to recent chats and last visited channels
• DMs view on the navigation bar to quickly get back to a group conversation
• Threads view, to see updates on conversations where I choose to Get notified about new replies

Sidebar “Unread messages”

You can take advantage of the sidebar Unread messages to process channels and messages in line with the sections concept shown above:

• Choose “Sorted like your sidebar”
• Display only the 🔴 Must section
• Once cleared, you can easily Jump to the 🟠 Should section
  • … and so forth, until all sections are cleared one after the other

❓ Questions

Does it mean that with this you have Slack under control, almost empty, and you’re very responsive?

Of course not 🙂

Days still go haywire and messages backlog accumulates. And quite often it all becomes chaotic. That’s a consequent of the environments we work in.

With this setup though, I’m able to take care of the most urgent and important messages in those chaotic days. Also, it’s easier to recover from a crazy week without the fear of missing out (FOMO) some interesting message.

What about using sections to organise and classify channels by type, scope, urgency, category, etc.?

Before, I was using different sections to categorise and classify channels by themes, scope, etc. It was a way to scratch my itch for having everything well organised and in their “right” places.

I stopped doing it because it was getting hard for me to maintain them and was getting lost on too many places to check. There was no easy way to triage what was recent vs old and important vs secondary.

It was a hard to kill all those sections curated with much care, after lots of time invested. This was quite scary to do 😬 but the benefits and simplicity gained from switching to a setup optimised for processing new stuff have more than made up for it.

What about the mobile app “Newest to oldest” view?

This inbox approach started in the Slack mobile app. I switched my channels list to sort by “Newest to oldest” (previously called “Recent activity”). This lists updated channels under “Today”, “Yesterday”, and “Last 7 days” groupings.

This change was such huge improvement. I found myself switching from desktop to my smartphone to check Slack messages. I could focus only on the “Today” view and keep up-to-date with what was changing (even if there was some past backlog).

The only drawback was that there was no easy way to distinguish between important vs unimportant channels. Triage of what could wait for later in the “Today” section was only visual.

Shortly after, a colleague shared a similar “timeline” setup of their desktop sidebar. Inspired by it, I decided to take the plunge and experiment with this “Slack as an inbox” setup in both desktop and mobile.

The concerns are also usually about negative feedback. It’s quite easy to give praise or positive feedback to people, since they receive it very well in general.

The internet is full of advice and frameworks to help us shape our message in a way that people receive it well. For example:

• NVC (Nonviolent Communication)
• SBI (Situation-Behavior-Impact)
• The feedback sandwich
• and many others, I’m sure…

It makes sense that it is so. It’s a natural psychological reaction for people to become defensive when they are criticised.

But what about the other side of the coin, the way we receive feedback?

Aren’t we loosing valuable information if the success of negative feedback is only on the speaker?

Won’t some difficult conversations not happen if the burden is only on the person shaping the message?

I, for one, have refrained on occasion from giving negative feedback to people because of that. Sometimes the emotional bandwidth to tone down my initial impulse wasn’t there. Sometimes I didn’t have energy to do the mental gymnastics needed to restructure it into a thoughtful message.

Poorly shaped negative feedback can take many common forms:

• It can be sloppy, too blunt, or even aggressive
• Can come from a colleague, a boss, or a client
• Someone might think they are better than those around them
• In some environments, competition and antagonism can be the norm

And yet, there seems to be lack of awareness and interest on how to deal with it.

Source
(blue = “giving feedback”, yellow = “receiving feedback”, red = “receiving negative feedback”)

Consider this real example of feedback to a technical proposal, many years ago. At the time, several people pilled on the proposal, with lots of comments received like these:

This change makes absolutely no sense to me.

I’d vote against this immediately! Why not just use [some simplistic alternative] instead?

Sure, let’s all do [insert gross exaggeration / ridiculous simplification] from now on.

What do you think each person was actually saying?

“You’re incompetent. This idea is stupid.”

or,

“I’m missing the context where this makes sense.”

We can interpret both these thoughts from the comments above. The first one is more likely to be the one we latch on (because of our ego, our sense of self-preservation, etc.). Yet, we get to choose which interpretation to focus on and respond to.

At its core, feedback is only information. It’s very easy for emotion and flawed terms to camouflage that information, tough.

We can approach the feedback we’re given like detectives or scientists solving an interesting puzzle. Investigate beyond what’s most obvious and uncover the information behind it.

Show compassion when we’re on the receiving end of feedback given in a “bad” way:

1. 🙉 Ignore “intention”, remove “tone”, strip the message down to its essence to put it into perspective

2. 🤔 Take the feedback in and relax by thinking what would it take for you to be the one saying that

3. 🎯 Thank the person for the essence of their point and consider, in a factual unemotional manner, what to do with it

One of the core principles of Stoicism can guide us here: the acceptance of things we cannot control. And we cannot control other people’s words, only ours!

In the words of the ancient Greek philosopher Epictetus:

Remember that it is not he who gives abuse or blows, who affronts, but the view we take of these things as insulting. When, therefore, anyone provokes you, be assured that it is your own opinion which provokes you. Try, therefore, in the first place, not to be bewildered by appearances. For if you once gain time and respite, you will more easily command yourself.

— in The Enchiridion, Section XX

So remember:

• How you perceive other people’s words has more impact on you than the way people said them or their real intention.
• You are in full control of how you interpret what others said and you cannot control how other people say it.

Picture a real life fire. People feel confused, scared, and don’t know what to do. They’re stressed and drop everything, scrambling around to deal with the emergency. They disperse their focus and their actions are erratic. Chaos is all around.

Source

As you can imagine, I don‘t think this is how we should react. What might surprise you is that I don’t think the analogy is wrong. I’d argue though, that we should embrace it even further.

Even firefighting needs a strategy

Trained firefighters make up another crucial group of people in firefighting. Their actions and attitudes are completely different from those described above:

• They have a well thought out strategy for tackling fires, which they adjust to the reality on the ground
• They have pre-established roles and communication lines, so everyone knows what to do
• They follow safety rules of engagement based on their learnings from past emergencies
• They train together, in controlled environments simulating reality, to improve their coordination

With this, they are ready to handle emergencies with calm and expertise. When fires do occur, they feel “familiar”. Even considering the natural levels of stress and adrenaline involved in these situations.

Source

Consider the case of forest fires and how trained firefighters behave when they’re on the scene:

• Headquarters coordinates efforts based on constant reports from the field
• Coordination teams choose where to best deploy their people and physical resources
• They take changing context into account (e.g. weather and wind forecasts) to decide which fire fronts to attack first
• At times, they even decide which areas to let burn to create a natural barrier for other advancing fires

So, why can’t we operate in a similar way in our companies? Why are we in constant in firefighting mode, reacting to emergencies as they arise?

We can choose to look at “firefighting” in a strategic way. We can seek to act like “trained firefighters”, rather than in a chaotic way like “civilians”:

• Have a plan in place for handling unexpected problems
• Make sure people understand their role in responding to unexpected challenges
• Train people on how to respond to crises in a calm and efficient manner
• Practice how to work together to find solutions in emergencies

This way we can create a better culture of preparedness in our companies. Like trained firefighters, we can be ready to handle whatever challenges come our way.

So, the next time you find yourself in firefighting mode at work, remember that you have a choice. Don’t react in a chaotic manner, like a civilian in a fire. Be strategic like a trained firefighter.

A história que ele criou foi esta:

For sale: baby shoes, never worn.
(Vende-se: sapatos de bebés, nunca usados.)

— Hernest Hemingway

Criar estas histórias é um bom exercício de “storytelling”, útil para “quebrar gelo”, vencer a síndrome da “página em branco” e fazer os fluidos criativos começarem a correr.

O desafio partiu de um post no Instagram do Virgílio Varela, onde explica o formato e propõe alguns exemplos:

O que é fantástico é que não precisamos dizer tudo para criar uma história inesperada e surpreendente.

“Estranhos, melhores amigos, amantes, estranhos.”

“Fugi pra floresta, fui dentro, encontrei-me.”

“Casei-me A minha mãe tinha razão…”

“Ele pediu desculpas. Ela não aceitou.”

🗣️ Partilha aqui as tuas histórias de 6 palavras!

Por algum motivo o desafio ficou-me na cabeça, e assim sendo, aqui seguem as minhas modestas contribuições:

“Vem à aventura”. Morreu dias depois. 🔗

Tudo correu mal. Que grande alívio! 🔗

Bateu no inimigo. Partiu-se o espelho. 🔗

Estilo “adivinha”: 😉

Não há. Só temos…
Pode ser. 🔗

“Hacking the format”: 😏

Era uma vez … felizes para sempre. 🔗

Que histórias curtas consegues inventar com 6 palavras apenas?

É a tua vez…

Yesterday I kept a pen and paper always by my side and noted the times of what happened during the day. ✍️

In summary, got some focused periods here and there 👨‍💻 but the interruptions ❌ are killing me slowly. Handling them can take anywhere from 2 to 20 mins.

To be honest, this was a pretty typical day, similar to most other lockdown days. Not exaggerating at all, unfortunately. 😩

Repeat after me: This has nothing to do with working remotely!

▶️ 🚦 Sit down to work

👨‍💻 11 min of work

❌ 🤔 Wife: “So how are we planning lunch and shopping today?”

👨‍💻 38 min of work

❌ 💡 Wife: “I’ve had another idea for lunch and shopping”

👨‍💻 41 min of work

📆 A few scheduled meetings

⏸️ 🛒 Local market shopping

⏸️ 🛍️ Pick up take away food

⏸️ 🚗 Deliver shopping to in-laws

⏸️ 🍽️ Family lunch

👨‍💻 15 min of work

❌ 💻 Daughter: “Daddy, the online lessons’ screen is frozen, I can’t type!”

👨‍💻 45 min of work

❌ 🗣️ Daughter: “Daddy, Z. wants to talk to you” [a relative who’s a teacher and is helping my daughter on occasion]

👨‍💻 19 min of work

❌ 😭 Daughter: “DAD, my brother R. is accusing me of farting. WITHOUT EVIDENCE! And I didn’t do it!”

👨‍💻 2 min of work

❌ 😱 Son R: “MOM, DAD, my sister is chewing with her mouth open!!!”

👨‍💻 6 min of work

❌ 😢 Daughter: “DAD, my brothers don’t make room for me to stay in front of the laptop camera” [while zoom calling with their cousins]

👨‍💻 6 min of work

❌ 💻 Son R.: “Daddy, T. made the zoom window disappear and we can’t find it anymore”

👨‍💻 22 min of work

❌ ⚽️ Son R.: “Daddy, you promised yesterday to play football in the living room with us!”
Me: “Ok, let me just finish something here…”

👨‍💻 8 min of work

❌ ⚽️ Son T.: “Daddy, are you coming or not?!”

🥅 Me: “FINE. I’m the goalie!”

⏸️ 🍽️ Family dinner

⏸️ Herding children to get them ready for bed

👨‍💻 15 min of work

❌ 🗣️ Wife: “Are you putting the kids to bed?”
Me: “Finishing something here, can you do it please?”

👨‍💻 12 min of work

❌ 🗣️ Wife: “The kids are in bed”
Me: “Ok, coming soon”

👨‍💻 19 min of work

❌ 😱 Wife: “THE KIDS ARE IN BED!”
Me: “OK! FINE!!!” 🙄

⏸️ 🛌 Goodnight to kids

👨‍💻 5 min of work

❌ 💻 Wife: “Can you help me figure out something here with the computer!”
Me: “Ok, ok… Just a sec!”

👨‍💻 7 min of work

❌ 🗣️ Wife: “About that computer thing, never mind, I’ve sorted it”
Me: “Oh… hum… ok…”

👨‍💻 50 min of work

❌ 👁️ Wife: “Have you read that email from the kids teacher?”

👨‍💻 21 min of work

⏹️ 🫠 (enough for the day)

In 2018, the company I’m working in decided to rollout 1Password Business to all employees, which includes ​free family accounts​ for personal usage.

I had heard about 1Password before but thought of it as just one more password manager amongst many. For my needs, the default solutions bundled in browsers and operating systems were more than enough.

Last year I got the chance of using 1Password with a Team Vault for work (in a project for a client). It gave me the hands-on experience of how powerful the software is and the wide range of possibilities it gives, but I paid no more attention to it.

Fast forward to February 2019, when my two 10 year old twins brought home their new school assigned tablets. With them, along came the usual myriad of access credentials for school email accounts, digital books and resources, online classroom forums, etc.

Both their devices and access credentials came predefined with default rules for passwords, like ​[school process number][first name]​ (e.g. ​12345hugo​) — quite convenient for those setting up the devices, right?

Students’ full names and process numbers are posted in the school lobby for all to see at the beginning of the school year. It shows who was placed in that school and in which class.

This means that, if not changed, everyone knows everyone else’s passwords! 😱

Security wise, an appalling default practice.

As the twig is bent, so is the tree inclined

I’m a firm beliver that security cannot be an afterthought and it needs to be ​designed and built-in right from the start​.

“No way”, I thought as a parent. “They are going learn good security practices from the start…”

“So, what was this ‘1Password Family plan’ thing again? 🤔”

A few hours spent on a weekend exploring it and not very long after I had each one of them setup with:

1. Their own vault on their tablets with auto-generated credentials for all the school services
2. Another shared vault with the family stuff (e.g. home wifi password)
3. A chosen strong and long master password made up of words of “things they like” (inspired by ​xkcd: Password Strength​)

That same week, arriving from school, one of my kids asked:

— “How can we setup and install this vaults thing?”
— “Why do you want to know?”
— “To tell my friends. They saw me using it and also want it, but their parents don’t know how to do it” 😁

Planting a seed and leading by example, two of the most effective ways of driving change, displayed here in practice in the real world.

(So, anyone know a simple ​“1Password: Getting Started Guide for Kids”​ that I can translate to Portuguese and have them send their friends?) 😉

Update 2016-08-13: No dia da pesquisa no site da ASF muitas das matrículas estavam a responder como “não encontrado”. Hoje essas mesmas matrículas já respondem com informação de seguros pelo que em breve irei actualizar esta informação com esses novos dados.

Existem uma série de questões difíceis de responder sobre o incêndio no Andanças, dada a dimensão e falta de informação sobre o mesmo:

• Quantas seguradoras estão envolvidas?
• Quantos veículos sinistrados estão afectos a cada seguradora?
• Quem são as outras pessoas na minha seguradora?

Responder a este tipo de questões tem sido uma das muitas dificuldades do grupo de pessoas prejudicadas pelo incêndio do Andanças (no qual, infelizmente, eu me incluo).

Juntando a informação publicada pela GNR no espaço do evento (gentilmente fotografada pelo Lucas Apitz) com os dados do seguro associado a uma matricula disponibilizados pela ASF (e uns pózinhos de programação à mistura) consegui ter a noção das várias seguradoras implicadas no incidente e quantos veículos têm segurados.

Como à data de publicação ainda não tinha recebido resposta da GNR nem encontrado online nenhuma listagem dos veículos em formato digital, podem existir alguns erros na transcrição das matrículas mas que não devem alterar muito os resultados.

Todos os dados estão disponíveis nesta Google Sheet: a lista das matrículas dos veículos afectados e a correspondente informação de seguros.

Seguradoras

Com 22 23 seguradoras envolvidas neste incidente, qualquer esforço de coordenação torna-se muito mais complicado, seja entre as próprias seguradoras, seja entre as pessoas sinistradas.

No entanto uma seguradora, a Liberty Seguros, destaca-se de todas pela sua atitude solidária de “assumir a reparação dos danos dos seus clientes mesmo que estes apenas tenham contratado apólices de responsabilidade civil contra danos a terceiros”.

Confesso que à primeira vista pensei que se tratasse de apenas mais uma manobra de marketing, com apenas uma mão cheia de veículos afetos a essa seguradora, mas olhando para a tabela abaixo percebe-se que outras seguradoras teriam também condições para oferecer essa benesse.

Nota: OK Teleseguros aparece como Via Directa
Nota: Seguro Directo aparece como Ageas

Países

Isto não foi só um problema português. Embora dada a dimensão do incidente os veículos estrangeiros estejam em menor número, é de realçar que cerca de 10% dos veículos não têm matrícula portuguesa, sendo na sua grande maioria espanhóis.

Se em Portugal já têm ocorrido vários problemas de coordenação entre as entidades responsáveis, seguradoras e sinistrados, e tendo em conta ainda a barreira da língua, decerto que para estas pessoas o passeio de férias a Portugal revelou-se um autêntico pesadelo. 🙁

Sketch — pen & paper rough drawings

• Quick brainstorm of ideias
• Easy communication of purpose

Wireframe — black & grey representation

• Use: quick communication of interactions
• Documenting the interface;

Mockup — static coloured visualisation

• Gather rough feedback and buy-in from stakeholders

Prototype — real interactive implementation

• User testing in a scenario close to reality
• Possibly reusable into the product

See also,

• Why It’s Important to Sketch Before You Wireframe
• Wireframing, Prototyping, Mockuping - What’s the Difference?
• Wireframe vs Mockup vs Prototype - What’s the Difference?