Homo Socialus in the Age of Distraction - key takeaways

As I discussed in my TFT14 talk, it is easy to be overwhelmed by the activities from social media. Multitasking won't help. Ignoring or demonizing the tools is a disease worse than the cure. Don't despair - we can take control by being more deliberate in how we use social tools.  Here are some simple ways that can help.

Determine what success means to you

You have more options in how to live than any of your ancestors. Choose to live a meaningful life. Ask yourself:

• What do you want to be? (NOT "What do you want to have?" - we are human beings, not human havings!)
• What do you want to experience?
• What relationships do you want to build?

Write them down and look at them every day. These items are where you want to focus your attention.

Shape your environment for success

Your attention is your most valuable resource. Treat it as such. Turn off alerts, notifications, etc by default. Limit who can interrupt you to the people and ideas that matter. 

Set smart boundaries around social tool usage. Put distracters away when you need to focus. Set aside time each day to review your feeds.

You will fall behind on occasion. Don't panic! Let go instead. You do not have to keep up with everything. 

If you start to get overwhelmed, take a deep breath. Then start pruning your feeds. What no longer helps you be successful? Don't apologize for unfollowing, hiding and ignoring what no longer works for you. 

Build relationships

Success is not a solo sport. Connect with others. Instead of posting what you had for lunch, reach out. We feel closer to people we communicate with regularly. Don't mistake this for following someone, though. Communication is a two-way street!

When you are connecting with others, be there and be authentic. Use technology to support the conversation, not instead of conversation. If the other person starts to tune out, shift the discussion to something they are interested in. Or end the chat - respecting their attention is important too!

Use the attention you get

Learn from everything you share. Every response is useful, even no response. 

• Positive response - keep it up!
• Negative response - refine and adjust
• Trolling/hate - don't respond, but don't stop because you are doing something that is attracting attention
• No response - reassess and ask for feedback from people you trust

Lastyly, be a venture attentionalist - invest your attention in resharing and encouraging others that create great content but don't have a lot of attention. This helps them and helps you too!

This is a rich topic and I would love to hear your thoughts on it. Reach out to me here, on Google+, or on Twitter. Best wishes on your journeys!

My 2014TFT Proposal - Homo Socialus in the Age of Distraction

There are many ways to use social media, and most of them are lousy. Join me as we examine why Homo Hermitus and Homo Multitaskus are headed for extinction. What traits can help you join the rise of Homo Socialus? 

I've been online for 20 years and a lot has come and gone. I have learned a few things and look forward to sharing them with a global audience. Thank you for your consideration!

The ITSM acid test for People, Process, and Tools

The ITSM trinity of People, Process, and Tools is most evident in reporting. If all three corners of the triangle are not in alignment, the following issues will be evident:

• If PEOPLE do not have the proper incentives and deterrents to encourage desired behaviors, reports will often have missing or incomplete information. This is because only enough information is captured in records to allow the person to meet their needs, while the needs of others are unlikely to be met.
• If PROCESSES are not defined, agreed, communicated, and trained, reports will have information that is disjointed, duplicated, and inconsistent between groups and team members. This is because different areas are applying different standards to how they capture information in records.
• If TOOLS are not properly configured, reports will not aid analysis required to determine trends and enable effective decision making. This is because the tool does not correlate information well, or is unable to access information in a manner to allow for trending.

How do we avoid these challenges? 

• Ensure that processes are more than documents in a binder. They must serve as agreements between teams on how work will be performed.
• Develop tool configurations in concert with process development. This must be an iterative approach as process development should drive tool selection and configuration, while tool capabilities may impose limitations on a process.
• Train staff on the intent of the process and how to use the tool to enable the process.
• Publish clear standards on how information created during process execution should be captured in records.
• Sanction appropriate rewards and reprimands to drive adherence to norms and rules.
• Monitor and improve all of these elements.

Getting the ITSM trinity working in concert will transform an ITSM practice into a value engine for the enterprise. That's the best kind of report!

The most neglected role in IT Service Management?

Pop Quiz:

• Who do most people in your organization go to first when there is a notable Problem?
• Who provides your final IT sign-off on a significant Change?
• Who defines the available Service levels?

Hopefully, your answer to all 3 questions was the same - the appropriate Service Owner. Sadly, in many organizations this is not the case. The ITSM organization is really a process organization. Even if the process owners try to focus on process improvement, they get sucked into being the default service owners for every IT Service. In trying to pull double duty, they often make little progress on either front. 

A friend of mine recently reminded me that Senge's Fifth Discipline calls out focusing on "highest leverage" points. One of those points for IT Service Management is clear accountability and authority for IT Services. A motivated Service Owner can often overcome poorly defined or nonexistent processes. 

If you're early in your ITSM journey, it's easy to get focused on all the processes described in ITIL. Don't fall into the trap of doing IT Process Management - it's called SERVICE Management for a reason!

My submission for TFT13

It's time to put the "Manage" back in IT Service Management - the ITSM way!

In my TFT13 presentation, I will apply Service Management thinking to the four domains that today's IT Manager must succeed in:

