Breaking Free from Negative Behaviors: A Guide to Self-Reflection and Change

It is a fundamental human instinct to believe that we are good, ethical, and fair. However, the harsh reality is that we are susceptible to cognitive dissonance, allowing our self-image to remain unblemished while we unknowingly or even knowingly engage in harmful behaviors. This discrepancy can lead to manipulation, bullying, and other harmful behaviors that cause significant damage to ourselves and those around us.

So how do we confront this dissonance? How do we determine if we are guilty of such behavior, and how do we change for the better? The first step is to accept that we are fallible - that we can and do make mistakes. The next step is to examine our behaviors critically, honestly, and bravely. It's time for us to wake up, open our minds, and commit to positive change.

Identifying Negative Behaviors

Before we can change, we must first recognize our problematic behaviors. Negative behaviors such as manipulation, bullying, gaslighting (making someone doubt their reality), and dismissiveness can be subtle and ingrained in our everyday interactions. We may rationalize these actions as necessary for our success or survival, but the truth is they harm ourselves and those around us.

Reflect on your interactions. Are you respectful and considerate? Do you listen actively and value diverse opinions, or do you disregard views that challenge your own? Are your criticisms constructive, or do they belittle and undermine others? This self-examination requires honesty and courage, but it is an essential step towards positive change.

Understanding the Impact

These harmful behaviors not only affect those on the receiving end but also have a significant impact on us. They can lead to a toxic work or home environment, resulting in increased stress, anxiety, and dissatisfaction. They erode our relationships, breeding resentment and mistrust, and can impact our reputation, limiting our personal and professional growth.

Furthermore, by engaging in these behaviors, we contribute to a culture that tolerates and perpetuates them. We become part of a cycle of negativity and harm, influencing others to adopt similar behaviors and alienating those who seek a more positive, inclusive environment.

Changing for the Better

Change is possible, but it requires commitment and effort. Here are some steps to guide you:

1. Acknowledge Your Mistakes: Acceptance is the first step towards change. Acknowledge that your actions have caused harm. It may be uncomfortable, but it's necessary for growth.

2. Apologize Sincerely: Apologies can mend bridges and demonstrate your commitment to change. A genuine apology accepts responsibility, shows understanding of the harm caused, and promises change.

3. Educate Yourself: Learn about the effects of bullying, manipulation, and gaslighting. Understand why these behaviors are harmful and how they impact others.

4. Seek Feedback: Regularly seek feedback from colleagues, friends, and family. They can provide valuable insights into how your behavior impacts others and suggest areas for improvement.

5. Practice Empathy: Empathy encourages understanding and compassion. Make a conscious effort to understand others' perspectives and feelings.

6. Set Positive Goals: Instead of just trying to "stop" negative behaviors, focus on what you want to "start" doing instead. For example, aim to be more respectful in your conversations or more supportive of others' ideas.

Changing ingrained behaviors can be a challenging journey, but it's one worth taking. By breaking free from manipulation, bullying, and other negative behaviors, we can improve our relationships, promote a more positive environment, and become better versions of ourselves.

Remember, it's not just about avoiding being a "shitty person." It's about striving to be a better person. It's about nurturing a positive, inclusive atmosphere where everyone feels heard, respected, and valued. By doing so, we contribute to our own personal growth and the betterment of our communities.

Our actions, big or small, contribute to the collective environment, and each of us has a role to play. If we all commit to treating others with respect and kindness, we can create a ripple effect that could transform our society for the better.

Commit to Lifelong Learning

The journey to becoming more inclusive and respectful is continuous. As society evolves, so does our understanding of what it means to be inclusive. We should continually educate ourselves, keeping abreast with the latest research, trends, and best practices related to diversity and inclusion. This can be done through reading books, attending webinars, workshops, or even listening to podcasts.

Support from Professional Coaching

If you find the process challenging, consider seeking support from professional coaches or therapists. They can provide valuable insights, strategies, and tools to help you navigate your journey towards positive change. Coaching is not just for 'problem' individuals; it is a powerful resource that supports growth and development.

Recognizing and changing our negative behaviors is not a sign of weakness but a testament to our strength and our commitment to personal growth. It might be a challenging journey fraught with uncomfortable revelations, but it's one that leads to a more fulfilling, respectful, and inclusive life. As we continue to learn and grow, let us not forget to extend our newfound understanding to others, cultivating a culture of respect and empathy.

Change starts with us, one person at a time. Let's take the first step and continue to stride forward, always striving for better.

Challenging Manipulation and Bullying: An Executive's Guide to Promoting Inclusive Leadership

In our increasingly interconnected and diverse world, fostering an inclusive corporate culture is a business imperative. As executives, we must be at the forefront of promoting positive leadership, advocating for diversity and inclusion, and challenging manipulative behaviors that undermine trust and cohesion in our teams.

Unfortunately, we're seeing a growing trend of harmful rhetoric in our society, with manipulation and bullying taking center stage. This behavior fosters division, breeds resentment, and ultimately undermines the success of our organizations. In response to this, it's incumbent upon us as leaders to proactively combat these damaging behaviors and cultivate a more respectful, empathetic, and inclusive environment.

Firstly, it's vital to understand that manipulation and bullying can take many forms. One such form is gaslighting, where individuals are manipulated into questioning their own understanding or perceptions. In the business context, this can manifest as questioning someone's competence, undermining their contributions, or dismissing their concerns. Recognizing and addressing this behavior is critical in fostering a safe and inclusive workplace environment.

Next, we should be aware of the divisive impact of oversimplified arguments and generalizations. In business, complex issues require nuanced solutions, and oversimplifying them can lead to ineffective strategies and frustration among team members. As leaders, we can promote constructive discourse by encouraging a comprehensive and nuanced exploration of the issues at hand.

The "No Asshole Rule", popularized by Stanford Professor Robert Sutton, is a powerful guideline for cultivating a respectful and inclusive environment. It entails zero tolerance for bullies, regardless of their talent or output. By applying this rule, we demonstrate our commitment to fostering a positive work environment where all employees are treated with dignity and respect.

Building an inclusive workplace is not about silencing or marginalizing dissenting views. Rather, it's about creating a space where diverse perspectives are valued and heard. It's about recognizing and challenging harmful behaviors, such as manipulation and bullying, which undermine this inclusivity.

Critics may accuse us of stifling free speech, but this is a misunderstanding. Freedom of speech does not encompass the right to spread hate, manipulate, or bully others. It carries with it the responsibility to respect others, engage in honest discourse, and uphold the values of our organizations. Affirming our commitment to these principles is not oppression; it's a stand against divisive, manipulative, and damaging behaviors.

In conclusion, as executives and leaders, our role extends beyond driving profits and growth. We are stewards of our organizational culture and have a responsibility to foster a workplace that promotes respect, empathy, and inclusion. Let's stand firm against manipulative and harmful rhetoric, and strive to create environments where every voice matters, where diversity is celebrated, and where the dignity of every individual is upheld. It's not just good for business; it's good for humanity.

The Imperative for Inclusivity in Tech

Across industries, the call for diversity, equity, and inclusivity has grown louder in recent years. Nowhere is this truer than in the tech industry. Often hailed as the sector of the future, tech has the unique opportunity, and responsibility, to lead the charge in creating inclusive and equitable work environments.

Inclusivity in tech is not simply a matter of fairness or compliance. It's a proven driver of innovation, creativity, and productivity. However, the presence of non-inclusive individuals in the tech industry poses a significant challenge to realizing these benefits.

Why don't we want non-inclusive people in tech?

At first glance, this question may seem to contravene the very concept of inclusivity. However, when we delve deeper, we uncover the paradox of tolerance - the philosophical concept that if a society is tolerant without limit, its ability to be tolerant will eventually be seized or destroyed by the intolerant. Simply put, to maintain a tolerant society (or industry), it must be intolerant of intolerance.

Non-inclusive attitudes and behaviors in tech contribute to hostile work environments, which in turn, cause talent drain, inhibit innovation, and ultimately, diminish competitiveness. Tech thrives on fresh ideas, unique perspectives, and collaboration - all of which are undermined when people feel marginalized, unheard, or unwelcome.

The value of inclusivity in tech

The tech industry is built on innovation. Each technological advance stems from a desire to solve problems, improve efficiency, or create new opportunities. The fuel for this innovation is diverse perspectives. A diverse workforce brings a myriad of life experiences, ideas, and problem-solving approaches, fostering creativity and innovation in unexpected ways.

Multiple studies have shown that diverse teams outperform non-diverse ones. A McKinsey report found that companies in the top quartile for racial and ethnic diversity are 35% more likely to have financial returns above their respective national industry medians.

However, diversity and inclusivity go hand in hand. Without an inclusive culture, diversity can breed conflict and division instead of collaboration and innovation. Inclusivity is about creating an environment where everyone feels valued and empowered to contribute fully. It's about dismantling barriers to participation and ensuring equal opportunities for all.

The paradox of tolerance

Developed by philosopher Karl Popper, the paradox of tolerance states that if a society is tolerant without limit, it will eventually be taken over by the intolerant, resulting in a loss of tolerance altogether. Therefore, to maintain a tolerant society, it must be intolerant of intolerance.

In the context of the tech industry, this paradox translates to a need for intolerance of non-inclusive attitudes and behaviors. This doesn't mean excluding non-inclusive individuals. Instead, it means creating clear standards of conduct, providing training and education, and holding people accountable when they fail to respect these standards.

However, if non-inclusive individuals refuse to evolve, learn, or respect the values of inclusivity, it may be better for them to exit the tech industry. Not out of spite, but simply because their presence undermines the industry's ability to be a diverse, inclusive, and innovative sector.

Good riddance to non-inclusive individuals in tech

Let's be clear: losing people is never a cause for celebration. Every person who leaves the tech industry represents a loss of potential ideas, insights, and contributions. However, when non-inclusive individuals leave, the net effect can be positive.

