3-5-7 Meeting Format for Weekly Staff Meetings

If you are the manager of a team of people at your job, here is a format we suggest for running your staff meetings. We call it the 3-5-7 format because of its convention of giving 3 to 5 minutes per person to answer 7 questions. This system assumes that you have fewer than ten direct reports so that you can complete such a staff meeting in under one hour.

The purpose of a staff meeting need not be to get status reports. If you have excellent collaboration tools at work where statuses, issues and risks are already documented, that’s preferable. Some companies like Automattic (WordPress) make great use of internal blogs for communication. However, face-to-face meetings are continue to be useful because our brains have evolved being wired for being most effective in face-to-face conversations for several things.

An in-person (or via video conference) discussion structured around these questions is likely to be effective in finding solutions, building a more collaborative team and keeping everyone on the same page.

Here are the seven questions we suggest you request each attendee to come prepared to answer.

  1. What did we (you and the team reporting in to you) do over the past week?
  2. What did you learn over the past week?
  3. What do we (you and the team reporting in to you) plan to do over the next week?
  4. What issues are we (you and the team reporting in to you) facing now or are likely to face in the future?
  5. What do you suggest are our countermeasures to address those issues?
  6. What do you need help with from the rest of us in this meeting?
  7. Is there anything non-work-related that you’d like to share?

Each person may answer the seven questions the order of their choice and may also combine the answers to multiple questions. The only requirement is that all seven areas be answered in a focused, efficient, and effective narrative lasting between three to five minutes.

Some of this advice is based on management experiences shared by Don Kiefer in an operations management class he teaches at MIT’s Sloan School of Business.

Mandela’s Way: Lessons on Life, Love, and Courage (Book Review)

I find many books on leadership to be fairy tales: Inspiring to read, but misleading about leadership that is actually effective in our real world. Real leadership — leadership that is based on evidence and science, and thus statistically more likely be effective in practice as opposed to “feel good leadership” — is less commonly found in leadership books. Mandella’s Way, written by Richard Stengel, a respected journalist, is one of the few books about leadership lessons from the real world presented with journalistic integrity.

Rating: ★★★★★

 

Suggested Template For Requesting a Meeting

Every time someone calls a meeting, they should consider using this simple template.

[ meeting-invitation-template begins ]

The desired outcome of this meeting is:

  • e.g. Come to agreement on solution for issue X
  • e.g. Make a decision about Y.
  • e.g. Share announcements about topic Z.
  • e.g. Continue to grow a good working relationship with each other by socializing in person.

Note: Explain what this meeting is meant to accomplish, instead of providing a description of the meeting. Focus on the desired result of the meeting. A meeting should accomplish one or more of three things:

  1. Solve problem(s)
  2. Make decision(s)
  3. Share knowledgeand agree to act on it and/or make it a practice
    • Knowledge, as in: data –leads-to–> information –leads-to–> knowledge –leads-to–> practice

You should come to this meeting because:

  • e.g. You are likely to have input into potential solutions for issue X
  • e.g. You are one of the folks who has a viewpoint on what decision to make regarding Y.
  • e.g. It would benefit you from hearing the announcements in this meeting.
  • e.g. This is your opportunity to ask questions about topic Z.

Note: Give the attendees at least one good reason to attend. Sometimes attendees have no idea why they are invited to this meeting. Don’t be seen as a waster of others’ time.

The guidelines for participating in this meeting are:

  • e.g. Please come prepared having read the document about ChaosMonkey.
  • e.g. Laptops & mobile communication devices are considered contraband during this meeting. If it is critical for you to have a computer during this meeting, bring a desktop computer :-)

Note: Set the expectations of the participations.

[ meeting-invitation-template ends ]

Further Reading & Thoughts:

Templates for Replying to Meeting Requests & Polite Ways to Decline Meetings

As much as possible, we should only attend meetings where we are active participants, not mere attendees with nothing to contribute to the defined outcome of the meeting. There are some exceptions to this like training sessions, educational presentations or others where the purpose for attendees is to learn something.

When I receive a meeting request, I often reply with the following text. In fact, I have it saved as a TextExpander macro as a shortcut to typing it.

May I please request the following information in advance of this meeting? It will enable me to prepare, participate and be productive in the meeting.

  1. What decisions need to be made at this meeting (if any)?
  2. What problems need to be solved at this meeting (if any)?
  3. What knowledge is planned to be shared at this meeting? (topics or documents)

