DEV Community: Data Unbound

How I Killed Bad Meetings

Data Unbound — Mon, 06 Jul 2020 09:21:48 +0000

10 tips for making meetings better

I realized we had a major problem. A colleague, distraught, pulled me aside. She’d had a bad meeting — one of the ones where your soul ebbs away while the clock laughs at you. I’d heard it all before, that day, from four other people. The worst part?

They weren’t the same meeting. It wasn’t just one soul-crusher; it was a culture of bad meetings. The chief complaint?

These meetings were a waste of everyone’s time.

It was just before Christmas. So I purchased six books on meetings and read them cover to cover. Of the six, I’d recommend two: Meeting Design and Kill Bad Meetings.

When the new year started, we did things differently.

Tip #1: Don’t Have a Meeting

We’ve all heard the complaint about the meeting that could have been an email. You see, meetings are a powerful tool to solve complex problems, but they’re expensive. They eat man-hours. Emails, however, are comparably cheap — written at a time convenient to the writer, read at a time convenient to the reader.

Meetings should never be the default.

So when do you need a meeting? Only when you need “ spaghetti ”.

Photo by DeMorris Byrd on Unsplash

We call work that requires synchronous communication, discussion, co-creation, and active participation “spaghetti” because people must work in a highly interconnected way to achieve a collaborative goal.

— Kevan Hall and Alan Hall, Kill Bad Meetings

The book, Kill Bad Meetings, goes on to specify some typical examples of spaghetti interactions:

Discussions to make a decision
Multidisciplinary problem-solving
Co-creating new ideas and proposals live in the meeting
Solving common problems
Learning common skills

That doesn’t mean everything else is an email. But if you can map the interactions clearly , you don’t need a meeting. That may not be obvious. So let’s look at two common meeting anti-patterns.

The Broadcast

The meeting organizer has called you all together. He disseminates information for an hour. You’re only here to listen.

Photo by Alexandre Pellaes on Unsplash

Why? Perhaps he just loves the sound of his voice or worries that if he sends an email, you won’t read it. And you probably won’t. At least you won’t if you fail to understand why the information is important. But right behind complaints of too many are complaints of too many emails.

We live in the information age. To not drown in the flood of information, we filter it out. As a survivor, you’d filter out this would-be email. Either way, you’re not listening unless the speaker is particularly entertaining or addressing your immediate concerns.

Just as you are accountable for listening and reading, the speaker or writer must be discerning in what he sends out. If all output from a given channel is relevant and terse, you listen.

Broadcasts aren’t always bad. Sometimes you should gather people to celebrate good news. Equally, some particularly thorny issues are best discussed to the group face-to-face.

But if the information invokes little-to-no emotion, send an email.

The Check-in

Communication flows from many to one in the more demeaning “check-in”. The organizer, usually the boss, summons his underlings to give him information.

Be better. Turn a regular check-in meeting into a regular email. Alternatively, schedule a 1–1 meeting with each of the reporters. Let’s look at the math.

Suppose you have 1 manager with 6 reporters:

1 X 60-minute meeting, 1 manager and 6 reporters →7 person-hours

6 X 10-minute meetings, 1 manager and 6 reporters → 2 person-hours

It’s the same amount of the manger’s time but saves 5 hours of everyone else’s time.That’s why these meetings feel so bad — they imply, “my time matters, but not yours”.

Disclaimer. 10 minutes won’t always be enough time. If an issue demands more time, request it, or deal with it separately. Also, some information will be useful to everyone. Distribute it later in an email.

Tip #2: Have a Shorter Meeting

But what if there is some spaghetti in the meeting? Cut the non-spaghetti elements out of a meeting and move them into an email, or some other form of asynchronous communication. This might occur before, or after, the meeting as a preparation (e.g. read and know this, come with your best three ideas, or fill out this survey).

Photo by Icons8 Team on Unsplash

