Search

mikehking dot com

Personal Reflections: Agile, Leadership, Technology, and Life

Category

leadership

Know when Working Harder isn’t going to Work

A dedicated employee who will work harder, with a greater sense of urgency (and maybe some extra hours when needed) is great.  But what’s much more valuable than someone with that work ethic, is someone who can see when working harder isn’t going to work, and they need to change their approach.

Think about someone using a dull saw to cut a huge pile of wood to build a house — they’ll look at the schedule and say “I don’t have time to sharpen my saw”, which is ridiculous to think about.  But we do it all the time when we try to shift into a higher gear and work harder to “dig out” of a busy season/project instead of thinking about what should we change.

It is so valuable as a leader to determine when a situation can be surged over, and when you need different resources/capacity/people/tools to overcome the situation.  Years ago, I was helping a Project Manager whose team was continually well below the needed velocity to get to the project’s finish line on time.  He kept trying to work nights and weekends to get back on the track, but simple math made it very clear that he could not single-handedly get the project back on track.  So we had to investing in both a technology and some additional people to help his team finish — it was easy to easy for those investments on his project; but it was much better to ask for them early in the project’s life as opposed at the end when he would be doomed to fail.

Think about if you need better processes/checklists, or a tool (e.g. software application) to help you be more efficient), or more people on your team, or something else.  Take the time to step back and think about how to change the game you’re playing so you can actually win.

Advertisements

Don’t Sleep in your Contacts… and the Importance of Communicating Risk Well

I went to the eye doctor recently, after my eye was bothering me.  I had slept in my contact lenses for several nights (which I’m prone to do), and my eye started bothering me.  In the past, when this happens, I take my contact lenses out, throw them out, and take a few days off of contacts.  This time however, my eye was bothering me much more than usual, so I went in to see the eye doctor.  I’m glad I did — I had a corneal ulcer, where bacteria had been stuck inside my contact lens. The eye doctor got me a prescription for some antibiotic eye drops and explained how lucky I was, since the ulcer wasn’t on the pupil itself (which can cause people to lose partial sight the rest of their lives!!!)!

The doctor asked me “Do you know you’re not supposed to wear your contacts overnight?” and I explained that I certainly did, but I had no idea what the real risks were — I assumed eye doctors said that, but that my approach to taking a break when my eyes bothered me was fine.

This is a great reminder of how important it is to communicate risks in a tangible, clear way.  It’s easy to say “That’s risky” or “This is not a best practice” or “It’s better not to do that”; but if we don’t take the time to truly articulate the possible impacts, explaining both the likelihood of something happening and the impact (severity) if it does happen, very bad things can happen.

Edward Tufte’s book Visual Explanations provides a powerful case study of this concept:  Engineers recommended the Space Shuttle Challenger not be launched based on specific weather conditions, but the launch was approved due to a lack of clearly communicating risk.

Are you Running in the Right Direction?

Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings  — it was a group game, in a big event space ballroom packed with engineers from all over the country.  I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.

 

It’s easy to say we should plan before we start doing work — people say things like that all the time:

  • Look before you leap
  • Measure twice, cut once
  • Cal Newport made this point on Ramit Sethi’s blog a while back
  • Agile Scrum “forces” people, every few weeks, to stop and assess where they’ve been (sprint demo), where they’re going (sprint planning), and how they could improve (sprint retrospective)

But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.

At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard.  This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).

Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.

While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.

The Risk of Oversimplificiation

Have you ever noticed how when something is simplified enough that it doesn’t intimidate people, people start to have a lot more opinions?

It makes sense that people who aren’t rocket scientists shouldn’t make recommendations on rocket ship designs.  But as complexity is reduced, two problems often arise:

  1. People start to make recommendations on things they shouldn’t, due to nuances or context they don’t understand
  2. People spend entirely too much time talking about details that aren’t important

aws_dashboardProblem #1 can be very dangerous.  I was discussing today how technologies like cloud hosting feel so accessible that people often make decisions where they don’t really understand the associated impacts and decisions.  Amazon Web Services (AWS) has a great dashboard that lets AWS users see all their cloud-based infrastructure. This dashboard is very powerful in the right hands, but often makes non-technical decision makers feel like they can manage their organization’s IT infrastructure, without realizing the impact of not having redundant systems, data backups, and disaster recovery solutions in place. (Note:  If you’re looking for AWS cloud expertise, check out JHC Technology or Halfaker.)

Problem #2 can also be very damaging to organizations — organizations sometimes spend shedtoo much time talking about what color the walls of their new office space should be, instead of what they should focus on strategically next year.  This concept is known as Parkinson’s Law of Triviality (Bicycle Shed Principle).  They call it the Bicycle Shed principle because of a story told by Mr. Parkinson about when decision makers charged with designing a nuclear power plant focused most of their time on what materials should be used to build a storage shed. (Thanks Ramit Sethi for introducing me to this concept.)

Watch out for both cases — it’s important for decision makers to be aware of where their expertise ends and where their attention should be invested.  Note:  A leader shouldn’t avoid areas outside of their expertise, but they should realize when they need to focus on certain parts of a decision, or when they need to rely on internal or external experts.

Fire and Forget: Difference Between A Vice President And A Janitor

The military classifies some missiles as “fire and forget” because they don’t need to be missilesmonitored after they are fired.  Great leaders are like this — their boss can give them an objective and know they don’t need to follow up over and over to ensure success.

