S4 E2: Featuring Robert Snyder

Tracie:

Hello, everyone. Welcome to Traceability Podcast. I am Tracie Edwards, your host. Today, my guest is Robert Snyder. He is the founder and president of Innovation Elegance. He's had a 30-year career, spanning roles such as developer, project management, change management, sales enablement, and he is also active in the performing arts. He's worked in corporate, he's been a consultant, he's worked in startups. He's certified in project management and Agile. And his arts career has seen him in numerous vocal, dance, and theater ensembles. He actually has an electrical engineering degree, but he also has an MBA in strategy from Northwestern. Super excited to have Robert with us today. We're going to be talking about his book, Innovation Elegance, and his innovation series that will be forthcoming. Robert, thank you so much for being with me today.

Robert:

Delighted to be here, Tracie. Great to meet you, and looking forward to the chat.

Tracie:

Well, how we usually start off at Traceability is we begin by diving into how you got your start in technology. The reason I ask this is I think that those of us who are of a certain age maybe did not expect that we would be working in technology. And yet, here we are. I thought it would be fun to dive into that with you as well.

Robert:

I think I might have a unique story, because at the age of eight, my father was a professor at a small liberal arts school in Central Illinois. He would drop me off at the computer center for an hour before I would walk to school. I was programming in basic language at the age of eight.

Tracie:

Wow.

Robert:

All the stereotypes of a programmer at that age fit me, and I went on to be an engineering major at the University of Illinois. For the first five years of my career as a programmer at what was known then as Anderson Consulting, now Accenture. I've always been in innovation. I joke that I might be one of the most generic IT consultants you can possibly conceive. As you mentioned in my bio, I've held many of the roles that you would expect an IT consultant to have. Then I went back for my MBA about 15, 20 years ago. And naturally and slowly start pivoting toward more business, sales, and revenue facing roles. My last corporate gig was with a major employer in Chicago. I'll call it this hybrid sales innovation and business PMO role. About five or six years ago, I concluded I have enough of a unique perspective on the ecosystem to get this stuff on paper. For the past five years, I've been writing books, and doing a ton of public speaking on what could be next. What have I learned from my background in the performing arts? What have I learned from working at Motorola, in the supply chain and operations world? I'm writing these books to try to help companies convert from these software-centric methodologies, to a people-centric methodology because software is not what makes innovation teamwork difficult. What makes innovation teamwork difficult, it's us. It's the people. It's how we interact, govern each other, collaborate. We're stink at collaborating. Most of us of a certain age, we have enough lessons learned to feed that back into formalizing. Envisioning, formulating, presenting a people-centric methodology. I often joke that no code was harmed in the writing of these books. Code is going to be just fine. Code is just one activity in your work worth keystrokes. But let's not lose sight of all the valuable keystrokes upstream from the code that, for whatever reason, nudge, nudge, wink, wink, are falling out of favor. The books and my public speaking really turn the screws on our communication channels. Let me try to hit my personal pause button. Communication. When teams get themselves into trouble, the cliché is, "Well, we just didn't communicate that well." That is a place to double-click on, dig into, about well, how do we need to manage, micromanage, mentor, micro-mentor our communication to minimize committing the same sins in innovation teamwork?

Tracie:

I love that. So much of that has to do with, as you say, software-centric methodologies right now. You and I have chatted about the Agile Manifesto, and the expectations that arose out of that. And the developer-centric, technology-centric approach to let's provide this type of value with this degree of frequency. This has been a thought of mine for a long time. I don't think that it prepared us for working in teams, and the communication that is required for working in teams. I wanted to unpack that a little bit with you, to get your take on what are some lessons learned, what are some best practices going forward that we can make our communication in teams more effective. Because I think it requires a degree of willingness to engage that I don't know that we're always prepared for.

Robert:

I'm a person of metaphors. Although this metaphor isn't formally in the book, I think it's appropriate for this conversation, the way we teed up communication. Let's imagine three buckets of communication channels. One is meetings. The second communication channel is email, or asynchronous messaging. The third communication channel is structured documentation. Stuff that has a title, like Process Flow, GUI Design, Roadmap. Training materials, stuff that's tangible, that you can print out. What I believe has happened over the last 20 years is that, in these three communication channels, what's in the front seat are meetings and email. What's in the backseat is any documentation, title or not. The model that many innovation teams are pursuing is talk, talk, talk. Meeting minutes. Talk, talk, talk. Meeting minutes. There's a collective shrug about structured documentation that applies to every project. For starters, I'd like your audience to consider just changing whose in the front seat, changing who, what is in the backseat. Consider putting meetings and emails in the backseat. What's in the front seat? It's structured documentation, and all the things that those of us of a certain age, of a certain experience level are more than familiar with. We're more than familiar with a change log, a roadmap, a project charter, a process flow. The GUI design. Your logical database model. Your code. Your migration script. Your data conversion scripts. Your deployment weekend plan. Your training approach. There are dozens of things that are worth documentation. They have a formal title. They're not surprising anyone. Although it's not predictive, it's predictable. To govern this inversion, asking folks to switch seats in the car, rethink the RACI Matrix. The RACI framework, responsible, accountable, consulted, and informed, it's also been around for 20-some years. Without going into too much detail of, I think its weaknesses, its limitations, I believe it is simply a false sense of governance. Again, it's had 20 years to solve our problems. To solve meeting gridlock, communication traffic jams. I do think that it got one thing right, in that the RACI Matrix assets well, there are four-ish tiers of contribution. So let's retain that. But another thing that, as we switch front and back seats here with communication channels, there's another really destructive thing that I've seen in teams over the last 20 years. I call it verb sprawl in your project plan or in your task list. Many of your listeners, I suspect, have seen a task list or a project plan with 20 different verbs, 30 different verbs, 40 different verbs. Holy ambiguity, Batman. Because anyone can look at these verbs, and you're left a little bit paralyzed, deer in the headlights saying, "Okay, which of this stuff is worth documenting? What's a chat? What's a switch in the vendor tool?" When you plan with verb sprawl, you slow down your planning. You're reinventing the wheel. You slow down the interpretation of that plan. You've got ambiguity all over the place. And verb sprawl is contributing to this newly resurrected acronym, VUCA. VUCA stands for volatile, uncertain, complex, and ambiguous. Many innovation leaders, C-suite folks, they're surrendering to VUCA. They don't think they can solve VUCA. I understand it's a crazy world out there. But within your team, within your team you should be able to solve VUCA. Do not adjudicate accountability for craziness and priority whiplash. Instead of verb sprawl and instead of the RACI Matrix, my books propose a framework that I call the Five Verbs. The RACI Matrix has four adjectives. Well, I believe anything that you would include in a RACI Matrix, trying to govern with those four adjectives, I believe is worth five verbs. The verbs are draft, review, revise, approve, distribute. If you can think of anything worth collaborating on, it's going to be worth documentation because you're going to want to remember it six to 12 months from now. Instead of trying to govern it with these four adjectives, govern it with five verbs. Draft, review, revise, approve, distribute. I wouldn't prohibit other work. I would just assert it's not worth putting in the project plan. It's low collaboration. It's low durability because evidently, you're asserting that it's not worth documentation. It's not worth oversight or approval. So maybe, do it at the pub. The books and the elegance methodology really challenges teams to take a hard stand. Your collaborative work, is it worth five verbs? If not, what are your verbs? It might be either outside the project plan, just don't govern it, so don't complicate your project plan. Or just do it at the pub because you're saying it's not worth documenting, therefore it's just a chat.

Tracie:

One of the things with Agile, it brings people together. But it doesn't necessarily say who or what. It just says you're working together to deliver this thing in two weeks. We've had all these folks who maybe had a title that are now part of an Agile team. They're wondering, "Well, what are my responsibilities within the Agile team?" Whose responsible for that documentation? Whose responsible for the communication? Especially as we're essentially creating some sort of conflict as we're trying to put this all together. Healthy conflict, hopefully. But how do we, A, the who and the what, and then really, how do we make it psychologically safe?

Robert:

Yeah. You hit on at least three different points I'd like to try to touch on. Amen to everything you're saying, first of all. I want to point to one of the performing arts. Imagine a team trying to imitate a symphony. There are two finite aspects of a symphony. Just how many instruments you have, and just how many notes can they play. The keyword here is finite. It could be a lot. You might have an 80-piece orchestra playing two, three, four octaves. It could be a lot. But it's still finite. I think a disadvantage that Agile has is that things are infinite. Things are very squishy. I think it's impossible to try to synchronize an infinite number of moving pieces. Agile puts teams that they like the culture trade of synchronization. It puts them at a disadvantage because you're reinventing the wheel. Your verbs are ambiguous. And you're just not that disciplined because I think in the Agile world as well, there is this blurring of the word explicit and rigid. Some Agile purists feel they are the same thing.