A clever meeting design can achieve this within the meeting for a fraction of the time. Take our previous “check-in” example, suppose there was spaghetti, and the information reported is of interest to the group.

Try this:

Call a 20-minute meeting.
Have each reporter write down each headline on separate index cards (or Trello cards for remote meetings). That’s one headline per card. Explain that they have only 10 minutes.
Collect the cards as they are completed. Curate them as you go, organizing them into themes and filtering out anything private or unconstructive.
At the end of that 10 minutes, invite a brief discussion of the most interesting ones.

Looking at the math :

1 x 20-minute meeting, 1 manager and 6 reporters →1.66 person-hours

That’s a third of the original meeting and arguably better than an email. How so? Imagine the resulting email chain and the time that would go into it. An honest, open 20-minute meeting saves potentially hours of crafting gaurded, diplomatic emails.

Tip #3: Have Fewer People in a Meeting

To save person-hours can cut hours or people. Culturally, this can be challenging.

The first cultural pitfall is meeting invitations or participation being seen as conferring honor and not inviting someone or “asking them NOT to come” as a slight. Let’s flip on its head.

Asking someone to come to a meeting when they don’t need to be there is a slight. It says, “I don’t value your time”. Instead, be thoughtful and ask, “Is this really the best way they could be spending their time?”

Besides, a meeting can only have so many active participants. Otherwise, it’s more like a dinner party. Perhaps that chaotic meeting (that should have been an email) should have been a dinner party? Regardless, if people aren’t active, they’re not part of the spaghetti. We need to minimize this.

Ask which invitees provide only marginal value. If you have one or two people from a team in the meeting, you probably get 80% of the value of having the whole team at a fraction of the cost. Afterward, these ambassadors will convey pertinent information to their team better than the meeting would have.

As a rule of thumb, I limit the meetings to 8 people (maybe 10 at a stretch) or break them up into groups for activities. Consider this a design constraint and use these tips. Keep in mind, your meeting goals in mind and consider how each person adds something unique to the discussion/activities.

Tip #4: Have an Explicit Goal

I keep using the word “design”, but what does that mean? Design means making deliberate choices and planning to some end, or goal.

Ever been in a meeting and wonder what the purpose of it is? If there was one, do you think you achieved it? Was it a valuable use of your time? Of course not! By stating a goal upfront, you get everyone on the same page and foster participation.

Tip #5: Produce Something

If you have a goal, how will you know if you achieved it? You should produce something.

Perhaps the goal is to make an informed decision. Well, then you should produce that decision — and the reasoning behind it. Write. It. Down. That sounds elementary, but not writing down decisions is commonplace in a bad meeting culture. In such places, colleagues often disagree on what choices were made — making it difficult to proceed as a team.

Perhaps the goal is to generate ideas, a brainstorm. Great, you should produce a list of ideas. You will need to curate them in some way. I like distributing stickers to allow attendees to vote for the ideas they feel would be most impactful or achievable.

Tip #6: Have an Agenda

And broadcast it beforehand. By agenda, I mean some written plan for the meeting. A good agenda explains how everyone’s time will achieve explicit goals. Knowing what is to be produced, why, and roughly how allows attendees to better prepare for the task.

Also, sending the agenda well in advance allows invitees to make a more informed decision regarding attendance. Perhaps they can think of someone else better-suited to attend. Ever attended a meeting that fell apart because the expert was, in fact, the wrong person?

Getting your team more involved in this self-selection improves meeting quality. However, the best results require they feel comfortable declining or suggesting a substitution.

Tip #7: Appoint a Facilitator

In a good meeting, goals are met, everyone fulfills their role, everyone has a voice, and the interpersonal dynamics are healthy. A facilitator owns these meta-goals rather than participating directly in the meeting.

A meeting facilitator:

Shepherds the participants back to the agenda, when needed
Entreats the timid, but utterly pregnant with thought, to speak up
Dissuades the more vocal participants from bloviating
Limits unconstructive comments or behaviors