This concept is incredibly important in your career as take on more and more responsibility.  Junior team members are expected to work hard and be guided by leaders to support the team.  However, there is an inflection point where the the value people add to the organization separates based on those who work hard and those who will ensure success.  It’s great to be someone who works hard to support the team, but it’s a whole different level of value to an organization when someone can be trusted to accomplish an objective without needing oversight.  This doesn’t mean you shouldn’t check in with your boss, or ask for advice or mentorship, or request in-progress reviews (IPRs) or other meetings to touch base — it means that your boss sees you as a person they can “fire and forget”:

This type of high-value leader doesn’t wait for someone to check on them if they have questions or obstacles (they analyze and solve them, or they ask for help, or they bring recommendations to someone for validation)

Business Insider wrote a post several years ago about a related quote by Steve Jobs:  Steve jobs explained that the difference between a janitor and a Vice President is that a janitor can have excuses for not getting their work done, but a VP is responsible to succeed, regardless of obstacles.

“Somewhere between the janitor and the CEO, reasons stop mattering,” says Jobs, adding, that Rubicon is “crossed when you become a VP.”

In other words, you have no excuse for failure. You are now responsible for any mistakes that happen, and it doesn’t matter what you say.

Invest time and energy and become a leader that people can trust to get things done when you say you will, without oversight or reminders.

Magnet Ball vs. Zone Defense: How Mature is your Organization?

There are a lot of ways you can measure and categorize organizational maturity.  I’m sureCMMI_maturity_levels there are several classes you can take on it if you get a MBA.  The CMMI Institute, as an example, talks about how organizations move from being managed, to defined, to starting to self-optimize.  These frameworks are all valuable, but I like to think of this concept as a simple spectrum between two extremes:

  • Magnet Ball – One extreme for an organization’s maturity is like watching small children play soccer.  Everyone, except maybe the goalie, surrounds the ball and you from away it looks like the soccer ball is a magnet pulling all the children toward it, into a swarm of chaos
  • Zone Defense – The other extreme is watching an organized group of people who know their role, they know where their role ends and someone else’s on the team starts, they know how to do their job well, and they know how to help their teammates when they need — this is like watching a great professional sports team work

magnet-ball-spectrum

Another great way to think about this is Tuckman’s Stages of Group Development (forming, storming, norming, and performing) is a great framework to understand how a group develops, and how you can help move a group through those phases.

Where does your organization (whether it’s a company, or a meetup group, or a church) fit on this spectrum?  How could you move it a little more to the right and out of the chaos?

Misadventures in Badge Printing: How Not to Issue 1,000 Badges

Several years ago, near the beginning of my professional career, I was a junior engineer helping with the design and issuance of new access badges for a campus of employees where I worked.  Thousands of employees would be getting new badges, they would wear it around their neck on a lanyard and it would have their name and picture on it, along with some other information and it would let them badge into the their work building.access-badge

The Project Manager I reported to, and the Security Manager (our client in essence), were focused on some parallel projects and trusted me to do a good job with relatively limited oversight regarding badge design, layout, and configuration.  I designed a variety of types of badges that denoted different types of employees, laid out all the badge information, configured the magnetic stripe encoding, configured the security groups for the access control system; and presented my leaders with my recommended approach.

Everything looked good, and we moved forward — the security office began issuing new badges to employees, scheduling times for employees to come to the security office to get their picture taken, hand in their old badge, and receive their new badge.  This badge issuance wasn’t cheap, as we were spending significant time for employees and security officers, as well as printing color badges on RFID badges (which at the time weren’t cheap).  After several days of badge issuance, with nearly a thousand badges issued, an employee came up to the security office and asked one of the security officers standing next to me:

Why is our company’s name spelled wrong on my badge?

I started at the badge while I started to realize the impact of this error.  I had misspelled one of the wordHead in Handss in the company division’s name, leaving out a letter.  I was horrified.  We had just spent a huge amount of time and money, and now I realized that my badge design had an obvious spelling error.

With great fear and embarrassment, I told the Security Manager and my Project Manager of my mistake.  Clearly we had to admit the mistake, buy more badges, ask those employees to come back, and ask the security officers to work more extended shifts to get this done.

What shocked me was how the security manager treated it.  I’ve seen managers scream at people for much less, but this guy took it in stride.  He realized the cost of this mistake, but also realized that I already felt horrible, it wasn’t intentional, and he reviewed and approved the badge design without catching the error.  I learned to spell check work products, but more importantly I learned that great leaders take the blame (and pass credit on to their people).

See this Snickers commercial for a similar misadventure:

Super-busy? You’re not a Hero, You’re Investing your Time Poorly

I’ve been working some long days recently, trying to balance some big projects at work. I overworkedlove the excitement and intensity that comes from leading big change, whether it’s setting up a new system or process, or chasing a big opportunity.  But I often need to remind myself that great leaders don’t have to work long hours, over-working themselves into a frenzy of stress and bad decision making.  Great leaders plan, delegate, recruit, mentor, and they build systems to ensure things get done well without having to be directly involved.  Like Michael Gerber teaches in The E-Myth Revisited:

Work on your business, not in your business.

Gerber’s book is focused on a company, but the concept also applied well to people who lead projects or teams.  Stop thinking of yourself as a hero when you’re super-busy with something — instead, think about how you can:

  • Better plan projects
  • Recruit great people to support the project
  • Mentor others to be able to contribute effectively without significant oversight from you,
  • Design systems/processes so others can work within those systems without needing your to guide them throughout in each step of the process

Powered by WordPress.com.

Up ↑