Their departure creates space for new talent—diverse individuals who might otherwise have been discouraged or driven away by non-inclusive behaviors. It also sends a clear message to the remaining members of the industry: non-inclusivity will not be tolerated. This can help foster a more inclusive, welcoming, and respectful culture, further boosting diversity and innovation.

The cost of "brilliant jerks"

There's a persistent myth in tech that some individuals are so talented that their contributions outweigh their negative impacts on team culture. These individuals, sometimes referred to as "brilliant jerks," are often tolerated, even revered, despite their non-inclusive attitudes or behaviors.

Research, however, paints a different picture. A Harvard Business School study found that toxic workers, those who engage in harmful behaviors like bullying or harassment, cost companies more than the value they bring. The cost isn't only monetary—these individuals can damage morale, reduce productivity, and cause high employee turnover.

Moreover, studies by Stanford professor Robert Sutton, author of "The No Asshole Rule," suggest that tolerating these toxic individuals can lead to an "asshole contagion," where negative behaviors spread throughout the organization. This not only degrades the work environment but also discourages potential talent from joining the company.

A future of inclusivity

The tech industry is at a crossroads. It can continue to tolerate non-inclusive attitudes and behaviors, with all the associated costs. Or it can take a stand, embracing the paradox of tolerance and creating a culture where everyone is valued, respected, and empowered to contribute.

This transformation won't happen overnight. It requires ongoing commitment from all industry stakeholders—employees, managers, leaders, investors, and customers. It requires clear policies, effective training, and a willingness to hold people accountable. But most of all, it requires a recognition of the inherent value of every individual, regardless of their identity, background, or perspective.

Inclusivity isn't a burden or a concession. It's a source of strength, a driver of innovation, and a foundation for the future of tech. Those who can't or won't understand this may indeed leave the industry. And when they do, we won't mourn the loss. Instead, we'll celebrate the opportunity to create an industry that truly reflects and respects the diversity of our world. And in that, nothing of value is lost.

Why you should be using Behavioral Interview Questions - and how to get started

Over the years I’ve evaluated and interviewed dozens if not hundreds of candidates. From resume reviews, initial phone screens, to formalized interviews I have done it all. The one technique I come back to time and time again is the use of behavioral interview questions - and now I hesitate to do it any other way.

In my experience there are two approaches people will take toward interview questions - what I’ll call the hypothetical question, and the behavioral question.

The first type really is just a hypothetical question - “if you were in this scenario what would you do.” I think these are really terrible questions because anyone with a little bit of knowledge can give a good answer to these types of questions. “How would you approach X” - well I’d approach it the exactly correct way! If I were a surgeon I would wash my hands, make perfect incisions, do everything correctly, stitch the patient up, and they’re ready to go. If I were leading a ski trip and someone got buried in an avalanche I would use my beacon, find them, dig them out.

All of these answers sound great, but they’re all hypothetical, theoretical. You can always give a perfect answer because in your mind, in that perfect world, everything will always go the way you expect it to. Furthermore the answer doesn’t tell me whether that surgeon can actually do surgery safely, and I don’t know whether that ski trip leader actually knows how to deal with the urgency and pressure of an avalanche burial.

So if hypothetical questions aren’t any good, what’s the alternative?

Behavioral interview questions!

You’ll recognize these right away:

“Tell me about a time when…”

“Describe a situation where…”

“Share an example off…”

These are sounding like the start of some good interview questions!

What makes these different? The interviewee can’t just fake it with some knowledge. They will need to go into their memory, into situations they’ve already encountered, and provide examples to answer these questions. This tells us as the interviewer that this person has already done this, or has experienced something like it. Now we know they have some experience that connects them to what we are looking for, that they have approached this problem, or something similar, in the past.

When we do this style of questioning we’re looking for some specific things, and sometimes you may need to guide the interviewee through it to get the answers you are looking for, and this is where the STAR framework can come in handy.

STAR stands for:

Situation

Task

Action

Results

Situation is where we ask for the specific example of something they have encountered and had to deal with, and this is where our starters from above (“Tell me about a time…”) come in. We want them to explain the situation and context including where, when, who, and any other relevant details to bring us to where we understand the situation they are describing to us.

The answer might look something like “That’s a great question and I can think of a time last year when I was working with Client X on PROBLEM.”

Task is where we want to learn about what needed to change. What was the challenge, what was the desired outcome they were pursuing? You can learn a lot about how the candidate things about the problem and their objective in how they answer.

Continuing from the previous example they might say “We were trying to accomplish Y by doing Z, but every time we did we got a lot of resistance from the teams and their leadership - we didn’t really expect this because we thought the change was desired by everyone, but when we discovered we were wrong we knew we had to take a different approach.”

Action is where we want to find out what steps they took - what did they actually do? How did they do it? Why did they approach it that way? Sometimes this is the step where you can start to see cracks - they have a situation, they have a task, but can’t clearly articulate what they did or why they did it - that is a red flag! You can probe a bit during their answer as you have questions to really dig into their mindset, thought process, goals, and approach.

This step in the process may look something like “We decided to do a 2 day off-site team building workshop, and we chose this for a number of reasons. Everyone was already planning to be in town and the agenda was incomplete so we viewed it as an opportunity to really turn things around, we noticed that team trust was pretty low and I had successfully used Five Dysfunctions of a Team in the past to overcome these types of issues, and we knew that the VP and Director - who we viewed as most resistant - were big fans of off-sites, so we decided to move forward with it. In the off-site we decided to do activity A, B, and C because […reasons…].”

The last step in the STAR framework are the results. Ultimately results are very important to us because it helps us understand if the candidate can deliver, can get the outcomes they are looking for, and if not or when they struggle how do they view the unsuccessful outcome and how did they deal with it. What we’re looking for is a clear and concise explanation of the benefits and outcome of the situation they chose. We get a lot of information out of this - are they analytical, do they measure results, can they see how their action impacted the end result, what are their values, how do they approach failure, what did they learn, what will they do next - we can get all this any the answers to many more just from how this question is answered.

I don’t always want to hear stories with positive results either! I start to get suspicious when every story ends with a success and everybody cheering since life doesn’t usually work out that way. I really like when I hear from a candidate that the results didn’t go as they expected, they learned the action they chose wasn’t right, and they had to pivot, reset, or reboot their approach to the problem. A story that ends in failure is OK as long as it’s clear they learned something and intend to adjust or tune their approach in the future.

The results portion answer may be something like “Well the off-site had really mixed results and outcomes - the VP and Director loved it, but the team hated it and felt like it took too much of their time away from regular work. We realized too late that we had been talking to leadership about the event and gotten them excited and on board with the idea, but we hadn’t brought the team along on the same journey. It was kind of embarrassing the first day when half the team didn’t show up, and half of those who did resisted the activities. We actually wound up taking a long break earlier than planned and used that chance to talk with the team and get them more engaged in the process, so the rest of the day, and day 2 went a lot better. We still had to change our plan since the timing didn’t work out because of the unexpected breaks, but in the end we were still able to do some team building and based on the survey we sent at the end we still saw psychological safety go up. So it didn’t go perfectly, and we learned a lot that we were able to apply in the future.”

That’s behavioral interviewing in a nutshell, and the STAR behavioral recruitment framework. Like most things it seems easy when you learn about it, but can be difficult to implement and master. Don’t try to blow up your whole interview process to get going with these! Start small with a couple questions, focus the behavior inquiry around key problems you are having in your space, and ask the same questions to every candidate. You’ll learn a lot as you practice and can work on polishing the questions and your approach as you go.

The more I work with behavioral interview questions when I am the interviewer, the more I appreciate them as the interviewee as well. With a bit of practice, and focusing on your specific accomplishments as part of your interview prep, I find it is actually easier to answer behavioral questions with real experience than it is to answer hypothetical questions. With hypothetical questions I will sometimes start to ramble and then have to ask if I answered the question, where when I am answering a behavioral question I find I can make my answers clear, concise, and concrete.

Feel free to reach out to me on LinkedIn, Twitter, or via Email if you’d like to learn more about using or answering behavioral interview questions or are interested in some coaching to help you prepare to interview - either as the interviewer or interviewee.

You can learn more about STAR from Management 3.0:
https://management30.com/practice/star-behavioral-interview-questions/

Creative Constraints and Chaos Theory

I’m still thinking a lot about creative constraints and wanted to explore some more ideas related to my last post.

Last time I asked you to tell me a story with no constraints, then with the constraint of “about a princess and a purple elephant” and remember the difference in those two states. Now think about how different constraints would lead to a completely different outcome - even just changing it to a normal grey elephant sets up a different set of constraints and in the end an entirely different story.

I’m reminded of Ian Malcolm’s explanation of Chaos Theory in the book Jurassic Park by Michael Chrichton. You can read the entire thing here https://jurassicpark.fandom.com/wiki/Chaos_theory but to summarize one of the main points:

If you fire a cannon ball of a certain weight out of a cannon pointed at a certain angle with a certain amount of gunpowder and then fire a slightly differently weighted cannon ball out of a cannon at a slightly different angle with a slightly different amount of gunpowder then you would expect them to land at almost the same spot.

But if you take a complicated system like weather and do the same thing to the temperature, humidity, wind, and other factors you will wind up with vastly different outcomes - a hurricane instead of a sunny day, a vastly different trajectory, or dies out instead of becoming more severe.

Sometimes creative constraints are like the weather system - with a purple elephant your story might be more fantastical, a grey elephant more reality based, and as a result those stories are completely different.

This means it’s worth experimenting with small changes to your constraints to see what happens - it could have a big impact.

The real point of Scrum (and other agile frameworks)

I’m not the first person to say the agile world has gotten away from itself, and I constantly see teams going through the motions without understanding the real why behind the way they’re working.

It’s about CREATIVE CONSTRAINTS!

That’s it. These are patterns of constraints that have worked well for others in the past, and they are sharing them so you can learn from their experience. One of the best ways to learn is to try working with the same constraints they set up and see what comes out of it for you.

