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.
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).
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:
- Maintain a current list of all the IT hardware (equipment) you use
- Maintain a current list of all of the software applications you use
- Invest in, and use frequently, a vulnerability scanning tool (e.g. Tenable.io) to identify security holes and then go fix them
- 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.
- 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
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.
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.
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.
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.