Maybe You Shouldn’t Schedule That Meeting

I read an interesting article on HBR last week outlining a framework for deciding whether or not to schedule a meeting. The quality of articles like this tend to vary anywhere between exceptionally helpful to common sense to a complete waste of time. The thing that stood out to me the most about HBRs article was the author outlined a framework for how to handle communication outside of meetings. This is an effective method that, if followed, should still result in the same level of communication (or better), but keeps everyone’s time from being wasted.

Meeting decision Tree

There is a ton of good information here, and I don’t want to simply re-hash what is in the article, so I will include some color commentary here and you should go check out the full article right after reading this post.

  • Schedule time to think/work - this is something we simply don’t do enough of as part of our busy workdays. Blocking off time on your calendar to tackle something specific is an effective way to make sure you are working on what’s important. It also ensures you aren’t distracted trying to accomplish the same work as part of a different meeting. Don’t have time on your calendar this week? Try scheduling some time in a couple of weeks and be pleasantly surprised when you “find” some time later on - your future self will thank you.
  • Leverage asynchronous communication - Just because you have something important to say, and have a few minutes to say it, doesn’t mean you need to call a meeting. After all, others may be busy trying to get work done, don’t bug them if you don’t have to. Instead, use IM or email or text to start the dialog and let your colleagues respond on their own time.
  • You probably don’t need to have a meeting - sometimes you do, most of the time you don’t. Are there ways to get the same level of communication across (or better) without requiring everyone to be in the same place at the same time?
  • Prepare - if you do end up scheduling that meeting, be sure to prepare. Put an effective agenda, schedule it for half to two-thirds of the time you think you will need, and manage the meeting size to reduce complexity.

Taking some up-front time to decide whether or not to hold a meeting can pay huge dividends in the future. If you can avoid one meeting per week 80% of the year, you can save a full week of waste. Imagine what you could accomplish with an extra week each year to focus on your goals.

Image Source - HBR

The New DevOps

My first five years as a software engineer, I worked primarily with a particular programming language. I had some responsibilities around testing and deployment scripts, but mostly I just worked with code and code-related activities. The following five years have been much different - there are entire projects that would have gone undelivered if I wasn't able to provide support in some area of Operations - networking, databases, operating systems, etc.

The development landscape has changed over the past several years. The lone-gunman programmer going off in a corner for months to deliver functionality has been replaced by development teams delivering business value every few weeks.

A similar shift has recently occurred in the area of Operations. Developers used to be responsible only for writing and (hopefully) testing their code. Infrastructure, networking, operating systems, RAM, CPU, power, and similar topics were someone else's problem.

Today, the landscape has again shifted to a more collaborative model merging development and operations (DevOps). Developers need to know much more about the operational components of their software - especially around network programming, services development, and continuous deployment. Likewise, the developer's IT counterpart needs to know much more about development - especially around infrastructure automation (Chef/Puppet), automated testing, and continuous deployment - I recently read a resume for an operations candidate that listed Ruby as one of the core skills.

As time progresses, the lines between developers and operations specialists will continue to blur, resulting in an ever increasing need for collaboration and communication between groups.

DevOps Infographic

Source - AppDynamics


The US economy has been growing. According to Morningstar, if you are in Healthcare, your industry enjoyed a 20% increase in 2014. Technology and Real Estate grew over 17% and Financial Services grew over 10% in the same period. These are some great numbers and if you work in one of these sectors, take a few moments to congratulate yourself on a job well done.

This also means that if you work as an individual contributor at Sony, Yahoo!, Qualcomm, Basecamp, or a startup 18 months out of Y Combinator and you haven't improved your skills by 17% in 2014, then you are actually a drain on your company's success. Either those around you have to grow more to make up for the difference, or your organization as a whole underperforms the industry.

If you run a team, the same principle holds, only the effects are magnified by the number of your direct reports. Can you point to an area where you saved 17% of your budget, increased productivity by 17%, booked 17% more sales, or improved the capabilities of your team by 17% or more? If your team didn't achieve these levels of growth and you are in the Technology sector, then you are lagging behind - even if you grew by 15% last year, it wasn't enough.

In this era, where everyone in the world is obsessed with improving themselves, take some time to assess whether or not you are improving at a rate that is greater than your industry. Otherwise, your competitors will slowly steal away your customers and market share. Maybe not all at once, say, 5% this year and 7% the next. Being content with your current position, with the expectation that you will still be doing the same work 10 years from now is a delusion. The market is growing and so should you.