## Output vs. Takt Time

The team’s challenge is to reach steady output of 180 units per hour.

Their starting condition was about 150 per hour. Their equipment and process is theoretically capable of making the 180 per hour with no problem.

They calculated their takt time (20 seconds) and established a planned cycle time of 17 seconds.

Some time later, they are stuck. Their output has improved to the high 160s, but those last 10-12 units per hour are proving elusive.

This is the point when I saw their coaching cycle.

Looking at their history, they had set a series of target conditions based on output per hour. Their experiments and countermeasures had been focused on reducing stoppages, usually on the order of several minutes.

“Does anybody have a calculator?”

“Divide 3600 seconds by 180, what do you get?”

“20 seconds.”

“Do you agree that if your line could reliably produce one module every 20 seconds that you would have no trouble reaching 180 modules per hour?”

Yes, they agreed.

“So what is stopping you from doing that?”

They showed me the average cycle times for each piece step in the process, and most were at or under 15 seconds. But averages only tell a small part of the story. They don’t show the cumulative effect of short stoppages and delays that can cascade through the entire line.

The team had done a lot of very good work eliminating the longer delays. But now their target condition had to shift to stability around their planned cycle time.

Performance vs Process Metrics

This little exercise shows the difference between a process metric and the performance metric.

Units-per-hour is a performance metric. It is measured after the fact, and tells the cumulative effect of everything going on in the process. In this case, they were able to make a lot of progress just looking at major stoppages..

Stability around the planned cycle time or takt time (you may use different words, that’s OK) is a process metric.

It shows you what is happening right now. THIS unit was just held up for 7 seconds. The next three were OK, then a 10 second delay. It’s those small issues that add up to missing the targeted output.

The team’s next target condition is now to stabilize around their planned cycle time.

Since they averaged their measurements, their next step is to (1) take the base data they used to calculate the averages and pull the individual points back out into a run chart and (2) to get out their stopwatches and go down and actually observe and time what is really going on.

I expect that information to help them clarify their target condition, pick off a source of intermittent delay, and start closing the remaining gap.

## Interesting Question about Cycle Time

An interesting search landed someone on the site recently. Here it is:

a machine is producing 55 parts in one hour. what is the cycle time for each part.

Likely this is someone Googling his homework question, but I’d like to take apart the question and discuss it. If this is a homework question, I would contend that the likely “correct” answer is wrong.

Take a pause and think about it for a second. How would you reflexively answer this question?

Someone encountering this question is likely to simply divide the 55 parts of output into the 60 minutes of elapsed time. Doing that, we get something just over 65 seconds per part.

Which is interesting, but it isn’t the cycle time per part. It is the average rate of production, but it isn’t the cycle time.

I contend you don’t have enough information to answer the question. To really do that, you need to get your safety glasses and hearing protection, go down to the machine with a stopwatch (I’d suggest one with a lap function) and click off the elapsed time interval between each and every part as it come off the machine.

Why?

Well… let’s say that the machine is actually running at a cycle of 55 seconds / part when it is actually operating, but there are frequent jam-ups that the operator has to clear.

Isn’t that a completely different story than running smoothly with one part coming off every 65.45 seconds?

## A Tale of Two Sites

With apologies to Charles Dickens, but the opening line is just too good to resist…

## The Best of Times

In this plant, the advance team is chaired and actively led by the most senior manager on the site. He is actively coaching, he is actively being coached. He is questioning his own learning, seeking council, and acting on it.

They are clear that, while there may be general guidelines, they must learn by trying and experimenting. They cannot simply deploy a roadmap because they can only see the next mile on a 1000 mile journey.

They see it as a method to shift their culture away from its “tell me what to do” legacy and toward one of an empowered workforce that takes initiative and works on the right things, the right way.

There is no doubt among the leadership team that this is the path forward.

They are starting to apply the language of the Improvement Kata informally in their meetings and discussions.

Overall, it seems a bit messy. But learning is like that.

## The Other Site

The “implementation of Toyota Kata” is a directive from the corporate Continuous Improvement team.

The corporate team spends much of their energy developing and deploying templates, PowerPoint presentations, setting standards for the forms and the layout, lettering and colors on the improvement boards, and setting milestones.

