Spoil Your Meetings

You just got a calendar invite your boss. 

What’s going on? Are you getting fired? Your last performance review was fine! 

You walk to your boss’s office. HR is sitting there with her.

Kermit being nervous

Oh crap, oh crap, oh crap.

HR walks out as you walk in. You sit down, and your boss says, “Hey I just wanted to bounce an idea off of you.


Meetings shouldn’t have surprises. Spoil them.

Tell everyone what you’re going to say before you go. Give away the ending. Put all the good parts in trailer. And the bad parts. And the song that’s going to play in the montage while your team builds the A-Team-esque vehicle that is needed to do the job. 

If your meeting doesn’t have spoilers, then it’s probably not worth having.

Real Work

I want to talk about real work and fake work.

Does this sound like your work culture?
Does this sound like your work culture?

We have 1:1’s, standup meetings, team meetings, check-ins, all-hands, and serendipitous meetings at the coffee machine. How long did you spend writing google docs, emails, slack chats, gchats, hipchats, and wikis? What percentage of your day comprised of tuning your vimrc/emacs/bashrc and organizing your trello lists? Are you patting yourself on the back for reaching Inbox Zero?

How many times today did a customer notice something you did?

Sam Altman writes about fake work for startup founders:

In general, startups get distracted by fake work. Fake work is both easier and more fun than real work for many founders. Two particularly bad cases are raising money and getting personal press; we’ve seen many promising founders fall in love with one or (usually) both of these, which nearly always ends badly. But the list of fake work is long.

I tell founders to consider how directly a task relates to growing. Obviously, building and selling are the best. Things like hiring are also very high on the list—you will need to hire to sustain your growth rate at some point. Interviewing lots of lawyers has got to be near the bottom.

So now we have rules for founders/CEO’s:
Real work: Building/Coding and sales, probably hiring.
Fake work: Interviewing lots of lawyers.

Does Sam think lawyers are unnecessary? No, but he realizes picking the 1st or 2nd best lawyer is indistinguishable from choosing the 12th best when it comes to your business. Finding the best employees is a better use of a CEO’s time.

But what about everyone else? How do we distinguish between real work and fake work?

Toyota’s legendary production system strives to eliminate waste everywhere. When talking about waste, Toyota’s Shigeo Shingo observed that only the last turn of a bolt tightens it.

"Only the last turn of a bolt tightens it" - Shigeo Singo
“Only the last turn of a bolt tightens it” – Shigeo Singo

That final turn in software engineering is shipping code. There are other activities so closely tied to deploying code that they are undoubtedly Real Work, such as programming and reviewing another engineer’s code. What about everything else?

I define Real Work as
A. Work that creates an immediate and positive change in your product/service
B. Work that is a direct constraint to the completion of A
C. Work you have been uniquely hired to do.

Type C has to be included because many jobs don’t touch A and B, but someone has to do them. Google famously hired a masseuse, Bonnie Brown, when they had only 40 employees. Was she improving our search results in 1999? Maybe not, but Larry and Sergei thought it was critical to their success. For Bonnie, she should be confident that shipping each great massage (type C) was Real Work as it had been identified by the business as type B work.

So why make the distinction between A, B, and C at all? Why not just say Real Work is what you were hired to do and leave the question of whether it’s valuable or not to the person who hired you. It’s because most of our jobs have a degree of autonomy in the the tasks we take on. We should prioritize type A tasks and have a high standard for B tasks. We should eliminate any B tasks that don’t enhance our ability to complete A tasks. Fake work is anything that doesn’t live up to that standard.

Things you can do tomorrow to minimize Fake Work
1. Skip a meeting you don’t need to attend
2. Turn your weekly meeting into a bi-weekly meeting, or even monthly
3. Be concise in communications. Be polite, but formality in email is dead.
4. Don’t jump into conversations just because you can. Comments can be useful, but they also add cognitive load to an issue.
5. Eliminate, automate, or delegate menial tasks.
6. “Table it!” Brian Sloane introduced this to me. If two people are having a drawn out discussion in a meeting, put your hand on the table (or in the air) and say “Table it” to indicate that this discussion should continue in another channel at a later time.

Things you can do tomorrow to maximize Real Work
1. Figure out what real work means for you in your job.
2. Schedule time specific tasks. Treat them like appointments.
3. Don’t check your email until you’ve been at work for an hour. This is an old Tim Ferris trick. If you’re feeling brave, forego Slack, too.
4. Observe the habits of people who get things done. Shamelessly steal them.

Minimizing fake work doesn’t mean you should eat lunch at your desk everyday. The advantage of focusing on Real Work is so you can perform at a high level and still live your life.

10 Things I’m Doing After Reading The Principles of Product Development Flow

A few weeks ago I showed this slide during a talk I gave to clients of RJMetrics.

Books on Flow and Throughput
Books on Flow and Throughput

The Goal is legendary in my family as a guide for unlocking throughput in manufacturing. Garvey Corp’s entire business model is helping companies exploit constraints and increase profits. It got me off to a great start in manufacturing, but the reality of workflow always seemed a little more complicated than Goldratt’s stories lead you to believe.

