XOIT (Self-management) Misguided Meeting Focus and Context Switching

One of the main goals of XOIT is to break the classical IT silos into hybrid groups with all the roles necessary to achieve a clear and defined purpose. While we can see this goal being achieved, we have also begun to see challenges with this approach. If you follow the XOIT methodology, there are two main challenges you will quickly experience: Misguided Meeting Focus and Context Switching.
Let me explain.  


In the past people where organized in silo teams which were focused on certain IT domains or functions, there is a continued tendency to focus their meetings on what they used to do as opposed to the purpose of the meeting. With XOIT people find themselves participating in teams that are responsible for creating new assets, maintaining existing assets and defining strategies for IT.  Regretfully the past still influences the present, and often when someone comes from a maintenance background, their focus remains on maintenance, regardless of the purpose of the meeting they are attending. This syndrome has caused us to miss one of our main objectives: to separate our focus, as a group, between strategy, projects and maintenance. Luckily the solution is fairly simple: if you start a group meeting with the purpose of the group and you stop all discussions that are outside of the purpose, it’s only a matter of time before everyone follows suit.


Context Switching is also related to the fact that people are involved in many groups; unfortunately, the solution for this is not easy at all. When people are participating in different groups (as everyone in XOIT is), every time they move from one group meeting to another, they have to switch their context to the current group. Changing context costs a loss of time because it takes time to do the switch, and also causes confusion – especially if you have to switch context multiple times a day. While we are aware that context switching is a challenge for us, we don’t have a resolution yet.
Posted in IT | Leave a comment

XOIT – Challenges learned in Jan

In this post I want to share the challenges we are aware of after one month of running in self-management way. The challenges are not order by any category, Just in the way they popped into my mind.

  1. Meetings, or number of meetings. That’s the main complain right now. To be honest we introduced technologies like Slack or GlassFrog that enable reduction of meeting and performing Governance functions without meetings, but people are not using them. We hope that’s a learning curve that will change in the future. While attending meeting I can still see people running those meeting in the OLD way, which required much more time and really doesn’t bring any value to anyone (except to the few of us that like to hear themselves talking)
  2. For managers it is hard to to the transition to leaders. In their mindset they are still managers with HR accountabilities. That create tensions between associate that understand self-management and adjusting their behavior and Ex-managers that understand self-management, but keeping on acting as managers.
  3. When new associates joining or moving from another business unit the transition is harder and it required very close and personal assistant and attention. It’s not a bad idea to closely assist new associate when he is starting new journey, but XOIT required more time and effort.
  4. People treat representative as a “Joke” up until the governance meeting start to touch the real challenges the group have (and any group have challanges). Due to that we sometime have the wrong personalities in the wrong role, which cause governance meeting not to follow XOIT. This issue usually resolved after the first true governance meeting.



Posted in IT | Leave a comment

XOIT (self-management) two small, but encouraging success stories

Have you ever been in a project meeting where something is going south?  Not only that, but you have 50 or more people all waiting to hear about itI think it is safe to say that we have all been there.  Let’s take it a step further.  Let’s say that every person in this meeting represented different aspect of the project and so they are trying to push their agenda, all while and everyone else is trying to prove to the rest of the group that they are the most talented and therefore, the savior of the project. The problem, of course, is that after 60 minutes of debate and shifts between different agendas, everyone simply leaves the meeting without any solution at all.
With XOIT, we are not an exception to the above scenario, but we are addressing this problem in a different way.  When this situation starts to arise, before it gets too deep, we simply agree to set up a new sub-group within the project, define its purpose, and then let the main group (in this case, the project) to nominate a lead to this sub-group. Once selected, the lead can define which roles are needed as well as who is going to fill them. When the sub-group is set, all members not only know that they are accountable for the success of its success, but they are also aware that they have full autonomy and authority to run their group.
Lately we encountered two performance issues. One was related to networking latency; the other, reporting.  Iboth examples we created two sub-groups and waited for the results.  While the network latency group managed to decrease network latency from seconds to milliseconds, their main success was that they found a basic issue in our private cloud definition, and suggested a fix that will impact all current solutions running on this platform.
As for the reporting group, they managed to reduce the time to run some reports from 40 min to 4-6 second.
Both success stories are examples of how self-managed teams created solutions that would have been very difficult to achieve in a classical hierarchal or command and control environment.
Posted in IT | Leave a comment

How your org chart looks like in self-managed environment?

If your organization is not following hierarchy roles, how your Org chart is going to look like?

That’s a common questions that I hear. Obviously there are many ways to organize and show your self-manage organization. We choose to use the Holacracy principle of circles. In our world IT is one big circle that contains main groups needed to reach our IT purpose. Each one of the main groups are created from sub groups or roles needed to reach a purpose. Each one of the sub-groups can be build from roles and their own sub groups.

This Structure helps to understand and see the main functions needed to reach the IT purpose. People are filling different roles in different groups, based on their skill sets and preferences.

Our org chart looks like that:


Posted in IT | Leave a comment

Starting to practice 100% XOIT (self-management)

If you are following our blog you already read about the slow deployment and adoption of our self-management practice ( which we call XOIT). Starting 1/3/2017 we are practicing fully XOIT. I’ll do my best to share with you on a weekly basis major observations, challenges or success stories.

One of the major observation that I have so far is how hard is for people to understand that they are self managed. It’s not that they want to be managed, It’s just so ingrained in our minds that it’s so hard to ignore it and manage yourself.

Posted in IT | 1 Comment

XOIT – How self-management increases engagement

