In the latest edition of the Full Stack Leader, we talked to Sergey Sundukovskiy, co-founder, CTO and CPO at Salesmsg.
A seasoned tech leader, Sergei emphasizes the significance of recognizing one’s unique leadership style, whether it leans towards a “Follow me” or a “Charge ahead” approach. He also stresses that prioritizing outcomes over specific methodologies is crucial for success, and reminds about the negative impact of overthinking.
In this conversation, Sergei talks about the multifaceted role of a Chief Technology Officer, particularly in the context of startups and established enterprises. He discusses the evolving responsibilities of a CTO, from being a hands on technical expert, to a more strategic leader focused on optimization and scalability.
Top leadership tips from Sergey Sundukovskiy
Below is a summary of the top Leadership tips shared during this week’s interview. Listen to the episode to learn more about the thoughts behind these tips:
- Understand your leadership style
- Outcome matters more than how you get there
- Document the guiding & operating principles
- Separate commitment from involvement
- Declare yourself in all situations
We hope you enjoy the episode. You can find more Full Stack Leader episodes here.
Part 1. On the role of CTO
Ryan: Hello everyone. And welcome to this week’s episode of the full stack leader podcast. This week. I’m here with Sergei Sundukovskiy. He’s the co-founder, CTO, and Chief Product Officer of Salesmsg. Welcome, Sergei. It’s great to have you here.
Sergey: Ryan, it’s super exciting to be here. I’m looking forward to a very interesting, productive conversation.
Ryan: Yeah, I think we have a lot to talk about. You cover a lot of bases in the tech leadership world. And so I think it’ll be interesting to hear how these things blend together for you.
Sergey: Absolutely. I have a lot of diverse experience and lots of years to cover. So, I have some very good examples, and I’m sure some good conversation will ensue.
Start of the CTO career
Ryan: Excellent. So, let’s talk a little bit about where you’re from. How did you end up in this position? How did you get into tech, and really, what kind of created such a well-rounded career for you?
Sergey: Well, I had a somewhat typical engineering career at the very beginning. I started with hardcore engineering, electrical engineering, and mechanical engineering, and then I immigrated to the United States. And eventually, I found my way into computer science. I didn’t quite know what computer scientists did. So I did everything across the board, anything from release engineering, which is now called DevOps, to database administration.
Eventually, I got a bachelor’s degree in computer science from UCSD and progressed through the ranks. Senior developer, Director, VP, CTO of this, and VP of that. And that’s been my journey. But over time, I diversified from technology, or rather, I didn’t go away from technology. I stayed firmly. I had a firm footing in technology, but I also diversified into other areas of the business, from operations to product to many different things as you have to when you become a startup founder.
Ryan: Yeah. What blows me away is the amount of diversity in the verticals you’ve worked in, as well as the different jobs that you’ve actually done within them. On a matrix, it’s a pretty big list. But one of the things that I was wondering upfront is I see that you’ve worked in everything from e-commerce to media to the financial sector. Which of those that you’ve worked on in the past has been the most interesting or the most growth for you over the course of time?
Focusing on one customer segment
Sergey: That’s an interesting question. I haven’t thought of it that way from “Which one has been more interesting or not.” I initially tended – and this is what happens to most of the people – to specialize in a particular vertical. And so did. I specialized in eCommerce, and I worked for the top five of the top 10 eCom SaaS providers, both on the direct-to-consumer side – be it Sears or Nordstrom, Macy’s, all the federated businesses = or working for SaaS companies that were providing software to smaller and medium businesses – Magenta, Volusion, just typical what you hear as eCom providers.
I either consulted or worked for them, but over time, I realized that the verticals were not what really interested me, but really a particular segment of the customers that I really liked. This was a small to medium business, so I started to specialize not on the vertical or the particular vertical but really on a particular type of customer. I got to know the customer really well in that particular segment. The needs had emerged, and so I would start or join startups that were covering the needs of these customers across the board, be it construction vertical, e-commerce vertical, finance, or marketing vertical, and so on and so forth.
The role of CTO and what it entails
Ryan: Yeah, that’s amazing. And it actually brings up a very good point of this kind of separation between these larger federated companies that you’re pointing out and startups and the way when you’re covering those types of customers, the companies themselves have to be a little bit different in the way that they’re working and the way that the financing is set up within the company causes a completely different way of doing business as well internally. What are some of the big differences you’ve seen over the course of time between working at some of the larger companies and some of the smaller companies and being tech leaders within them?
Sergey: It’s a really interesting question because there’s a lot of diversity, and also, there’s a lot of confusion about the role of the CTO in the smaller company and the large company. Again, roles are somewhat malleable, and so they have evolved over time, but in general, larger companies demand different things from technical leaders, be it a CTO or a VP of Engineering.
CTO is not just about “T”
Again, some of the titles have been somewhat diluted based on the size of the company, but the biggest difference from a startup perspective is we need to have a lot of people within the company, so if you’re a technical guy, then they call you a CTO, and they just expect for you to do a whole gamut of activities from actually writing the software and hiring the team and managing everything technically related, so if it has an on and off switch, they want you to handle it but at the same time be in the boardroom and talk to the investors and whatnot.
In larger companies, the job tends to be more political, and I don’t use “political” in a pejorative sense. It requires a lot more “people” work, and it has to do with more optimization than building things. So if you’re part of a larger company and you have an $80 million budget – which, at some point, I had, really – optimization becomes the core of your job as opposed to just building things and de-risking the business and building products and so on and so forth, even though there’s a lot of that is involved. So you move from really being the builder to being a people manager.
Being a startup CTO VS CTO in a big company
Ryan: And what does that look like on a day-to-day level? Like, if you imagine the day in the life of a CTO at one of the startups you’re at versus how it’s very different in the day in the life of you with the $80 million budget.
Sergey: Yeah, again, great question. Day-to-day changes from a startup perspective depend on the life cycle of the startup itself. At the very early stage, half of your day is taken up by writing code and being the best partner to your co-founder or co-founders as you could be, which basically may involve pitching VCs, talking to the board, or being involved with the rest of the business because there’s just not enough hands in the pot in order to have everything aligned.
That’s why you end up being an expert in many different areas, and you just get involved in other areas, be it marketing or sales or anywhere else you’re expected to оpine – even if you don’t own those areas, you still need to get involved. Now, when you are in the larger company, the majority of the day is taken up by the meetings and really just making sure that everybody’s aligned across the board.
So you still have business partners, and you still have the same concerns as you have as part of the startup. But a lot of the conversations are about risk and risk mitigation and making sure that you’re on time and on target on your projects and whatnot, and half of your day or more, you’re just meeting with people.
CTO and leadership
Ryan: That’s really interesting. And on a related note, thinking about that, when you think of the concept of leadership within those two roles, where do you actually show the leadership on a startup level versus show the leadership on, let’s say, an enterprise level from a leadership perspective?
Sergey: It’s all part of the leadership again. When you’re part of the startup from a leadership perspective, obviously, you’re expected to be the flag bearer for the technology and the product that you’re developing. So you’re showing leadership from both defining the product, finding technical solutions, making some choices, and sometimes making some really hard choices in terms of what to build and how to build it and whatnot.
Now, from a leadership perspective in a larger company, sometimes again, as I said, it’s a lot more of a people management job. It’s an optimization. It’s career management of your much larger team than it would be in the case of a startup. So, managing people’s careers, you’re still making some technical choices but also opining on some of the business choices that you have to make.
And again, the leadership, there is a lot more choosing between multiple products or technical solutions that you’re going to be introducing into the enterprise, which is not an easy fit, right? Because within larger organizations, you have compliance, and you have many other things you have to worry about.
So, some of the leadership that’s expected from you is to push against those obstacles and get your projects through.
Relationship between CEO and CTO
Ryan: Yeah, it’s a great way of looking at it. A minute ago, you brought up an interesting point about the relationship of a startup CTO with the startup CEO.
And I think that also applies on the enterprise level, especially trying to move through some of those challenges that you’re talking about. What do you think about the relationship between the CEO and the CTO? Are they different in these two environments, or how does this work for you, and how has it worked for you?
Sergey: They are somewhat different, yet there are certainly similarities. In the larger enterprise, a lot of what you’re doing is optimization. So. What, in general, does the CEO need to know from the CTO? Well, first of all, that we’re on time and on target for whatever it is that we’re building. That’s one.
On technical debt
Sergey: Number two, whatever it is that we’re building, we’re not doing so at the expense of the future. We’re not incurring disproportional technical debt within the product. Now, again, when you’re part of the startup, a lot of the technical debt goes by the wayside because it doesn’t really matter as much.
What technical debt you’re going to incur if you’re at the very beginning of the journey? You’re literally just worried about the survival of the company. So, the CEO expects things to be built fast, fast pivoting, and building the minimal viable product. So, the CEO is a lot more concerned with being on time and on target.
When you’re part of a larger company, technical debt is certainly an issue -organizational debt, technical debt that needs to be, that needs to be managed. So all the shortcuts that you have taken at the beginning and you’re operating at scale, the CEO needs to make sure that we’re not gonna paint ourselves in the corner and we’re just disproportionately managing our debt as opposed to producing the new functionality.
Differences in leadership and communication style
Ryan: Yeah, that’s really interesting. Would you say there’s a difference in the communication style between the two? When I think of startups, I tend to think of people in a single bullpen or small conference rooms working together versus in a corporation, maybe more boardroom-oriented.
Is this consistent, or is there a change happening over the course of time?
Sergey: This is pretty consistent. And again, if there’s any change, it’s certainly the change that happens from the time of the company from the inception point of view to the point of view of the company being out of survival mode from a startup perspective and getting into the hyper-growth or the scaling phase.
So, in larger companies, you have a lot more people, a lot more hands in the pie of everything that occurred. You’re expected to be more political, right? You’re expected to reach a consensus on things. And so your leadership style might change when you might be a lot more direct at the time of just purely being in the survival mode to the mode of optimization where there are lots of opinions and you just need to reconcile them and chart the course.
So again, yeah, there are certainly differences in the leadership style, and it’s not just what you’re comfortable with, but what’s required of you in order to, and in order to get the projects across the board, whatever that might be.
Understanding the role of CTO
Ryan: That’s amazing. Yeah. It’s really interesting to think about, like, really the same conceptual role name and these kinds of very big differences.
It brings up the question of why this role of CTO is kind of misunderstood in general. And what are the expectations? Do you feel like that’s something you faced as you’ve gone into new organizations in the past?
Sergey: I certainly have. The role of the CTO has been understood very differently by, well, first of all, there are differences obviously between small companies and large companies, startups and well-established enterprises.
So, what’s expected of you changes. So that’s one. You go from a doer to a manager, doer to just purely manager, right? And because, again, people management tends to be the core of what you do with the larger company, even though you’re expected to be technical, you’re still the emphasis of your job is going to be all about optimization, right?
Expectations from a CTO
I mentioned optimization a number of times, but that’s really what it’s about. We’re optimizing operations on a large scale. The job of the CTO gets misunderstood because, when the company in that stage where it’s going from the day-to-day survival to scaling, you’re still expected – unless the CEO changes the perspective as well in terms of what’s expected of you – you’re still coding day to day, and you’re what I call “being on the critical path,” which is your part of the project and you’re acting as one of the developers or architects on the project versus purely being on the management side.
That expectation at a certain point gets stretched to the point where it’s not really clear what you’re doing day to day. So that’s why the misunderstanding comes with from the fact that, again, you’re now acting in a different capacity.
So this is both CTO and CEO and the entire management team or executive team education in terms of what’s expected of you.
What to expect when you are switching to the CTO role
Ryan: So, let’s say you’re a developer who is being promoted into this position, or you’ve been requested by a CEO to become a partner in the company on this level. What are some of the first things that you would recommend that they think about going into a startup as a CTO if they have never done it before?
Sergey: So there’s a couple of things. Let’s unpack this question. Let’s just say you were a first technical hire or you’re the partner in the business and you’re growing up in the business. And now, so you were given a title of CTO before, and now you actually have to scale the company now, scale the staff, and scale the operations of the company.
First of all, You need to figure out if this is what you want to do. Just because there is a career path into staying a CTO or becoming a CTO, it doesn’t mean -just keeping in mind- that the majority of your job is going to be all about optimization. You need to understand if this is what you want, right?
Doing your research
Because often, I’ve seen it where people really don’t realize what the job entails. And, once they get there, they don’t want to do it. So, first of all, you need to be introspective and retrospective in terms of what you want to do.
Well, let’s just say this is what you want to do. You need to realize what you’re going to have to do in addition to what you’ve been doing and what you’re going to give up – and just basically structuring your day in such a way – so, just realizing what the job entails. One of the best ways of doing this is actually talking to other CTOs and seeing what they do and just emulating, just trying to find somebody who has been in that position and trying to get some tips on what exactly the job is going to be like and what you’re going to be doing from a day-to-day perspective.
CTO and product: where they mix
Ryan: Yeah, this is great. I think it’s such a powerful illustration of some of these challenges of somebody who’s really growing into the very, kind of, early stages of that growth-oriented CTO, and it really also applies to somebody moving from a startup CTO, growth-oriented CTO to more of an optimization CTO. It’s excellent. And I’m glad you’re sharing this.
One of the other things that strikes me about this, especially with your particular title, is how many different things a CTO might do because you’re a CTO and a CPO, and really probably cover even more bases than that,
How do those two things cross?
Sergey: Yeah, Ryan, that’s an excellent question. So one of the things we’ve seen within the industry where CTOs diversify into product especially, this happens. So again, diversification into product occurs early on because within the startup, you cannot, you really cannot separate what you’re building from how you’re building.
You need to clearly understand your customer. You need to understand what the customer wants. Why do they want it? Why are we building things the way we’re building? All that is part of the product. If you’re purely technical and you’re just an order taker, tell me what to do, and I will do it, and I’ll figure out the “how” that’s just not going to work for the smaller company, or it has severe limitations.
…and where they don’t
Sergey: So, the role of the CTO has diversified into the product very naturally. You need to know, love, and understand the product you’re building. Otherwise, you’re not going to be as good at building that product as you otherwise might be.
Now, when you’re moving to larger companies, there’s just so much for you to handle on the technical side. Some of the product responsibilities might go by the wayside because, again, a company can afford a separate Chief Product Officer or somebody on the entire product group, and simply by nature, you’re just not required to do anything on the product side, or not get as involved there.
However, I see those lines are being pushed harder and harder, even in the larger companies, because just understanding how things need to be built cannot be separated from “What we are building?” and “Are we doing in the best way possible to meet the needs of the customer?”
Product analytics: CTO view VS CPO view
Ryan: Yeah, that’s really great. I think that a lot of this stuff shows up in the way analytics are read as well. If you had your CTO hat on versus your CPO hat on, how might you look at a common set of app analytics or product analytics differently as a CPO versus as a CTO?
Sergey: Again, it’s a wonderful question because this is the type of activity that occurs on a regular basis, and it’s difficult to separate what sort of things were reporting from a technical perspective and what things were reporting from a product perspective.
So, let’s just talk first about the differences from a technical perspective. What you need to know as a CTO, as well as similar stuff that the CEO would be asking. “Are we building disproportionate?” or “Are we incurring disproportional technical debt?” So you need to manage that, which is really “How many bugs are we seeing in the system? Are they escalating? What’s the difference between created bugs and resolved bugs? What’s the average time that it takes for us to resolve a particular issue? And also the new functionality – when it gets requested, how long has it taken us?”
Measuring core KPIs
So you’re basically measuring the productivity of your technical team in addition to looking at all the core metrics from an infrastructure perspective. We’re now in the brave new cloud world. It’s not so new anymore, but still, we need to keep an eye on just the basic cost. What does it take for us to run our software, and is the cost escalating as we’re scaling, right?
We want to make sure that the cost remains manageable. Otherwise, at scale, the company is not going to operate well. Now, that’s the purely technical side. At the same time, there’s core analytics that’s needed, and it’s overlapping between whatever it is your business is doing.
So, I’m currently a co-founder of a two-way SMS messaging company, and from our core functionality perspective. We need to know how many messages we are sending out, how many campaigns and broadcasts we are sending out, how many conversations were in the business of fostering conversations, and how many conversations we are sending out. Is it costing us more progressively to do core operations of our platform than it cost us a year ago? That’s ultimately what we’re looking at.
So, core elements of the business, core KPIs of the business are overlapping between technology and product.
Engineer-driven or product-driven?
Ryan: Yeah, that’s, that’s great. These two sets of analytics have to be explored oftentimes by different teams, especially in the enterprise, but sometimes, in the case of a startup, one person has to be able to look at them through both lenses. And it brings up a related question for me, and I’m going to ask your opinion.
This is an opinion question. Do you think it’s more powerful to have engineering-driven product development versus business-driven product development? Are you leaning one way or another? Do you think that there are benefits of either or both?
Sergey: Again, a very good question. And it doesn’t have a single answer because it really depends on the type of business that you’re doing.
So, if you’re in a consumer-centric business, then use the consumer-centric approach, which is “We’re a technology company, we’re business-led” – this is probably more aligned with the business model.
However, if you’re a PaaS (platform-as-a-service) or infrastructure-as-a-service business, and you’re by nature designing for things to be built on top of your platform, then you might be more technology-centric.
In other words, technology first, and then business second. It just really depends on who you’re targeting. If your target audience is technical, then that might be a technology-led company. And if you’re a lot more consumer-centric – and consumer meaning B2C or B2B, it doesn’t really matter, then you might be a lot more product-led company, as opposed to a technology-led company.
Embracing growth as the CTO
Ryan: That’s a great answer. And I haven’t heard it put so well, so concisely before. So I really appreciate that. My last question. It comes back to rounding all of this up.
Let’s say you’ve invested a lot of time and effort into being the startup CTO, and you’ve actually been successful at the growth, and you’ve really seen the kind of metrics hitting that you want to hit. You’ve seen the audience growth. You really understand the product and where it’s going. And then it exits into a sale to another company, or you just blow up and really take off.
What are the differences that you’re going to be looking at facing in terms of moving with the company? And do you think that transition can be done very consistently and effectively?
Sergey: I’ve seen it done successfully. I certainly have.
But even just realizing that there’s no foregone conclusion, you could still remain a technical co-founder and just hire an operational CTO when you go into a larger company, and that’s perfectly fine. Just understanding who you are, where you are most comfortable, and really where you want to go.
People are not born great leaders, and they’re not born into specific positions. You can get better. Again, we give a lot of credence to “Well, he’s a natural speaker” or “He’s a natural CTO,” if there’s such a thing, but I believe you basically will get great at what you practice.
Taking charge of your own career
So it’s certainly possible. You just need to understand if this is what you want. And once you get there and you get what you wanted, you still need to check yourself, whether this is everything you dreamed it was going to be, and whether it’s okay to take what some would perceive as a step back and just remain purely technical, or just move into a purely managerial position.
That’s perfectly fine. People can change careers from the perspective of others, but it’s really your career. So you should take an active role in managing it and just not let the current carry you. You’re just going to end up where you’re going to end up.
Ryan: Wow. Amazing. This is a really invaluable conversation and one that I think is unique in some of the interviews I’ve done where we’re able to talk about this crossover between all these different pieces. I really appreciate you taking the time and offering your thoughts and expertise in this area.
Sergey: Of course, Ryan, it was. Thank you so much for your thoughtful questions. This was an absolute pleasure.
Part 2. Top leadership tips
Ryan: Welcome back, everyone. Again, we’re here with Sergei Sundukovskiy. It’s great to have you. We appreciated all of your amazing insights throughout your career and thinking about the way that all of these different things blend together. But now I want to hear about some top five tips that you have about being a tech leader, and it really can range across all of those different areas, but summarizing this would be great to hear your thoughts. So, let’s start with your first tip.
Tip 1: Understand your leadership style
Sergey: All right. Well, my first tip is you need to understand your leadership style.
And again, there is no “good” or “bad.” You just need to understand how you lead. If I’m going to put a Ph.D. answer on different leadership styles aside, we could simply define it as a “Follow me” leadership style, which is there’s a hill we need to run up that hill, and if we need to die on that hill, we’re going to do it.
So that’s the that’s the “Follow me” style. And then there is also “Charge ahead” style. And again, the “Charge ahead” style is not better or worse. It’s just different, which is painting, having a North star, having a plan, directing your team to charge ahead and having their back, and just knowing that mistakes are going to happen, but you need to be the face of the technology team to the leadership team and give them confidence. And if things don’t go right, you’re the one who is going to take the arrows. Tip number one is “Understanding your leadership style and following it.”
Ryan: Phenomenal tip. That’s really good. And it makes me think of my own leadership style and even how that’s evolved over the course of time.
Tip 2: Outcome matters more than how you get there
Ryan: So yeah, that’s a great one. What about tip number two? What do you have?
Sergey: Outcome matters more than the way you’re going to get there. If you’re outcome-driven, then some of the discussion about the how might not be as important, right? So one of the tips or one of the guiding principles we have within the company is “10 shades of gray, it’s going to work either way.”
If that’s the case, if it’s going to work either way, let’s just not spend time on the discussion and just argue. Are you in “10 shades of gray” if we’re going to get there? So that’s fine. As long as you believe that you’re going to get there, you don’t need to get your way on the how, right? Just leave that to the people who are actually doing the execution.
Ryan: Is there anything that you feel like you really have to go to the battlefield on, though? Like, are there certain things that you are going to have to try and get your way?
Only in the choices where you feel if you don’t do it that way, things are not going to work.
In this day and age, there are very few things of that nature. In the past, some of the technology choices would sink the company. But in this day and age, there are many ways of getting there and many ways to skin that cat.
Ryan: That’s a great nuance.
Tip 3: Document the guiding & operating principles
Ryan: Yeah. Thank you. How about tip number three? What do you have?
Sergey: Make sure that you have documented – either just for yourself or for the entire company – the guiding and operating principles. The behavior needs to be codified, right? Some behavior there is just clearly wrong, but other types of behavior are really “gray.” Unless you define that – that has to be part of your culture – unless you clearly define it and people do know where the red lines are (and you know where the red lines are), then you can always check yourself against those red lines and make sure that you’re not stepping over them.
So, just make sure that you have documented guiding and operating principles for your behavior and for the behavior of your team.
Ryan: What is your suggestion on how to get teams to engage with that in the most complete way?
Sergey: Well, the best way of doing it is not coming up with these principles all by yourself and declaring them. It needs to be collaborative, right? So, the entire team needs to understand it first of all.
This is expectation number two: if you’re not participating in defining those, then you’re just going to be held to account on these rules, no matter what. So you want to engage, you want to bring your whole self to work and just define the culture and define the behavior that’s going to be acceptable within the team and what is not. Otherwise, you know, anything gets defined, and it’s going to be what you will have to accept.
Tip 4: Separate commitment from involvement
Ryan: Great. Yeah, that’s awesome. All right. How about tip number four? What do you have?
Sergey: Tip number four. Make sure that there’s going to be lots of activities – this happens, especially in the growing company – where you’re going to get involved and other activities that you’re going to get committed to.
Commitment basically means you’re the one that’s gonna drive the decision, and you’re going to be responsible for the outcome and other things you’re going to be simply involved in because you have to be.
Now, keep in mind your role and make sure that you don’t confuse the two, right?
So if you’re involved, then you’re basic, you’re helping, right? You’re helping to row in the same direction. But if you’re committed to something, you’re the coxswain, right? You’re sitting in the boat and directing the boat where it needs to be. And just don’t confuse your role. You’re either rowing, or you’re a coxswain. Don’t be both.
Ryan: And it’s so easy sometimes to get caught in that back-and-forth. So it’s a really great tip to have a check-in with yourself as to whether you’re rowing or being rowed.
Tip 5: Declare yourself in all situations
Sergey: That’s exactly how I would define it, and the tip – the last, but certainly not least – is a principle of declaring yourself in all situations. What that means is, quite often, especially in startups, it’s not clear how you are acting.
Are you acting as an individual contributor? As an architect? Are you acting as a manager? As a CTO? So again, if I’m coming in and I’m still being an individual contributor, I need to say, “My opinion is just, just as your opinion, it’s because I’m a peer developer,” right? Quite often, people don’t declare themselves, so the team looks at the CTO and tries to align behind what the CTO is gonna say.
But if you’re in the architecture meeting and you’re participating as an architect, well, act as an architect. Don’t act as a CTO if you are a developer. Make sure that you act as a developer, and you don’t act as a CTO. Right?
So, speaking from authority and alluding to authority in inappropriate situations could very easily escalate.
It’s not easy, but even if you don’t say it out loud, say to yourself, “Who am I acting as?”. If acting as a developer, well, just exhibit developer behavior.
Ryan: Wow. What a great final tip. It is an interesting spot where you can easily get caught in that mix-up.We really appreciate your great tips today and all of the great insight you’ve provided across the whole podcast.
It’s been wonderful to have you here, and we wish you the best on your journey with your current startup.
Sergey: Ryan. Thank you so much. And I’m gonna take those wishes to heart. Thank you.
Ryan: All right. Thanks.