It’s not uncommon for the organizer to facilitate, but the facilitator should be someone impartial. More practically, it may be difficult to manage both roles all the time. Consider delegating this as an “introductory leadership opportunity”.

Tip #8: Appoint a Scribe

Many of these tips require that you send information about the meeting to interested parties afterward. Who writes it all down? Consider appointing a scribe.

As the organizer, by default, this is you. Why not unburden yourself to better run the meeting? I often do this simply because some colleagues take much better notes.

But be warned, many people don’t like scribing or find it hard to take notes and be part of the discussion. While some like being the influence of putting what happened into words; others see it as demeaning. Don’t press anyone into scribing; invite volunteers. Take turns.

Tip #9: Follow Up

Send out those notes. I generally commit everything to the company wiki and send an email with a link.

I also take the opportunity to:

Thank everyone for their hard work
Elicit feedback. What went well? What could we do better?
Show attendees what they produced
Celebrate the achievement of our goal

You should be able to prove that it was time well spent.

Also, once people see that you regularly follow up, they’ll be more comfortable with not attending.

Tip #10: Train People

Lastly, if I have to sit through an hour fire safety training — preparing for a disaster that never happens, then it’s worth spending an hour training for a disaster that happens several times a day. Train people to organize better meetings. Train people to be better attendees.

The post How I Killed Bad Meetings appeared first on Data Unbound.

Terraform in Anger Part 1: AWS S3 Access

Data Unbound — Tue, 05 May 2020 11:11:11 +0000

Terraform allows you to set up infrastructure across a wide variety of vendors and platforms. I love it because it’s declarative—meaning you just say what it is your want and Terraform figures out how to get there. There are many good introductions to Terraform out there, but they lack that real-word-project feel. What’s it like to use Terraform in anger? I want to explore that with a real project example built from the ground up.

To that end, one need I frequently come across in my freelance data science work is secure data transfer. Often clients need to send sensitive, possibly medical or top-secret, data. In this series, we’ll deliver a really slick experience for three different types of users on AWS. With the first being secure upload to S3 via the AWS CLI. Later installments will look at giving the client’s Business and IT users access via AWS Console (browser) and SFTP, respectively.

Defining The Problem

Clearly we can’t just create a public bucket because this data is sensitive. Equally, we can’t give the client access to our entire platform. Though challenging, locking the client down to a secure bucket without access to anything else is the only feasible option for a real project. And we’ll need to do this while delivering pleasant user experience.

Although we should create our own browser portal for data transfer, it's a lot of work. It would be fine for me to invest that time for my own business, but I’d think it negligent charging a client for something so bespoke unless core to their business. I am about delivering value for money, not building cathedrals.

Download The Complete Series Example Code

The Plan

First, we’ll create a bucket that doesn’t expose any client information
Then we’ll create a user for the client that has access to the AWS via an Access key
After that, we need to define a policy that limits a user to only accessing S3 and only that bucket
And finally, we’ll associate that policy to the user

Now, this is still a toy example because, on a real project, you would probably need to support several clients—each with many users. We’ll address that in part II of this tutorial, but keep it simple for now. Later we can refactor using some more advanced features of Terraform to enable multiple users. This may seem forced, but I always recommend programming iteratively: starting with something simple that works and building out the functionality through refactoring.

Installing Terraform

Being written in Go, Terraform, consequently, installs easily. Simply fetch it from downloads (for your system), unzip it, and move it to a directory included in your system’s PATH. Finally, check the version you’re are using. Here’s mine for reference.

dataunbound$ terraform --versionTerraform v0.12.24

From here on, I’m assuming you have an AWS account, an access key, and awscli working on your machine. So if you haven’t done that, you should do it now.

Terraform HELLO WORLD

To kick things off, we’ll define AWS as a provider and nothing more.