Constraints sounds negative, but they’re really not. In fact they are necessary for success and will contribute to more creativity and better problem solving than if there are no constraints.

Riverbanks are constraints for the flow of the river, without them flooding would happen constantly and the water would be unpredictable.

A specific product or market focus is a constraint, and helps you to zero in on what you’re building.

Let’s try a little experiment, don’t look ahead!

First task:

I want you to tell me a story. That’s it, that’s the ask - what can you come up with in 30 seconds?

.

.

.

.

.

.

.

.

how was that? Easy? hard?

how did that feel? did you like the sky being the limit?

.

.

.

Second task:
I want you to tell me a story about a princess and a purple elephant

30 seconds, GO

.

.

.

.

how was that? different? the same?

what did you like better? what was worse?

was one easier than the other?

For most people the second task is substantially easier. Why? Constraints!
In the first one you have to come up with everything, there’s nothing to get you started. In the second one you have some potential characters, which can lead to ideas for locations, and ultimately makes it easier for you to be creative and come up with a story.

Let’s go back to Scrum. It has some constraints:

• we’re going to use short timeboxes

• we plan for the iteration in planning

• we make a goal and pick work as our ‘commitment’ for the timebox

• we have a daily standup

• we review our sprint at the end

• we reflect and retrospect, taking experiments to improve our ways of working back into our process

• we deliver shippable code each iteration

These constraints are meant to relieve your mind of some burden of coming up with the rules yourself, but also creates a nice structure for us to work inside of. We have to plan small. We have lots of opportunities to improve. We need to work together to succeed.

You don’t have to follow Scrum or Kanban Method or any other existing framework, process, or set of tools, but if you don’t you’ll need to be a lot more diligent about identifying and experimenting with various constraints and staying on top of your ways of working to be effective and not just flying by the seat of your pants. Personally I think it’s worth working a little slower and taking more time to talk about how we work and talking about and planning the work, along with spending a lot more time learning together, but that’s not for everyone and Scrum is a very useful starting point for your ways of working.

Just remember doing Scrum isn’t about “DOING SCRUM” it’s about utilizing a set of constraints that have worked for MANY folks before you to maximize your creativity and help you deliver valuable working software that your users will love!

Sprint review is the most important Scrum event - and the one you’re probably doing most wrong

Call it a ceremony, event, or ritual - the most important one in Scrum is the Sprint Review. Equivalent activities in other frameworks can take it’s place, or whatever you call yours, as long as a few things are happening.

Let’s get this out of the way first - THE SPRINT REVIEW IS NOT A DEMO. A demo might be a small part of your sprint review, but demoing is not the point. Work should be completed in small chunks throughout the iteration, which means we should be getting acceptance throughout the iteration, which means we need to demo completed work as soon as it as done, as soon as possible, throughout the iteration. If the first time your stakeholders or PO are seeing your completed work is during the Sprint Review you should probably focus on that before trying to improve your reviews.

If it’s not a demo, what is it?

The sprint review is the place to actually look back at what you worked on and how it went, what new information has come to light, and how that’s going to change your plan going forward. If you work in sprints and do the goal or commitment thing, then this is where you review how well you did against your plan to help you adjust your plan going forward. If you’re working in a flow based system like the Kanban Method this is when you look at things like your throughput, cycle time, SLEs, and other information to help you better manage your work.

So what should a sprint review look like? What do we do? How do we run one?

Using the Scrum Guide as our starting point we’ll timebox it to 90 minutes for a 2 week sprint.

I’d suggest to split it into 2 phases - start at 45 minutes each and see where the right balance is for you - the first phase is for the Scrum Team, the second phase includes stakeholders.

For the first phase with the team we’ll:

• review our plan vs reality for team availability and actual time in the sprint

• review each work item that was complete, what did we learn?

• review each work item that was incomplete, what did we learn?

• based on those things we learned (uncovered dependencies, clearer understanding of effort required, alternative solutions uncovered) how will this impact any future plans?

Phase two we’ll get our stakeholders in the room and:

• share what was complete and what was incomplete and how this impacts the current plan

• demonstrate the entirety of the product increment - this means show the new functionality in a production like environment as ready to deploy - ideally a key stakeholder would interact with the product instead of this being a demo by the team or PO

• discuss information about product strategy, market fit, stakeholder needs, or anything else that impacts or requires adjustment to the current plan based on the information shared and the functionality that is complete

Depending how you look at it this is either the last event or the second to last event in your sprint (some consider the retrospective in between sprints, others say it’s the last event in the sprint).

If I’m running 2 week sprints that start on Wednesday and end on a Tuesday my preference is to have the sprint review on Tuesday morning - the sprint officially ends the minute the review starts (usually the first activity in the review) - we do the Retro on Tuesday afternoon, then planning on Wednesday morning before kicking off our sprint Wednesday afternoon (1 week sprints are very similar, just more compressed timeboxes)

With these thoughts take some time to reflect on your review and see if there’s anything you can change to make it more effective and get some of the real intended value out of it!

Forget Delivery on Commit - what's your Service Level Expectation?

I’ve been pretty vocal about how little I like Delivery on Commit (also known as Say/Do) measurements - sure they have their place and can be useful like if your team is struggling with general discipline and doesn’t seem to get much work done (at least compared to how much they start) and you’re working in a sprint or iteration based environment then DoC can be a practical place to start.

However once your team starts getting a better sense of what’s a sustainable pace for them and how much they can deliver, we really want to de-emphasize DoC or else we risk turning into a feature factory - “Deliver what you say no matter what happens!” - that’s the anti-pattern that I see most people fall into with DoC and why I don’t like it.

So instead let’s take a look at your current service level expectation!

I do this using an Alteryx workflow, but there are lots of ways you can calculate this. We’ll talk through the steps and you can try doing it yourself.

1. Go pull the last 6 months worth of team story data. Maybe less if the team has been more consistent lately. And if your team is pretty new, you can use as much as you have available.

2. Make sure you have cycle time for each item - you might need to calculate this and add it to your data set

3. calculate your percentiles on your cycle time in days - at most I’d suggest 50%, 75%, 85%, 95%, and 99%.

   my standards are

   • 50% will basically be a coin flip - half your items are below this point, half above - I generally consider

   • 85% is a generally accepted “high confidence” point in general stats

   • I use 95% and 99% just to get a sense of the total picture and spread to a very high level of confidence. It’s possible in some cases 85% is not confident enough and we want to be more conservative

   but sometimes I do use

   • 25% can sometimes be an eyeopener for teams - there’s only a 1 in 4 chance of you getting it done within 10 days - suddenly it’s obvious they miss completing in an iteration 3 out of 4 times and maybe we should do something

   • 75% might be useful if you’re wanting a slightly less conservative estimate than the 85% - 3 out of 4 is not bad for a lot of people, and seeing the range for 75% to 85% can also give you a sense of some spread on the reliability

Now we have a set of expectations around when we can be expected to deliver for any random story at any particular level of confidence. We can also use this to help us focus on the work and moving it through so we have continuous flow.

Using the sample data above our 85% cycle time is 16 days that means it takes us more than an entire 2 week sprint to get any random work item done.

First let’s try to get down to completing within a sprint - that’s 10 working days or 14 calendar days (we should be calculating cycle time in calendar days!). We can work on hitting our target by starting less work so we focus on seeing things through to the finish line when we start them - we can do this by implementing a WIP limit. We can also focus more on work item age, so in our daily standup instead of going around person by person let’s walk our Kanban board and look at each work item - we can even start with the longest aged items first.

Eventually let’s start setting a check-point where we might swarm on something - if our target is 10 days maybe any item that ages to 7 days needs to be prioritized and swarmed by the team for completion. We make each of these changes slowly and once we start getting closer to our targets - maybe eventually we get to 85% done in 5 days just by focusing on the work and managing it through the system.

At a certain point we’ll max our just by focusing on the work already in the system and we may need to try other things - making stories smaller, or pairing or working as an ensemble (previously known as a mob), focusing on one piece flow - until we reach the point where we’re just moving work through at a consistent, steady, maintainable, sustainable rate of flow. In this world we’re highly predictable, effective, efficient, and working like a true high performing collaborative team. Can you do it? I believe in you, we just have to try.

The Extremely Slow Decline and Death of the 40 Hour Week

Twitter has apparently started a "9/80" work schedule where in a 2 week period you work 8 days at 9 hours a day, 1 day is 8 hours, and you get an extra day off.

I've worked a 4/10 and there were pros and cons, but the biggest issue I see is that there's still pressure against the clock even though we all know time with hands on keyboard or time working doesn't directly translate to productivity or value.

40 hours a week or 80 hours every 2 weeks isn't based on anything other than history and what workers rights were able to claw back. Henry Ford didn't reduce hours out of the goodness of his heart or care for people, he did it because of his bottom line. His attachment to Taylorism and scientific management, which focused on squeezing every ounce of productivity from their mindless, interchangable people resources (people are not resources, they are human beings, but Ford and Taylor didn't understand that, and many leaders still don't) says to make each step repeatable so they could slot in any worker to do it.

This is much different from the creative, complicated and complex, knowledge work in many fields, especially software development. The work we do today requires we have time to think, process, reflect, and collaborate together. To be creative, to try things, experiment, fail, and try again. We're not working an assembly line anymore, and the places that are - the best places that are, like a Toyota - learned that even assembly lines need to be run differently and empower their people to stop the line and fix problems (Andon cord)

Some places have been experimenting with overall shorter time working (32-36 hour weeks) and are seeing increased productivity, more effective meetings, less burn out, and happier employees who have more time to spend with or take care of themselves and their families.