Later I devoured Jeffery Liker’s The Toyota Way, which describes the infamous Toyota Production System. It seemed to me that if you carried Goldratt’s constraint theory logically throughout your production system, you’d probably end up with TPS or something like it. As good as it is, the Toyota Way’s strategies always seemed better suited for a different type of manufacturing. One where you were producing roughly the same thing, slightly customized. My manufacturing reality had tremendous customization and variability.

The Principles of Product Development Flow by Don Reinertsen was what I was looking for. Here are ten things I’m incorporating into my workflow. (Manufacturing bits now instead of machines, of course)

1. Smaller projects – We’ve been shrinking our projects at RJMetrics for a while now, but initially I resisted it. “Some projects just take a long time, but are still worthwhile,” I thought. In 2015, however, the equations making projects worthwhile change fast. It’s better to hit a 2 week checkpoint and say “let’s keep going” than go for 6 months and say, “maybe we shouldn’t have done this.” I’ve even been making a conscious effort to make my pull requests smaller (under 50 lines) and more frequent.

2. No more backlogs – Keep TODO issues in a short list, but kill off the long collection of items that linger forever. This is super hard for a GTD’er like me, where you’re supposed to get everything out of your head and into a system. That system breaks when you get multiple people adding items to a backlog that will never get touched. The real backlog is in your brain. If it’s important enough, it will stay there bugging you to be completed and eventually you’ll add it to your short todo list. The key reason why backlogs are bad is this: Your team is smarter today than it was in in the past. Your issue backlog was created by an inferior version of your team.

3. Late assignment of issues – No one gets assigned anything until they can work on it. Have you ever been stuck in a grocery line behind someone who is super slow? You’ve already committed to that line! You’re stuck there because the physical constraints of a grocery store force assignment of a few customers to a register. When matching devs with issues, wait until the last possible second to make the assignment so that it doesn’t get stuck behind another slower than expected issue.

4. Fast feedback is critical – In 2015, everyone says we need to ship an MVP and iterate, but we still don’t always do it. There are many excuses: “The design isn’t ready”, “It’s not valuable without feature X,” etc. Not only is fast feedback worth overriding these concerns, it’s the best plan for fixing them.

5. Start teams smaller, then bring in reserves – “Make early and meaningful contact with the problem.” Planning is good, but plans get shattered once work starts. Things always turn out to be harder than we thought and the best way to find out where we are is to have someone start working on the project. A single developer will have a better picture in one week than a plan ever will. This is one reason why hackathons pay off so well for RJMetrics. Bring in other team members in week 2 and their start will be better focused. Plans should set goals, but be light on implementation details until work beginds

6. Use Little’s Formula – to provide more accurate response times for issues.

7. Make queues visible – Luckily we have a great BI tool to use for this called RJMetrics. Reinertsen recommends Post It Notes to track queues, but the book was written BT (Before Trello).

8. Queue = Todo + In Progress – Don’t just count items that are waiting. The item you’re currently working on is still in queue. The team’s issue queue should be judged on the sum of Todo and In Progress, not just one.

9. Have a framework for when to escalate team communicationPrinciples says to use regular meetings over irregular meetings, in person vs email, etc. I’m hesitant to escalate the communication due to the transacational costs associated with context switching, but when do you decide to stop emailing and start chatting? When do you stop chatting and start speaking? I’m going to start using the following framework for communication and adjust it:
– Email goes to chat after 3 emails
– Chat goes to in person after 10 messages

There’s no 10th item. Don’t feel like you have to fill every meeting/PR/project with content to fit the allotted time.

Best Things This Year (2013)

Anecdotally, it seems like a lot of people shook up their lives in 2013. I certainly did. Here are the best things that happened to me in 2013.

1. RJMetrics – In March I started working at RJMetrics, an e-commerce data analytics firm in center city Philadelphia. Leaving Garvey Corp was a difficult decision, but being a developer at of the best SaaS data visualization companies in the world has been amazing.


2. The Bulldog Budget – I worked with Philadelphia City Controller candidate Brett Mandel to implement his vision for the city’s open data future. We built a visualization tool using D3 and MySQL that gives both a high level view of the General Fund budget, but still allows you to drill down to individual transactions. A lot of people got excited about it and I think it made an impact in Philadelphia. It also influenced similar projects in Italy and Oakland, California.

Treemap of the Philadelphia General Budget
Treemap of the Philadelphia General Budget