This block states that we’ll be using AWS and want eu-west-2 to be our default region; provider is a keyword. Nothing could be simpler.

Now let’s “apply”. What could go wrong?!

dataunbound$ terraform apply

Error: Could not satisfy plugin requirements


Plugin reinitialization required. Please run "terraform init".

Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can\'t be located,
don\'t satisfy the version constraints, or are otherwise incompatible.

Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints from each module, run "terraform providers".

Error: provider.aws: no suitable version installed
  version requirements: "(any version)"
  versions installed: none

Fantastic! An asinine message that contains its own solution—i.e. initialize the project with terraform init first.

Luckily, I use thefuck and so should you. It corrects simple mistakes from the previous console command—unnecessary, but fun. Have a look:

dataunbound$ fuck
terraform init && terraform apply [enter/↑/↓/ctrl+c]

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.60.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 2.60"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

So what happened here? Well, first thefuck ran terraform init and discovered we’re using AWS as a provider. Consequently, it installed the necessary dependencies (to our local Terraform). Then terraform apply looked for what need to be done and found nothing, hence:

**Resources: 0 added, 0 changed, 0 destroyed**

That’s because we have declared any resources. Let’s change that by declaring a bucket for our client’s data.

Creating a Secure Bucket in S3

This is our first resource, aws_s3_bucket, and we named it test_client_bucket. When we apply, Terraform creates a private s3 bucket name “test-client-bucket-x130099”.