They have published a step-by-step procedure for a site to implement Toyota Kata, based on their assumptions of what ought to work. None of them has actually led a change like this.

They are, in turn, working through the site continuous improvement team who is expected to execute to these standards.

The site leader receives weekly reports on progress. Training the managers and “implementing Toyota Kata” is the responsibility of one of the site’s continuous improvement staffers. The site leader questions him using the 5 Questions each week, and issues direction in response to the answers.

It is the continuous improvement practitioner who is responsible for motivating the members of the management team to challenge their own processes and develop their improvement boards. A significant number of them are questioning the need or purpose of this exercise.

## Thoughts

Unfortunately I run into the second case far more often than I see the first. But the story is decades old. That is how we did Six Sigma, kaizen events, Theory of Constraints, Total Quality Management. In each case we have separated the deployment of a core change in the way we manage operations from the responsibility for actually managing.

It

doesn’t

work.

This TED talk by Tim Harford actually sums up the difference pretty well:

But beyond what works, and what doesn’t, we also have to ask “Which approach is respectful of people?”

What are the underlying assumptions about the people at the gemba when “standards” are established thousands of miles away, published, and then audited into place?

Why do they feel they must tell people exactly what to do?

What do they feel is lacking on the site?  Competence? or Clarity?

## “Why Don’t You Just…”

Most leaders will at least superficially agree that organizations with an aligned, empowered workforce are more effective; that decisions are faster when made at lower levels that are closer to the actual facts; and that work teams are the ones in the best position to improve their own processes.

Most would agree that they would prefer their people to take initiative to come up with the best way to solve a problem.

Here’s a quiz.

Take a look at this old photo (it’s real, not staged!), and try to imagine what you think day-to-day interactions with this commander would be like.

How much day-to-day initiative do you think the four officers in this photograph would show when the boss isn’t right there?

What does he teach them to do when he is talking to them?

Why would we expect they would learn to do anything else other than what they are being taught in the course of those day-to-day interactions?

This is, of course, an extreme case, meant to make a point.

But listen to your day to day interactions with your own people.

Do you give them directions they are expected to follow? Those directions, by the way, can take very innocuous forms. They can be disguised as suggestions, “Why don’t you just…” or “Have you considered…?” as well as just being orders.

You can think you are “correcting” or “teaching” people when your language actually is communicating something quite different.

You are teaching your people every time you talk to them. They will answer the questions you ask. If you make a habit of overriding their ideas, they will learn to not bother to work very hard to develop those ideas. If you argue with them, they will quickly learn to give in, or even just wait until you make up your mind. Any time you are making declarative statements about what should be done you are eroding initiative a little.

Frankly, from their perspective, it is a lot easier to just wait for the boss to give direction and follow it than it is to take initiative. There is much less psychological risk and energy involved. And if the organization has a history of risk-aversion you have an uphill battle to begin with.

It only takes a few negative experiences to stamp out initiative.

A thought experiment:

You wish people would take more initiative, self-organize the right people to work on problems in your organization.

Someone is working on understanding a problem or improvement. They come to you with a fairly decent picture of the current condition, but their next step isn’t the one you think they should take.

You have an overwhelming urge to say “Why don’t you just…” and get to a workable solution fast.

If you do so, what have they just learned?

You cannot simultaneously maintain full control and develop initiative.

## Creating an Empowered Team

EDIT: There is a follow-on post here: David Marquet: Turn the Ship Around

In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.

“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”

They brandished their wand uttered some wizard’s chant, and bing! empowered their teams.

“What did you expect to happen?”

“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”

“What actually happened?”

“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”

“What did you learn?”

“That empowerment doesn’t work.”

Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.

The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.

Take a look at this video that Mike Rother sent around a couple of days ago, then come back.

A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.

I’d like to cue in on a couple of things here and dissect what happened.

First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.

But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.

What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.

Let’s put this in Lean Thinker’s terms.

As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.

“What obstacles do you think are now in the way of reaching the target?”

See the illustration above.

Competence and clarity.

### Clarity

Or… where the hell are we trying to go?

Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do it entirely broke down.

What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”

Doesn’t work. Never has.

But I’m beating that topic to death right now, so I want to move the pillar on the left.

### Competence

In my book, that means “The leader has a good idea how to do it.”

What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.

It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.

In Lean Thinking world, competence means a few things.