Tracie:

Right.

Robert:

I would argue they're not the same thing. The ink can always be wet. You can be explicit, but not rigid. I do believe that ... The sibling of a symphony is a jam session. A jam session is accidentally successful. It's not repeatable. If you get lucky, you're successful. Well, a symphony is so well rehearsed, that even if a violin player sneezes and has to step out for 10 seconds, the symphony is going to be fine. I understand that a lot of innovation professionals like the metaphor of a jam session. A jam session is not scalable. We could go even deeper into the culture traits of a jam session, and we could go even deeper into the culture traits of a symphony. But I'll go back to the term synchronization. I understand that Agile claims to be fast. I'm going to say it's really high frequency. Speed and high frequency are not the same thing. Companies that are obsessed with speed as a leader culture trait get themselves into trouble because, what happens is thoughtless speed, unsynchronized speed ends up in traffic jams. If you want speed, that's great. But teams must treat, they must treat speed as a lagging culture trait. Well, what is the prerequisite? What is upstream? It is synchronization. Teams that are obsessed with speed end up in traffic jams. The only way a team has a prayer of being past, or whatever tempo they want to work at, they must be obsessed instead with synchronization. The five verbs framework, it's finite. A team may have a lot of documentation, 20 different things to document, 30, 40. It's still finite. It's synchronizable, it's scalable. I don't need 10 verbs. Just like a symphony has two finite components, the elegance methodology has two finite components. What's worth documenting and the five verbs. Everything else, don't prohibit it, just don't manage it.

Tracie:

Okay. I liked that. I think that gets to the heart of what is important. What is important that needs to be retained? Everything else is extraneous.

Robert:

Could I continue on the topic of conflict?

Tracie:

Sure.

Robert:

My experience executing the five verbs at my previous employer. Again, the verbs are draft, review, revise, approve, distribute. Just like in a symphony, you have dissonance, tension in the chord, followed by resolving the chord. It's called consonance. In our teams, we need the same things to have the efficacy, the value of team and diverse thinking. The five verbs welcomes divergent thinking. Then it says, "Okay, time to converge." The five verbs supports the richness of what we see in a symphony. But it is task conflict, it is not personality conflict. Let's say you, Tracie, are representing the insurance line of business. And I, in the same company, represent our public sector line of business. Every now and and then, you and I should expect to have disagreements. The five verbs helps keep us focused. This is task conflict, and our respective bosses, they're name is next to approve. You and I always know there is a micro-escalation point. There are micro-sponsors. There's a built in tie breaker for if and when insurance line of business and the public sector line of business have a different perspective of a GUI design, or something. The five verbs, while it's incredibly simple, and looks almost petty, it helps teams to say, "Task conflict, good. Personality conflict, out of scope. Disagreeing is okay. Demonizing, not okay." I love the image, instead of a boxing ring of people, it is a boxing ring of ideas. I believe, and we had this experience at my previous employer, the five verbs is culture shaping. To steal a quote from W. Edwards Deming, "Small hinges swing large doors." I believe five verbs is a small hinge that swings a large door of culture change because of those things to anticipate the conflict. What are the chances that two or more intelligent, independently-minded adults are going to disagree about something in the workplace? Well, 100% chance. Again, anticipate the disagreement, manage for it. Give wonderful visibility and transparency to not only the content, because it's on paper, but also the schedule to minimize surprises. At my former job, my boss and I, that was our default question is what is the next negative surprise? Can we find it before it finds us? The five verbs help us to continually ask, "What next? What next? Where is the next surprise?" Because all of us I believe want cultures where we minimize our negative surprises, and we maximize our positive surprises, which tiptoes into the art of improv. But again, I want to hit my personal pause button.

Tracie:

Well, I really loved that. I love the analogies that you used there. Speaking of symphonies, and speaking of timing, I think one of the arguments for lack of hard assets is time. "I don't have time. We need to push this out." Speed. But I think the question then is well, what's the trade-off?

Robert:

Yeah.