There is no need for the 40 hour week in knowledge work anymore. Paint a clear and compelling vision, get people working together towards the goal, and trust your people. Reset your expectations to something reasonable - infinite growth is not reasonable, uncontrolled growth is not sustainable, and growth isn't a goal, vision, or mission in itself. If you want your organization to be here for the long term, execute strategy with long instead of short term thinking. Sometimes that means you go a little slower, but better to go slow and get where you want to go than to try to go too fast and wind up destroying everything.

Professional Coaching – A Brief Introduction

In my last (lengthy) article about what an Agile Coach is I mentioned professional coaching as once of the stances, but didn’t go into too much detail. I’d like to expand on that concept a bit in this article and give a quick introduction to professional coaching. My last article’s length got away from me a bit, so I’m going to do my best to keep this short and give the important bits – but more detail and nuance may be better for a future article.

Professional Coaching is a partnership between the coach and the coachee to have a series of creative and throught-provoking conversations that focus on the growth and development of the coachee. The coach holds space and the belief that the coachee is an expert in their life and work, and that by helping them to examine themselves and the world around them thy can unlock their potential. The goals and the direction of the coaching should arise from the needs of the client, and uncovering these is often part of the initial steps (and continually ongoing after that).

Since a coach is helping the client to generate their own successes, coaching is different from things like consulting, therapy, mentoring, training, and even sports coaching. A coach will not resolve conflict, give advice, do the work for or force the coachee to take any specific action. However, the coach will listen in a profound way, reflect things back, keep information confidential, and create a supportive relationship while providing a structure for making things happen in the conversation.

I’ve found professional coaching to be very beneficial for myself. It can help me to see blindspots, encourages me to reflect on myself, challenges me in ways I don’t expect, and overall is quite a positive force. In particular I found it very useful when working through a career change and interviewing for jobs and figuring out how to resign. I can’t always figure out or articulate exactly how the coaching has helped, but afterwards I always feel like I have taken a step forward and made some progress. I’ve noticed in the weeks following how my awareness shifts and I observe new things about myself.

Coaching typically involves specific agreements or a coaching contract before beginning the engagement. Some coaches may even have a conversation before this to see if they even want to take the client on, or if the client really wants to start an engagement with the coach – since this is relationship is entered into and agreed to by both parties, either may not want to engage or move forward if the fit or timing is not right. Often doing inventories and exercises early in the process can help to clarify values, and create a vision. A coach will typically be in a deep level of listening to really understand the coachee, and pose challenges and questions that help the client reflect and move forward.

Hopefully this article has given you a better understanding of professional coaching and how it might be useful for you. If you’d like to learn more, or work with me, feel free to contact me at Edward@agile-ideation.com

What is Agile Coaching? What does an Agile Coach do?

What is Agile Coaching

In celebration of International Coaching Week 2020, I thought it would be helpful to dive into some topics around coaching. To start I thought it would be good to talk about Agile Coaching to help people understand this role. I think a lot of people don’t fully understand what Agile Coaching is or how an Agile Coach can help them, their team, or their organization. I’ve also heard people who are “Agile Coaches” say things like “they don’t want a coach, they want a trainer” or “they’re not asking for coaching, they’re asking for facilitation”, which I think is really doing a disservice to the role. I hope after reading this article you have a better understanding of Agile Coaching.

If you search for “what does an agile coach do” you’ll find a lot of articles, and a lot of models and diagrams about the skills or knowledge or abilities of agile coaching. They are mostly the same – some break things into smaller chunks, some talk about skillsets the coach should have, and some maintain simplicity while hitting a lot of the key points. It’s clear that there are a lot of commonalities, yet many organizations develop their own model of what they think this should look like.

When I think about how I would describe and break down the Agile Coach position (and in reflecting on the various models out there) I see the following as the sort of “big categories” of ideas –

• An Agile Coach is a Lean, Agile, DevOps leader and practitioner

• Who brings themselves and role-models behavior

• And encourages others to improve how they work through:

  • Doing, Telling, Consulting, Counselling, and Advising

  • Teaching and Training

  • Mentoring

  • Facilitating and

  • Professional Coaching

• By understanding people.

Let’s dive a little deeper and unpack each of these concepts.

An Agile Coach is a Lean, Agile, DevOps leader and practitioner

I believe pretty strongly that if you’re an Agile Coach, just knowing Agile, or Scrum, or how to set up a Kanban board is not enough. An Agile Coach should be leading the way in growing knowledge and understanding about Lean, Agile, and DevOps concepts – specifically focusing on values and principles, and then looking at practices and tools. Since Agile came out of Lean, and DevOps is a direct successor to Lean – and the prevalence of Lean Software Development an the widespread (mis-) use of Kanban boards – an Agile Coach should first and foremost be growing their expertise in these topics and sharing what they learn to help grow the people around them.

Being a leader in these spaces can mean different things for different coaches. Some coaches were developers or testers in a previous life and bring extensive technical expertise and mastery to the table, and may focus more on those practices. Some coaches are experts in transformation and bring experience and mastery in the space of change management, driving organizational change, and spreading messages across an organization. Other coaches may be business experts, with a heavy focus on identifying business value, taking ideas and moving them through to fruition, or improving processes around how the business actually completes work. Personally, I’m a generalist and have a lot of range, so I dabble in all of these areas. Regardless of a coach’s focus and background and expertise, it should be reflected in how they act as a leader in the space.

However, learning and sharing is not enough. An Agile Coach must demonstrate they practice what they preach! This may be in their own personal lives, whether it’s managing daily and weekly responsibilities, tracking projects, planning vacations, or setting up home-schooling curriculum. An Agile Coach should also experiment with new tools and techniques on themselves before subjecting the team to them – maybe that new idea intake and refinement process will work great for your teams, test it out on a problem you’re solving in your own life. This gives an agile coach a lot more credibility with a development team, when you can say “I’ve tried this, and I really liked it, and here’s why, and what I got out of it – I think you could get something too, I’d like to experiment and see” – the team will be more receptive to something you do yourself. The more you fall into the “do what I say and not what I do” you weaken your relationship and will likely lose influence over time.

An Agile Coach brings themselves and role-models behavior

Being the Lean, Agile, and DevOps expert is really just the start for an Agile Coach. Since an Agile Coach encourages teamwork, encourages the team to learn about and understand one another, to respect people for who they are, to encourage daring behavior and leadership at all levels – agile coaches need to bring this to the table as well.

Bringing yourself is about being who you are, talking about what you’re passionate about. Sometimes it means making mistakes, sometimes it means saying something stupid, or being embarrassed. But that’s courage, and it shows that we’re not just about doing everything by the book perfect – we’re learning and growing and exploring, and our backgrounds and histories impact that. We can uncover new ways of working when we bring ourselves, because we each have a unique perspective, understanding, and behaviors.

So agile coaches role-model the behavior of bringing themselves, but also role-model other behaviors as well. Having the courage to speak up, to ask stupid questions, to have crucial (or fierce) conversations and practice radical candor, to challenge each other, to criticize ideas (but not the people) to voice assumptions, leadership behaviors, and more. The list is really never-ending. And this role-modeling includes what I talked about above where an agile coach should be practicing (to some extent at least) the ways of working they are preaching to the teams they work with.

How an Agile Coach works with teams

Doing, Telling, Consulting, Counselling, and Advising

Agile Coaching is a strange job as one of the big goals is to help the teams figure out the best way of working, and help them to get work done fast, safe, happy – but the agile coach should in most cases not be doing the work themselves for the team. That’s where this bucket comes in – I’ll be honest I’m not exactly sure what to call it because there are so many degrees of this, so I’d like to look at it through the lens of a Management 3.0 tool called Delegation Cards (or Poker), which is a tool to help managers and teams understand how decisions should be made.

Delegation Cards have 7 levels that you move through, numbered 1 through 7. On the “left” side at 1 you have “Tell” where the manager is telling their directs exactly what and how to get the work done. On the far “right” side at 7 you have “Delegate” which is basically exactly the opposite – the team members have fully authority over the decision, and the manager isn’t involved. In the very middle at a 4 you have “Agree” which means the manager and team members have equal decision-making power and need to come to a decision together. As you can imagine levels 2 (Sell) and 3 (Consult) are various levels where the manager ultimately has decision making power, but is either convincing or getting input from the team – and levels 5 (Advise) and 6 (Inquire) is exactly the opposite, ultimately it’s the teams decision but they need to get input or sell the decision to the manager.

When we look at it through that lens, we can see that the Agile Coach wants to generally be closer to a 7, than to a 1 on that scale. With that in mind, here’s how I would ‘point’ and describe the categories I mentioned above:

DOING (0) - this may need to happen in some organizations, but that means the Agile Coach is fully responsible for the idea, plan, approach, and outcome – the team doesn’t really get involved, and they may not learn or be empowered by a coach who does it all for them. Sometimes doing up front may be good to set the teams expectations, or as a way of teaching them, but in general this should be avoided.

TELLING (1) – Just like doing, sometimes an Agile Coach does need to tell the team what to do to help them, but this can quickly devolve into the coach always telling the team what to do (just like a bad manager who tells the team how to get their work done). This can disempower the team, it can make them less confident or reduce courage to speak up, it can lead the team to falling back on whatever the coach tells them – and not think about how they can best get the work done. This one can be risky because the team may think “the coach knows best, they can tell us what to do” without realizing and embodying the idea that they are closest to the work, they are the best to figure out and uncover new improved ways of working.

COUNSELLING (2) – There are many ways to interpret ‘counselling’ but for our purposes I’m going to equate it to “selling” from the M3.0 model. Counselling by definition is providing advice to someone, but in my experience most of the time advice is being given by an Agile Coach they are essentially trying to sell the idea or advice to the recipient. Again, this isn’t necessarily a bad thing – someone who has tried a few things and doesn’t know what to do next, or doesn’t know how to improve things that aren’t working – could be a prime candidate for some counselling. Ideally however the coach isn’t selling ideas, and mentoring can be a good alternative to this type of advice giving. Agile Coaches want to get to a point where team members are coming up with ideas and deciding what to do on their own – sometimes they may need help in generating ideas, or may need example of things that have worked before – but we want coaches to get out of trying to advise or convince people to do something.

