Category Archives: Behavioral Science

03/30 – LESS TALKS: Virtual Collaboration & Facilitation Lab – Part 2

One of the most powerful techniques to understand organizational design and dynamics is to model them, with your colleagues, in front of a white board. Not according to ‘best practices and cook books 😉 but based deep system thinking and shared understanding, by all participants.

But what if you cannot get together in front of a white board???

Miro Board In combination with Zoom (shared session & team rooms), will give you an opportunity to collaborate on-line – together by diverging into teams and converging in a large group. Lets try this together!

Since Large Scale Scrum (LeSS) is NOT a ‘methodology’ or ‘set of tools’ but an organizational design framework, system modelling is its critical part. But even if it was not for LeSS, understanding the way your system (e.g. enterprise) behaves could be very powerful.

Please, note, once you learn this stuff, you will not be able to ‘unlearn’ it and your knowledge could be viewed by others, as dangerous 😉 (and frustrating to you).

In this session, we will try bringing real life system modelling conversations (please, see examples of images from past LeSS training below to gain understanding) into a virtual session.

Examples of real-life CLDs:


03/03 – LESS TALKS: “What is Your Product?”, with Ellen Gottesdiener

To be product-aligned and customer-focused, everyone in your product development ecosystem needs to agree on the answer to the question, “What is Your Product?” Many organizations don’t have clarity on what their product or products are. Ambiguity and disagreement on the answer contribute to slow response to changing customer and market needs and less than satisfying product outcomes. It thwarts your efforts to scale agile product development and causes a plethora of organizational and communication woes.Large Scale Scrum (LeSS) rightly states that this question—and the imperative to answer it—is one of your most important decisions for successful product development. A clear answer to “What is Your Product” powers all aspects of product development, including product management roles, team organization, and product activities. The implications are vast and deep, especially in large enterprises. Product definition is one of the paramount steps in LeSS adoption. Depending on how a product is defined (how widely) an organization may consider simple LeSS or LeSS Huge. Based on the ladder, team structure and alignment is defined, product owner team is created, etc. Product definition has a significant impact on LeSS organisational design.Based on ongoing work with a variety of organizations, Ellen shares techniques for enabling product development leaders and communities to define their product using a cohesive set of product definition principles. In this keynote, Ellen will share why this question is so vital to your product success and ways she’s helped organizations co-discover the answer to the question, “What is Your Product?”

Whether your organization’s product or products are a primary source of revenue or are essential for your business operations, you will learn techniques that help instill product-thinking and shared understanding.

Ellen Gottesdiener’s Bio

Ellen is a Product Coach and CEO of EBG Consulting focused on helping product and development communities produce valuable outcomes through product agility. Ellen is known in the agile community as an instigator and innovator for collaborative practices for agile product discovery and using skilled facilitation to enable healthy teamwork and strong organizations. She is the author of three books on product discovery and requirements, frequent speaker, and works with clients globally. In her spare time, she is Producer of Boston’s Agile Product Open community and Director of Agile Alliance’s Agile Product Management initiative. You can connect digitally via:
http://ebgconsulting.com/blog/
https://twitter.com/ellengott
http://ebgconsulting.com/newsletter.php
http://www.linkedin.com/in/ellengottesdiener


03/03 – LESS TALKS: Meet Ron Jeffries & Chet Hendrickson @ LeSS NYC (‘Dark Scrum’ and more…)



First and most importantly: Ron Jeffries and Chet Hendrickson are long time friends and colleagues who both had a huge impact on what defines AGILITY.
About Ron:

Ron Jeffries is author of Extreme Programming Adventures in C#, the senior author of Extreme Programming Installed, and was the on-site XP coach for the original Extreme Programming project. Ron has been involved with Scrum, Extreme Programming, and Agile for over ten years, presenting numerous talks and publishing papers on the topic.

Ron is the proprietor of www.XProgramming.com, a highly-ranked source of Agile Software Development information. He was one of the creators, and a featured instructor in Object Mentor’s popular XP Immersion course. Ron is a well-known independent consultant in Scrum, XP and Agile methods, recently specializing in helping Scrum teams get Done-Done.  Ron is one of the original authors of the Agile Manifesto.  Read Ron’s post on ‘Dark Scrum’ at: https://ronjeffries.com/articles/016-09ff/defense/

