Think before you GIF

Animated GIF images are an inescapable part of our online experiences, and more and more tools make it easier and easier to include them in our written communication. Sometimes this can be a good thing.

Sometimes. Not all times.

Before you include a GIF image – especially one that flashes or blinks or strobes – in your next chat message, please pause to consider the impact that this may have on the recipients.

burnout-3721062_640

Before you include a GIF, ask yourself:

  • How many people will see this – is this a 1:1 chat, or is it a large group?
  • Does the GIF include flashing, strobing, blinking, fast-moving images?
  • Do any of the people who will see the GIF have photosensitive conditions like seizures or migraines?
  • Are you sure?
  • Does the software tool you’re using allow users to disable GIF autoplay?

I include this last point because Microsoft Teams does not provide any option to disable GIF autoplay. Seriously – even tough the UserVoice forum for Teams says that this was done in 2017, the Teams UX today does not provide any option for users to prevent GIFs from playing for them.

So if you are on a Teams meeting with 100 people and you post a GIF, everyone sees it. And odds are, that GIF you posted will mean that someone on the call will need to leave the call, or close the chat, or maybe end up in a dark room in pain for the rest of the day.

So please think before you GIF.

Lazy communication is theft

If you follow me on Twitter[1], you have likely seen me post something like this:

You’ve probably seen it more than once. But you’ve only seen it an order of magnitude less than I’ve thought it, because if I posted it multiple times each day I would be part of the problem. Typically when I tweet a variation on this theme, it’s because someone has been lazy, and has stolen my time, and the time of others.

Consider these scenarios.

Have you ever forwarded a lengthy email thread to a group, with “FYI” or “this is interesting” as your only addition, without adding a summary of the thread? If you have, then each person who receives your mail needs to read through the thread to understand what is important for them.

Have you ever sent an email with a meaningless and non-descriptive subject line that’s unrelated to the message content? If you have, then each person who receives your mail needs to read through the message to understand your intent and to prioritize any follow-up actions.

Have you ever sent an email that includes a document or link to a valuable resource, but you don’t include any relevant search terms in the subject or body? If you have, then when your recipients need to find and use that link or document they will not be able to easily search to locate it. You’ve forced each recipient to implement their own discovery process.

Have you ever sent an email that references a shared resource like a web site or an Excel workbook on a SharePoint site, and didn’t include a link to that resource? If you have, then each recipient has needed to manually locate the shared resource – you have wasted the time of every person who received the mail. And to make matters worse, your laziness has introduced ambiguity, and increased the likelihood that people will end up using the wrong resources.

Have you ever sent an email that includes a general description of a specific problem for which you are requesting assistance? If you have, then you are offloading the responsibility for identifying the problem cause to the recipients – and this often means that multiple people are duplicating the effort that you should have put in proactively.

Have you ever sent an email that includes an acronym that you have not explicitly defined? If you have, then you’re again forcing the recipients to do the heavy lifting to figure out what you mean, when you could have saved them this effort by putting in a little effort on your own…

Have you ever sent an email related to an event – a technical conference “call for content” announcement, for example – and you haven’t bothered to include the event dates in the mail? If you have, then you have forced every recipient to look up this information before they can act on your mail.

Have you ever asked someone for help solving a technical problem or error, but you haven’t clearly articulated the scope of the problem? Maybe you couldn’t even be bothered to include key details like error messages? If this is the case, you’ve very clearly told the people who could be helping you that you do not value their time, and that you are choosing to make your problem their problem.

Of course, the impact of this laziness isn’t limited to email – email just happens to be where I personally experience it the most. My most recent[2] periodic reminder came when someone on Twitter asked for help, and included an undefined acronym. By the time I noticed the conversation, three or four members of the Power BI team had replied, either asking for clarification or proposing possible answers if the acronym meant what they thought it meant. (I did not join that conversation.)

The common theme of these scenarios – and many more like them – is that a small effort to be mindful in your communication can help reduce the cost on the people with whom you are communicating. If you choose not to put in that effort, your lazy communication is stealing time and productivity from your teammates, peers, and colleagues.

Is that what you want?[3]

Each of these bad habits is easily and simply corrected. In most situations it only takes a moment to clarify the meaning and context of your message, to add a subject, or summary, or link. A moment of your time can save many minutes wasted by every person who receives your communication.

Will you choose to spend that time, and to respect the time of others?

Or will you steal their time?


[1] I wouldn’t recommend it.

[2] Most recent when I started writing this post, anyway. That was back in early November. It’s taken me so long to finish and publish this post because people keep stealing my time.

[3] If it is, please don’t tell me.

Common sense solutions to simple problems