CONSULTING (3) – The concept of consulting gets us closer to where we want to be, the biggest problem is that consulting can often mean it is still the Agile Coaches decision about what to do when, but that they at least took the idea to the team and got some input from them before the plan goes into action. Like all of the previous ones, sometimes this is needed and necessary, but again creates that potential risk the team will feel disempowered or defer decision making to the coach. At least in this case the team’s input is being considered and hopefully has a big impact on the final decision so consulting may be less disempowering than some of the previous ones, but it still holds that risk.

ADVISING (5) – Lastly is the idea of advising. In this case the team is ultimately the ones who will be making a decision, but the Agile Coach is providing some input and potentially encouraging the team to adjust the plan. When we’re in this category we’re really moving more towards the team making and owning their own decisions. While the risks are again reduced at this level, there is the potential for this to be abused by the Agile Coach or the team. On the coaches’ side they could come into an advising situation very aggressively and say that won’t work, do it this other way. That would be pretty heavy handed. There is also the potential for the team to come up with a half-baked idea and bring it to the Agile Coach with the hope to really get the Coach to fix the idea and tell them exactly what they should do – this may seem like advising, but is really an anti-pattern to success.

Teaching and Training

A very common stance for an Agile Coach is that of a teacher or a trainer. This may be for developing organization wide training to introduce individuals and teams to Agile, Lean, DevOps, Scrum, Kanban, etc., and ensure all new hires are on the same page. This training may be refreshers for teams that need to go back to basics, or to add or enhance additional skills. It could be on specific and detailed topics like how to manage a backlog, split user stories, manage conflict, deal with bugs and technical debt, have conversations, or other practices the team wants or needs to enhance how they work. I think the idea of teaching and training is pretty straight forward, and the sky really is the limit for what topics or areas could have training opportunities.

Mentoring

Mentoring is an interesting stance that, while generally easy to understand, has some specific nuance that people often miss. Mentoring is the idea of using past experience to give a person or teams ideas about how to approach or solve a problem. It may be things the coach has personally experienced, or in working with other teams and coaches may be things that have been shared with the coach. Fundamentally mentoring is saying “here’s how I’ve solved this problem before, how I’ve seen this problem solved, what I’ve tried before that didn’t work, or what I’ve heard from others about things that have or haven’t worked.”

One caveat about mentoring as a coach is to always add the qualifier that just because something worked for another team, in another situation, under certain and similar circumstances, does not guarantee it will work for you, or that it’s the right or best thing to do. Mentoring can help uncover and share ideas, but every team, every individual is different, as are companies and teams – so that means it may be a starting point, but is not the same as saying “you should do it this way.”

Facilitating

Facilitation is an interesting stance and an area I think is really important, but again has some important aspects that many people misunderstand. I think we’ve all been in poorly facilitated meetings that seem to jump from topic to topic, and at the end nothing was really decided and it feels like time was wasted. A facilitator is there to help create the best space for a group to come to better decisions more easily than they could if they were on their own. If someone has a stake in the decision that is made, if they care about the specific outcome that comes out of the meeting, they really are a participant and not truly in the role of a facilitator. So as an Agile Coach in the facilitator role it’s important to keep that in mind – it’s not necessarily about the specific decision the team makes, but helping them get to where they’ve decided something. There are tons of tools, techniques, and advice out there on improving your facilitation approach – and it sure feels good to see teams have greater success as a direct result of good facilitation!

Professional Coaching

Of all the stances Professional Coaching is probably the least understood, and for a lot of people the most complex. I’m going to give a quick explanation here, but this will likely spawn an article of its own just on the topic of professional coaching.

Professional Coaching is a partnership between a coach and client, where the client’s needs and desires are the focus of the interaction. It is intended to be creative and thought-provoking, where a coach believes the client is an expert on themselves, their life, and work and helps the client to unlock, uncover, or unpack the information inside of them. A professional coach works to understand and clarify what the client hopes to accomplish, helps with self-discovery (often through the use of questions), encourages the client to come up with solutions and strategies for moving forward, and helps to hold the client accountable and responsible.

I think this gets the basics across clearly, but there is much deeper to go, and I think it will need to be the topic of a future article.

           

Agile Coaches Understand People

The last major trait of Agile Coaches is that they seek to understand people. How humans work, how we think, how we solve problems, how we respond to change, how we work together. Behavioral economics and psychology are usually areas of interest for a lot of agile coaches, and if you’ve been exposed to these areas you known the information is broad and deep. At the heard heart I think we can identify 3 major areas of understanding people that Agile Coaches tend to focus:

Encourage Change / Respond to Resistance to Change - coaches need to understand how humans respond to and feel about change so they can help people feel comfortable with things changing, and also feel like they have ownership. Dealing with resistance to change and finding ways to overcome is also an area that comes up regularly, especially as it relates to “Agile/Digital Transformation”

Manage conflict – coaches need to understand conflict between team members, leadership, and more. Managing conflict may mean bringing people together and acting as a facilitator or coach to navigate through the conflict. It definitely means teaching teams, individuals, managers, executives, and people all throughout the organization to understand conflict, and how to have (and not shy away from) healthy conflict.

Help with collaboration – Coaches must also help with collaboration. Whether that means taking a more active role in bringing people together to collaborate, teaching people how to collaborate, introducing tools and techniques, providing opportunities to collaborate, or simply encouraging and empowering collaboration across the entire organization. This may also be asking questions about why collaboration isn’t happening, or providing a coaching stance to help individuals see the value and importance of collaborating on their own. Either way an agile coach needs to understand how people work together to help them improve and get the best outcomes.

Coaching Anti-Patterns

Before ending I think it’s important to cover at a high level some common coaching anti-patterns. For those unfamiliar in software development a “pattern” is a leading practice, something that tends to work well for most people, and an “anti-pattern” is something that people often do, something you tend to see, that doesn’t work very well or moves us away from where we are trying to go.

Big Change All At Once – the first common anti-pattern is an Agile Coach coming in and trying to make big change everywhere all at once. Uprooting everything that has been done up to this point, and replacing it with something else. The biggest problems with this anti-pattern include making people feel like nothing they were doing before was good (disempowering), or overwhelming people with change which can lead to more resistance and a harder road to get where you’re trying to go. I typically try to make small sustainable changes (with wins!) to build momentum and succeed over time instead of pushing everything all at once.

“Doing” Agile, but not Thinking or Being Agile – You see this a lot in companies that push Scrum – bring someone in, teach them the ceremonies, and roles, and how to story point and let them run with it. Teams starting DOING all the stuff, but nothing changes, nothing gets better. That’s because nobody learned how to change their way of thinking and being to match – they just got a set of rules and instructions to follow without really understanding the why or where we’re going with something. I generally focus more on values and principles to help try to overcome this anti-pattern.

Drive-by coaching – All these anti-patterns are peeves of mine, and this one especially. Drive by coaching is this idea that a coach can pop in, not really know what’s going on, and then make suggestions or tell the team what to do. This one really rubs me the wrong way – the same way that if a new team manager come in and start changing things before they understood the situation the team won’t appreciate it – a drive by coach is going to run into issues with buy in, understanding, may point the team down the wrong path, and biggest of all isn’t establishing or building any sort of relationship with the team. This can also be hugely disempowering if the team has an idea, a coach comes in without fully understanding the context and says it’s a bad idea, and leaves.

Acting like a manager or project manager – Managers come from a place of authority, and the relationship with team members is not the same as it is between peers or others. Project Managers are there to manage a project, not the people, and are heavily focused on getting things done. As an Agile Coach there is no automatic authority in the role, the team doesn’t have to listen to you, an agile coach should gain ‘authority’ through influence and building strong relationships. To that same end an Agile Coach isn’t focused on ‘ensuring the project gets out the door on time with all requested features” – that’s a secondary (or even tertiary) objective to helping the team to work well together, and to find a sustainable pace. A coach should come from a place of curiosity and problem solving. As soon as a coach starts telling the team who should do what work, or how they should work, or dresses them down for not hitting a milestone or objective you know they’re in this anti-pattern.

How can an agile coach help you?

An agile coach can help you in many different ways depending on where you are right now, and what your needs are at any particular time. If you have Agile Coaches in your organization, I’d encourage you to set up some time with them to talk about some challenges you are struggling to solve and see if you can work together to find a way to help overcome. It could be through formal training or workshops. Maybe a coach can help facilitate your next team planning or other meeting. Maybe you can create a coaching agreement and they can help you uncover the solutions inside yourself. Or maybe they have seen the problem before and can share how other people have solved it to help you get over the hump.

Conclusion

Hopefully this article has helped you to understand what an Agile Coach is, does, and how they can help you better. As you can see it’s not completely cut and dry, and Agile Coaches have a lot of things they need to be able to do. Some coaches do focus their expertise in one or a few areas, others are more broad generalists. Either way by contacting a coach and sharing your problems you open a door to many potential solutions.

Coaches are here for you! We want to help people learn, do better, and be better.

If you’re interested in learning more about coaching, or would like to engage in coaching, feel free to contact me at Edward@agile-ideation.com.

EventStorming for a 2 day Project Kick-Off Offsite (Onsite)

This week I facilitated a big project kick-off offsite (it was really onsite, but for some reason everyone called it an offsite!) meeting, and overall it went really well. Had about 18 people participating when everyone was in the room and really explored the domain space. There were some challenges and hiccups, I had to pull a lot of ideas out of my facilitator bag of tricks, but eventually we got where we were trying to go. I got a lot of positive feedback and I think the session helped to give business partners more confidence that the technology teams understand what they are trying to accomplish and that they are serious about redesigning these legacy systems to be more intuitive, functional, and useful. I think this also helped the senior leadership to see that their business folks do understand what they want to accomplish and can steer this in the right direction.