About Chet:

Chet Hendrickson has been involved with Agile Software Development since 1996, when as a member of Chrysler’s C3 project he helped develop Extreme Programming. In 2000, Ron Jeffries, Ann Anderson, and Chet wrote Extreme Programming Installed. It detailed XP’s core practices, how to do them, and how they work together to help teams be successful.

Chet is the first signatory to the Agile Manifesto.

Since 2002, Chet has been an independent consultant, coach, and trainer. In 2009, he was asked by the Scrum Alliance to help develop the Certified Scrum Developer program. Chet and Ron Jeffries taught the first CSD course and continue to offer them in the United States and Europe. He has been a Certified Scrum Trainer since 2009.

Ron and Chet were the curators of the Scrum Alliance’s Agile Atlas website and in that function created the Alliance’s official Scrum description, Core Scrum.

Chet and Ron Jeffries often work together and are popular conference speakers, bringing an interesting mix of humor and deep knowledge, and the odd cat picture. The are a fixture at the Agile Alliance’s annual conference, Agile 20xx, as presenters in the Stalwarts track.
Last year, Chet attended Craig Larman’s LeSS class in NYC and this is what he had to say:
http://www.keystepstosuccess.com/2018/06/may-30th-june-1st-certified-less-practitioner-course-with-craig-larman-nyc/


02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell



Recently, Evan  Campbell wrote an article on SolustionsIQ site: The Spotify “Model”: Don’t Simply Copy-Paste.  It resonated strongly with  many people. This LinkedIn feed alone attracted more than 23,000 viewers and it is growing.

On February 27, Evan was a guest-speaker at Large Scale Scrum (LeSS) meetup of NYC, answering questions about his views and the writing.  The video recording and transcript with live questions are below:

Top 5 Questions submitted before the session:
  1. Evan’s article talks about many large companies blindly adopting the Spotify model, because this is the strong recommendation they get from large consultancies. Are there any examples, at least, when such recommendations were followed and implemented successfully? It seems that ING success is overly inflated.
  2.  In the article, there is mentioning of hard-line reporting within the “chapter” or the “tribe” structures? It means that historical/orthodox challenges of organizational design persist in new “agile” structures. Could you elaborate on that?
  3. In the article, there is mentioning of random consultancies’ PowerPoint solutions, in which a heavy deck is the most important asset delivered. It is often delivered by a consultant who has very little industry experience, yet presents from the deck ‘as if’ it was the best known practice. Any comments on that?
  4. Our organization is big and one-team Scrum is not sufficient. If Spotify is not the right solution to scale, then what is?
  5. Our company was advised to adopt Spotify model. Today, some of old vertical organizational structures (e.g. QA department, Architecture group) have become chapters, and people are mandated to be a part of those chapters. Used to be managers, are now chapter leads. Nothing seems to be changing. What are your thoughts on this?

02/18 – LESS TALKS: Tsvi Gal, CIO/CTO @ multiple Fin-Techs: sharing experiences about organizational agility



Tsvi Gal is an accomplished technology business leader, the winner of the Einstein Award for technology excellence.  Tsvi had served as CTO and CIO at a number of large enterprises: Morgan Stanley, Bridgewater Associates, Deutsche Bank Investment Banking, Time Warner Music Group and other companies.  Tsvi has extensive experience in technology and operations, mostly in financial services, media and telecom.
In his recent career, Tsvi led the divisional Agile & DevOps transformation and the changes to the ways of work in technology, workforce strategy and front-to-back initiative.