Have you ever looked at a problem and immediately known how to solve it?

Have you ever seen that there’s already a group of people who are responsible for solving this problem this problem, and although they’re working on a fix they obviously have not seen the common sense solution that is so apparent to you?

ford-498244_640
I knew we could park here! Problem solved!

Yeah[1].

In situations like these, there are three[2] potential reasons for what you’re seeing:

  1. The other people are just too stupid to to see the simple and obvious solution that’s been sitting right under their noses all this time.
  2. The other people, due to the time that they have spent closely examining the problem and potential solutions, have realized that the simple and obvious solution doesn’t actually address the problem – even though common sense suggests that it should – or that the solution has unintended side-effects that outweigh its benefits.
  3. The other people are responsible for additional problems and solutions across a broader or more strategic scope, and although the simple solution may make sense in isolation, implementing it has been deferred to enable work on other, higher priority problems.

(At this point I feel compelled to point out that this is something I’ve thought about for decades, and I’ve had a draft blog post on this subject for almost a year. I’m not trying to subtweet[3] anyone. I’ve had several people recently reach out to me to make sure that they’re not the reason I tweet periodic reminders that lazy communication is theft, so a disclaimer here feels appropriate.)

In my experience, many people seem to automatically gravitate to the first choice, and that bias seems exacerbated by differences in perspective. If the observer is in a business group and the solution team is in IT – or vice versa[4] – it’s easy for them to miss the complexity and nuance in something that appears simple and straightforward from the outside.

Part of this challenge is inherent in this type of relationship. It’s natural and appropriate to hide internal complexity from external stakeholders. I’m pretty sure I even learned about this in college… not that I remember college[5].

But part of it is the choice we make when we engage in the cross-team relationship. Every time we see a “simple problem” with an “obvious” or “easy” or “common sense” solution we get to decide how to react. We can assume that we know everything important and that the “other guy” is an idiot… or we can consider the option that there might be something we don’t already know.

The choice is ours.


[1] This is less of an actual footnote than a tool to enforce a dramatic pause as you read. Assuming you read footnotes as you go through the post, rather than reading them all at the end. I may need more telemetry to better understand use behavior. Why aren’t any simple problems actually as simple as they first seem?

[2] If you can think of other reasons that aren’t just variations on these three, I would love to hear about them in the comments. My list used to only include the first two reasons, but over the last few years I’ve added the third.

[3] Sub-blog? is that a thing?

[4] There are scores of other variations on this theme – I picked this one because it’s likely to be familiar to the people I imagine read my blog.

[5] Maybe this?

Tough love in the data culture

When I shared on Twitter the most recent installment in the BI Polar “data culture” series, BI developer Chuy Varela replied to agree with some key points from the video on executive sponsorship… and to share some of his frustrations as well[1].

2020-01-13-08-46-03-439--msedge

Chuy’s comments made me think of advice that I received a few years back from my manager at the time. She told me:

Letting others fail is a Principal-level behavior.

Before I tie this tough love into the context of a data culture and executive sponsorship, I’d like to share the context in which the advice was given.

At the time I had just finished a few 80-hour work weeks, including working 12+ hour days through a long holiday weekend. Much of that time was spent performing tasks that weren’t my responsibility – another member of the extended team was dropping the ball, and with a big customer-facing milestone coming up I wanted to make everything as close to perfect as possible.

Once the milestone had been met, my manager pulled me aside and let me know how unhappy she was that I had been making myself ill to deliver on someone else’s commitments[4]. She went on to elaborate that because of my well-intentioned extra effort, there were two negative consequences:

  1. The extended team member would not learn from the experience, so future teams were more likely to have the same challenges.
  2. The executive sponsors for the current effort would believe that the current level of funding and support was enough to produce the high quality and timely deliverables that actually required extra and unsustainable work.

She was right, of course, I’ve added two phrases to my professional vocabulary because of her advice.

The first phrase[5] gets used when someone is asking me to do work:

That sounds very important, and I hope you find the right folks to get it done. It sounds too important for me to take on, because I don’t have the bandwidth to do it right, and it needs to be done right.

The second phrase gets used when I need to stop working on something:

After this transition I will no longer be performing this work. If the work is still important to you, we’ll need to identify and train someone to replace me. If the work is no longer important, no action is required and the work will no longer be done.

Now let’s think about data culture and executive sponsorship in a bottom-up organization. How does a sponsor – or potential sponsor – react when a BI developer or analyst is delivering amazing insights when it’s not really their job?

If the sponsor is bought in to the value of a data culture, their reaction is like to include making it their job, and ensuring that the analyst gets the support and resources to make this happen. This can take many different forms[6], but should always include an explicit recognition of the work and the value it delivers.