• The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
• The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.

While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.

But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.

We end up with pokes and tweaks on the current condition, but no real breakthrough progress.

Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.

In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.

First, I gave them answers and explanations.

Then I transitioned to first asking them what they thought I would give as an answer.

Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”

“Captain, I propose we submerge the boat.”

“What do you think I am thinking?”

“Um… you would want to know if it is safe?”

“How would you know it is safe?”

In other words…

What are you trying to achieve here? How will you know?

So here is a challenge.

If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.

You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.

## Curiosity

The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.

To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.

Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?

Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.

To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.

Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.

Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”

You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?

That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.

“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?

All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.

Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.

I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.

But if not them, who? And how do they know it is getting done?

## Active Control

Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?

OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)

Can you predict what will happen, more likely sooner than later?

It doesn’t matter how “stable” your car is.

There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)

I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.

But your process is going to encounter random chatter, and when it does, what typically happens?

In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.

They will clean up the spilled coolant, catch the leaking oil.

They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.

In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.

“Waste is often disguised as useful work.”

All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.

How do we stop the cycle?

The point of intervention is in the last paragraph… “All of this goes unnoticed.”

It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.

Here are some fundamental questions to ask yourself:

Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.

If the team member doesn’t have everything needed exactly what do you want him to do?

Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?

If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?

How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?

Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!

#### An Active Control System

Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”

I alluded a little to this above, but let’s go a bit deeper.

On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.

But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.

The hard part is what is supposed to happen next?

Now we are back to the original questions because the andon is nothing more than a trigger for another process.

Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?

What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?

When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.

How much intervention can the first responder make before being required to escalate the problem to the next level?

#### As a minimum

As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.

This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.

Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”

The only question is what do you want them to do?

## Applying 5S to Processes

The idea that “you always start with 5S”, for better or worse, has been deeply ingrained in the “lean culture” since the late 1980’s. A lot of companies start their improvement efforts by launching a big 5S campaign.

Often, however, these 5S efforts are focused on striving for an audit score rather than focusing on a tangible operational objective.

It is, though, very possible to help bridge the gap by putting the process improvement in 5S terms. By using a language the team already understands, and building an analogy, I have taken a few teams through a level of insight.

For example –

We are trying to develop a consistent and stable work process.

## Sort

Rather than introduce something totally new, we looked at the process steps and identified those that were truly necessary to advance the work – the necessary. The team then worked to avoid doing as many of the unnecessary steps as possible. In their version of 5S, this mapped well to “Sort.”

Now we know the necessary content of the work that must be done.

## Set in Order

Once they knew what steps they needed to perform, it was then a matter of working out the best sequence to perform them. “Set in order.”

Now we’ve got a standard work sequence.

## Sweep or Shine

The next S is typically translated as something like “Sweep” or “Shine” and interpreted as having a process to continuously check, and restore the intended 5S condition.

Here is where a lot of pure 5S efforts stall, and become “shop cleanup” times at the end of the shift, for example. And it is where supervisors become frustrated that team members “don’t clean up after themselves or “won’t work to the standard.”

In the case of process, this means having enough visual controls in place to guide the work content and sequence, and ideally you can tell if the actual work matches the intended work. A deviation from the intended process is the same as something being “out of place.” Then, analogous to cleaning up the mess, you restore the intended pattern of work.

One powerful indicator is how long the task takes. Knowing the planned cycle time, and pacing the job somehow tells you very quickly if the work isn’t proceeding according to plan. This is one of the reasons a moving assembly line is so effective at spotting problems.

Now we have work content, sequence and maybe timing, or at the very least a way to check if the work is progressing as intended. Plan, Do and Check.

I believe it is difficult or impossible to get past this point unless your cleanup or correction activities become diagnostic.

## Standardize

The 4th S is typically “Standardize”

Interesting that it comes fourth. After all, haven’t we already defined a standard?

Kind of. But a “standard” in our world is different. It isn’t a static definition that you audit to. Rather, it is what you are striving to achieve.

Now, rather than simply correcting the situation, you are getting to the root cause of WHY the mess, or the process deviation happened.

In pure 5S terms, you start asking “How did this unintended stuff show up here?”

The most extreme example I can recall was during a visit to an aerospace machine shop in Korea many, many years ago. The floors were spotless. As we were walking with the plant manager, he suddenly took several strides ahead of us, bent down, and picked up….. a chip.