Some questions presented & answered:
  • When someone wants to transform, it implies that there is a need to transform (change). What were some of the most pressing needs, in your experience, to go through changes? Something did not work? Was not efficient? Other?
  • How many people were involved in the transformation? How long did it take? Who was spear-heading this effort: internal coaches, external coaches, mix of both, PMO, etc?
  • How did you address HR related issues that frequently arise when agile teams are being stood up: individual performance appraisals, bonuses, promotions, career path?
  • Who provided guidance to technical excellence during the transformation? Technical coaches (internal, external)? Were teams using TDD, CI/CD?
  • Did you use any known agile frameworks ro scaling approaches? Or was it all internally defined?
  • DevOps vs. DevSecOps? Any difference? Is it dev practice or org. silo?
  • HR is years behind, when it comes to agility. Why? Do not blindly copy & paste (e.g. Spotify model)

02/11 – LESS TALKS: Nicolas M. Chaillan, US Air Force Chief Software Officer On Technology Agility, Scaling and More

On February 11, 2020, NYC Large Scale Scrum (LeSS) meetup was honored to host the event for a special guest-speaker Nicolas Chaillan – the first Air Force Chief Software Officer.  Nicolas is also the co-lead for the Department of Defense Enterprise DevSecOps Initiative with the Department of Defense Chief Information Officer. His full bio is available here.

Presentation Slides

CSO Memo on Agile – and SAFe, by Nicolas M. Chaillan (US Air Force Chief Software Officer)


Run This Method Through Organizational Compiler