Thank you,

Time Management Tip: When you receive an invite for a meeting at work where you believe you may not add much value, reply to the invite with a polite message like:

Thank you for inviting me to this meeting. It seems from the subject, agenda and attendees list that I’m not a required participant for this meeting. If I’m mistaken and my presence is required in this meeting, please accept my apologies and let me know that I should attend.

This is preferable to ignoring the meeting invite or declining without comment that may come across as rude. I have this text also saved as a TextExpander macro.

Discussion about declining meetings: https://plus.google.com/107443707510532643538/posts/inUkYy1Ufg7

When to have and when not to schedule meetings

Companies should, by default, avoid scheduling meetings that start before 10am or end after 5pm. If an employee comes to the office at 8am on some days, it is often to use the two hours of the morning before meetings to catch up and/or get a head start on the day. Meetings that start before 10am are often harmful overall since they put the attendees in reactive catch up mode for the rest of the day. Similarly, meetings that go on beyond 5pm (or worse, start after 5pm) take away valuable time from employees that they use to absorb information and events of the day, catch up with replying to email and get ready for the next work day.

i.e. Companies should consider any time outside the 10am to 5pm window to be not available for meetings and definitely not any weekly recurring meetings.

Preferably, employees who are ‘makers’ should have one 4-hour continuous block of time each day when they are free from meetings. (‘Makers’ differentiated from ‘Managers’)

50/25 Meeting Format

If you manage a team, value your team members time and want to improve productivity at your workplace with a simple change, consider implementing the 50/25 Meeting Recommendation that some companies are embracing. You can communicate something like the following to your team:

Dear Colleagues,

We deeply value your time, your productivity and your comfort at the workplace. As a part of our initiative to make your workday more productive, less hectic and better manageable, we recommend a 50/25 meeting format. It is simple concept: As much as possible, let us take all our meetings that are 1-hour long and shorten them to 50 minutes. For our meetings that are half-hour long, let us limit them to 25 minutes.

You will find that a 50 minute meeting will accomplish no less than a 60 minute meeting did and a 25 minute meeting will be as productive as a 30 minute one was. In fact, by having clear 50 minute and 25 minute deadlines, our meetings are likely to be better focused, on topic and more attentive. (For example: Since you will have time after the meeting to check email, there is likely to be less temptation to check emails during the meeting itself.)

The extra 10 and 5 minutes will give you valuable time back that could be used for many useful activities: Getting in the frame of mind for the next meeting or task; checking your messages to see if there is something urgent that needs your attention; or simply taking a bio break.

Please note that this not a mandate, but a recommendation. We realize that you may not be able to do this for every meeting. What we ask is that you consider doing this for meetings that you organize or can influence. As a result, we will make our great work culture even better, less stressful and even fun.

Further Reading & Thoughts:

  • NYTimes article about Larry Page, Google’s founder and new CEO instituting the same 50/25 meeting recommendation at Google:
  • http://www.nytimes.com/2011/11/10/technology/googles-chief-works-to-trim-a-bloated-ship.html?pagewanted=all
  • If a meeting accomplishes all its goals in even less than the 50 or 25 minutes, please, by all means end the meeting even sooner.
  • We suggest that you do book the full hour or half hour in the calendar even as you implement the above so that others don’t schedule over the “10 minutes left over” in your calendar.

Thank you for considering this,

[Signature]

A discussion about this 50/25 Meeting Format: https://plus.google.com/107443707510532643538/posts/AtYgnmbhtqc

Laptops, Smartphones and Other Communications Devices in Meetings

It has been common for over a decade to find people reading and responding to emails on their smartphones in all sorts of situations, including during business meetings. This question, however, is not about smartphones: It is about use of laptop computers during meetings.

In what types of meetings and situations do you consider laptop usage to be acceptable?

There are some situations, where it seems to make good sense:

  • + Note taking during meetings: Saves time wasted transcribing later and better than having notes on paper which can’t be searched easily and piles up as clutter.
  • + More secure than taking notes on paper that can be forgotten and read by others who should not have access to the information.
  • + Quickly looking something up that is relevant to the discussion
  • + Entering action items that come up during the meeting into your to-do-list (especially useful for GTD system users, e.g. OmniFocus.)
  • + Meeting notes and action items can be automatically backed up in real time.
  • + Quickly and discreetly asking a question, or sharing an opinion or information over instant message without disturbing others in the meeting.
  • + Environmentally friendly, saves paper
  • + As for distractions, the user can be disciplined and focus on the meeting. Perhaps even using the laptop to participate more actively in the meeting. (Even a person using pen and paper can be distracted doodling or daydreaming.)
  • + This is the digital age.