dataunbound$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_s3_bucket.test_client_bucket will be created
  + resource "aws_s3_bucket" "test_client_bucket" {
      + acceleration_status         = (known after apply)
      + acl                         = "private"
      + arn                         = (known after apply)
      + bucket                      = "test-client-bucket-x130099"
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + region                      = "eu-west-2"
      + request_payer               = (known after apply)
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + versioning {
          + enabled    = (known after apply)
          + mfa_delete = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

This first bit above is the plan. Notice that there are several attributes marked as (known after apply). We’ll discuss this in a minute.

But first, we should ensure everything in this bucket is encrypted server-side. We’ll use AES256 like so:

If you apply now, you’ll see that Terraform only changes the existing bucket rather than destroying and recreating it.

**Plan:** 0 to add, 1 to change, 0 to destroy.

But this won’t always be the case. When unsure, use terraform plan to see a dry run.

As an admin, you can explore this new bucket. When your done, we’ll create a user whose sole ability is to view this bucket and administer its contents.

Creating a Restricted S3 bucket User

We need to create a user and, moreover, restrict their knowledge and control to this bucket. There are many ways to do this; but for now, we’ll use an aws_aim_user and an aws_iam_user_policy with a separate aws_iam_policy_document.

The User

Nothing complex here—just a name, Alice.

But to access AWS via the cli, the user will need an access key.

Now we finally encounter something interesting. By aws_iam_user.test_client.name, we are asking for the value of the name attribute on whatever gets created by the resource "aws_iam_access_key" "test_client" block. It's invaluable to note that the Terraform documentation (which I’ve been linking to as we go along) lists the attributes for each resource.

dataunbound$ terraform apply
aws_s3_bucket.test_client_bucket: Refreshing state... [id=test-client-bucket-x130099]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_iam_access_key.test_client will be created
  + resource "aws_iam_access_key" "test_client" {
      + encrypted_secret     = (known after apply)
      + id                   = (known after apply)
      + key_fingerprint      = (known after apply)
      + secret               = (sensitive value)
      + ses_smtp_password    = (sensitive value)
      + ses_smtp_password_v4 = (sensitive value)
      + status               = (known after apply)
      + user                 = "alice"
    }

  # aws_iam_user.test_client will be created
  + resource "aws_iam_user" "test_client" {
      + arn           = (known after apply)
      + force_destroy = false
      + id            = (known after apply)
      + name          = "alice"
      + path          = "/"
      + unique_id     = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_iam_user.test_client: Creating...
aws_iam_user.test_client: Creation complete after 1s [id=alice]
aws_iam_access_key.test_client: Creating...
aws_iam_access_key.test_client: Creation complete after 1s [id=AKIA6MFJDG3VVFMKP4EF]

Even cooler, when Terraform sees this reference, it will flag it as a dependency. When we run apply, resources will be created in the required order, and in parallel where possible. Here Terraform figured out it was just a literal which is why "alice" was included in the plan for the access key.

So we could have used the literal "alice" ourselves, but then we would be repeating ourselves—which is never good. But professional standards aside, you don’t always know the value of the property before it is created. Remember all the attributes in the output labeled (known after apply)? Imagine, for instance, we needed the ARN rather than the name.

What are the ARNS for the resources we’ve made anyway? Well, after apply, you can see all current values with terraform show.

dataunbound$ terraform  show
# aws_iam_access_key.test_client:
resource "aws_iam_access_key" "test_client" {
    id                   = "AKIA6MFJDG3VVFMKP4EF"
    secret               = (sensitive value)
    ses_smtp_password    = (sensitive value)
    ses_smtp_password_v4 = (sensitive value)
    status               = "Active"
    user                 = "alice"
}

# aws_iam_user.test_client:
resource "aws_iam_user" "test_client" {
    arn           = "arn:aws:iam::988197107435:user/alice"
    force_destroy = false
    id            = "alice"
    name          = "alice"
    path          = "/"
    unique_id     = "AIDA6MFJDG3VRPQBSAB4R"
}

# aws_s3_bucket.test_client_bucket:
resource "aws_s3_bucket" "test_client_bucket" {
    acl                         = "private"
    arn                         = "arn:aws:s3:::test-client-bucket-x130099"
    bucket                      = "test-client-bucket-x130099"
    bucket_domain_name          = "test-client-bucket-x130099.s3.amazonaws.com"
    bucket_regional_domain_name = "test-client-bucket-x130099.s3.eu-west-2.amazonaws.com"
    force_destroy               = false
    hosted_zone_id              = "Z3GKZC51ZF0DB4"
    id                          = "test-client-bucket-x130099"
    region                      = "eu-west-2"
    request_payer               = "BucketOwner"
    tags                        = {}

    server_side_encryption_configuration {
        rule {
            apply_server_side_encryption_by_default {
                sse_algorithm = "AES256"
            }
        }
    }

    versioning {
        enabled    = false
        mfa_delete = false
    }
}

Neat! It’s worth noting here that Terraform does not output-sensitive values to the screen; the (sensitive value)sections are not edits on my part.

But where did the access key go? And when you find it, how are you going to get it to the user? We’ll cover this in more detail in a later segment, but suffice to say look for a file in your working directory called terraform.tfstate. You can find it there.

Now let’s give Alice some access.

The Policy

Policies in AWS are defined as JSON. Most tutorials inline the JSON to define such policies. However, this leads to hard-coding identifiers. These can change when a resource is recreated and cause problems. I don’t know how the other authors sleep at night, but I’ll break from the norm and provide a civilized example. I’ll use a separate aws_iam_policy_document.

This policy allows access to the contents of aws_s3_bucket.test_client_bucket.arn. This policy document is not a resource like our other blocks. Instead, it is a data source and will provide reusability and some protection against fat-finger mistakes.

With it, we’ll create a user policy like so.

The .json converts our data source to literal JSON. Now let's take it for a spin.

Testing

After apply, you can test your new user. I did this by adding the access key information from terraform.tfstate to my ~/.aws/credentials file in a new section [alice]. You can then call awscli --profile alice followed by any of your usual commands.

We may look at automated testing in a future post, but not here.

Next Steps with Terraform

Stay tuned by subscribing and you’ll get notified immediately when part II is available. In Part II we will refactor aws-hello-world.tf into separate files and modules and adding optional aws console access.