The room that the project manager had booked was not a great setup for EventStorming, and I couldn’t find any other rooms that would work better and available to switch to, so we had to make due. I had the facilities folks swap out the regular chairs for stackable chairs so we could get them out of the way when not needed. Instead of a big conference table this room had some smaller movable tables, so I pushed some out of the way/along the walls, and arranged the remainder into a large pod so during the parts where we were sitting we’d have somewhere to do so and set up laptops and work, but the set up ensured there was plenty of room for people to move around and work the modeling space. There was wall space (well technically windows) where I could hang the paper, it was maybe 4-5 meters of space which was going to be a tight constraint.

Everything started really well. I used the same meeting ground rules about no one has a monopoly on truth, that we work together for understanding, and to deepen our relationship - everyone was in agreement and was good with them so we got started. I had re-done all of the posters based on feedback from the previous attempts, and I think it helped create greater clarity and understanding up front. The chaotic exploration started and people were a little unclear why we were working solo, but events started getting posted rapidly. I think the updated poster helped because they were much more in line with the desired format than had happened the last session. Lots of events were posted in the 20 or 30 minutes of quiet time - even with some background understanding of the space, and I knew it would be a big domain, it was even bigger than I expected.

Before opening it up for discussion and to enforce the timeline, I hung another sheet of paper on the wall to expand the modeling space. The group had nearly completed filled the initial sheet with events, so we had to expand the space to give them more room to work. The discussion started going really well. I told them to dump the trash straight on the floor below the modeling surface and they started refactoring their work. Pulling down duplicate events, re-writing bad events, adding ones that had been missed, and ordering them along a rough timeline. The group did a great job and I heard a lot of discussion about why things happen the way they do, or whether things need to continue happening that way. Overall I think they all learned a lot from each other.

One of the biggest challenges facing this group was a very condensed timeline (1.5 days for the offsite) and what they wanted to accomplish in that time. EventStorming seems to work better if you can do 2 hour time blocks 1-2 times a day for multiple days in a row, and we were trying to cram as much as we could into the 10 or so hours we had. I think by the time we finished with the rough timeline the group was starting to lose some steam, mainly because of the size of the domain space and the number of events that were represented.

We next moved in to adding structure, and this is where we started to encounter some challenges. I added one more sheet of paper to expand the modeling surface again (vertically, since we had no more horizontal space to work with) to give them more space to work. I explained pivotal events and temporal milestones and asked them to consider that type and level of structure first, and then showed them swimlanes. They identified the pivotal events pretty easily, and it took some time but eventually they had some swimlanes on the first ¼ to ⅓ of the flow, but it was then time to break for lunch and things kind of stopped and didn’t pick up again after everyone ate. I think the biggest issues was the lack of horizontal modeling space, not having all the right people in the room, too much to accomplish in the time we had, and general brain drain and exhaustion. Without more space it became hard to refactor the events and add structure because there was too much going on to easily add the structure. There were not as many domain experts as I would have liked - we had Director, VP, and SVP level people in the room in spades, but the actual people who do this work day in and day out was limited to only a few, and I think this made the level of understanding and focus a bit more high level than could have made this really successful. As I mentioned before it was a lot to try to cram into a short period of time, and as a result I think mental energy was being expended to where people were feeling fatigued. Where we did get was a great start, but I feel like there was a next level we weren’t quite able to reach.

After the structure we tried to get into where do events come from - my attempt to fix the problems with agents & external systems from the last EventStorming session I ran - based on some things I saw where it combined people with actions/commands. This is when things really started to go off the rails. The business folks didn’t understand why there needed to be a blue “place order” sticky and then an orange “order placed” sticky - we tried to explain, but it didn’t click or go through. As a result the concept of actors/agents also collapsed because they said there were way too many to represent. I attempted to facilitate through it, but with no success. Even the BSA and architect tried to jump in and help me, but we couldn’t seem to break through. We wound up brainstorming a long list of external systems and just tracking them on another flip chart instead of putting them into place. This helped us to see how many external systems people are using, but not really map them to any of the events we had put up. I think again the space constraints made this too mentally taxing - they’d have to move too many stickies in too small of a space that I think their brains just kind of shut down at the idea of adding another layer onto the events.

When we tried talking about actors/agents again, we got redirected. There was a heavy focus from some of the more senior business people in the room that they felt it was really important to talk about “role attributes”. I wasn’t exactly sure what they meant and was having trouble wrapping my head around the concept. It seemed like it was agents/actors/people that they were talking about, but when trying to get them to add people to the events we had created there was a lot of resistance and pushback - this system could technically be used by anyone in the company, so they felt there would be too many to represent, or too many events that could be performed by multiple people. I expressed that really we only need to categorize specific types of actors, not all of them. I have experience and expertise in this domain so I understood where they were viewing it as more complicated so I said maybe the actors are just something like “employees”, “supervisors”, “analysts” (to represent their department), and that would be enough. That didn’t seem to click, and I was told that wasn’t the problem they were trying to solve. Certain people met certain criteria that would cause them to be treated a certain way, that’s what they meant by role attributes. I suggested we brainstorm the list of “role attributes”, but each time I tried to visually represent them I was told that wasn’t how they worked.

So I took a step back and said I was going to unveil the rest of the EventStorming concepts, that it was going to be a lot to take in, but that we hoped this would provide a solution to the problem they were trying to address. We unveiled aggregates, policies, and read models. I explained how they all worked, and showed them the “picture that explains everything”. I said, “It sounds like these role attributes might be policies - whenever someone meets these criteria then something specific needs to happen?” - it turns out this is exactly what they meant, but again there was resistance to this new concept and too much brain fatigue for this to click and be effective. So I started asking more questions and we tried to represent role attributes in multiple ways (a tree diagram, mapping out the various attributes as if it were a database table, etc.), but nothing really landed. So in the end we just had a large discussion where we talked about the different types of people, how they are identified, what some of the ‘roles’ meant, and they seemed satisfied with the discussion and understanding, even if there wasn’t really a clear outcome that we could take away.

As we started winding down the discussion I had them start putting up red stickies for their biggest problems, I gave each person 3 problem stickies to mark problems. Discussion on other topics continued and at the next break I gave out 3 green “opportunity” stickies to each person to write down ideas to put up what they see as the best ideas or greatest opportunities for a future design. Then finally as they were leaving the room I handed out small blue stickies that I had drawn arrows on - 2 per person - so they could vote/pick their problem and point their arrows at the key problems or opportunities that they felt would be most important to address in the future.

I learned a lot from this session and overall I think it went well and I got a lot of positive feedback. There were certainly some hiccups and we didn’t get as far as I hoped we would or thought might be possible, but overall I think we had a good outcome of more knowledge sharing and understanding. Also I think a lot of the business partners thought the space was relatively simple or they fully understood it. I got the impression that seeing everything laid out in front of them, realizing there are gaps in understanding and how they do things today, and even areas that people weren’t sure how they work or how they are supposed to work, really helped them realize how complex this space is and that it likely will not be as simple or fast to modernize the processes and underlying applications as they thought it would be.

The more I work with EventStorming the more power I see that it has. The more flexible I realize it can be. And I’m starting to wonder about ways it could be used for employee onboarding, running retrospectives, and other activities. I’m a bit disappointed that I haven’t been able to take it all the way to the level of a process design or system modeling exercise, but maybe we’ll move into that in the future. I’d really like to see some of the modeling concepts like policies, read models, commands, and external systems get added in to better understand how that helps development teams build the software solution.

EventStorming Successes and Gaps to Improve

This week I got to facilitate my first big picture EventStorm with the business partners in one of the domains for which my team owns the application. This was specific to a fraud investigation team who is responsible for check, ACH, and other card fraud. It was a really interesting experience and I learned a lot.

I re-did all the keys and guides based on my experience and the additional information I gained from Alberto’s and Paul’s respective books. Overall things went pretty well considering we only had 2 hours and I received a lot of positive feedback, but there are some things I would change in the future.

Instead of having a single key for all the elements, I made individual keys for each of the components so I could reveal them individually as we went. I also created a poster with some ground rules based on something I read (maybe it was called Deep Democracy?? I need to look again), basically that no one has a monopoly on truth, we agree to learn together, and the point of working together is to start a conversation and strengthen our relationship.

I decided we would try to do as much of the Big Picture concept of an EventStorm and not really break into the design portion since we weren’t working on the particular application for a while. Started by having them put up events. I did notice it was hard for that group to write events in the proper past tense format, so that was a note I have as a take away to try to address in future sessions. The chaotic exploration /slash/ slient working time went reasonably well, but I noticed when I opened it up for discussion and refactoring there was a hesitancy to remove or replace anything that they had already stuck up there - I will plan to tell everyone in the future that the amount of garbage we create is a measure of success and learning to help solve that problem. One thing I did notice was a lot of discussion about hypotheticals or details about how systems worked and what systems were involved well before they truly understood the events. There were a couple… let’s just call them troublemakers who wanted to do their own thing and only get involved in a limited capacity otherwise. I will have to find some facilitation tricks to deal with that in the future. I think one thing I will do next time is if someone is monopolizing conversation and explaining a lot verbally, ask them to show me where that information is on the events so we can address it. I also need to let them know if they want to introduce concepts not to try to figure out how to add them, but to let me know and maybe we can introduce additional concepts early. They really wanted to talk about external systems, and for some reason kept trying to express their existing system as an external system instead of just recognizing the events we were creating were part of their existing system, so the system itself doesn’t need to be represented.

Something else I noticed was that folks started writing on the paper - which I should have warned against and stopped as soon as I saw it - and suddenly their creativity and willingness to move things around went through the floor! I know Alberto talks a lot about how the size of the modeling space will impact mindset and approach, which is why we try for the unlimited modeling space concept - but it became clear to me that I need to warn people not to draw on the modelint surface or do anything that might limit them. All the materials I provided were movable, removable, replacable, and changable. Sticky notes and post-it tape/roll - so in the future I will be a bit more specific about that up front.

