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 Point at Problems, Attack Them!

There should be a word for people who have the annoying tendency to point at problems and talk about them, instead of trying to actually improve the situation (or maybe there is, and I just don’t know it).  I don’t know if you’ve been in a meeting with one of these people, but it’s so frustrating to listen to someone pontificate on and on about some problem and how it’s SO horrible, without trying to come up with any ideas, or asking someone to help them solve the problem, or just stop talking about it so someone else can try to solve the problem.

I’m not saying you should wait to bring a problem to your boss until you have a solution — for some teams/problems that’s a good idea, and for others that’s a horrible idea, and you need to get help for problems.  But what I am saying is that you should focus your attention and energy on fixing the problem, or removing the problem, or getting around the problem, or changing the situation so it’s not a problem anymore, or something else productive.

Email 101: Avoid the Bystander Effect

There’s a fundamental pyschology concept called “Bystander Effect“, where a group of people are less likely to help someone in need than when a single person is present.  Everyone in the group thinks someone else will/should help the victim, instead of them.

Think about this when you send an email — I recommend you clearly articulate who you want to do what, and ideally only put 1 person in the To: line of the email (even if you have a few people in the CC: line).

Cyber Security 101 for Small Businesses

If you’re a small business, the world of cyber security can be very overwhelming and intimidating.  There are infinite articles you can read about, a long list of cyber security maturity frameworks and concepts you could try to learn, and an overwhelming feeling that you can’t possible actually defend yourself from the hackers all over the place!

Cyber is a big, complex thing that is hard to do — if you’re looking to better defend your organization and you don’t know where to start, I recommend this approach:

  • Read the Center for Internet Security’s (CIS) CIS Controls, as they’re a great list of security controls (fancy way of saying todo items) that are already in priority order — so you start at #1 and just keep working your way down the list.  Here are the top 5:
    1. Maintain a current list of all the IT hardware (equipment) you use
    2. Maintain a current list of all of the software applications you use
    3. Invest in, and use frequently, a vulnerability scanning tool (e.g. Tenable.io) to identify security holes and then go fix them
    4. Limit who within your organization has Administrative Access.  Instead limit the access to only those who must have it, and then track who has it and who is using it to do what when.
    5. Configure IT equipment securely and monitor the configuration to ensure these configurations are being changed — for example, you may use an imaging solution to push out a consistent, pre-configured image of Windows 10 for new employee laptops and then use a device management software (e.g. Microsoft SCCM) to monitor the configuration across your organization
  • If you’re ready to keep digging in, read the NIST Cyber Security Framework (CSF), give yourself a red/yellow/green score on each of the 5 core domains and then focus on improving on the areas you think are the best return on your time and money

Recurring Activity Matrix: Write Down what your Team Actually Does

Scott Adams, the creator Dilbert, has written about how systems are much more valuable than goals.  This concept is incredibly powerful, and there are great, large, complex frameworks for defining and enhancing systems that people and organizations use and manage.  Frameworks like ITIL and CMMI do a great job of helping organizations think through all the various aspects of defining process architecture and governance.

However, they’ve often big, intimidating frameworks for a small team looking to become more mature.  Something I’ve found a lot of success with is starting with creating a Recurring Activity Matrix (RAM) for teams to write down all the stuff they do more than once, so they can publish a body of knowledge, which helps them be more efficient, collaborate with each more easily, and bring new people onto the team quicker.

I start small with teams, building a simple table with these columns in a wiki platform (e.g. Atlassian Confluence):

  • Team – specify the team (if this group has more than 1 team) that does this work
  • Owner (Role) – specify the role (not the person’s name) who performs this work
  • Recurring Activity – name the actual activity performed (e.g. “Check that the Website is Still Working”)
  • Frequency – e.g. Weekly on Fridays at 3pm
  • Link to Procedure/Checklist – provide a link to another wiki page with the details of what is actually performed (this can start pretty small, but eventually the goal should be that someone with little to no experience in this area could use this list to perform the activity)

Teams usually populate this data initially with a very small list, with early versions having the owner as someone’s job title. But as team’s mature, they start to identify a lot of items that go in this table, and start to break up roles more, so they’re not directly tied to job titles (Holacracy has a great concept related to this called Role vs. Soul).

As teams advance in this, I like to keep building on this — ideas like:

  • Automate the reminding and tracking of these actions, such as using recurring calendar reminders, or emails from SendRecurring.com to the person to reminder them, or (if you really want to show off) an email from SendRecurring.com to a Jira Service Desk instance to create a Jira ticket and assign it to the right person to do the work (and track if they completed it)
  • Use daily standup meetings or other sync-up meetings to identify tasks that are occurring that aren’t tracked in the RAM (or when someone takes a vacation and no one can figure out how to do something)
  • Separate Process Owner, Process Manager, and Practitioner roles (see ITIL process roles)

Eventually organizations as they scale will want more complex process management, looking at things like an ITIL Service Catalog or CMMI Organizational Process Definition; but early on the real value is just writing something down and incrementally improving it.

This is great, short article about how 1-800-GOT-JUNK wrote down their key processes, published it in a binder, and used it to rapidly scale a huge franchise business across the country.

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.

Interview with Tom Cagley re: Scaling Agile

I recently chatted with Tom Cagley on the Software Process and Measurement Podcast (SPaMCAST) about some of my experience helping scale operations at Halfaker using best practices from various business books (e.g. Good to Great), frameworks (e.g. CMMI), techniques (e.g. Agile Scrum), and tools (e.g. JIRA).  I really enjoyed our discussion on why I was excited to JIRA, a tool that is not very opinionated, so we could configure it in some specific ways for individual Halfaker departments and projects.

The SPaMCAST is a great resource for learning more from great thought leaders in the Agile, Process Improvement, and Software Engineering world. Check out the interview at:

And if you’re looking for a Podcast app recommendation, check out Castro for iPhone/iPad.  It has this great “Inbox” concept (works like an Agile backlog, where you can accept things into the backlog and then prioritize/re-prioritize them.

Ideas at the Intersection of Agile, Startup scaling, Business Process Management, and Organizational Design