Category: productivity

Join me for iDEAFest2020 on April 21-22: Agile, Leadership, and Cyber Security

Posted in CIO, CISO, cybersecurity, leadership, lessons-learned, Process Improvement, productivityLeave a comment

With so many in-person conferences and events cancelled, I’m excited to be presenting at iDEAFest 2020, a virtual (all online) 2 day conference on April 21 and 22.

The two-day event will be all online, and only costs $99 to attend.

Speakers will include:

  • Ty Schieber, Chair of the DoD Cybersecurity Maturity Model Certification (CMMC) Accreditation Body (AB), will keynote the first day, providing updates on how CMMC and how the next several months will look
  • A panel of Cyber Security experts, including several CMMC AB members will discuss CMMC
  • Jim Bouchard, “The Sensei Leader,” will be keynoting the second day, focused on self-organization and leadership
  • Jeff Dalton, author of Great Big Agile, will be talking about how NOT to judge Agile maturity
  • Jeremey Berriault will talk about how Agile is changing leadership and organizational culture
  • Ron Lear and Michael West will discuss CMMI 2.0, Scaled Agile Framework (SAFe), and how to build high performing organizations
  • Tim Zeller will discuss “Agile Performance Management,” a new idea for effective performance reviews

I’ll be presenting on the fundamentals, and lessons learned, of building an enterprise information security program.

Sixteen speakers, two days – and all for only $99! I hope you’ll join me for the conference and the virtual happy hours/Q&As at the end of each day. Register at iDEAFest2020.org.

To Get to the Point, you need to Know the Point

Posted in agile, leadership, lessons-learned, productivity1 Comment

It sometimes feels like you need lots of words/pages/slides to look/sound credible, but great communicators go through the hard work of refining their idea/message/recommendation down to a crisp, easy-to-digest message.

“I didn’t have time to write you a short letter, so I wrote you a long one” – Mark Twain