I also observed that things start to fall apart a little bit or collapse a bit once I tried to introduce the concepts of external systems and actors/people in the system. I need to see if there’s a better way to have that make sense and start being effective. I felt like the external systems were being put up at a rate that was way heavier than I expected, and they seemed to self-restrict and start trying to represent multiple external systems on a single sticky. I think if we had discussed and focused on the flow we could have found some specific ways to fit the external systems in without overdoing it. The actors/agents piece I think just wasn’t well understood. I’ll need to re-evaluate that part and do some further reading and research to figure out how to make that aspect work a bit better.

Overall it went really well. I got a lot of positive feedback from the business partners that participated and from the folks on the development team as most of them had never worked in that domain space or with that application. I’m going to keep exploring what others have done in the EventStorming space and getting ready for the big one with all the folks who are traveling to kick off this project. I am curious about how the results of an EventStorm might turn into a Story Map and if there’s some way to migrate work that way. I also started looking into Story Storming and Example Mapping - I think there could be some cool ways to combine these techniques or have them flow from one to the other - maybe an EventStorm to understand the domain space, then a Story Storm to actually create all the relevant stories to include in a Story Map, and then Example Mapping to help ensure the team understands all the rules/policies around what they are creating… it’s still too soon for me to have a unified process for all of these, but I’m adding these to my list of places to explore in the future.

Lean, Agile, DevOps - You should be doing them all

Cheat sheet with some of the principles, values, ideals…

DevOps 3 Ways

1. Systems Thinking

2. Amplify Feedback Loops

3. Culture of experimentation and continuous learning

DevOps 5 Ideals

1. The First Ideal — Locality and simplicity in our code and organization

2. The Second Ideal — Focus, flow and joy in our daily work

3. The Third Ideal — Enablement of improvement and achievement

4. The Fourth Ideal — A culture of psychological safety

5. The Fifth Ideal — A ruthless and relentless focus on our customer

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Lean Development Principles

1. Eliminate Waste,

2. Build Quality In

3. Create Knowledge

4. Defer Commitment

5. Deliver Fast

6. Respect People

7. Optimize the Whole

7 modern principles of LEAN

1. Optimize the whole

2. Eliminate waste

3. Create knowledge

4. Build quality in

5. Deliver fast by managing flow

6. Defer commitment

7. Respect people

5 original principles of lean

1. Identify Value

2. Map the value stream

3. create flow

4. establish pull

5. seek perfection

3 pillars of scrum

1. transparency

2. inspection

3. adaptation

Scrum Core Values

• Commitment

• Focus

• Openness

• Respect

• Courage

Kanban Principles

1. Principle #1 – Visualize Workflow

2. Principle #2 – Limit Work in Progress

3. Principle #3 – Focus on Flow

4. Principle #4 – Continuous Improvement

Kanban Methods

1. Start with what you do now

2. Agree to pursue incremental, evolutionary change'

3. Respect the current process, roles, responsibilities & titles

4. Encourage acts of leadership at all levels

Kanban Properties

1. Visualize the workflow

2. Limit WIP

3. Manage flow

4. Make Process Policies Explicit

5. Improve Collaboratively (using models & the scientific method)

Why Morning Pages didn't work for me and how I applied kaizen and continuous learning to find something that did

A small lesson in kaizen and continuous improvement (and not doubling down on a failing strategy) I want to share this morning.

Almost a month ago I started doing the Miracle Morning and the S.A.V.E.R.S. Starting a meditation (S - silence) practice again was great and I immediately started seeing the benefits. Positive affirmations (A) were new, but I liked them. Visualization (V) was also new and a little tricky, but it felt positive. For Exercise (E) doing some Sun Salutations A & B has also had a positive impact. I usually listen to audiobooks in the car so Reading (R) was nothing new really.

That final S is for scribing, journaling, writing. Sure I get my bullet journal ready in the morning, but I wasn't actually journaling. So I started doing a little research and stumbled across The Artist's Way and Morning pages. 3 A4/8.5x11 sheets of paper handwritten every morning, stream of consciousness writing. The idea is that you dump all the thoughts and feelings that are blocking you and it helps you to be more creative. The creator says they will be whiny, complainy, negative, and that's OK.

For me that was NOT OK. Starting my morning being negative meant my thought patterns were negative, that I focused on the negative. So today I tried something new.

This morning I did my own variation, I don’t have a name yet, for for now I’ll call them positivity pages. I wrote a minimum of 1 full page, still handwritten, but focusing on things that went well, things I want to try, things I am good at, things I have learned, things that are good. It seems to have already made a difference.

So I’m going to keep trying this and see how it goes. If I need to change it again, I will, and if this works well for me I’ll keep doing this.

No matter what you try, be ready to change if it’s not working. Don’t get stuck because you are unwilling or unable to learn, change, and grow. Kaizen means continuous improvement, but through small incremental steps. Get an idea, make a hypothesis, test, and adjust. Plan, do, check, act.

Exploring EventStorming

I returned to work from my sabbatical and following the DDD meetup was going to look for opportunities to start using EventStorming in my day job. Amazingly within 30 minutes of getting back to the office my solutions architect approached me and said he had finally read the Domain Driven Design book he had sitting on his desk for the last 8 months. To my chagrin he said he heard about EventStorming and wanted to use it for this project we were kicking off, but he didn’t really know anything about it, other than software folks saying it was a valuable practice.

I told him he was in luck because I had not only heard of it and looked into it some, but had actually DONE IT. I proceeded to tell him about the DDD meetup and he wanted me to get ready because he was going to push for EventStorming to be a big part of the upcoming project kick-off offsite (which was actually onsite). So I started doing a deep dive in the research and have discovered a lot, and still have a lot to learn.

First I watched a few videos from Alberto Brandolini, and definitely the 50,000 Orange Stickies Later video from 2018 had a lot of great information. I can tell there is some difficulty in explaining the technique without actually doing it. While I was piecing some things together from the video, I still felt kind of challenged. I found some other videos, blog posts, Github repositories, and more with notes and facilitation materials, I poured through it all.

I spent a week or so deep diving and preparing and finally we decided to do a trial run. I figured once we did it we’d understand the gaps and areas I needed to explore further to have better understanding and explanations for our business partners. Shortly before we did our trial run I discovered Alberto was working on a EventStorming book on Leanpub. As I write this it’s only about 70% complete and there is a lot of repetition, but it really helped fill in some gaps - but having only just discovered it, it also created some confusion and lack of clarity! There was so much new information, I didn’t see the where to start and what to do first, and didn’t understand how to layer on the additional levels of complexity.

We decided to at least start for our domain space, acknowleding that we would be incomplete, and that we wouldn’t take that information into any design or future sessions since there would be too many gaps. I set up the space, hung up the paper, had stickies in all the colors mentioned, and even created a couple flip charts. The first being an overall legend based on some things I had seen online and the other being “the picture that explains everything” that Alberto had shown in multiple presentations and was in the book. At this point it explained very little to me and I really didn’t understand how we tackle this process.

We started putting up events, that seemed to make sense. But from there we sort of got stuck - commands, external systems, aggregates, read models, policies… just so many pieces that we had at our disposal that we didn’t quite know how to piece together. I pulled out Alberto’s book and we started going through it, and finally found a section about Big PIcture EventStorming and the steps to layer things in. It was starting to click more, and a lot of the extra things we were looking at we realized was a next level of complexity that we didn’t need to get into yet. Really what we wanted was the big picture, some problems and opportunities, and maybe some of the initial modeling structure, but the rest was getting too deep into design.

So a lot more exploration to do in the EventStorming space. I’ve learned a lot, but still some aspects of this are not completely making sense. I’m going to deep dive into Alberto’s book and I learned that Paul Rayner (creator of the Explore DDD conference in Denver) has a Facilitating EventStorming book, so going to keep working in this space and try to run a few more sessions to try to get a better view on facilitating these sessions. At some point I’m going to write a long post about running this, maybe put together a facilitators guide, and I’m thinking about putting a talk together to share with others, take to a meetup, or whatever else. I think this is a really powerful technique, I just need to wrap my arms around it a bit more so I understand and can explain it better.

Intro to DDD and EventStorming

I finally made it to the DDD - Domain Driven Design Meetup here in Denver and it was a really awesome night. The session was not their standard meetup format as the Explore DDD conference was in Denver - while the conference is only 2 or 3 days, there is a whole week centered around Domain Driven Design with multiple workshops, events, hands-on activities, and much more. I feel really lucky that my introduction to DDD and EventStorming just happened to coincide with this conference as there were a lot of really thoughtful and considerate developers from around the world in attendance to contribute their thoughts and experience.

The plan was a hands on modeling workshop, and I honestly didn’t know what exactly to expect when I arrived. “Hands-on Strategic DDD Modelling and Architecture Kata with Kacper Gunia & Nick Tune” was the title, and the description said it would be a night of hands-on DDD modeling in the domain of loyalty. That we would work in small teams and with an initial set of requirements design a system - the bounded contexts, the domain flows, technology choices, and other architectural details. The description said we would look at some of the tehniques to model domains including “context maps, domain storytelling, the bounded context canvas, and c4 software architecture”, but I don’t recall ever doing an overview to learn those things, so now they’re on my list of areas to look into.

I arrived, we split up into groups, and one of the facilitators handed out sheets with a high level context of the domain and explanation of the requirements. The domain was a fast-casual restaurant chain serving organice meals and beverages. The comapny has decided to introduce a consumer loytalty program with rewards of points and ways to redeem for food options. In our small group we read through the details and what they were looking for - the requirements were a lot around how they wanted points to work, what should happen if the system is down and they want to redeem points, how many concurrent users and new sign-ups need to be supported, and that they wanted to differentiate themselves by tying a credit card to the rewards account so you can swipe to pay and the transaction will be automatically associated with your rewards account.