Tracie:

Right?

Robert:

I have a couple responses, but did I let you finish?

Tracie:

Go right ahead.

Robert:

Okay. We don't have time. One word that comes to mind is debt. Many of us of a certain age know this term tech debt. Where developers will cut corners to meet a short term goal, but they make someone's life harder later. Because the code is uncommented, it's not scalable. It doesn't anticipate future modifications, so it hinders future teams. That's tech debt. It's not the only kind of debt in the business world. Financial debt, for another time, another podcast. But when we cut corners on documentation, you can imagine a new employee coming in to an organization, a new project starting and someone saying, "Oh my God, nothing's documented." This is called documentation debt. There's a third kind of debt I see that I'll call innovation debt. Because many companies... There's a term change saturation. Teams are overwhelmed, there's fatigue, there's burnout. Consciously or subconsciously, I believe companies are figuratively seeing these communication traffic jams and concluding, "Why would I put another car on the road? We don't manage this current traffic jam very well. Why would I add to our innovation demands?" The demand of innovation. Companies are innovating less than they could and should. Valuable innovation work is piling up. There's a lot of idle innovation work. On the other side of that equation, the innovation supply. Through the meetings and networking that I've done over the last few years, I believe there are more under-employed and unemployed innovation professionals than really makes sense. Given all this valuable work, we've got idle innovation work, we have idle innovation workers. The market's not clearing because of the high level of friction. This is how I conceive a kind of innovation debt. I think it's fair to name a fourth kind of debt that I'll call methodology debt. The word agile has been much more successful than the teams who are executing Agile. Agile is a bulletproof, invincible term so good job. But when you think of what's happened to Agile over the last 20 years, the first evolution of Agile that I was exposed to was called Disciplined Agile. Suggesting the previous version was less than disciplined. Then there was Scaled Agile, suggesting that the previous version was not very scalable. Noted. Now we've got this term Business Agility, suggesting that previous versions of Agile were not very business focused. I would violently agree with that. We're still hanging on for deal life to this word agile because of the reaction we had to what the web was in the mid and late '90s. Ladies and gentlemen, it is 23 years later. We have methodology debt. The innovation world has methodology debt. I believe it is straightforward. We need courage to pay back all of these forms of debt. Tech debt. We need to go find the documentation debt and knock that out. Innovation debt, methodology debt. Back to your point about, "Well, we're just going to shrug because we don't have time." Well, basically that raises their hand and says, "I am willing to take on the debt." Okay. But your future team thanks you very little. If we think about a city with certain decisions about their public transportation. That city, going back to your point about, "Well, we just don't have time." A city, there are plenty of cities in the United States that would say about their train system, "Well, we just don't have time to build a train." So what happens is they're overly dependent upon highways and cars. We could probably name a half-dozen of those cities ourselves.

Tracie:

For sure.

Robert:

But some cities have said, "No, we're going to take the time to have public transportation. Buses, trains, left-turn lanes, stoplights, overpasses." An overpass might be the most benign example. If you don't have time to build an overpass where there's a lot of traffic, well you've just signed up for a really busy, painful intersection that gets talked about and gets more attention. Then it just drags down the morale of anyone having to drive through this intersection that could have had an overpass. If you would have just had the foresight to anticipate, "Well, maybe over the next few years, our traffic..." And again, I'm going to jump back to an innovation team. "What are the chances that our innovation traffic, our communication traffic is going to increase over the next few years? If you're a growing company, of course your communication traffic is going to increase. You must anticipate that, or you are explicitly signing up for debt. Methodology debt, innovation debt. If you don't have time, you are signing up for innovation debt. You're less creative, you're less innovation. You're not as profitable. You're less interesting the work for because you put all your employees in communication traffic jams. No, thank you. No, thank you. I need to settle down.

Tracie:

That actually brings me to another question. The politics of it all, right? The trade-off happens because there's a political, cultural thing happening within company representatives, city representatives, et cetera. Tips for breaking the political barriers?

Robert:

Yeah.

Tracie:

To addressing some of this debt.

Robert:

Yeah. This does tiptoe back into the topic of psychological safety, and I'm glad you raised it. I'm going to ask a somewhat playful, mischievous question on the topic of politics. What are your verbs? Some people care about your pronouns. I respect your pronouns. But as an innovation leader, I want to know your verbs. I'm coming to any innovation team, any organization, any team with five verbs. Now, I hear this dark cloud call politics. Should I put the word politics in my project plan?