There are also some reasons not in favor of using laptops during meetings:

  • - It comes across as disrespectful to some other meeting attendees, especially those with traditional styles of working.
  • - The laptop screen creates a “wall” between you and the people sitting across you.
  • - The laptop does make it easy to get distracted into reading your email or other online activities. (A tablet like the iPad that lies flat on the table like a writing pad does not have this problem.)

Are there certain situations where it should be ok? For example: Large group meetings, small team meetings? Meetings with certain types of people? …?

Here is what I personally do: When I bring a laptop to a group meeting or one-on-one meeting, each time I respectfully explain to the others beforehand that I’ll use the laptop for taking notes and recording action items in my to do list only. I inform them that I will be focusing attention on the discussion and that the laptop is simply my digital notepad.

A discussion about using laptops, smartphones and other communications devices in meetings: https://plus.google.com/107443707510532643538/posts/NZ9NqEA7PVu

What I Learned During the Hacking Attacks of August 28, 2013

One of the most important lessons that was reinforced to me during the Aug 28th hacking attacks on Melbourne IT, the domain registrar for the Web sites of The New York Times, Twitter and many others was the importance of human relationships, personal networking and real-time communications during an emergency situation.

In this article, I’ll mention some of the human collaboration and technical aspects of the lessons that were reinforced. Minimizing the chances of having outages and getting hacked is beyond the scope of this article. This post is about resilience (i.e. dealing with and recovering) not prevention.

Note: To learn about the incident itself, see the section ‘Hacking Incident: Information & Misinformation‘ below.

The Power of Human Collaboration

I witnessed the power of multi-participant video conferencing that is commonplace these days thanks to Google Hangouts. Back in 2009, I wrote an article about the benefits of using real-time textual group chat during incident management and emergency situations. All the lessons mentioned in that article were yet again reinforced to me during this incident. I suggest reading that article to review the real-time communications recommendations in it.

Matthew Prince, CEO of CloudFlare summed it up well at the end of his blog post:

We spend our time building technical networks, but it’s comforting to know that the human network is effective as well.

My colleague Jon Oden Tweeted:

Well that was a fun day… lots of fantastic people in the tech community is a silver lining

I felt so honored, humbled, and happy when my friends and their friends at some of the best known Internet companies went above and beyond to help and spent most of their day in a Google Hangout video conference, helping restore public access to The New York Times’ Web site and other sites for the public on the Internet. They did this because they are good, helpful and tech experts. They took time out of their own jobs to help because they care about a common good cause and fighting against malevolence.

It was inspiring to watch so many brilliant tech people and leaders from multiple companies, many of who met on the video call for the first time, collaborated so well together and overcame the problems together. The combination of multi-participant video conferencing and text chat in Google Hangouts made it feel like we were all working in the same physical room together.

I’d like to thank John RobertsMatthew Prince and the engineers at CloudFlare; David Ulevitch and several engineers at OpenDNS; Mandar Gokhale, John W. McCarthy and others at GoDaddy;  The technical infrastructure engineering team at Google; Bob Lord at Twitter;  Sara Boddy and team at Demand Media; and many others who helped yesterday. You all showed amazing teamwork on the video conference yesterday.

Technical Lessons

If you run a high profile Web site, it is critically important that your Disaster Recovery & Business Continuity Plan includes dealing with an emergency when your primary systems  are unavailable, despite all the safeguards and backups you have in place. The domain registration hijack was one such example. A company can only have one registrar that holds their domain name registration information. There is no concept of a backup or failover registrar for a domain. To deal with this single point of failure, you need a backup Web presence on a separate domain.

Backup Web site on Separate Domain

