Sunday, August 31, 2014

Book Review: Dreams of Gods and Monsters (@lainitaylor)

Dreams of Gods and Monsters by
Review by ()

As book three of the Daughter of Smoke and Bone trilogy, we bring the trilogy to a close. But no mere end-cap, this book (613 pages in print), like the last two, is an epic in its own right. We learn why the Chimera and Seraphim are both living on Eretz and why portals exist between Eretz and Earth, amongst a lot of other things. Truly a lot happens in this book and to describe any of it to someone who hasn't read books 1 & 2 would be silly (go read those books!) or to someone who has read books 1 & 2 (go read book 3!). Which leaves me with short review as is often the case with the final book of a series I've made it all the way through.

I recommend this book, I recommend this series. Taylor creates a world all its own that feels unique, thought out and yet plausible. It doesn't break any of the laws of nature or physics that we know today, but offers a much larger potential world and then explores its implications, woven throughout a complex story of beings wanting a better future and dreaming big.

Love has brought Karou and Akiva together multiple times, their nature has allowed them to weather the circumstances. Back also are the always fabulous Mik and Zuzu. And with a race of beings in which regeneration is possible, there's always hope and that hope will be rewarded - but this isn't some fantasy where "they all live happily ever after" - this is a war - there will be death as well, the permanent kind.

A really great read.

(Amazon, My Review)

(Amazon, My Review)


Thursday, August 28, 2014

How-to: Light up your @NewRelic Apdex

the super-bright blink(1) mk2
Earlier this month I wrote about my new toy, my blink(1) mk2 from thingm. (There's no financial stake here for me, I just think it's really cool.)

My problem was that I didn't have, well, a really practical use. I already had methods for learning about new mail and I really didn't care to constantly be informed of new Facebook updates, it's not like I'm using Facebook at work anyhow.

But I realized yesterday I did have a good use for it - passive/ambient real-time information about the health of our systems at work.

Several of the members of my team handle On-Call responsibilities. We use NewRelic, KeyNote, WebMetrics integrated with Zapier, PagerDuty,, Atlassian, etc. for our work.  But for the most part, unless it's a "hard down," an incident must be happening for a period of time before notifications start going off. If we're in the tools, we might see an alert sooner, but otherwise, we're all busy working. No one's sitting around watching monitors.  (We have a desire for more of an NOC but right now it's pretty reactive.)

It occurred to me that since NewRelic offered an API I could use my hacky AppleScript skills (ok, more like awesome Googling skills) and translate NewRelic's red/yellow/green lights for our systems into, literally, red/yellow/green lights that I could see as I worked, even if I wasn't in NewRelic.  Since we have that requirement of sustained impairment before notification, sometimes we hear about something in a drive-by before alarms are ringing. That's embarrassing.

I figured if I could have a closer to real-time look into the system but without spending time in the system that we could have a little bit more of a warning if something was starting to go wibbly-wobbly.

And so with a little work I cobbled together a script that pings the NewRelic API, gets the apdex_score of five sites, displaying a red/yellow/green status.  It shows each one for 5 seconds and then shows a blue light (to help you know the cycle is restarting) and then goes again. It can poll all five systems in about 30 seconds and in the AppleScript log window I have a running history of the apdex_scores.

It's also been a great conversation-starter the past two days, carrying my laptop to meetings and then leaving it sitting there with the laptop mostly closed, the little light quietly pulsing, only stopping to open the laptop and look if something starts to trend down. It's building up credibility for our group as having, literally, our finger on the pulse of the system and it was fun to code it. I'm a little dismayed at a few of the shortcuts I took, but my main job isn't programming, so I didn't want to spend a lot of time on it.

So here's the code, it should be pretty clear where you swap in your api key and your transaction or application IDs. Click the photo of the blink(1) to go and buy one for yourself. (Again, I have no financial interest here, I just think it's cool.)

Lori's Cupcakes (All-Natural Coloring)