And what if the analyst who has enabled more data-driven decisions is ready to move on to new challenges? What happens to the solutions they’ve built and the processes that rely on their work? What then?

Again, if the sponsor is committed to a data culture, then their reaction will involve making sure that it becomes someone’s responsibility to move the analyst’s work forward. They will assign the necessary resources – data resources, human resources, financial resources – to ensure that the data-driven insights continue.

If you’re working on helping to build a data culture from the bottom up, there are a few opportunities to apply this advice to that end. Please understand that there is risk involved in some of these approaches, so be certain to take the full context into consideration before taking action.

  1. Work with your immediate manager(s) to amplify awareness of your efforts. If your managers believe in the work that you’re doing, they should be willing to help increase visibility.
  2. Ensure that everyone understands that your work needs support to be sustained. You’ve done something because it was the right thing to do, but for you to keep doing it, but you can’t keep doing it with all of your other responsibilities.
  3. When it comes time to change roles, ask who will be taking over the solutions you’ve built in your current role, and how you can transition responsibility to them.

Each of these potential actions is the first step down a more complicated path, and the organization’s response[7] will tell you a lot about the current state of the data culture.

For the first potential course of action, managerial support in communicating the value and impact of current efforts can demonstrate the art of the possible[8] to a potential executive sponsor who may not be fully engaged. If you can do this for your current team or department, imagine what a few more empowered folks could do for the business unit! You see where I’m going…

If this first course of action is the carrot, the other two might be the stick. Not everyone will respond the way we might like to our efforts. If you’re building these solutions today without any additional funding or support, why would I give you more resources? Right? In these cases, the withdrawal or removal of existing capabilities may be what’s necessary to communicate the value of work that’s already been completed.

Wow, this post ended up being much longer than planned. I’ll stop now. Please let me know what you think!


[1] I don’t actually believe in New Years resolutions, but I am now retroactively adding “start a blog post with a sentence that contains six[2] or more hyperlinks to my goals for 2020[3].

[2] Yes, I had to go back to count them.

[3] Nested footnotes achievement unlocked!

[4] If your reaction at this point is “what sort of manager would yell at you for doing extra work?” the answer is “an awesome manager.” This may have been the best advice I ever received.

[5] I’ve probably never said either phrase exactly like this, but the sentiment is there.

[6] Including promotion, transfer to a new role, and/or adding capacity to the analyst’s team so the analyst can focus more on the new BI work.

[7] Remember that a culture is what people do, not what people say – have I mentioned that before?

[8] The art of the possible is likely to warrant its own post and video before too long, so I won’t go into too much depth here.

Never stop asking “stupid” questions

When I joined Microsoft, the team running my NEO[1] session shared a piece of advice with my “class” of fresh-faced new hires:

“Think of your first year as a grace period where you can ask any question you want, without anyone thinking it’s a stupid question for which you should already know the answer.”

This sounded like empowering wisdom at the time, but the unspoken side of it was damaging. Between the lines, I heard this message as well, and it was this part that stuck with me:

“You’ve got one year to figure things out, and after that you’d better have your act together and know everything – because if you keep asking stupid questions we’ll know that we made a mistake hiring you.”

I hope it’s obvious that this wasn’t the intent of the advice, but I’ve spoken to enough people over the years to know that I’m far from the only one to take it this way.

bored-3126445_640
How Matthew pictures everyone reacting when he asks questions.

In retrospect, I believe that I should have known better, but I let this unspoken message find a home in my brain, and I listened to it. I remained quiet – and remained ignorant – when I should have been asking questions.

Over the past few years[2], I have finally broken this self-limiting habit. Day after day, and meeting after meeting, I’m the guy asking the questions that others are thinking, and wishing they could ask, but don’t feel comfortable or confident enough to speak up. I’m the guy asking “why” again and again until I actually understand. And people are noticing.

How do I know that others want to ask the same questions?

I know because they tell me. Sometimes they say thank you in the meetings, and sometimes ask their own follow-up questions. Sometimes they stop me in the hall after the meeting to say thank you. And on a few occasions people have set up 1:1 meetings with me to ask about what I do, and how they can learn to do the same.

How do I know that people are noticing?

A few of the people I’ve interrupted to ask “why” have also set up time with me to discuss how they can better communicate and prepare to have more useful and productive meetings.[3] These are generally more experienced team members who appreciate that my questions are highlighting unstated assumptions, or helped them identify areas where they needed a clearer story to communicate complex topics.

I’ve been with Microsoft since October 2008 – a little over 11 years. I’ve been working in the industry since the mid 90s. At this point in my career it’s easy for me to ask “stupid” questions because the people I work with know that I’m not stupid.[4][5]

