This is a post is in the Useful Ideas series.

From Reactive to Proactive

Cybersecurity often gets stuck:

• triaging the same types of alerts and events that came yesterday
• gathering the same kind of data to answer questions that were asked for last audit
• finding more of the same classes of security bugs in software
• playing whack-a-mole patching the worst vulnerabilities
• writing up risks similar to ones found during the last business initiative

If you aren’t in cybersecurity, you’ve probably seen a similar predicament in your domain. When a team is constantly in reactive mode, it feels inescapable. I can’t drop any of these required activities. Where would I find the time to change things?" But finding a time to invest in doing less of these activities is the only way to break the cycle.

In my work with organizations, I use a several methods to break this cycle, but I want to share one option with you here: routine postmortems.

You’re likely familiar with a variety of techniques for diagnosing how something went wrong. Five Whys, Root Cause Analysis, Blameless Postmortems, and more. If run well, these can be a very powerful tool for understanding the process, system, and even cultural problems that led to a breakdown. They also level up the organization through knowledge sharing and by implementing changes that stop the same type of problem from resurfacing.

However, if your organization is in reactive mode, you probably don’t feel like you have the bandwidth to perform these analyses for all but the very worst of events, and even when you do, you struggle to find time to implement any changes that would prevent the problem from reoccurring.

Shifting from ineffective formal emergency retrospectives to ongoing proactive analysis requires a cultural shift.

Routine Postmortems allow you to start to build the change into the fabric of your organization.

Implementing

Start small. Select a recurring time for the team to meet (somewhere between weekly and quarterly), or reserve some time in an existing meeting cadence. In preparation for the meeting, the team(s) should bring one reactive event from the last period for each functional area, along with an initial analysis. They should not spend much time on the analysis (less than the meeting itself is booked for). It’s better if these are not full emergency incidents. For example, within cybersecurity, items could include:

• a SOC alert
• an audit or pentest finding
• a vulnerability
• a configuration error
• a design weakness
• an unmitigated risk

Walk through a light version of your chosen diagnostic process, giving extra opportunity for team members to ask questions with nonjudgmental curiosity and to chime in with additional ideas on what upstream changes could have avoided the problem.

Go through as many categories as you have time to go through, but it’s ok if it’s just one! (Simply rotate the focus category next time.)

It’s better if this isn’t heavy with formality, but it’s perfectly fine to jot down takeaways and decisions.

When It’s Working

• preparing for the meeting, and even knowing they will be preparing for the meeting, gets people re-orienting their mindset towards problem prevention over firefighting
• silos of problem-responding are breaking down, people are learning from each other, and solutions (which often require cross-team collaboration) are emerging
• people are seeing that “an ounce of prevention is worth a pound of cure”, and that the effort invested is freeing up time for more strategic work

Failure Modes

Blamestorming: it’s tempting to criticize an initial analysis or to focus on people instead of problems. Use your facilitation skills to align the conversation to the future, not to the past. Practicing this routine will help the team improve at both analysis and problem-solving.

Giving Up on Ops: routine postmortems aren’t an excuse to stop responding entirely. Remember this is a method to carve out a slice of time to turn the ship.

Lack of Follow-Through: if people are having great ideas, but nothing is changing, then you likely have execution problems. That’s another topic, but one thing you can try is picking the quickest win from each session and making sure the right person has ownership to drive that result.

Something Else?: If you’ve tried this and run into other problems that you want to debug, I’m happy to help!

This is a post is in the Useful Ideas series.

“Working in Public” or “Working with the Garage Door Open” or “Working with the Garage Door Up” are related concepts that invoke the idea that for some work, it is better not to toil in secret.

Potential benefits to you: rapid & diverse feedback, getting assistance, finding collaborators, finding people who would benefit from your work

Potential benefits to others: keeping collaborators updated, helping others learn from your mistakes, helping people “not in the room”

This is a post is in the Useful Ideas series.

People sometimes say “it’s easy to criticize” but how easy is it to criticize well?

Many of us often find ourselves in situations where we are called on to be critical. As a cybersecurity and product security leader, this is one of my core job duties! So, I thought I’d share some of the lessons I’ve learned (often, the hard way!) about criticism.