Running this method through an “organizational compiler” may improve health of your organization: (variables are “globally declared” and clickable hyperlinks. You can pass any arguments to this method, as long as they are valid arguments 🙂 )
public class LegacyOrganizationalEcosystem { 
public static void main(String[] args){
if((agile_framework == this_framework{ 
System.out.println ("Simplify your organisation.
Try scaling agility by de-scaling complexity")
} 
else if (agile_maturity_goal == this_goal){
System.out.println ("Stop chasing numbers. Self-assess, systemically")
}
else if (agility_measurement == this_measurement){
System.out.println ("Stop internal competition. Recognize command & control behaviors through system modelling.")
}
else if (coaching_model == this_model-left_side){
System.out.println ("Avoid locally optimized for coaching ivory towers and Agile CoEs.")
} 
else if (agile_coach == this_coach-right_side){
System.out.println ("Beware of 'quasi-coaches'.")
}
else if (agile_coach_career_path == this path){
System.out.println ("Get REAL, experienced coaches with effective coaching approaches")
} 
else if (agile_knowledge_basis == this_certification){
System.out.println ("Avoid certification collectors. Be cyber-vigilant.")
} 
else if (talent_acquisition_model ==  this_model){
System.out.println (" By-pass staffing agencies. Select vendors diligently and responsibly.")
}
else if (architecture_expert == this_architect){
System.out.println ("Avoid 'power-point' architects.")
}
else if (prod_owner_team_communication == this_comm){ 
System.out.println ("Remove translation layers. Learn about benefits of feature teams through gaming.")
}
else if (prod_owner_sm_relationship == this_relation)
{
System.out.println ("Avoid faking Scrum roles. Understand Scrum roles through system modelling.")
} 
else if  (scrum_pattern == this_pattern)
{
System.out.println ("Recognize Scrum anti-patterns.")
} 
else if (sprint_naming == this_convention){
System.out.println ("Avoid Sprints without PSPI. Understand and expand product definition.")
}
else if (customer_request == agile_requirement){
System.out.println ("Avoid 'agile' BAs and BRDs.")
}
System.out.println (“Overall, your organization may need a refresher on what agility truly means :). You may enjoy sharing this” + anecdote + “ with your colleagues and play this”+ game +” at your next town-hall meeting.”)
}
 }

 

11/13 – LESS TALKS: NYC LeSS CLP and Meet-Up with Craig Larman

NYC LeSS Meetup with Craig Larman (Video Recording)
Summary by a featured guest-blogger, Enterprise Strategy & Organizational Design expert and Certified LeSS Practitioner – David Stackleather.

I had the opportunity to watch the NYC LeSS Meetup with Craig Larman via video. I attended one of these when Craig was in California, and have attended two CLP training sessions with him, so I have some idea about his message. It’s always useful to hear the news again if for no other reason than to overwrite some of the general nonsense one hears so often in the hallways of the average corporation or on the average Slack channel. Fresh air is good for the soul.
For those who haven’t heard Craig speak, or attend one of his training sessions, the best way I can describe him is that he’s the honey badger of change consultants, he just doesn’t give a, well you catch my drift. There aren’t a lot of weasel words or marketing fluff. Just the simple facts as he sees them. These facts, a description of reality really, can be challenging to hear at times. It’s why you often hear folks giggling uncomfortably in these sessions when Craig says something stark. The thing everyone should understand is, he’s not joking. So pay attention.
Although these sessions only run an hour or so, there is enough content to fill a book, literally. The concepts go deep, and the skills and tactics mentioned in a few sentences can take years to master and fully understand (things like systems modeling, for example). Here are just a few items that stood out to me during this particular session.
Scale Matters
A difficult thing to understand for many is that behavior at small scale is almost meaningless at large scale. Everyone wants to think they can improve their process, or get a little better at their job (or, hope that the other guy gets better at his). Larman makes the point that at scale, it’s the structure that drives change. The root cause of the problems many large enterprises encounter are the result of their design not how good the developer sitting in a cube on the 42nd floor is. Deming taught us this long ago; the workers are not the problem; the problem is at the top.
I like to think of this scale issue from the standpoint of process improvement. In process improvements focused on cycle time, improving the performance of individual processes is unlikely to improve end to end cycle time much if at all. Just messing with the procedures is just as likely to elongate the cycle time as it is to reduce it. The queues and delays between are the story. It’s the structure of the process that must change, not the pieces. Same for organizations. This is a very difficult message for folks to hear if they are not in the mahogany lined offices on the top floor. You can improve locally, and that is all well and good, and I’d advise it, because moving forward is the only way to survive, but it won’t solve your organization’s problems.
The market for deep change
Craig makes the point that the worldwide market for deep change, meaning those companies that really want to change at a fundamental level, is small, perhaps 500 companies total.
I’m not sure how many companies there are but I found online that the total listed companies across all stock exchanges is around 45,000. This is wrong, no doubt. It excludes private companies (some of which can be very large even in countries with deep financial markets where listed would be advantageous), and many of those 45,000 companies are likely rather small. But given that number, we’re looking at one percent of listed companies as being open to real, fundamental, change. That’s a sad state of affairs, but there are deep-seated reasons that there is so little appetite for change at the power center of companies.
Without a profound sense of urgency deep change doesn’t happen. Until leaders are backed against the wall with a real crisis, they are loath to upset the very system that has provided so much. Most large organizations are elegantly designed to provide a steady stream of only what the boss wants to hear. Everyone down the chain of command is in on the game as well, so they want to play by the rules as well. Any information that is raw, real, and innovative is squeezed of real value before it ever gets to the board room. This all feeds very nicely into the strong confirmation bias we all have. It’s very near a closed-loop system in many organizations I’d wager, recycling the same excuses over and over again.
Problems are provoked with fake change
Fake change are those change efforts where the senior leaders are unwilling to fundamentally change the organization, even if they say they are. Instituting change in this environment can provoke existing power structures. When problems inevitably are uncovered, there isn’t the courage to tackle the root cause. There isn’t the courage because that wasn’t the point. The most significant sign that the organization isn’t ready for real change is the avoidance of making the fundamental structural changes necessary. There will often be reasons to retain the old structure or relabel them. If that’s the case, it’s just a show. If you begin a change program in such an environment, you run the risk of awakening a dragon with no ability to slay it, at least organizationally. The problems initially articulated that provided the excuse for the change are not resolved and perhaps made worse by the change chaos. In some cases, it would be better to let the dragon sleep.
Is it hopeless?
Perhaps 99% hopeless. But that means there is a chance! Larman makes a great point about the individual, however. A point I think too many people miss because it’s uncomfortable. If you are in management, or any other specialist function that isn’t directly related to building something customers are willing to pay for, plan your exit. Learn a skill, become valuable. So many people operating in large organizations are intently focused on moving up the hierarchy that they forget that the purpose, at least in theory, of hiring anyone for anything is the skills that person brings to the table. If you never gain marketable skills or let them atrophy after years in the corporate environment, you will find yourself a prisoner. A prisoner of the very same organization you complain about.
Certified LeSS Practitioner –  Feedback From The Room

Summary by a featured guest-blogger, Agile Coach and Certified LeSS Practitioner – Soledad Rivero.

Definitely, participating in Craig Larman’s CLP training has fundamentally raised the bar for me, as a change agent, Scrum Master and Agile Coach. I managed to incorporate new concepts that will not only help me in my current situation, but will also be handy for many years to come. During this course we dont get into a deep dive of LeSS experiments (there are more than 600 of them and for that, there are 3 books that provide guidance, with examples and practical techniques in different chapters).  Instead, in this course we had a very unique 3-day experience with Craig, as he taught how to design your organization in a systemic way, thinking systemically, seeking to optimize the whole and not just locally. This course broke my mindset and perception and then put it back together again.  It opened up my mind, giving me more tools, and energy to keep changing things.

As Craig said in class: “to be an agent of change in an organization you need a lot of patience and big amount of sense of humor“.   It will not be easy, but for sure it will be worthy. Thanks again for amazing learning opportunity!

More Kodak Moments

About Contracts That Support Agile Ways of Working



One of various under-served (ignored) dimensions of agile transformations that frequently limit an organization’s success, there is one that requires special attention.

It is vendor management that can be traced back to legal contracts between a client company and supplier/vendor.

Vendor management norms and guidelines define relationships and interaction between a company’s own employees and external workers, individually and in team-level settings.  Unfortunately, this issue is not always obvious and therefore, is neither explicitly raised by inexperienced agile coaches, nor adequately addressed by senior leadership that is satisfied with limited results (could be also a sign of complacency).

There is a lot of improvement required in how corporate attorneys and vendor managers define, initiate and maintain external relationships with third parties.

This post provides a short summary of recommended improvements – they are  listed below.  It is based on a more comprehensive excerpt: Agile Contracts Primer, by T. Arbogast, C. Larman, B. Vodde.

(Also, please refer to Top-5 high-level recommendations for what to look for in vendors, selected for agile projects, in “Survival List to Vendor Selection on Agile Projects”)

Recommendations for Attorneys and Vendor Managers:
  • Acknowledge that Legal, just like Finance and HR can diminish project success if not considered as a part of agile ecosystem
  • Get rid of false dichotomies around the 3rd Agile Manifesto value: “just because we value customer collaboration than contract negotiation, it does not mean that a contract has no value” 😉
  • Make sure that attorneys understand that a “successful contract” is not the main goal.  It is a successful project or product (delivery) that is the main goal.
  • Draw analogy between software project complexity and your own (if you are an attorney) legal work complexity, to appreciate how difficult it is to do precise upfront estimation on huge, unpredictable body of work
  • Understand how agile approaches can lower (not completely remove) friction around, such areas of contract negotiation as liability, warranty, payments, pricing, deliverable
  • Understand that external legal contracts have downstream impact on internal non-legal contracts – relationships between people
  • Understand repercussions of subjective incentives and rewards (bonuses), given to attorneys for legal outcomes (event if they are successful), instead of focusing on an overall project success
  • Understand/study agile and iterative development (e.g. Scrum, Kanban), system thinking concepts, lean principles and agile project assumptions differ from traditional project assumptions
  • Gain strong grasp of what Acceptance Criteria, Definition of Done, PSPI and MVP mean
  • Study how continuous deployment and incremental development can reduce risk and exposure, as oppose to sequential/waterfall SDLC that usually  increases it
  • Understand positive implications of agile ways of working Limited Liability and Warranty, Deliverable and Pricing
  • Specifically, with regards to Pricing, understand:
    • Variations of T&M contracts and why they are good for agile projects.  For example:
      • Fixed price per iteration (per unit of time), fixed-price per large project
      • Fixed price per unit of work
      • Pay-per-use models
      • Hybrid shared pain/gain models
      • Capped-Price, Variable-Scope vs. Capped-Price, Partial-Fixed-Scope vs. Fixed-Price, Variable-Scope
      • Target-cost
    • Reasons why FPFS contacts are least desirable/most risky and what are some of the ways of lowering such risks
    • Difference between flexible scope without and with penalty (shared gain/pain)
    • Early termination – does not mean failure
Conclusion

Contracts are not necessarily always bad.  Having an external, legal contract between a client and a vendor/service provider/supplier is perfectly normal and even necessary.  It is the form of a contract that matters, as it has downstream effect on dynamics and behaviors between people within a client company, as well as between the parties.

To produce a meaningful contract for an agile project, an attorney should have good understanding of what is valued most in agile work, by agile teams, and optimize his/her own work for the benefit of an overall project, not just for having an amazing contract (locally optimized for an attorney’s benefit).  To gain such understanding a legal professional needs to invest significantly in studying principles of agile/adaptive product development (e.g. Scrum, Kanban), lean and system thinking.

Some of the above listed contract types are more supportive of agile work than others and each once must be explored in detail for suitability, depending on unique organizational settings.

 

Thoughts by Rick Waters, CST

Rick Waters is a Business Agility Coach and Trainer, from Chicago, with more than 15 years of technical software development experience, and almost 10 years of Agile leadership experience.  Rick primarily trains Scrum, Enterprise Scrum Business Agility, and Kanban.
This is what Rick wrote, in support of the recently released book by Gene Gendel (Adaptive Ecosystems: The Green Book: Collection of Independent Essays About Agility):

Nearly every time we talked, my dear friend, Mike Beedle (RIP), would challenge me to think deeper about less conventional concepts that I wouldn’t normally consider having an impact on the subject matter we were discussing.  Often, Mike would come back to Employee Experience.

“Employee Experience,” he would say “is the where we need to focus in order to truly give our customers the amazing experience that we want them to have with us, as a company, and our products.”

Recently, the well-meaning practices of installing ping-pong and foosball tables, or game rooms, or a kegerator in the lunchroom, have come under fire.  Though these ‘perks’ to working in a space where at least someone is focusing on an aspect of Employee Experience (EX) seem great on the surface (mainly to new employees during the interview process), they don’t speak to the long-term EX.  They speak, mostly, to something I like to call Short-term Employee Gratification.

I want to reiterate, the people responsible for work-place ‘improvements’ like those already mentioned, are well-meaning.  But, like many good deeds, they don’t go unpunished.  Here, mostly because these Short-term Employee Gratification efforts are just that – short-term.

Long-term EX is about sustainability.  We see, in the Principles behind the Manifesto for Agile Software Development, that there has always been someone concerned with sustainability.

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

So, why do even the best of us not understand that our actions are not having the intended effects?  Because we are HUMAN BEINGS, and we have this natural tendency to believe that when we ‘fix’ something, that it stays ‘fixed’.  In this case, when we make our employees happy, they should stay happy.

So, why don’t employees stay happy?  Because they are HUMAN BEINGS, and trying to get a human being to stay happy when nothing around them is improving, the morale suffers.

We talk a lot, in the Agile world, about the concept of Continual Improvement.  We also warn those whom we mentor, to only take on as much change as they can handle at any given time.  Trying to change too many things at once and realize which of those changes actually had a positive effect can be darn near impossible at times.

So, in this example, maybe just provide one perk at a time.  But, in all fairness, slowly rolling out toys for employees to play with at work … that’s still just a stop-gap measure to gratification, not a solution to improving the Employee Experience.

I now invite you to take a trip down memory lane with me.  The year was 2004.  I was working at a young company in Chicago, still relatively small at 100-125 employees.  We had a culture of freedom, not fear.  That would come later.  Our products were platforms and API’s for electronic traders (of stocks, bonds, future, options, etc.) to make trades quickly, setup their own custom automatic trading rules, and develop custom trade strategies.

Life was great!  For a while.  There were monthly bonuses for everyone, when the Sales department hit their quota.  There were free donuts and bagels once a week.  I believe that, for a time, there were even free soft drinks from the vending machines.  Our team even had full autonomy over who we interviewed, and who we hired.

As the company grew, and we grew quickly, these perks slowly disappeared.  Every one of them.  Until if we asked around, “Hey, do you remember when we used to have <perk>?”  The general answer was likely “That was before my time.”  But, in reality, it likely wasn’t before their time, they just didn’t remember it.

Let’s fast forward a bit through the ugly parts – fast growth in head count, demanding deadlines and the resulting loss in quality, stolen/lost autonomy, creation of a command and control environment, increasing number of periodic performance evaluations, and finally periodic layoffs.

The changes did not take long.  Two years at most.  But they, and their resulting culture, lasted for much longer.

I eventually left the company.  I knew I was a valuable part of my team, but I was extremely frustrated with many of the negative turns the company had made, as well as some of the decisions my immediate co-workers had made.  I needed to get out to preserve my sanity.  Or so I thought.

I let my manager know I had another job offer, and I had already accepted it.  I gave my two-week notice.  He begged me to stay.  I asked him “If the company values me so much, why doesn’t anyone feel this way?”

Two hours later I got a meeting request from the CTO.  I was to bring all of my improvement suggestions to him, for discussion, first thing the next morning.  Improvement suggestions?  The CTO!?!

I went home and immediately started writing down everything I thought was wrong with the company and how they could improve the working relationships with their employees.  From problems with retention of talent, to employee happiness, to wage inequality, etc.  It ended up being a 3 page long handwritten bulletized list.  I was proud and scared at the same time.

The next morning I handed the papers across the CTO’s desk, and we had a 3 hour long conversation about why I was leaving, the devolution of morale at the company, my unwillingness to stay, his failure (his words not mine) to his employees, and much more.  This is saying a lot about a man who repeatedly would blow off scheduled meetings and short people on their time to talk with him.  Our meeting was only scheduled for 30 minutes.

I left that meeting feeling extremely valued.  Exactly what I wanted all along.  I was shocked, because nowhere in those three handwritten pages had I even come close to mentioning that a deep face-to-face conversation, with the CTO focused on me as an important employee, was enough to restore my hope in the company.  But that did the trick!

Out of foolish pride, I left anyway.  I wasn’t always as enlightened as I am today.  I’m still not as enlightened as I wish to be.  So I made mistakes.  And I will make mistakes.  Leaving the company at that point was probably a mistake.

After I left the company, it took me six weeks to meet with the CTO again and ask to come back.  He agreed.  He wanted me to see the changes that he was making.

I returned to the office (with a raise and promotion) after 10 weeks of absence.  I found a foosball table and a conference room had been transformed into a game room (the newest Nintendo® and XBOX® game systems installed with many games for each).  These were suggestions I had made.

But during those 10 weeks of absence, I realized I was wrong three different ways.  #1 for leaving.  #2 my suggestions were based on short-term gratification. #3 I never brought up any of my suggestions at the times they occurred to me over the last several years.

Just as you might guess, these improvements, and a few more over a short period of time, had an immediate positive effect on employee morale.  But, long-term systemic change had not been addressed.  Frequent performance evaluations still remained.  Deadlines were a constant source of stress.  Development was not focused on building Quality into the product, so it had to be tested out of the product afterwards.  Layoffs became more frequent, and the culture of fear quickly resumed, after the shine of the foosball table dimmed.

The EX had only gotten better for a short period of time.  Eaten alive by the terrible system that was still in place.  Like painting and waxing a rusty automobile, without grinding away the rusty bits first.

Agility is defined slightly differently by almost everyone in our industry.  To me it speaks of a company culture that I would love to work in.  During my entire career, I can think of only a few years when I worked in an environment that I can confidently describe as Agile.  All other environments were either deviating further and further from Agility, or trying everything they could think of to get closer to Agility (with varying levels of short-term success).

While hearing Mike Beedle’s words about Employee Experience echoing in my head, I blend them with Craig Larman’s.  Craig saying that cultural change follows only if there is systemic change, makes clear sense to me these days.

Today, when large organizations want me to help them change their culture, I try to refocus them on their system and how they are providing a long-term gratifying Employee Experience.  Cultural change will follow, and thus Customer Experience.