• I - great managers begin by managing themselves effectively
• Team - great managers build great teams with their staff and form great teams with their peers
• Stewards - great managers understand and deliver against the needs of their direct supervisors and other organizational leaders
• Marketplace - great managers respond to and shape their customers, industry, and society

For each domain, I will show how good practices from frameworks such as ITIL and COBIT 5 apply. I will also translate those ideas into specific actions you can take immediately to increase your value. 

After over 17 years in IT and over a decade in leadership positions, I have learned a lot about what works - and what doesn't. I would be honored to share some of these lessons with a global audience. Thank you for your consideration!

People Being People

This post is about the critical role people play in ITSM efforts. It is inspired by recently getting the pleasure to discuss ITSM with Pink Elephant's Troy DuMoulin. He shared a blog about rethinking the common mantra of People, Process, and Tools and I'd like to expand on this line of thought a bit.

I created a graphic that I think is a more accurate reflection of the relationship between these three pillars of how work gets done.

• People Being People - I first heard about the concept of jen from Alan Watts. In the context of ITSM, we can never forget that people are going to behave as people throughout history always have. They will forget things, they will sometimes take advantage of others, they will break rules to help others, and they will behave in all other sorts of noble and depraved manners. You can't ignore it, and you'll always have surprising and unexpected behaviors to keep things interesting.
• People Executing Process - Processes don't execute themselves. Furthermore, people don't truly execute a process, they execute their understanding of a process. Troy shared a great quote on this topic - "the tangibles are not the deliverables". The reason to create documentation is to facilitate a common understanding among people. Otherwise it's just ink on paper on a shelf!
• People Employing Tools - Tools are powerful, yet they can never guarantee quality or effectiveness. People will employ tools to do things they consider valuable, and "fire" them if they get in the way. That may or may not match up with your intent! For instance, if a Service Desk analyst values efficiency over data quality, don't be shocked when they figure out the quickest way to record a valid Incident record so they can get to the next caller. 

The key takeaway is that we tend to fall short of what people need to adopt ITSM. A great approach to use in ITSM is the Balanced Diversity portfolio advocated by Karen Ferris. Whatever approach you take, give yourself some slack when your improvement efforts are impacted by people factors. After all, you're people too!

Antifragile ITSM

This post is about applying antifragile thinking to ITSM, particularly in the realm of Change Management. I'm a big fan of Nassim Nicholas Taleb, the author of Fooled by Randomness and The Black Swan. I'm currently reading his latest, Antifragile, and it is thought-provoking as his previous works.

A key point in NNT's works is that we often fall into traps because we believe that we can predict the future based on our understanding of the past. While this is true in some domains, we can get ourselves into a lot of trouble when we do so blindly.

A simple example is building a house in an area prone to flooding. The high-water mark is often used to indicate where it is safe to build. But that high-water mark would have been considered safe before that flood occurred! Therefore, we cannot blindly assume that we have seen the worst-case scenario.

In the world of Change Management, managing risk is of the highest concern. Most risk schemes use some combination of projected impact and likely probability to assign risk. The difficulty, as we have seen, is that probability only works when we know the likelihood of outcomes. And in the real world, we don't!

So what should we do instead? NNT suggests that we use fragility as a risk measure. The idea is simple - if there is more downside to a variable than upside, we need to limit our exposure to that variable. If there is more upside, then we don't need to worry about it. Let's see how this idea works on the "7 Rs" that are often used in Change Management.

Variable	Fragile	Robust	Antifragile
Who RAISED the Change?	An individual limited by what they know and expect	Standard Change with pre-defined expectations	Group effort that accounts for multiple perspectives
What is the REASON for the Change?	Service reasons directly related to desired outcomes	Standard Change with pre-defined relationships	Technical reasons unrelated to the IT Service(s) affected
What RETURN will the Change deliver?	A failed Change will reduce the value of overall Services more than a successful Change will increase their value	The Change has no effect on the value of overall Services regardless of success/failure	A failed Change will reduce the value of overall Services less than a successful Change will increase their value
What RISKS are there if we do or do not carry out the Change?	The Change could interrupt one or more Services if it fails	The Change will not positively or negatively affect IT Services	The Change will only affect Services already unavailable (e.g. Emergency Change to restore service)
What RESOURCES will be required to perform this Change?	The Change requires resources limited in their availability	The Change only requires resources in ample supply	The Change will require less resources than it supplies
Who is RESPONSIBLE for this Change being performed?	The Change can only be performed by a subset of the team with confidence	The Change quality is the same regardless of who executes it	The value of learning the organization receives from others performing the Change is greater than the potential reduced quality of the Change
What RELATIONSHIPS are there between this and other Changes?	The Change may affect other Changes negatively	The Change does not interact with other Changes	The Change will only positively impact other Changes

Thinking in this way causes us to focus less on trying to predict what will happen and more on limiting downside. The benefit is that even when we are lousy at predicting the future, we are less likely to be hurt by it. And since we are all lousy at prediction, we end up with a system that is less impacted by our inevitable failures.

How can this thinking be applied to other areas of ITSM? More to come on this topic in the future.