Skip to content

July 31, 2011

42 Rules of Employee Engagement

Book Review-42 Rules of Employee Engagement

One of the best things about 42 Rules of Employee Engagement by Susan Stamm is that because it’s 42 separate rules – so you can consume the material a few pages at a time. The book for me was a sort of flash cards, a collection of bits and pieces that I’d learned elsewhere that I was in some state of forgetfulness about. Although my interest wasn’t in engaging the employees I manage – I still found some nuggets of useful information about how to engage employees – and perhaps more importantly what breaks employee engagement.

The book ends with a list of references to other books that might be useful to the reader. In fact about 15% of the book are these references to other books and tools.

Here’s the list of rules covered in the book:

  • Rule 1 Rules Are Meant to Be Broken
  • Rule 2 Get “Under New Management”
  • Rule 3 Begin at the very Beginning
  • Rule 4 Listen, Listen, Listen
  • Rule 5 Be a Hands-On Manager
  • Rule 6 Be a Low-Tech Communicator
  • Rule 7 Everyone Needs Feedback
  • Rule 8 Keep Learning
  • Rule 9 Allow Your Team to Grow
  • Rule 10 Support Your Team Members When Needed
  • Rule 11 Relationships Determine Results
  • Rule 12 Sharing Builds Community
  • Rule 13 Your Beliefs Drive Results
  • Rule 14 You’re Still the Boss
  • Rule 15 Everyone’s Not Like You (Thank Goodness!)
  • Rule 16 Be Direct with People Who value Results
  • Rule 17 Be Enthusiastic with People Who value Enthusiasm
  • Rule 18 Be Accepting with People Who value Sincerity
  • Rule 19 Be Reliable with People Who value Quality
  • Rule 20 Build Self-Esteem When Discussing Performance
  • Rule 21 Involve to Engage
  • Rule 22 Use Your Head
  • Rule 23 You Don’t Have to Be the Smartest Person in the Room
  • Rule 24 Compete with Your Competitors
  • Rule 25 Get Out of the Shower
  • Rule 26 Turf is for Stadiums, Not Teams
  • Rule 27 Right Actions Bring Engagement
  • Rule 28 Leave Your “Good Parenting” Skills at Home
  • Rule 29 Leave Your “Bad Parenting” Skills at Home
  • Rule 30 Expect Exceeded Expectations
  • Rule 31 It Only Takes a Minute
  • Rule 32 Recognize Good Performances
  • Rule 33 Problem Solving Is a Team Sport
  • Rule 34 Help Your Team Accept Change
  • Rule 35 He Who Has the Gold, Rules
  • Rule 36 Build Acceptance, Reject Prejudices
  • Rule 37 Honesty Is Always the Best Policy
  • Rule 38 Give It Your All
  • Rule 39 Know What You Want
  • Rule 40 Engaged Teams Get the Facts
  • Rule 41 Ask, Don’t Tell
  • Rule 42 These Are My Rules, What Are Yours?
cats

How This Developer Solves a Puzzle

My wife purchased a puzzle for our family, and her Aunt and Uncle that we’re staying with on vacation to do. The puzzle consists of nine square pieces each of which contain half of an image of a cat on each side. The completed puzzle is a 3×3 grid of the pieces where all of the cats match up. After an hour or so of trying to randomly try pieces and combinations, I decided to come up with a plan that would definitively solve the puzzle. I decided to break the problem down into a set of comparisons the computer could do – and write a program to solve the puzzle.

Before I get to far, yes, I was informed by my wife that this was cheating. However, I’m not sure I agree (feel free to provide your comments if you would like). I don’t agree because puzzle solving should be about using all of your skills to be able to create the solution – not just simple trial and error. If you believe I cheated in finding the answer, that’s OK. If you prefer to think, as I do, that what I did was find an ingenious way to solve the puzzle read on.

Since I’m not an expert in image recognition, I decided the first step was to inventory the pieces and convert the images into something easier to handle. I decided that each cat had a left and a right side of the image. Since there were four different cats I’d number them 1 (Black), 2 (Orange), 3 (Gray), and 4 (Tan). I would then label the left side of the cat as the A (or true) side and the right side of the cat as the B (or false) side. Then I could create a inventory of each piece with it’s numberic identifier for the piece (which I randomly assigned) and the number for the cat image on each side: 3b, 2a, 4b, 1a… With this conversion from physical objects into numbers in hand I was ready to create some classes and structures.

I decided at the most basic I was matching sides so I created a class with the Cat Number and Cat half variables. The cat number had to match and the cat half had to be opposite. Because of this I used a boolean for the cat half. I also created a method for the class called match, which took in another puzle side and returned a simple true-false to indicate whether the sides could be matched together. One key here is that I returned true of there wasn’t a piece on the other edge. I knew there wasn’t a piece because the cat number was zero.

I also needed a puzzle piece to contain the piece’s identifier and the sizes of the piece. I also created a puzzle placement class that considered the orientation of the piece – since pieces could be rotated you didn’t know which side should be up. Finally I created a puzzle solution class to hold attempted solutions. The puzzle solution class had a method to return whether two solutions matched. This was used to prevent solutions from being tried multiple times by the program.

The main code of the program consisted of some lines to initialize variables, followed by a set of nested loops. The outer loop was a solutions loop where I recorded each tested solution. Inside of that I had loops for x and y positioning and inside of that pieces and inside of that orientation. Through these loops I’d test a piece at a time in each orientation to see if I could get it to match on all four sides. One key here was my array of positions was actually five by five and not three by three. Why? I kept a set of empty positions all around the pieces so that I didn’t have to worry about running into array bounds issues. It was wasteful of memory to be sure – but it’s efficient from a coding perspective and given this was quite literally throw away code, it seemd like a reasonable thing.

After working out some of the logic and a few minor logic bugs I ended up with a program that tried 283 solutions before finally settling on and displaying the answer on how to solve the puzzle to me. I should say that the answer was displayed instantaneously – at least to me it was instantaneously. I’m sure there were some number of milliseconds involved but to me they weren’t even measurable. I tested the solution on the real puzzle and it worked.

I ended up having about an hour in the code – and I’m certain that solving the puzzle by hand would have taken much longer than this given the complexity of the problem so I was happy with my puzzle solution.

Clearly you can’t use this technique to solving every puzzle. The typical jigsaw puzzle doesn’t lend itself quite as nicely to this sort of problem – but it was a fun exercise to convert a real world puzzle into an algorithmic one that the computer could solve.

The completed puzzle looks like this:

If you want to look at the code it’s available here.

Recent Posts

Public Speaking