One tiny chip of aluminum.

He started looking around to try to see if he could tell how it got there.

They didn’t do daily cleanup, because every time a chip landed on the floor, they sought to understand what about their chip containment had failed.

Think about that 15 or 20 minutes a day, adding up to over an hour per week, per employee, doing routine cleanup.

If you see a departure from the intended work sequence, you want to understand why it happened. What compelled the team member to do something else?

Likely there was something about what had to be done that was not completely understood. Or, in the case of many companies, the supervisor, for his own reasons, directed some other work content or sequence.

That is actually OK when the circumstances demand it, but the moment the specified process is overridden, the person who did the override now OWNS getting the normal pattern restored. What doesn’t work is making an ad-hoc decision, and not acknowledging that this was an exception.

Once you are actively seeking to understand the reasons behind departure from your specification, and actively dealing with the causes of those departures, then, and only then, are you standardizing. Until that point, you are making lists of what you would like people to do.

This is the “Act” in Plan-Do-Check-Act.

## Self Discipline or Sustaining

One thing I find interesting is that early stuff out of Toyota talks about four S. They didn’t explicitly call out discipline or sustaining. If you think about it, there isn’t any need if you are actively seeking to understand, and addressing, causes in the previous step.

The discipline, then, isn’t about the worker’s discipline. It is about management and leadership discipline to stick with their own standards, and use them as a baseline for their own self-development and learning more about how things really work where the work is done.

That is when the big mirror drops out of the ceiling to let them know who is responsible for how the shop actually runs.

## The Struggle

In The Leader’s Journey, I highlighted the struggle with escalating challenges as a core driver of growth in both our fictional heroes and real-life developing leaders.

This week I was essentially doing 2nd level coaching with a client I have been working with for quite a while. One of the things we did was have a brief session where we reviewed and reflected the ideal state of a coaching / problem solving culture (thanks in large part to Gerd Aulinger and Mike Rother). We reviewed the principles of what a coach and the coaching chain is striving to achieve, and the mechanics of doing it.

Combining that review with the shop-floor 2nd level coaching, a couple of my participants commented on how much better they “got” what they were trying to do. They started to move from rote to the higher-level understanding.

I am still digesting why this week had this kind of breakthrough when we have been working on the same key things for months. Nothing we went over was new information. What was different this time around?

My thought right now is that they have been in the struggle trying to understand this stuff, and finally reached the point where the additional theory snapped things into place. I told them “if you hadn’t been struggling with this, you wouldn’t have had the insights you got this week.”

I really think that is the case. We can give people all of the answers. But I am realizing if they haven’t, first, been struggling to find those answers on their own – if they haven’t been trying hard to figure it out – then the additional information would have far less (or little) impact. It is only after they have challenged themselves that the externally supplied insights have any meaning or context.

At least that is where I am right now. Time for a couple of additional experiments.

## What Mode Are You In?

The main purpose of an andon is to signal that some part of the system is no longer in normal operating mode. The immediate response should be to quickly assess the situation, and recover the process to the normal mode.

Many organizations, however, do not make that mental shift. They don’t have a clear sense of whether they are in the normal operating pattern, or in recovery mode.

Without that sense of mode, “recovery” can quickly become the norm, and a culture of working around problems develops. Sometimes we call this a “firefighting culture,” but I find that term regrettable, as it reflects poorly on actual firefighters.

In the andon driven environment, the andon is either on or off. That is, things are either operating as they should be (no andon) or they are not (andon is triggered).

All of this presumes, of course, that you have some idea what your normal operating pattern should be. Go and walk your shop floor or work area. What can you see happening?

Is what you see what you want to be happening? How do you know? What do you compare it against?

Can the people working there tell if they, and their process, are in the normal operating pattern, or in some other mode?

If they are recovering, do they know they are recovering? Are they striving to get things back to the normal operating mode; or are they striving to simply get the job done in spite of the immediate problem? Big, big difference here. This is what makes or breaks your continuous improvement effort.

Once the normal operating mode is restored (assuming you had one), are at least some of these incidents investigated down to root cause, with countermeasures tested by appropriate PDCA cycles and experiments?

What mode are you in right now?

How can you tell?