This isn’t true for everyone. If you’re younger, new to role or new to career, or from an underrepresented group[6], you may not have the position of relative safety that I have today. My simple strategy of “asking lots of questions in large groups” may not work for you, and I don’t have tested advice for what will.

My suggestion is to ask those questions in small groups or 1:1 situations where the risk is likely to be lower, and use this experience to better understand your team culture… but I would love to hear your experience and advice no matter what you do. Just as your questions will be different from mine while still being useful, your experience and advice will be different, and will be useful and helpful in different ways.

Whatever approach you take, don’t be quiet. Don’t stop asking questions.

Especially the stupid questions.

Those are the best ones.

 

P.S. While this post has been scheduled and waiting to go live, there have been two new articles that showed up on my radar that feel very relevant to this topic:

  1. The Harvard Business Review posted on Cracking the Code of Sustained Collaboration and how leaders can build and encourage cultures where these behaviors are rewarded.
  2. Ex-Microsoftie James Whittaker posted on Speaking Truth to Power, which presents critical observations of three eras of Microsoft, with examples of how different generations of leaders have affected the corporate culture.

These are very different articles, but they’re both fascinating, and well worth the time to read.


[1] New Employee Orientation. Sadly not anything to do with Keanu Reeves.

[2] I wish I could say that this was a deliberate strategic move on my part, but it was more reactive. Credit goes to the rapid pace of change and my inability to even pretend I could keep up.

[3] Yes, that means meetings where fewer people interrupt to ask “why.”

[4] I’m waiting for the flood of snarky comments from my teammates on this one…

[5] Or in any event, my asking questions is unlikely to change any minds on this particular point.

[6] If you’re not a middle-aged, white, cisgender man…

Writing effective problem reports

If you build software or data solutions[1] you have probably encountered one or both of these situations:

  1. You’re trying to report a bug, but the developer doesn’t believe that there’s a problem.
  2. Someone is trying to report a bug to you, and you can’t tell what the problem is supposed to be.

The problem report has itself become a problem[2].

Fortunately, there’s a simple approach, and simple template, that can make reporting problems easier. This is the template I typically use when I’m reporting a problem and asking someone else to fix it:

Problem: Concise description of problem behavior

Steps to reproduce problem:

  1. First step
  2. Second step
  3. Third and subsequent steps, as necessary

Desired or expected behavior:

4. What I wanted to happen

Observed behavior:

4. What actually happened, including the full details of any error messages

That’s it – simple and easy.

It can also often be helpful to include screen shots, recordings, or other visual resources to supplement the text descriptions. If you use TechSmith Camtasia (commercial, paid) or ShareX (open source, free) or other screen recording software, it can be trivial to record and attach a video – but remember that the video does not replace the written problem report, it supplements it.

I should mention that if you’re a software developer working on a software development team, you probably have a heavier-weight process already[3]. Follow that process. This approach is intended for more casual problem reporting – the sort of thing that you might send to someone in an email asking for help. The sort of email where if you don’t communicate clearly and effectively, the recipient ends up spending more time asking for information than he spends actually answering the question or solving the problem.

Yes, this is why I wrote this post. I hope I never need to link to it…


[1] Or work in a technical field, or use software…

[2] Because I never metaproblem I didn’t like. Yes, this sounded funnier in my head.

[3] If you search for “how to write good bugs” you’ll find a huge number of excellent resources that go into much more depth than this post.

Managing email and work-life balance

I’ll probably never be the most consistent blogger, but WordPress recently made me aware of something: I only blog regularly when I’m taking time off from work.

Streak

I’m back in the office today after a week of part-time work from home[1] and I realized that without making a conscious to do so I ended up blogging every day that I was away from the office.

This insight got me thinking. Specifically, it got me thinking about how I spend my work days, and about how in recent months[2] I’ve been letting my inbox push me around. Although playing a defensive game can work in some contexts[3], I believe I need to adopt a more aggressive posture in this fight.

Starting today I’m trying this approach to Inbox Zero from MVP Luise Freese. I’m hoping that by managing my email more proactively and strategically I can not only be more productive at work, but also have more mental energy and time remaining for blogging.

My teammate Adam Saxton is doing the same thing; he’s a few days ahead of me and is pleased with his progress so far. I’ll check in with him – and with you – next week to see how things are going. Now back to Outlook; I have more items marked for follow-up today…


[1] Part time work from home and full-time feeling old: My older son graduated from high school last week. Where did the years go?

[2] Years.

[3] Please don’t tell Johannes Liechtenauer I said this.