Criticism is not the same thing as feedback

While it’s tempting to think all the same rules apply, there are some different aspects to consider. I’ll write about giving useful feedback in a different post. If you’re in a mindset of giving constructive feedback, consider reading that commentary instead.

Criticism is not about blaming

Finger-pointing is rarely helpful. Good criticism seeks to get to the heart of the matter, so it often involves considering the context of the situation, the processes/structures/systems that produced the outcome, and the variety of factors that contributed. If you find yourself wanting to blame someone, check your motivations.

Criticism is not for it’s own sake

If the criticism isn’t leading to learning or change, then it is not valuable. If you are not prepared to help with that learning or change (whether through recommendations, support, or addressing a problem), it is not valuable. If it is not delivered to the people that are best positioned do something about it, then it is not valuable. If it is not delivered in a context and setting where the audience is receptive, then it is not valuable. If you are not trying to drive a good outcome, check your motivations.

Good criticism is difficult, and a lot more could be written here, but I hope these warnings will help you learn from some of my own experience giving it.

This is a post is in the Useful Ideas series.

This is a framework to guide organizational design decisions, based on three directions: inside-out, outside-in, and upwards. Most of us tend to primarily consider one of these directions, so this framework helps us to evaluate the other directions, as well.

As you evaluate these factors, there will be tradeoffs to make, but considering each of these directions helps you to make informed tradeoffs and to mitigate the downsides of your approach.

For each direction, I’ll give a brief glimpse of an org design that highly prioritizes that perspective often at the expense of the other perspectives.

Note: I believe these principles are relevant to many types of organizations. However, I chose to use consistent and simplified language where possible. So, when you see “customers”, for example, you may need to mentally substitute this with “stakeholders”, “boundary partners”, “constituents”, “members”, “clients” or whatever is the appropriate term for the type of organization you are designing. Do this for other terms, as well.

Inside-Out: Delivery

The inside-out direction focuses on how a team is aligned for delivery. It considers questions such as:

• Is it easy to get quality output & results through the system?
• Have we limited dependencies so that there are reduced handoffs and waiting?
• Do we have all the needed skills and competencies within the team?
• Are roles and responsibilities clear?

Extreme example: the team is fully self-contained and has a highly-structured production line.

The inside-out direction is about creating a structure that supports the execution of the strategy and the delivery of value to the customers.

Outside-In: Customers

The outside-in direction focuses on how customers engage with the organization. It considers questions such as:

• Is it easy for customers to get support?
• Do customers know where to go for support, and are there limited places to go?
• Are we building rapport and trust with customers?
• Are we aligned to anticipate and respond to customer needs and expectations?

Extreme example: each customer has a personal ambassador to the organization who is fully equipped and empowered to address the customer’s needs.

The outside-in direction is about creating a customer-centric culture and a customer-oriented structure.

Upwards: Expertise

The upwards direction focuses on how team members gain domain knowledge, skill, and ability to troubleshoot. It considers questions such as:

• Do people responsible for delivery get significant exposure to problems?
• …and are they incentivized to understand and solve them?
• Do team members get practice & timely feedback that hones their skill & knowledge?
• Are we helping people become adept at their craft and greater in wisdom?

Extreme example: for every offering, team member(s) are responsible for the complete lifecycle from initial design to ongoing support.

The upwards direction is about creating a growth-oriented culture and a people-oriented structure.

Summary

Each direction represents a different perspective on how to align the structure, roles, and competencies of the organization with its strategy, culture, environment, customers, and people. The framework helps to evaluate the tradeoffs and benefits of each direction, and to create a balanced and effective organization.

This is a post is in the Useful Ideas series.

When discussing contributions, it’s often important to address both the me and the we.

This can apply in many situations:

• both accomplishments & problems
• both personal & professional

Addressing both the “me” and the “we” is important not just because the personal and the collective are both important, but also because of the systems and relationships between them are important.

Example:

• When I interview someone and they focus on what their group accomplished, I don’t get a useful understanding of their capabilities & skills. When I interview someone and they focus on what they personally accomplished, I wonder if they work well with others. When I interview someone who addresses both, I can better understand the whole picture of the environment they were working in and how they made an impact in that environment.