3. Coffeescript – I was skeptical at first whether Coffeescript was a worthwhile abstraction from Javascript. After 9 months of using it at RJMetrics, I’m a fan. Here’s why:

  • Cleaner syntax: No parenthesis, braces, or semi colons. The time I save writing console.log instead of console.log(); has been worth the switch.
  • Improved workflow: Continuously running the Coffeescript to Javascript compiler alerts me of stupid mistakes (ie. ones that won’t even compile) faster than finding them after I’ve loaded the browser.
  • Existential operator: I can’t count the number of bugs I’ve fixed with one character are due to Coffeescript’s great ? operator, which checks to see if it’s null or undefined before proceeding. For example, if in javascript you previously did this:

    if (player != null) {

    In Coffeescript you just write:


  • Comprehensions: The Coffescript.org docs say you almost never have to write a multiline for loop and they can be replaced by comprehensions. For example:

    for (player in players) {
    if (player.health < 0) { player.kill(); } }

    In Coffeescript you can write:

    player.kill() for player in players when player.health < 0
  • I'm looking forward to getting better at Coffeescript in 2014.

4. AngularJS - I don't want to develop another interactive UI without AngularJS.

5. Bought this swingset from craigslist - With the help of my friend Mike and my father in law, we disassembled, packed it up and a U Haul, and reassembled it in my back yard. I'm amazed it went back together so well.


6. Read 13 Books - My morning commute afforded me more reading time. Here's what I did with it.

  • Bonfire of the Vanities by Tom Wolfe
  • Ready Player One by Ernest Cline
  • Look at the Birdie by Kurt Vonnegut
  • The Trial by Franz Kafka
  • A Beautiful Mind by Sylvia Nassar
  • Boys from Brazil by Ira Levin
  • Game of Thones (books 1-3) by George RR Martin
  • Life of Pi by Yann Martel
  • Timequake by Kurt Vonnegut
  • How to Win Friends and Influence People by Dale Carnegie
  • Thinking Fast and Slow by Daniel Kahneman

7. Public Speaking - I got way out of my comfort zone this year and did some public speaking at Ignite Philly and Technically Philly's Civic Hacking Demo Night.

8. Built the Gonginator

9. Spark Program - Some coworkers and I participated in an apprenticeship program for Philadelphia school kids where we spent 2 hours a week with 8th graders interested in programming and computers. Together we built a game!

That's as much as I could remember from 2013. Check out my lists from 2012 and 2011.

Scariest thing I’ve read all year: The Dunning-Kruger Effect

When Will Ferrel describes his George W Bush impression, he says he just imagines having a lot of “unearned confidence.” How would you know if you were one of these people? I first heard about the Dunning-Kruger effect in a comment on Hacker News and it immediately made me question a lot of things.

David Brent: Classic case of the Dunning-Kruger effect

The Dunning?Kruger effect is a cognitive bias in which an unskilled person makes poor decisions and reaches erroneous conclusions, but their incompetence denies them the metacognitive ability to realize their mistakes

Throughout my life I’ve forced myself to be confident in my abilities (ie. gotten out of my comfort zone) in an effort to improve my skills and do more things. I’ve always considered being optimistic and determined to succeed was a positive thing.

Luckily, according to Dunning and Kruger if I suffered from this effect I wouldn’t be able to recognize and change anyway. WIN.

New Job

Garvey Corporation was started long ago as a gas station in 1926 by an Irish immigrant named Gordon Garvey. He chose a location on Route 73 directly between Philadelphia and Atlantic City, since it would be an ideal place for people to stop for gas coming from either direction. The company moved away from being a service station over the years and evetually got into making sheet metal parts. By the 50’s and 60’s, Gordon’s sons Fran and Bud took over the company and developed their own line of modular conveyor systems to sell to the local glass making industry. In 1980, Mark and Bill Garvey, sons of Bud and Fran, took the helm of the company and expanded its reach into more extensive and complex product handling systems with customers all over the world.

As of last week, I’m the new General Manager.

Infinity Rx

It’s a role I never would have expected to come this soon if at all. It’s nerve racking and exhilarating at the same time and an immense test on my abilities. I like the work I have been doing far more than I ever thought I would and that helps. Wish me luck, as I am responsible for the livelyhood of 80 people and their families. I take that 100% seriously and think about it every day.

Not that I don’t have help! We have a great group, including my brother Jake.

If you’re curious about what we do, check it out: http://www.garvey.com

Also, here’s a case study I wrote for a wine magazine about what our equipment did for Rodney Strong Vineyards.

What I do

I don’t make too many work posts, but here is a quick explanation of what I do every day. I’m the Engineering manager for Garvey Corporation, a company started in 1926 by my great grandfather, Gordon Garvey. We make product handling equipment for high speed packagers in the food, beverage, pharmaceutical, and consumer products industries. Mainly that means conveyors, accumulators, loaders, unloaders, inspection stations, etc. Our customers are mostly big food companies like Kraft, General Mills; goods producers like Proctor and Gamble; beverage makers like Ocean Spray; and pharmaceutical companies like Merck and Wyeth. We also do a ton of work in the wine industry for Rodney Strong, Don Sebastiani, Mondavi, etc. which was spurred on by my Dad’s work in creating a new type of buffering system to accumulate wine bottles between the filling and labeling machines. We called this new accumulator the Garvey Infinity and have sold hundreds of them since 2001.

The reason for this post is that we’ve come up with a breakthrough accumulation machine for the pharmaceutical industry that I’ve been working on for months. It’s finally finished and it turned out even better than I hoped. It applies all the lessons we learned in the beverage industry and focuses them on super tiny pharmaceutical bottles, sometimes as small as 15mm wide.

Here’s a video of the Infinity Rx accumulating and single filing 2ml 15mm vials at over 850 vials per minute. It’s for a show, so that’s why it loops back into itself.