Tracie:

Probably not, right?

Robert:

How many [inaudible 00:28:25] should I reserve for "politics?"

Tracie:

Yeah.

Robert:

By the way, that's a noun. Is politics worth documenting? Because everything else, I'm just going to leave out of the project plan. Any time someone brings me this term politics, "I need your verbs." Is whatever your talking about, is it worth putting on paper? Is it worth memorializing? If it's not, do you want me to manage it? I just want to know your verbs. Politician ABC, if you're coming to me without verbs, why am I managing this stuff? I just don't have any sympathy. Another metaphor of the books and my public speaking. I am here to shepherd. I've got my five verbs. I'm thinking about the project charter, and the process flow, and the GUI design, et cetera. I'm thinking about this agreement factory, and expectation factory. That is my mission. I'm just here to synchronize an elegant expectation factory. If someone says, "Oh, but politics." Well, does that slow down my factory? Of course. Does it hurt my speed? Yes. Does it hurt my quality? Yes. Does it create more waste? Yes. Okay. So you're gumming up the factory with politics. This might be their world and I'm just in it. I love the phrase, "Lead me, follow me, or get out of the way." If some political force is coming at me, I'm just going to say, "You know what, I'm happy to lead this expectation factory. But if I'm not the right leader, I'll follow. Or I'm just going to get out of the way." But don't create this whiplash, and foster this culture of VUCA. I'll do that for you for a short window, but you better believe I'm going to go find a less political environment that is more synchronized, that's more harmonic. There is more harmony. That I feel that there's more value there. Instead of having to deal with political landmines. So politicians, show me your verbs.

Tracie:

I like it. In the time that we've got left, I think let's take it back off this a little bit. You alluded to it. The topic of okay, this situation, for whatever reason, is not working. And either lead me, let me lead, or let me be left behind. How do we know, in our own careers, when we're in that situation? How can we feel comfortable pivoting, et cetera?

Robert:

I'm going to key in on two words you said, if that's okay, and tell me if I'm interpreting it right. The words "not working." This is not working. A few things come to mind. One tool that I include in the book and I include in my public speaking frequently is a tool called I Like, I Wish, I Hope, I Wonder. I like, I wish, I hope, I wonder. Those four phrases, inviting all employees to finish the sentence when they have a compliment to give, when they wish something was different. When they're concerned that something in the future may not be in place as expected, as needed. Then the I wonder is welcoming the innocent question, the politically sensitive question. That framework is worthwhile every week as an appendage to every employee's individual status report. That is just one tool that I hope can confront this condition, this culture that you called "not working." Another thing that came to my mind is out of Negotiations 101 class, and the Getting To Yes book is probably behind me somewhere. There are two terms that employees should know to safely step back from job security, and grow, take the steps toward career security. The first term is BATNA, B-A-T-N-A. It stands for best alternative to a negotiated agreement. I believe all of us, as we care for our families, we need to keep a roof over our heads, et cetera, we owe it to ourselves to exchange, to swap in job security. Because we don't want to be at the mercy of executives, or businesses, or business models that are vulnerable to bad management, poor market dynamics, that sort of thing. We owe it to ourselves instead to be obsessed with career security. We always need to have amazing options so that if we were, let's say we're hitting a rough patch at a certain job, it's a powerful position to be able to walk away. Imagine a situation where you're in an ethical dilemma. All of us owe it to ourselves, owe it to our families to have the power to walk away. That term BATNA, I think can be helpful. Again, that is in negotiations fundamentals. The other negotiation acronym is ZOPA, zone of potential agreement. Any two people, any group of people, you and I over the last week in planning this event, we had a ZOPA. We had a zone of potential agreement. You and I are either one or two time zones away. If we were 14 time zones away from each other, our ZOPA would be constrained.

Tracie:

Yes.

Robert:

That's a lighthearted version of this. Going back to your term "not working," I believe this framework, I Like, I Hope, I Wish, I Wonder, it fosters a culture of psychological safety. Two-way accountability. The title of your podcast, Traceability, I'll call this it's two-way traceability accountability. In the books, there is a very vigorous lessons learned template that not only uses those phrases, I like, I wish, I hope, I wonder. But it also inventories about a dozen culture traits that I believe qualifies the pattern in the problems. I believe there are not a million different categories of problems in innovation teamwork. I count about 12. I count safety, accountability, alignment, morale, momentum, simplicity. Stylishness. Are we learning? Emphasis, balance. Again, there's about 12. I believe that the typical retrospectives and lessons learned, they're just not very rigorous. They simply ask, "What did we do well? What could we do differently?"

Tracie:

Right.

Robert:

All I'm asking teams to do is go through a checklist. Just like a pilot goes through a checklist. How is our psychological safety? And finish the sentences. I like, I wish, I hope, I wonder. How is our transparency? I like, I wish, I hope, I wonder. How is our scalability? How is our accountability? How's our alignment? A monthly rigorous lessons learned, I believe it makes these culture traits in your face. It minimizes the chance we were blindsided. Like, "Oh my God, here we are three months later and XYZ isn't working." We have to continue to monitor, challenge ourselves with the right language, the right word choice. Because again, we've got a generation, we've got 20 years of lessons learned. We all know that the feedback loop of the collective lessons learned in innovation is terrible.

Tracie:

Yes.

Robert:

That's what these books aim to do is to, even with a paranoid lens, what could go wrong? What should I do with that narcissist that's about to be hired? I believe that the dysfunction, the cultural problems that teams have, they're not a surprise. We know what they are. Let's put them on paper and let's map them to the phrases I like, I wish, I hope, I wonder. Now this grid, 12 by three, that's 36. I'm not asking teams to populate 36 things. As few as two.

Tracie:

Right.

Robert:

Two sentiments a month, and getting into a routine, a rhythm of this really rigorous framework. Having these incredibly valuable culture traits, they're always there waiting for us, reminding us we need to be striving for healthier accountability, alignment, transparency, morale, momentum, et cetera. I'm trying to make this muscle memory. I'll make one references to the world of dance. My books and the elegance methodology focuses on mechanics. I'm hoping that teams embrace the five verbs, embrace tools like this Lessons Learned, and the I Like, I Wish, I Wonder framework. They normalize them. And they become easy, and routine, and second nature. This muscle memory is a form of automation. The value is now that we don't have to spend our brain power on it anymore, where does our brain power go? Well, on the dance floor, instead of mechanics, it's called style.

Tracie:

Okay.

Robert:

That's where the creativity comes in in innovation teamwork. Because once we're fabulous at the fundamentals, we're brilliant at the basics, we can transcend, we can raise, elevate our brain power into the creativity, into the surprise and delight for our stakeholders. Because we're spending too much time reinventing the wheel, mired in verb sprawl, and the mechanics. Well, no wonder we're not having fun when we haven't mastered our mechanics.

Tracie:

I think that is a great point to wrap up with. That the more practiced we become, the more innovative, the more creative. And really, the more timely we become.

Robert:

Teamwork becomes easier, more joyful, more creative, more strategic. More empathetic. We find new customers. We find new things to solve for new customers. It is about the money. Follow the money. Follow the profit, follow the value. Pursue it. I hope your listeners will keep working upstream. To push the mundane and push the mechanics downstream, automate it, so that we can focus upstream toward the creative. New markets. New stakeholders. New customers. New profitability.

Tracie:

Love it. Well, as we conclude today, thank you so much for being here. Are there any questions you have for me?

Robert:

Gosh. Well, what's coming up on your calendar, professionally or personally, that you're looking forward to? Here in Chicago, we have 12-months of outdoor fun jammed into three months. In your part of the world, I don't know whether you have something similar. You have a different geography, you have a different weather. Your relationship with mountains and oceans, or lakes, is different than mine. What do you have coming up that you're looking forward to?

Tracie:

Let's see. I guess personally, I have been working on a doctorate, so the end of the summer, I begin my capstone project. That will segue with a lot of the professional work as well.

Robert:

Thank you for hosting me. I hope your listeners get something intriguing, entertaining, something amusing, and helpful for their teamwork.

Tracie:

It's going to be magnificent, I know. I really appreciate you hanging in there with me, and being willing to be here. Again, the book is Innovation Elegance. It's available on Amazon and other outlets. Definitely worth your time, and definitely worth the read.

Robert:

Thank you. Thank you for hosting me.

Tracie:

Thanks, Robert.