I am not a developer and didn’t really know how to approach it, I figured I was mostly there to learn and observe, but the developers I was with were DDD practitioners and immediately said “We should do an EventStorm”, I said I didn’t know what that was and the whole group got excited to spread the word of EventStorming. We had some paper hanging up and some stickies “we don’t have orange, so we’ll have to make some adjustments” I didn’t know what that meant, but I later learned orange stickies are one of the main elements of EventStorming, but that will be a topic for a future post.

They told me we pick a color for events (since we don’t have orange), and start writing one event per sticky, in the past tense, using the exact same language that was provided in the requirements sheet. This way we were speaking the same way as the business. Then we started organizing it in a timeline and associating pieces to one other, we started grouping items by drawing cirlces around them. I didn’t exactly understand what we were doing with the stickies, but I did see that we were creating understanding and actually designing the architecture of the system. We had a sense of what parts went together, what might be microservices, what might sit where and how we might hook things up. The design was coming together.

The rest of the night was sort of a weird blur, I wasn’t exactly clear on our desired learning outcomes and it went by pretty quickly. In the end I was mainly just really impressed with these developers and architectures using DDD and how thoughtful they were and how much care and consideration they put into learning about the domain they were supporting and constructing for. I also had this take away that i wanted to learn more about DDD overall and EventStorming specifically. I had never seen a technique that had so much potential to allow for discovery, discussion, and to create a shared understanding and shared language between business and technology partners. I know EventStorming is something I want to look more into and use going forward.

There is no future for business analysts in IT

There is no future for business analysts in IT. This is the scary conclusion I've come to in watching the agile and devops space for the last few years. Product owners own the backlog, the ScrumMaster does whatever is necessary to help the team, and the development team is now working more closely with the PO and stakeholders to understand what they truly want and need us to build. So if there developers are getting closer to the people asking for the work, and understanding the business and their objectives better and better, why is a business analyst even needed on a development team any longer? I write this from the lens of working in compliance, where lots of people think BAs are still needed, but when you look at revenue generating products no BAs are needed, and I don't think they're needed for internal departments either, at least not on the tech side.

I haven't come to this conclusion lightly. A big chunk of my work is business analysis, I am technically a business analyst right now. But I don't see a future for me as a dedicated business analyst, and I don't see a future in it for you or anyone else either.

The ScrumMaster owns the process and protects the team, but also works to remove impediments and does whatever is necessary to help the team succeed. If a ScrumMaster is doing their job, coaching the Product Owner and the team on how to be more effective, than the feedback loops should be so tight that we don't need big up front analysis, no massive requirements documents, and no one stuck in the middle trying to play telephone between stakeholders and the engineers.  The bread and butter for a business analyst is acting as that go-between, relaying information, and questions, and clarifications back and forth. How ludicrously inefficient! As we understand our stakeholders better, the vision our PO has, the business goals and objectives we already know we're building the right thing so we no longer need that role.

The product owner works with stakeholders and the development team. They use tools like impact mapping to figure out goals and objectives, needs for the business, value that can be obtained from whatever we build. They use tools like user story mapping to flesh out what is needed, how it goes together, and what order we want to deliver small slices of value so we aren't waiting for some big bang release one day down the road. A good product owner reduces context switching and builds the most valuable thing, one thing at a time, until it is either complete or it's not the most valuable thing anymore. A reduction in context switching means everyone from the business stakeholders to the dev team is focused on just that thing - we can build, and demo, and get feedback, and adjust our approach, repeat ad infinitum. 

Not all hope is lost my fellow business analysts. 

I agree with Mark Schwartz in his book "The Art of Business Value" where he says technical business analysts are some of the best suited to become product owner. We know more about what's possible, and are better at digging down behind the what to find out the why we're even being asked to build this thing. I think Sr. Business Analysts should look at the product owner role very seriously.

I also think business analysts can make great ScrumMasters and coaches. We often do whatever is necessary to help the team, and I think many analysts see more bottlenecks and problem areas because they work across more of the value stream. I strongly believe good ScrumMasters should coach the PO, the development team, team managers, and even coach operations teams and help move people towards DevOps. This may require the average business analyst to step up their knowledge and get up to speed on some new concepts, but definitely a great option.

Finally there's the product owner team. The PO can't do everything by themselves and they need help. Building a team around the product owner can lead to improved outcomes and better queuing up of future work, better user stories, requirements that are more clear and useful to the developers. The product owner team, in my opinion, would be the PO, one or two designers (UI and UX folks), the architect, and a couple business analysts. However I think these should be more Junior and mid-level roles with the idea being they eventually grow into product owners.

DevOps Enterprise Summit 2018

I was extremely fortunate to be able to attend the DevOps Enterprise Summit (DOES) again in 2018, and this time the event was in Las Vegas. It is incredible to spend 3 days listening to talks from thought leaders in the field, meeting people from different organizations, industries, and backgrounds and hearing about their challenges and successes in the DevOps space.

Not every presentation is a winner, but I did still take 23+ pages of notes, and got a lot of good ideas and information. It really is a re-energizing event, to be there with "my people” - other agilists, technologists, and DevOps practitioners who really get what we’re trying to accomplish and how we want to change companies, technology, and software delivery for the better.

A few of the talks really stood out to me and I wanted to share what I learned and took away.

Digital Transformation: Thriving through the Transition - Jeffrey Snover, Microsoft

https://www.youtube.com/watch?v=qHxkcndCQoI

Jeffrey Snover gave a fantastic presentation about digital transformations and ensuring your career can thrive through them. Transition means disruption, and when things are changing so rapidly it does not matter if you are excellent at your job if your job no longer matters. Transitions can bring some people down, but they can also be the wind in your sails and have a substantial positive impact to your career. Most career pathing is made up of Stair Jobs - you have to move up one step at a time. During times of disruption and transition you have the potential to find your Elevator Job, the position that will move you up the ladder much more quickly.

There’s been this idea that with digital transformations it is a sign that software is eating traditional business, but this is the wrong way of looking at it. All businesses are now technology companies, every company is a software company. No matter what industry you work in, nothing gets done without software and technology, and therefore all organizations need to seriously look at how they treat their IT department - gone are the days of worker bees just doing what the business asks, now it needs to be a partnership and technology should be considered from the first step instead of brought in and tacked on later on.

Organizations often focus on too many things instead of their core, the thing that differentiates them from their competitors in the market. Those things that are mission critical and failure means big, deep trouble - those are your core. Everything else is context, and helps to enable the mission critical but is not what should be focused on. Organizations should only build the things that differentiate them from their competitors, everything else can and should be purchased - why spend tons of time and money and energy on something that isn’t a differentiator, doesn’t give a competitive advantage, or isn’t something you are competing on?

This transition requires new heroes, and changes to how we think about moving forward.

STOP clicking next, START automating

STOP crafting no-value add solutions, START leveraging SaaS to free up talent

STOP building snowflake servers & clouds, START DevOps

STOP low leverage architectures, START leveraging Cloud (public and on-prem)

STOP dialing it in , START investing in your career

Uncomfortable is the new normal. So step outside of your comfort zone and learn, and try new things, and challenge the status quo. Be one of the key people who are moving the business forward, one of the people who are securing the future. BE THE HERO!

Understanding Job Burnout - Dr. Christina Maslach

https://www.youtube.com/watch?v=gRPBkCW0R5E

Dr. Christina Maslach is one of the foremost researchers on occupational burnout and her talk about understanding this really hit home with me. She notes that there are some specific occupations that experience this more than others including health care, human services, social activism, customer service, and technology industries. People who have a passion for solving problems seem to be hit with this - the feeling of no matter how hard we work, we don’t seem to get anything done.

Some of the key contributors to burn out are that many employers seem to have less concern and commitment to their employees in various ways, there is destructive competition between co-workers, an divisive tactics reward “talent” but not everyone.

There are no metrics of the human costs which include:

• long-term stress and health problems

• physical exhaustion

• sleep deprivation

• disruptions of personal life

• loss of self-worth and meaningful achievements

• burnout

• depression, anxiety

• suicide

And there is a horrible underlying assumption from employers that employees who burn out are not the best ones, so they are expendable and disposable - in reality the highest performers and those who care the most are often the ones who wind out burning out fastest and first.

The problem of unhealthy jobs includes

• Various job conditions that are highly stressful and toxic

  • long working hours and high demands

  • job insecurity and lack of control

  • low social support and work-family conflict

• These job conditions (stressors) pose a danger to the worker’s well-being

  • Increase in annual unnecessary deaths and healthcare costs

  • lower worker life expectancy and more working years lost

  • greater risk of burnout and depression

• And these job conditions do NOT enhance productivity or the bottom line

The match between a job and the person is critical in 6 strategic areas:

• Workload

• control - how much autonomy you have

• reward - can be salary/benefits, but research shows social reward is more important

• community - relationships you have with others at work

• fairness - is whatever the policy/practices are fairly administered

• values - why am I doing this, why am I hear, what are we trying to accomplish?

So burnout is not just about working too hard and being exhausted and tired, but having the passion, meaning, and drive beaten out of you instead of being allowed to grow and thrive.

If your idea of a good day is “nothing bad happened” and you don’t respond with specific positive things, that is a sign of impending burnout.

When there is high Job-Person mismatch we see:

• Demand Overload

• Lack of Control

• Insufficient Reward

• Breakdown of Community (socially toxic workplaces)

• Absence of fairness

• value conflicts (being asked to do things that go against their values)

The more mismatches, the more burnout. People can tolerate some mismatches as long as the ones that match are powerful.

Burnout is a stress phenomenon and is a prolonged response to chronic situational stressors on the job with 3 dimensions:

1. Exhaustion - individual stress, feeling of “can’t take it anymore”

2. Cynicism - negative response to the job (“socially toxic workplace”)

3. Professional inefficacy - negative self evaluation (“erosion of who I am”, “no future for me”, “I’m stuck”)

Squad Health Check