Lori was recently(ish) commissioned to do cupcakes for a church event. Because of some of the research on dyes and their impact on some children (including observed behavioral changes in our daughter when she's had red dye #40), Lori's been only using natural colorings. Because this was a children's event, she saw it as the perfect opportunity to expand her available color palette of natural colors with the goal of also being tasty as frosting.  I think it was incredibly successful.  (See the Flickr collection.)

Here's what her research yielded:

  • Pink: beet powder + strawberry purée
  • Magenta: blackberry purée with powdered freeze-dried blueberries
  • Purple: purple yam with natural cherry extract
  • Green: fresh spinach with lime juice
  • Orange: sweet potato with powdered freeze-dried oranges
  • Yellow: mango in both powdered and reduced purée forms
We hope to someday turn her creative genius into a business.

Tuesday, August 26, 2014

Coding a Car (A Work-Related Post)

There are a million (I'm guessing) things that can go wrong with a car. Tires can go flat, lights can stop working, batteries can go dead. Hoses can rupture. It can run out of fuel. The driver can drive it off a cliff.

As the car manufacturer, you can't control for all of these things. But you can design the car to work well and be intuitive, things that will make it easy for someone who's never driven your car before to get behind the wheel and not drive it off a cliff whilst trying to change the turn on the turn signal. You can source quality parts and stress test to make sure hose ruptures and timing belt failures are rare. And you can test it under extreme conditions to make sure that your car can handle most of the crazy things your customers might throw at it, even if you hadn't intended for the car to be able to do that in the first place. Because let's face it, your customers are humans - inquisitive, irrational, unpredictable.

But there's two really important things to do.

Documentation - you create guides for mechanics who will do much of the repair for you.

Awareness - you anticipate some of the most common problems the car can have and you build in systems to monitor, record, track and alert. They may tell the driver (a chime and light to tell you "low fuel"), they may call ahead to the mechanic ("a part has failed" or "a part is about to fail, please order it and call my owner to schedule service"), they may simply record for later review by the manufacturer or law enforcement ("the car was going 45 mph in reverse with the windshield wipers on when it went off the cliff")

Good software will go through all of this thought as well. A lot has been said about these first few:

Good design:

  • Looks good.
  • Placement of controls are logical and use existing conventions or best practices.
  • Workflows make sense, tasks can be completed.
  • The product is true, authentic, real, accurate. (That is, a salesperson can sell it without lying or guessing.)
  • Is it going to hold up reasonably well under wear and tear.


  • Does it meet policy/law regarding the safe provision and transit of publicly identifiable information or payment processing and financial?
  • Is it secure?


  • Meets intended scenarios and business requirements.
  • Withstands innocent incorrect usage. (Better yet, recognizes these lost users and guides them back to the path.)
  • Withstands hacking attempts - doesn't let you hide SQL commands inside form fields, protects itself against DDOS attack, etc. Hire people to try to break your system.
  • You've pushed it to its limits to see how it responds.

But less thought and attention may be given to these - and that's dangerous.


While the goal may be to produce a product so perfect that everyone just instinctively knows how to use it, that's just wishful/prideful thinking.  You need to see how real people interact with your product and then tweak and adjust as you go. But you also need to know that you probably can't make it foolproof. You will need labels, guides, self-service documentation that allows the user to figure out some tasks without coming back to you.

It also may be that you're going to hand the product off to a different team to support once you've written it. Perhaps an On-Call team or a Network Operations Center who will be watching your system. They need to know how to support the product, how it works, what levers and pulleys are at their disposal to right the ship if things start to go sideways. (And who to wake up if it completely falls over.)

System Health - Monitoring, Alerting, Notification, Logging:

You want your system to be resilient, to never fail, to just work perfectly and flawlessly all the time. If you think that's possible, you're incredibly vain or prideful. Or you have an unlimited budget and your product will never ever actually ship because you'll be coding forever.

The developers who build the system must spend time imagining how it can break down. Those scenarios must be turned into things that can generate logs, monitors, alerts and notifications. There is a tendency to overlook these items during planning - they aren't sexy, they aren't business requirements from the business, they are extra work for the developers, but they must be considered, must be added to the product backlog, must be delivered before the product goes live. These are your insurance policy. Unless you're willing to be making payments on a car that someone has stolen.

Logs - call it the black box of your software program - you need to know what was happening when things went south. In the midst of the crisis, you may be too busy trying to keep the thing flying to stop and ask what went wrong, but you need a way later to go back and better understand the original causes. This is only possible if you take the time to build in the code that captures snapshots of what was happening.

Monitoring - computer software is easy to set and forget. There's often no tangible product. Monitoring is at-a-glance statistics and measurements elevated to a pretty screen. It may tell you about network connectivity or disk space, about how many successful logins have occurred in the past 15 minutes or how many orders have been placed. It will be real-time and where appropriate should show trending/trailing stats so you know if something has changed.

Alerting - something has gone yellow. It's not yet time to wake someone up, but it's an early warning sign that something might go bad. It could be something innocent (a commercial drove a lot of traffic to your site) or something not so innocent (a distributed denial-of-service attack has just started against your system). These appear within your monitoring tool (on the screen if you're watching it) and your logs.

Notifications - ok, now there's a fire. Something is "hard down" or something's been in the yellow state for more than 15 minutes or some metric is so off (shopping cart creation vs completed order, signin attempts vs successful signins) that it's time to wake someone up. People are getting text messages or automated phone calls at this point.

And there's actually one more piece beyond that, a place where the car analogy no longer works so well.

Your software product must be resilient. As products become more complex, you eventually find that you don't control the entire stack. You may depend on someone else's API to tokenize your credit card, to process your credit card, to place the order. The product catalog may be on a different system, curated by non-technical people. There may be physical components - perhaps your software controls robots that assemble and ship orders or even cars.

It's time to stop making assumptions and start honoring chain of custody. If your system has a particular piece of information that it must pass to another system, it cannot simply assume that a hand-off was successful. It now needs a way to safely and securely store that piece of information (an order, complete with credit card details, for instance) until it is assured that the next system has successfully received (and confirms receipt of the data).  This is a somewhat newer mindset, but if you want to make sure nothing falls through the cracks, you must be willing to be responsible for your data until you have proof positive that it's been accepted by the next layer in the stack.

So when you hear "I just want to code" be very afraid. You may need some code written, but far more importantly, you need really solid end-to-end thinking and you need a culture that says isn't "making babies" but "raising a child" - if you're churning something out and you're tossing it over the fence as soon as the commit is made, you're solving for today but you won't need to worry about tomorrow because your company will go off the cliff and you won't know why.

Sunday, August 24, 2014

Book Review: Quantum Zoo

Quantum Zoo by (and others)
Review by ()

Quantum Zoo is an anthology of short stories in the science fiction genre on the theme of "zoo" - as in a collection of living creatures. Sometimes animals, sometimes aliens, sometimes humans. A number of authors employ a number of different styles of writing taking place in a number of different time periods and places. All of them more well thought-out than that last sentence I just typed.

The variety and quality varies from story to story, but there is a decent number of different stories here and the price can barely be beaten. The Kindle edition also provides jumping off points to other works by each author. If you want some quick fixes of sci-fi, several of these will fit the bill, especially one involving a race to the edge of the galaxy to capture creatures that have just been discovered.

I did grow bored with one of the stories, but read the other ones all the way through. This 99-cent Kindle book will give you more than enough material for a plane ride, or if you're like me and like to read before bed, quite a few nights of entertainment, reading a story over one or more nights.

Quantum Zoo (Amazon)

Monday, August 18, 2014

The Trouble with MVP (A Work-Related Post)

Too many of us have drunk the Kool-Aid. It used to be that "MVP" was "Most Valuable Person" or "Most Valuable Player" or "Most Valuable Product." In Agile, it becomes "Minimum Viable Product" - what's the least amount of effort/money/time that we need to put towards this and have something to show for it?

In being nimble and responsive and to avoid wasting effort, this is a great mindset. It's not laziness-as-an-artform, it's about executing quickly to get a proof-of-concept into someone's hands so that they can quickly affirm that you're on the right track or so that we can quickly discover that the business requirements were wrong.

from Amazon
But there must still be a group in leadership that concerns itself with "Most Valuable Product" - if the "Minimum Viable Product" mentality creeps too far up the org. chart you end up with "perpetual alpha" - a product that works as a proof of concept but then fails under load testing, fails security scans and fails to delight customers. Used to be that a really good prototype was also quite ugly. With technology kits like Bootstrap, your proof of concept can look extremely polished and be mistaken for the final product.

But as leadership, you must concern yourself with the whole, quality product. You may still want to iterate quickly, and if you've got a forgiving audience who enjoys living on the edge or is excited by continually discovering new features you've just added, but if you have paying customers, you may take the MVPs in bundles to release to your customers.

And it's at those releases of new features that become a great time to celebrate your other MVPs - the "Most Valuable Player" who deliver quality Minimum Viable Products that don't require a lot of refactoring to move from proof-of-concept to world-ready scalable secure releases.

The Problem with MVP (A Work-Related Post)

Also posted on LinkedIn

Too many of us have drunk the Kool-Aid. It used to be that "MVP" was "Most Valuable Person" or "Most Valuable Player" or "Most Valuable Product." In Agile, it becomes "Minimum Viable Product" - what's the least amount of effort/money/time that we need to put towards this and have something to show for it?
In being nimble and responsive and to avoid wasting effort, this is a great mindset.
In being nimble and responsive and to avoid wasting effort, this is a great mindset. It's not laziness-as-an-artform, it's about executing quickly to get a proof-of-concept into someone's hands so that they can quickly affirm that you're on the right track or so that we can quickly discover that the business requirements were wrong.
But there must still be a group in leadership that concerns itself with "Most Valuable Product" - if the "Minimum Viable Product" mentality creeps too far up the org. chart you end up with "perpetual alpha" - a product that works as a proof of concept but then fails under load testing, fails security scans and fails to delight customers. Used to be that a really good prototype was also quite ugly. With technology kits like Bootstrap, your proof of concept can look extremely polished and be mistaken for the final product.
But as leadership, you must concern yourself with the whole, quality product.
But as leadership, you must concern yourself with the whole, quality product. You may still want to iterate quickly, and if you've got a forgiving audience who enjoys living on the edge or is excited by continually discovering new features you've just added, but if you have paying customers, you may take the MVPs in bundles to release to your customers.
And it's at those releases of new features that become a great time to celebrate your other MVPs
And it's at those releases of new features that become a great time to celebrate your other MVPs - the "Most Valuable Player" who deliver quality Minimum Viable Products that don't require a lot of refactoring to move from proof-of-concept to world-ready scalable secure releases.

Sunday, August 17, 2014

Book Review: Ruin and Rising @LBardugo

Ruin & Rising by
Review by ()

Ruin and Rising is the third and final installment of Leigh Bardugo's fascinating and imaginative Grisha series. The books take place in a land called Ravka, which is controlled by a Monarchy with an uneasy alliance with a group known as the Grisha - humans who have special powers, drawing from the elements around them from what are called the small sciences. Some produce wind or fire, others have special skills in alchemy or healing. Our heroine, Alina, discovers in the first book that she is a very rare Grisha, capable of bringing forth light. Ravka is a kingdom also geographically divided a desert, shrouded in darkness cuts off most of the country from the sea and the opportunities for trade that come with it. By book three, we've learned the cause of the dark desert (called "the unsea") and we've been on a journey to try to end it.

This is a YA book, so while we've lost one suiter, another arises so that Alina still has a conflict there to contend with. It's not much of a conflict for her, but while she's made her decision and she's confident in it, politics and position prevent it from being the slam dunk she'd like it to be.

I don't want to say a lot about this book because I strongly recommend you read the entire trilogy unspoiled. But it is a well-conceived world, a really enjoyable read and a satisfactory ending.

There's some great supplemental content on the author's website as well.

Shadow and Bone (My Review, Amazon

Seige and Storm (My Review, Amazon)

Ruin and Rising (Amazon)

Wednesday, August 13, 2014

Are You "Poachable"? (A Work-Related Post)

Doesn't this look good?
Corn Cakes with Smoked Salmon
& a Poached Egg (
A healthy company will practice the "right people on the bus" methodology, examining its current employees' potential to fit positions that come open. "Do we have the right people on the bus, and are they in the right seats?"

This practice, however, takes effort. The HR department must really understand the position they're recruiting for, employees must be permitted to thoughtfully consider other opportunities within the organization and leaders must be aware of the strength of their peers' "benches." Oh, and there must be a culture that says "poaching" is not only OK, but a good thing.

If your recruiting efforts are always focused outside (and you're not a startup that's growing like a weed) that may signify a problem with your organization: you may have a bus full of the wrong people, you may be relying too heavily on your recruiting team, your leaders may not have a great understanding of what happens outside their own silos or a desire to protect it at all costs, even to the detriment of the greater whole.

How can you grow a culture of poaching? It starts with an emphasis on the individual - this investment in each individual employee creates an environment where people stay not because it's easy but because they can't imagine going anywhere else. It's an environment that says "we believe in you, we trust in you, we want you to succeed" - an environment that makes sure staff are trained, are allowed the time to stay current in their fields of expertise (and has mechanisms to make sure they really are) and makes sure that they are empowered and equipped to be successful. And just as important, does not have goals that conflict with that of their team, group, department, division or the organization.

[Make it a place where] people stay not because it's easy but because they can't imagine going anywhere else.

Second, a natural progression exists. For every job, at least one clear career path exists. We can't all be CEO, but each employee should be aware of the next steps they could be taking and what's expected of them to reach that next step. There's something to be said about being good at what you do and being happy where you are, but if you're not growing, you're dying. If you stay at the same level too long, the number-crunchers will eventually question whether a more junior person could do the same job for less money. Even for the jobs that seem to be primarily about individual contributions, someone who has become an expert in their field can produce additional value by shepherding a small team of contributors while strengthening their own skills in leadership.

Third, establish a "feeder." A feeder is a great way to identify new talent, typically at a junior level, who can hit the ground running. Many companies invite interns to join them for the summer to provide work experience, but it's also a great way to do on-the-job interviews. Even if they have to go back to school, you can identify those diamonds early and spend the school year getting their job ready. Other feeders include franchisees, call centers, retail employees and in some cases, maybe even some of your fans who are out there doing marketing for you for free already.

The most important thing to remember, however, is that it applies at the individual level, regardless of the company culture. As you interact with other departments, what will they remember about you? Do you get things done? Are you passionate about the organization and its mission? Will they remember your intelligence, your eagerness to find solutions that benefit everyone? Or will they remember that you raised the shields and tried to defend your turf and its goals? Did you put up roadblocks or tell people why it couldn't be done? Did you remind them of past failures? Did you exhibit suspicion and mistrust? Every interaction with a co-worker is a soft job interview. Be positive, be solutions-oriented, be passionate. In short, be remarkable. Make it so that when they have a job opening the first thing they think is "Boy, it would be awesome to get [your name here] to come over to our team and do this for us."

In short, be remarkable.

So... are you "poachable?" If not, no better time to start than today.

Sunday, August 10, 2014

How To: Make Your Mac React to Your Presence

the totally awesome blink(1) mk2
I love technology, but all too often it's just on a screen - there's no real world impact. I am really excited about the potential for real world impact and automation, stuff that happens automatically. Like the fact that I can set my washing machine to start at a certain time. That's kinda cool. It's a bit basic, sure, but it's cool. Or that my wife can get a text message when I leave the office.  Proximity is probably an easy cool thing - maybe it's a warning if I drive away from the house with my garage door open or if my autistic son gets out of the house.

On a smaller scale, I've set up some proximity automation on my computer that's pretty fun. When I walk away from my computer, it turns on the screensaver. If Skype is running, it sets me to invisible. It HipChat is running, it shuts down. And if my blink(1) is attached, it turns yellow to signify that I'm away. (It's on a USB extension cable so I can mount it higher where people can see it.)

If you haven't seen blink(1), it's very cool - double-sided LED USB key. Can set to any color you want on each side, blink in patterns, etc. Connects to IFTTT and email programs and you can also address it from Terminal or AppleScript. (You have to check the "Enable API Server" - most people miss that and think that they can't run Blink1Control and issue cURL commands at the same time.)

And then when I walk back up to my computer, it kills the screensaver. If Skype is running, it sets me to available. If it's between 8 and 5 on a weekday, HipChat starts. Microsoft Office syncs (first checking to see if it's in offline or online mode). And if my blink(1) is attached, it turns it back to green.

Oh, and my screensaver (Soundstream) is noise activated so that the patterns change depending on the amount of noise nearly in our open air office. That's kind of fun.

So how do I accomplish all this? A few neat tricks.  First a program called Proximity. You introduce your Bluetooth phone to Proximity and then every so often it pings to see if your phone is around. If it senses a change, it runs the Applescript you've identified. Future places I should probably go are ignoring mouse and keyboard inputs and muting the entire computer.

Here are my scripts:

do shell script "curl 'http://localhost:8934/blink1/fadeToRGB?rgb=%23FFFF00'" 
tell application id "" to launch 
if application "Skype" is running then 
tell application "Skype" to send command "SET USERSTATUS invisible" script name "invisible" 
end if 
if application "HipChat" is running then tell application "HipChat" to quit 
end try

do shell script "curl 'http://localhost:8934/blink1/fadeToRGB?rgb=%2300FF00'" 
tell application id "" to quit 
tell application "Microsoft Outlook" 
if working offline is true then 
set working offline to false 
set working offline to true 
tell application "Microsoft Outlook" to sync 
end if 
end tell 
if application "Skype" is running then 
tell application "Skype" to send command "SET USERSTATUS online" script name "online" 
end if 
set x to weekday of (current date) as integer 
set y to hours of (current date) as integer 
if x > 1 and x < 7 then 
if y > 8 and y < 17 then 
tell application "HipChat" to activate 
end try 
end if 
end if 
end try
The reason that Microsoft Outlook has to check to see if it's online or not is because I have another script that is running that takes it in and out of offline mode automatically. That allows my outgoing messages to temporarily be held and it prevents new messages from being pulled in too frequently. (Otherwise Exchange delivers them immediately and it's distracting. Email doesn't need to be that quick. Yes, I have my notifications turned off, but I actually spend a lot of time in email. It's easier if it's not filling up as I empty it. It's also nice to have some forced delay before my messages go out, in case I change my mind about a message or to avoid email pingpong.)

repeat 100 times 
log "Sync at - " & (current date
tell application "Microsoft Outlook" to set working offline to false 
tell application "Microsoft Outlook" to sync 
delay 5 
tell application "Microsoft Outlook" to set working offline to true 
delay 600 
end repeat 
log "** Final at - " & (current date
tell application "Microsoft Outlook" to set working offline to false 
tell application "Microsoft Outlook" to sync

Saturday, August 09, 2014

Book Review: The 10X Rule @grantcardone #10X

The 10X Rule by

Review by ()

This book is amazing. Changed my life. I swear. You might be asking if that's really true. I started listening to the audiobook about 18-20 days ago. Ask my co-workers if they've seen a recent change in me. Ask my parents, my children, my wife. Seriously, this book has changed my life. I even started a business while listening to this book.

This was totally coincidental. I might even say providential. I had an email from GoodReads which recommended this book based on other books I'd read. I kept postponing the email, probably for more than a month. One night, trying to clear out some email, saw this one, figured "I'm already reading two books on my Kindle, I have three on my nightstand - I'll get this as an audiobook from the library." I'd never done that before, listened to an audiobook from the library.

The basic premise of this book is that we are not successful because we don't work hard enough. As someone who regularly saw "Does not work to full potential" on report cards growing up, this was like a kick in the pants. Cardone says that success is your duty, your obligation and your responsibility, and that if you're simply settling for average, you are being unethical.

Holy cow. Unethical? If you are not living to your full potential, you are being unethical. That's transcendant. That's not "work hard and you'll succeed." That's not "you don't have what they have because you didn't work hard enough." That's hard core. Unethical.

Dang. That's both convicting and empowering.

What really made this work for me, though, was listening to it on audiobook. Cardone, a sales motivational speaker and trainer launches into this book with an amazing amount of passion. He's reading his own words, but he brings them to life. He's excite about this topic and you can't help but be as well. He's not pitching you snake oil, he's not giving you some magical investing formula (well, he is, see below), he's not selling his business (it's way late in the book where he slips in a 1-800), he's coaching you. Made me wish my drives were longer. (He does lose a little steam passion by the end, but by then I was so hooked, I still hung on every word.)

The magic strategy? MORE TIME + OUTRAGEOUS GOAL + BELIEF IN YOURSELF = SUCCESS (again, keeping in mind that it's your duty, obligation and responsibility to succeed).

I realized as I listened to this book that all of the things I was trying to accomplish and master were small - tame my inbox, keep my to do list tidy with all the little things crossed off each day. There was so many somedays, hopefuls, eventuallys and maybes. Maybe someday I'll drive a Tesla. Get my bills paid off. Get air conditioning installed in the house. Increase my giving to church. Own a house by the beach.

Soon this book will go back to the library, and I know I say all the time "I should read this again on a regular basis" about lots of books, but this one... this one is motivation, it's fire, it's the kick in the pants I needed, right when I needed it. If you someday ask "James Lamb, why are you so awesome?" I'll answer "Oh, I've always been awesome, I was just keeping it to myself."

I really recommended the audiobook. The only downside is you'll be constantly scrambling to try to capture stuff. I don't know why #10X isn't a permanent trend on Twitter because this is an immensely quotable book. Perhaps I'll get the print copy and do a chapter-by-chapter examination at some point.

The 10X Rule: The Only Difference Between Success and Failure (Amazon)

Monday, August 04, 2014

Are You Spending Enough Time with Your Staff? (A Work-Related Post)

According to a new study by Leadership IQ, the optimal number of time you should spend with each of your staff is six hours per week. It found that those who did had staff who reported being more inspired (29%), more engaged (30%), felt "more innovative" (16%) and were more motivated (15%) than those who spend only one hour per week with their boss.

In this modern high-tech world, it's easy to become disconnected, especially if you're a working manager, or you have a large number of direct reports.

All too often, the demands that spring up and cry for our attention (skype, email, meetings, our own boss) may be the places where we spend our limited budget of work hours. But if we aren't intentionally making time for our team, we're not being helpful.

Without even realizing it, sometimes the tendency is to wind-up the toy soldiers, aim them in a specific direction and let them going. "I love you. If anything changes, I'll let you know."

But that doesn't work. Rarely will they be fully equipped to be that autonomous, rarely will the objectives be that clear, rarely will the metrics they're working towards be so well defined and measured, and rarely will things go day after day without some kind of change in plans, some kind of shift in strategy or some kind of subtle course correction. If that's truly the case, you need robots, not human beings.

Human beings crave community, human interaction, and more importantly, encouragement and confirmation that they're on the right track, that they're adding value, that they're of worth. Even the most anti-social headphone-and-hoodie wearing individual contributors. They're not protesting your meeting, they're protesting your bad meeting.

So how on earth do you get to six hours per staff member per week? It may mean a change in priorities, or at least a very intentional effort. The report says that about 27% of that is in fact email, but that nearly half (48%) is face-to-face. You'll get to some of this by meetings (unless you don't involve your staff in the planning, strategizing or decision-making), you can also get to some by the dreaded-drive-by, standups, team meetings as well as regularly holding 1:1s.

The Dreaded Drive-By

Bill Lumbergh in Office Space actually got this kind-of right. While I never had the snazzy tie and suspenders, for awhile there I made it a practice of filling my Innotech coffee mug and making the rounds. The problem was, like in the movie, I picked the time that worked the best for me - near the end of the day. So I would invariably be interrupting someone trying to bang something out so they could clock out and be gone. So often conversations were brief. Or I wasn't prepared for a longer conversation because I had five or six workstations to hit.

The drive-by can be a way to touch base with team-mates, but it needs to be strategic. Probably earlier in the day when the team is fresh, when the issues they're facing are more about how to do something versus the end of the day when it's more about "get-it-done" and it's gotta be a true commitment - you've got to be ready to spend time if they seem like they need you to hear them about something. But also, watch body language, sometimes the signal is "I'm busy, dude - do you want me to do the work you assigned me, or do you want me to sit here blabbing?"

Drive-bys should focus on work or culture for the most part, but may be a follow-up to a stand-up, team meeting or a 1:1.


A lot of teams or departments now to daily standups. They are usually designed to be really quick, a coming together near the beginning of the day where everyone quickly assembles, remains standing and quickly goes around the circle. A lot of groups adopt the agile principle of answering three questions: "What did you do yesterday? What are you going to do today? Do you have any blockers?" Anything else needs to happen outside of the meeting. It's a quick level-set that helps each person commit to work: nothing worse than coming day after day and admitting what you did yesterday isn't what you said yesterday that you said you were going to do - that quickly becomes apparent to teammates and supervisors. If someone has a blocker, someone else should immediately commit to the next action. No one should leave a meeting with an unaddressed blocker.

Other groups are a little less formal, but there is the risk of tangents. The structure of the agile meeting doesn't stifle innovation and creative thinking, but it does keep it more tightly focused on the work at hand.

The stand-up also produces a natural flow into a useful drive-by: "Hey, Jenkins - you mentioned at standup that you were working on such-and-such but that you were having difficulty with the thing. How can I help?"

If you aren't leading/facilitating this meeting, make sure your staff still feels you are engaged, otherwise the time doesn't count towards quality time with the team members present.

Team Meetings

Team meetings are a chance for group bonding. Here's a couple of different ways we've use team meetings in the past. Sometimes devoting a full meeting to a single topic, other times covering multiple items in a planned agenda.

  • Information sharing (from other meetings, especially when the supervisor is part of a leadership team, making sure that information makes its way down)
  • Culture consideration (how does something we're working on fit within the culture. How does that recent memo from corporate change how we work?)
  • Study (we've studied books on leadership and, being a Christian organization, also worked through devotionals or Bible studies)
  • Team bonding (we've looked at how our Birkmann scores complement one another, done exercises to learn more about each other and right now we've been looking at each person's Strength Finder results)
  • Sprint planning (our team also controls a body of work, so we regularly meet to plan out another two weeks' worth of work and to assess whether we were able to finish what we committed two in the previous two weeks and if not, what unplanned events came up and blocked us.)


I think the 1:1 is probably the most important meeting you can have with a staffer. Take hand-written notes, or at least keep the laptop screen (shield) lowered as much as possible during the meeting. Schedule these in advance for a long period of time. Have them in a neutral place away from the team. This shows that they are a commitment you are making to them as an individual, to focus your attention on them for the entire 30- or 60-minutes, and then let them have at it - this is their meeting. I schedule mine for the cafeteria - it gives them a little anonymity, it doesn't have the same connotations as a closed door meeting room with your boss, it frees up scarce conference rooms and most importantly, it sets a different tone - the meeting may not need the whole 30 minutes. It's much easier for the staff to announce that they're done and excuse themselves and get back to work.

Be prepared for anything. It may be related to work, to struggles with a co-worker or with the job or the employer. It may be something going on at home. Be prepared to listen, to engage, and to offer assistance if you can if they seem like they are asking. Sometimes they're just needing a chance to talk. Because we're a Christian organization, I often end our meetings asking if there's anything specific I can pray for them for.

1:1s are incredibly personal. Sometimes it's personal stuff they probably haven't shared with anyone else in the office, but I provide a safe place outside their family and friends who may all be involved. Sometimes it's dissatisfaction, I've even talked with more than one about their job search - just make sure the reasons they are looking elsewhere aren't things within your control to change and that they're aware of that (they probably are or they'd be mad at you and wouldn't be sharing) and make sure they don't tell you of an intent to leave on a specific date because that counts as a resignation.

Before the 1:1, review your notes from the last meeting. After the 1:1, summarize your notes (I like Evernote) and take care of any action items from the meeting and follow-up with the staffer.


If you don't want all the messy human stuff, stop hiring humans and get yourself some robots. Otherwise, be prepared for it, knowing that the time you spend with them is an investment. You are shepherding them - helping them to be successful, which in turn helps you be successful.

Read more on LeadershipIQ.

Sunday, August 03, 2014

Book Review: Captives (Safe Lands #1)

Captives (Safe Lands #1) by Review by ()

In the 2080s, much of the known population has perished due to the lack of safe drinking water. Only a few places remain in the known world. The story takes place in a region that has a large, modern population in a walled city and several small, more primitive townships around it. There must be other populated areas as planes regularly depart from the large, walled city, but those that live outside its walls don't know much more than that, having adopted a way of life much more akin to that of frontier life, trading with each other, living in close knit families, raising children, growing crops and tending to lifestock, attending church, and so on.

The story focuses on the big walled city and one of the smaller towns. The large city has not seen a successful birth in years, everyone is sick with a plague. They have eschewed all sense of family - children are raised in schools, adults enjoy a very cavalier do-as-you-please lifestyle including drugs, alcohol and everything else you can think of. Women all have to take turns trying to conceive (via artificial insemination) during their two-month stint each year as part of "The Harem," a life of extra luxury in essentially a guarded dorm.

One of the members of the township makes a deal with the city's leaders in order to gain wealth and power for himself, a deal to allow the city access to the township. The idea is that they will come into the township and offer rewards and benefits to those who come to live in the city voluntarily, the hope that they will be able to provide new babies to the city. Things go awry when they arrive in the town and eventually the town's residents end up finding themselves to be residents of the city by force. Of course, they would rather not, so the book is the first in three about their attempts to navigate the city and its culture while staying alive, staying true to their own beliefs an eventually escaping.

The city is a near police-state where people are assigned their jobs by taking tests and they believe that each person has 10 lives. A digital tattoo on each person shows which life they are in and then if they've been in trouble, one or more X's next to their name. After three X's, you get "liberated" and are free to move on to your next life. (Of course, there are no next lives if they can't solve the lack-of-babies issue.) So that's the cleverness of the author, right? Just who are the captives?

It's probably pretty clear this is a morality play, with the outsiders praying and quoting scripture. I rarely felt hit over the head with this, it was more like "Oh, yeah, we don't usually see this in dystopian futures." It was mostly more like when you see someone on TV come out of a bathroom and you think "Oh yeah... how come no one on TV ever uses the bathroom?" The places it felt down, though, were when characters were so spitting mad they wanted to curse, but because of their upbringing they're yelling nonsense phrases. I already sent the book back to the library, so I'm paraphrasing but probably stuff like "you rat vomit!" - To me, that was unnecessary - it was jarring, cheesy, and if we're really being honest here, it's not the words that come out of your mouth, but if you allow yourself to become angry. (Click here for some Bible verses about anger.) Also, the writer attempts to invented trademarks to describe the technology which really hardly ever works. It would have been better not to have given them names. The third thing that bugged me were five or six blatant word errors. They wouldn't be flagged by a spell-checker (they were spelled correctly) but the editor must have been asleep on the job because these shouldn't have gotten past the editor.

Despite its short-comings, it worked well enough for me that I'm interested in reading the next book.

Captives (Amazon)

Friday, August 01, 2014

The Sift (Aug. 1, 2014)

Happy Friday - here's 5 articles that I thought were cool.

ENGADGET -- A 1,000-foot high wall might be the key to saving the midwest from tornados - Darn it, I knew I should have copyrighted that idea when I had it years ago.

HOUZZ -- How to Add a Backyard Shed for Storage or Living - just so we're clear, internet, I still haven't forgiven you for not telling me about this site sooner

KITEBRICKS -- Kite Bricks - they call it a new way to build, but I was creating buildings and space ships and cars when I was a kid. In fact, wasn't there a movie about this kind of building process earlier this year? (Oh.. wait.. these are full size Legos? Well, then that's completely different.) Either way, this is interesting - very little waste and probably a very fast method of construction. Check out the video.

SETH GODIN -- When in doubt, re-read rule one - hint: rule 1 is the customer is always right. It's a little myopic (he probably doesn't read Not Always Right but it's still a good thought.

BAKER -- Case Study: Wrigley 5 Gum - as a fan of this gum, I thought this was a really cool read - how they took it from ideation to execution, complete with a progression of designs and themes.