You should maintain a backup Web site that:

  • Has a different domain name. For example, if your site is at example.com, your backup domain could be example.net.
  • Is registered with a different domain name registrar than your primary one. For example, if your primary registrar is MarkMonitor for example.com, then use Network Solutions for the backup domain example.net.
  • Uses DNS service hosted somewhere else. For example, if you run and host your own DNS servers for example.com, use an outsourced DNS hosting service like CloudFlare for example.net.
  • Uses a different Content Delivery Network (CDN). For example, if you use Akamai for example.com, use CloudFlare for example.net. You must have a CDN on your backup Web site so that it can handle your traffic.
  • Is hosted somewhere other than where your primary site is hosted and is implemented using a different (much simpler) technology platform that is highly likely to not have the same vulnerabilities.
  • Can feed your Mobile apps. Your mobile applications should be designed to be aware of this backup Web site and should be able to switch to it (automatically or via manual intervention) for retrieving content.
  • Does not share administrative access, logins and passwords with the primary site.
  • Preferably, this backup domain example.net should be managed by a separate team. This has two benefits: 1. In the situation of the primary team itself being compromised (sysadmin accounts hacked or a rogue employee) 2. The separate team can work on activating the backup site while the primary team focuses on restoring service of the primary site.

What you use your backup Web site for is up to you. If your primary Web site is a news and media Web site, you could use the backup Web site to publish content during an emergency impacting the primary Web site. If it is impractical for the backup Web site to provide similar (or a subset of) functionality, you could use it for providing status updates and communicating what is going on.

When the backup domain is not needed (which will hopefully be the case 99.9% or more of the time), it could simply be used for providing systems status, explaining it is in place for emergencies and linking to the primary Web site.

Access to a Reliable Public DNS

For end users (i.e. people on the public Internet visiting Web sites), I highly recommend considering using OpenDNS (instructions here) and/or Google Public DNS (instructions here) either as primary or as backup DNS providers.

Other

There are also other lessons, not specific to this incident, both process-related and technical that I’ll write about in a separate article.

Hacking Incident: Information & Misinformation

Wired Magazine’s article titled ‘Syrian Electronic Army’ Takes Down The New York Times correctly explained that:

There’s no evidence that the Times’ internal systems were compromised. Instead, the attackers got control of the NYTimes.com domain name this afternoon through the paper’s domain name registrar, Melbourne IT…

Melbourne IT is the company that manages the domain name registration for The New York Times, Twitter and many other well-known sites. On Aug 28, it was Melbourne IT’s computer systems that were hacked which enabled the perpetrators to hijack The NY Times, Twitter and other companies’ domain names.

Surprisingly, the article on Ars Technica (an otherwise well-respected technology publication) was inaccurate and misleading. It incorrectly stated (quote) “The Times DNS records have been altered, and now point to an Australian hosting company, Melbourne IT.” (end quote) That would lead readers to incorrectly believe that the hackers redirected nytimes.com to DNS or fake Web sites hosted at Melbourne IT.

I’m surprised that the Ars Technica staff did not do their research before writing that post. Melbourne IT is (and has been for years) the official domain name registrar of The New York Times. In addition to being a domain name registrar, Melbourne IT also happens to be a hosting company, but that had nothing to do with the incident. As far as I know, none of the sites impacted that day used Melbourne IT for anything other than domain registration.

What Ars Technica should have said (like their sister publication Wired did) is that the perpetrators hijacked the nytimes.com and other Web sites by hacking Melbourne IT, the company that holds their domain name registration.

The Ars article is also misleading in its claim that The nytimes.com DNS records were altered. It was the domain registration records at Melbourne IT that were altered that then pointed to a whole different set of DNS servers outside of The NY Times’ control.

The Ars Technica article also pointed readers to NY Times’ URL by one of its IP addresses, which was also a mistake. If the Ars Technica folks had tested it themselves, they’d have realized that pointing people to the URL by IP was not the recommended way to access nytimes.com during the incident. Clicking on links on the IP page leads back to www.nytimes.com by name. They should have instead pointed readers to the alternate news.nytco.com URL recommended by The New York Times’ staff, which is what the Wired article did. They could have also suggested other good solutions like switching to using OpenDNS. In fact, I’d have expected a technical publication of Ars Technica’s good reputation to have published a step-by-step guide on switching to OpenDNS, which they wrote about back in 2006.

SHA-3 Hash Generator


SHA-3, originally known as Keccak is a cryptographic hash function. Learn more on WikiPedia…

Enter text below to generate the SHA-3 Hash Code for

Output length in bits:

The SHA-3 Hash Code is below

Victory is winning people, not defeating others.