This concept is so valuable in so many ways — for example:

  • Getting to the root cause of an issue requires that you continue to ask “Why did this happen?” to get past the symptom/second-order effects, and get to the root (see 5 Why’s Technique)
  • In Product Management, it’s tempting to add many variations/options/different products, but it’s powerful when someone works on refining that down, like the classic story of Steve Jobs in 1997, created a simple grid with 4 product categories and shifted Apple to only make 1 product in each category, with a focus on excellence
  • When communicating with others, push yourself to try to get to the point faster — the US Military communicates very efficiently in this way, often using things like a Bottom Line Up Front (BLUF) or Executive Summaries (not to be confused with Introductions) to rapidly communicate the point, instead
  • When launching a new IT project, don’t rush through exercises like a project charter or determining the business case/justification/problem (see Digital Services Playbook, Play #1) — invest time in peeling back the layers of really understanding what the real problem you’re solving is — it will be well worth it!
  • Amazon has a meeting culture where the meeting requester/leader crafts a 6 page memo with the recommendations/context, and everyone in the meeting silently reads the memo to start the meeting.  The quote below shows their approach and their expectation that a good 6-page memo should take a week or more to develop and refine into a high-quality product.

We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of “study hall.” Not surprisingly, the quality of these memos varies widely. Some have the clarity of angels singing. They are brilliant and thoughtful and set up the meeting for high-quality discussion. Sometimes they come in at the other end of the spectrum.

In the handstand example, it’s pretty straightforward to recognize high standards. It wouldn’t be difficult to lay out in detail the requirements of a well-executed handstand, and then you’re either doing it or you’re not. The writing example is very different. The difference between a great memo and an average one is much squishier. It would be extremely hard to write down the detailed requirements that make up a great memo. Nevertheless, I find that much of the time, readers react to great memos very similarly. They know it when they see it. The standard is there, and it is real, even if it’s not easily describable.

Here’s what we’ve figured out. Often, when a memo isn’t great, it’s not the writer’s inability to recognize the high standard, but instead a wrong expectation on scope: they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more! They’re trying to perfect a handstand in just two weeks, and we’re not coaching them right. The great memos are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two. The key point here is that you can improve results through the simple act of teaching scope – that a great memo probably should take a week or more.

Jeff Bezos, Amazon Shareholders Letter

You’re Not Good at Multitasking

Posted in leadership, lessons-learned, productivity1 Comment

In computer science, the concept of a computer’s processor switching from one system to another is referred to as context switching, where the computer switches from updating your gmail browser page over to your Microsoft Word application, etc.  Computers are very good at this, but people are horrible at this.

Everyone, myself included, thinks we’re great multi-taskers who are great at juggling lots of things at once, and we’re so much faster doing that than stopping to focus on one thing at a time.  While this sounds intuitive, it’s usually horribly wrong.  Not only are you slower overall when juggling lots of different things, you also can’t significantly advance the important/complex work — instead you’re often attracted to, and only make progress in, tactical/shallow work.

Cal Newport, a professor at Georgetown, has written a great book (Deep Work) on this concept of how important/valuable work happens when you ignore everything else, you don’t check Facebook every 6 minutes, and you instead really focus on the important, complex work that is valuable.  A similar book I’ve heard great things about is Nicholas Carr’s The Shallows.

There are techniques that can help in this vein, like the Pomodoro Technique, where you intensely focus on a single task for 25 minutes, take a 5 minute break, repeat that cycle 3 more times, and then take a half-hour break.

Another concept is to check your email only a few times a day (2-3 times), and intensely review/groom/action your inbox during these times, instead of checking in on it every few minutes, you’ll be much faster.

Paul’s Graham wrote a great essay, Maker’s Schedule, Manager’s Schedule, about the difference between the work schedule of makers (e.g. software developers, business analysts) and managers (leaders who are focused on making decisions through a series of reviews and meetings), which is related to this concept that if you’re a maker, you need to dedicate significant blocks of time to advancing important/complex things.

Not only is focusing on one things overall faster, it can also be a much more effective way to deliver value more frequently — instead of slowly advancing 10 big initiatives, if you finish 1 before moving to the first, it means that first thing got complete and delivered value faster, which is great (one of Agile’s great values is encouraging/forcing people/teams to actually prioritize their work and then force prioritized progress within timeboxes — check out Great Big Agile by Jeff Dalton for some great techniques for this within a team/organization context).

It’s hard to do in today’s frenetic, distracted world; but when you can carve out intensely focused time, you’ll accomplish important things much faster than you would trying to advance everything all at once.

(James Hance is an awesome artist, who does amazing mashups.  This one, The Meep is a great mashup of Edvard Munch’s 1910 The Scream and Beaker from the Muppets — you can buy a print of The Meep at https://www.jameshance.co.uk/collections/regular-prints/products/the-meep)

It’s Tempting, but DO NOT skip Planning and Premortem

Posted in agile, leadership, lessons-learned, productivity, strategy1 Comment

So many leaders or teams quickly move too quickly (or skip entirely) the early parts of a new project/initiative, failing to invest real time in wrestling with questions like:

  • Should we do this project? (This question is skipped way too often — think about investing in exercises like a business case or a project charter to ensure everyone is clear on the value/ROI)
  • Who are all the stakeholders/users (not just the primary one(s)) who are affected or will be affected by this project? What do they really want/need?  What are their pain points?  What are their issues they don’t even know they have?  (Note: The whole field of User Experience (UX) and User Centered Design (UCD) has many, many tools and techniques to help navigate this area)
  • Do we really understand why we’re doing this project? (What is the business problem?  What value will the ‘business’ receive at the end of the project?
  • Do we understand the different ways we could break down the value we’re going to deliver, to understand the trade-offs in different ways to approach the project (e.g. could we deliver value earlier and get validation (reduce risk) by starting to focus on a specific Minimal Viable Product instead of running in the direction we think is ‘most efficient’ for the final product (which almost certainly isn’t the most efficient way, because there’s so much we don’t know at this point) (See The Startup Way by Eric Ries)

After we get through those phases, we should avoid the desire to jump into execution by taking a breath and asking ourselves:

  • Conduct a Premortem (see HBR Premortem article):  Get the team together and ask everyone to imagine this project has failed spectacularly — start writing down, independently, all the ways it failed, and then have the group discuss (Heard about this from Seth Godin)

Clayton Christensen, in his book How Will Your Measure Your Life? encourages people to ask a great question early on in a new project/initiative:

What assumptions must prove true for this plan to work?

New Top Career Book Recommendation

Posted in books, leadership, lessons-learned, productivityLeave a comment

When I’ve chatted with people in the past about how to plan/manage their careers, I would often to refer to the book What Color is Your Parachute as my go-to recommendation, as it’s packed with great resources (a great friend of mine referred me to its Flower Exercise many years ago).  But recently I’ve been listening to Clayton Christensen’s (who recently passed away) How Will You Measure Your Life? (Harvard Business Review has an article about the book here), and it’s now going to be at the top of the list, along with What Color is Your Parachute as a recommendation for people to invest the time in reading.

Christensen is famous as an Harvard Business School profession who wrote extensively about disruption, and I’ve enjoyed his writings on that topic; but this book is a great read in a very different direction.  This book is focused on asking great questions about how to plan and run your life, with a focus on how to measure ‘success.’

He starts the book talking about how interesting it was to see at school reunions how different people’s lives evolves, and how they prioritizes their time and energy.

He shared some great concepts to be thinking about through your career like:

  • Deliberate vs. Emergent Strategies: The different between having a clear goal and working toward it vs. being open to new opportunities and seeing where they take you
  • Identify Assumptions: Before making a big decision, thinking about ‘What would have to be true for this to success?’, where you invest time in thinking about what assumptions/dependencies are inherent in this thing you’re considering (similar to investing time in a pre-mortem)
  • Resource Allocation: How will you invest your time and energy?  Be careful not to invest it only where short-term feedback/gains show up (such as work) and not invest where it takes a while to see feedback/gains (e.g. relationships with your spouse, children, friends)

I’m only 40% through the book, but it’s already so good I have to share it.

Simple Meeting Best Practices

Posted in leadership, productivity1 Comment

Many people have written great blog posts (see Seth Godin’s blog) and books (see Michael Hyatt’s No Fail Meetings) on the topic of planning and running meetings well.

Here’s a few tips on things you, as a meeting leader, should ensure:

  • Before the Meeting
    • There’s a clear owner of the meeting who will prepare for, present information, and “own” the meeting
    • The time allocated to the meeting is appropriate to what is needed, not just a time slot that fits in the calendar
    • There’s no better way to move this forward than to have this meeting. (Ensure a meeting is necessary before scheduling it, as it’s a very ‘expensive’ investment of time
    • If you organize and schedule a meeting, always include a specific, detailed purpose and agenda in the meeting invite
    • Avoid coming “empty handed” to a meeting if you’re the organizer – come organized with a draft approach, presentation, documents, etc. to accelerate the meeting and use people’s time more efficiently
    • Ensure you’re prepared, so you’re not spending the first 5 minutes of the meeting pulling up the right documents while everyone watches
    • When sending out a meeting invite, include links (instead of document attachments) when sharing documents to make version control easier AND know that based on calendar sharing, actual attachments can be seen by anyone who can see your calendar – make sure you don’t attach docs that are sensitive in nature
    • Clearly communicate who will be taking notes, if anyone, and how actions will be captured and/or tracked after the meeting
  • Starting the Meeting
    • Review attendance to ensure the right people are there
    • Clearly state the purpose of the meeting
    • Clearly state the desired outcome using simple language like “This is what I want to happen from this meeting: ___”
    • Clarify the type of meeting:  Is this to review a draft approach? Is this to gain someone’s approval? Is this to work on an approach that isn’t created?  Something else? (see https://seths.blog/2009/03/three-kinds-of-meetings/)
    • Present the agenda clearly and get feedback from group on recommended revisions
  • After the Meeting
    • Follow up with quickly with pictures of whiteboards, action items, etc.
    • Ensure every action item has a single owner/assignee (group assignments aren’t clear re: ownership)
    • Consider tracking the actions in a system to track them to closure (e.g. Atlassian Jira) to ensure they’re not “lost” among competing priorities

Know when Working Harder isn’t going to Work

Posted in leadership, lessons-learned, productivity, strategyTagged Leave a comment

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.

Don’t Point at Problems, Attack Them!

Posted in lessons-learned, productivityLeave a comment

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

Posted in miscellaneous, productivityLeave a comment

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).