if you have been following me for a while, you probably won’t be surprise to hear about our latest achievement. Our company conducts an employee engagement survey every two years. The last time that this survey was conducted IT had a participation rate of around 30%, and a Net Promoter Score (NPS) equivalent of -15. 
This year 82% of our IT associates participated in the survey and our NPS equivalent score was +42. We improved ourselves in every category (with the exception management relationships,which is hard to understand when you hear about selfmanagement all the time), and have become one of the leading groups in engagement across the company. 
I am certain that all the IT associates hard work as well as XOIT has contributed to this change. This is not to say that we are perfect – there are still areas where we can improve, but it is a complete change from two years ago.
Posted in IT | Leave a comment

Toyota Production System, Lean management and why Agile development is not what it meant to be

This post begins at Fremont, California home of one of the worst auto factories ever owned by GM. The quality of both the cars and the employees that produced them was so notorious that GM made the decision to close the factory in 1982.
In 1983 Toyota and GM began negotiations to again open the Fremont factory, with each partner having  different goals. GM began to think about manufacturing smaller and more efficient cars and thought that they can learn the successful “Toyota Production System.” Toyota on the other found themselves behind Honda and Nissan, both of whom had factories in the Statesand they were afraid that they could lose market share in the United States. Those discussions lead to the creation of NUMMI (New United Motor Manufacture Inc).
As you can imagine there were many areas of disagreement, and one of them is applicable to our story today. Toyota came into this partnership with a culture that was known as the Toyota Production System. This radically different culture promoted two basic ideas:
  1. Employees were coming to work to contribute their expertise. The company trustedthem to make the right decisions and contribute to their greatest ability.
  2. To promote continuous improvement, which was obtained by the company shyingaway from bureaucracy and encouraging employees to come with new ideas and a willingness to test them.
Those two Ideas where translated into more tactical approach that was implemented intoemployees daily work lives:
  • People are more important than processes and to succeed they need to work in groups based on commitment and trust;
  • Decentralized decision making – pushing decision making to the lowest possible level: People that are doing the work know the domain better and can fix issues and improve the process;
  • If you put people in the position to succeed they will;
  • Mistakes are OK, as long you learn from them. The biggest problem occurs when employees do not have opportunity to make mistakes.
When GM heard about the Toyota approach they literally laughed. Workers in the Fremont factory were characterized as only caring about themselves while performing the least amount of work that they could get away with. GM had committed to the union that NUMMI will reemployed 80% of the previous factory’s employeesperhaps because the thought this new initiative would fail while still learning enough from Toyota in order to be successful. Toyota, on the other hand, agreed to take the risk.  Perhaps they knew that success in Fremont would translate into greater success throughout the US.
Once the agreement was signed, waves of employees from the old GM Fremont factory madetheir way to the Takaoka auto factory in Japan to learn about the Toyota Production System. They returned with stories about the “Andon cord,” and how managers are “working” for employees. The general feeling was that something different was going to happened under NUMMI.
In 12/10/1984 the first Chevy Nova (Yellow Chevy Nova) was manufactured and things were really different. The past bad behavior had disappeared, the Andon cord had not been pulled, nor had  new suggestions been implemented
A month after NUMMI was opened the President of Toyota, Tetsuro Toyoda, paid visit to the new factory. While going through one of the production lines he noticed an employee struggling to install some rear lights on a vehicle. Mr. Toyoda approached the employeelooked at his badge, and said “Joe, please pull the andon cord.  Joe looked at Mr. Toyoda (and the entire factory executive team behind him) and replied, I can fix it, sir.” Mr. Toyoda replied Please Joe,” to which Joe replieI can fix it sir. Mr. Toyoda then reached out and taking Joe’s hand, he lifted it up and together they pulled the andon cord. A yellow light beganto flash and Joe (with his hand shaking) continued to work on the car. Once the car reached the end of Joe’s work area, the production line stopped. Joe finished his work and pulled the andon cord again, the production line return to normal work. Mr. Toyoda bowed to Joe and began to speak in Japanese. Joe,” he said, please forgive me! I’ve done bad job ofcommunicating to your managers the importance of the andon cord. Only you can make the best cars. I’ll do everything in my power to make sure that I don’t let you down again.
By noon the entire factory had heard about it. The day after that the andon cord was reportedly pulled over ten times, and an average of 100 per day a month after Mr. Toyoda’svisit. Two years later, and a visit from the Harvard Business School to have data proving that the worst factory ever had become the best factory GM had, with a quality level on par withToyota factories in Japan. NUMMI was a huge success that was discussed and celebrated. 
The Toyota Lean System, or the Lean Management as it is known in the states, penetrated many industries and began to make a difference. From Hollywood to Health Care, the new culture and concepts influenced many different industries.
This change didn’t pass up the software industry. On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah several software engineers met to discuss how to bring Lean Management into software development. They looked for a way to help software companies to adopt the Toyota Production System, instead of creating new strict ceremonies and processes.
If you look at the Agile Manifesto, you’ll see the Toyota Production System elements that I laid out in the beginning of this post. Each statement of the Agile Manifesto promotes trust, commitment and continuous improvement. The Agile Manifesto simply tried to adjust this culture and tactics to the software industry.
Culture changes are the hardest to implement, therefore human beings are more open to adopt new process and ceremonies to promote new culture. Regretfully it’s not working. Changing a culture is hard work that demands a lot from everyone that is involved in this effort. The fruit of culture changes are the same as NUMMI experience. 
Agile, DevOps and whatever will come in the future are all culture changes, so understand the difference in the culture and adopt it. Simply adopting new processes and ceremonies to replace the existing ones won’t drive any change.
And NUMMI?  NUMMI was closed in 2010. Today this factory is being used by Tesla to produce their cars
Posted in IT | Leave a comment