Episode Summary
Rachel Stephens has worked as an analyst at RedMonk, a firm focused on software developers, for the last four years. Prior to that, she held several other analyst positions for companies like Western Union, Dish Network, Frontier Airlines, and LaSalle Investment Management. She’s also volunteered as a grant writer and mentor for Minds Matter, a nonprofit that helps students from low-income families.
Join Corey and Rachel as they discuss what an analyst firm actually is, how RedMonk helps companies understand the link between developer preferences and business strategy, the disconnect between financial and engineering departments and how to bridge the gap, how finance has become more interested in the way IT costs come together, why engineers don’t like being referred to as IT people, why finance isn’t always keen on digital transformation initiatives, how engineers aren’t always interested in making money or generating revenue, Rachel’s number one recommendation for effective financial controls in engineering, and more.
Episode Show Notes & Transcript
About Rachel Stephens
Rachel Stephens is an industry analyst with RedMonk, the developer focused industry analyst firm, covering a broad range of developer and infrastructure products. At RedMonk she has worked with vendors such as Amazon, Google, IBM and Microsoft.
Rachel Stephens is an industry analyst with RedMonk, the developer focused industry analyst firm, covering a broad range of developer and infrastructure products. At RedMonk she has worked with vendors such as Amazon, Google, IBM and Microsoft.
Rachel arrived at RedMonk with a background in finance, including an MBA with a Business Intelligence specialization, along with broad exposure to a variety of enterprise database systems. Her analysis and work leverages a variety of programming and statistical modeling languages including Python and R. At RedMonk she has covered everything from Infrastructure-as-a-Service pricing patterns and trends to explorations of serverless definitions and usage.
In her free time, Rachel enjoys skiing and spending time in the mountains of Colorado, where she lives with her family.
Links Referenced
Links Referenced
- Twitter: @rstephensme
- LinkedIn: https://www.linkedin.com/in/rachelstephens/
- Company site: redmonk.com/rstephens
Transcript
Announcer: Hello and welcome to Screaming in the Cloud, with your host, Cloud Economist, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: And this episode is sponsored by InfluxData. Influx is most well known for InfluxDB, which is a time series database that you use. If you need a time series database, think Amazon Timestream except actually available for sale and has paying customers. To check out what they're doing both with their SaaS offering as well as their on-premise offerings that you can use yourself because they're open source, visit influxdata.com. My thanks to them for sponsoring this ridiculous podcast.
Welcome to screaming in the cloud. I'm Corey Quinn. I'm joined this week by Rachel Stevens, who's an industry analyst with everyone's favorite analysis firm RedMonk. Rachel, welcome to the show.
Rachel: Thanks for having me.
Corey: So let's start at the very beginning because six months ago I had no answer to this question that wasn't actively insulting. What is an analyst firm and what did they do?
Rachel: This is a great question and I've been doing this for three years and I'm still not sure I have the correct answer, but I can tell you what RedMonk does. How about that?
Corey: Perfect.
Rachel: So RedMonk, I would say we help technology companies understand how developer preferences can impact their business strategy. So sometimes it's working with them on things that are technical. A lot of the times it's working with companies on things that are decidedly not technical. So it will be things like marketing and messaging and developer personas and things like that. So it can take on a lot of different flavors depending on what the company is looking for and what help they need. But generally it's just trying to help people understand how developers drive their business.
Corey: The strangest thing that I find whenever I'm in analyst rooms or attending analyst summits at various events is people look at me and say, "Oh Corey, good to see you. Glad you're here." And my response is, "I think I'm in the wrong room. I don't think I'm an analyst." And the response is always, "Well what do you do?" It's like, well I have no idea of what I do exactly. You are an analyst is the usual punchline there. But I talk to companies that are building things. I talk to their customers that are building things and everyone smiles and nods and then where I deviate is, and then I take the service that they built, they released and I build something with it myself. And everyone stares at me for the longest time because that apparently is the one step too far where most analyst firms break off.
So it feels like everyone has their own pocket definition of analysis of being an analyst. There's a bunch of snark and sarcasm in the rest that I could hurl at you, but I won't because you know, insulting people's professions on the air, generally a bad look.
Rachel: Oh, no worries.
Corey: In the wide world of analysis, what is your specific area of expertise?
Rachel: So I come to the technology field with a fairly atypical background because I actually started my career in finance. So I started out running people's budgets and crunching numbers and typical bean counting kind of things that most developers do not resonate. It doesn't resonate with developers really at all. When I'd kind of talk about my background and then I was a DBA, which is usually like a developer enemy. So that's always fun. So usually I try to steer clear of talking about how I came into the analysis field when I'm with a developer audience because usually they don't really care about anything that I've done in my past. But I have found that it can be really helpful to have both of those backgrounds around how a company makes money and what a company does with the data. Like developers may not think they care about that, but they actually do.
Corey: It's strange. I mean, I started my company of fixing AWS bills three years ago and at the very early days I assumed, "Oh, it's an engineering problem." Turns out it's not. Engineers don't care about the bill. It's a distraction from what they got into their jobs generally to do, which is usually feature releases, building exciting things, not cool. We built this awesome thing. Now let's make it cost a lot less money as as a primary function and in my experience it seems that finance and engineering are wonderful at talking past one another. How do you find that relationship between the two groups generally tends to play out?
Rachel: I think you are 100% correct. I think they are departments that have historically not been aligned very well. I think that's changing a little bit. I think especially as the role of technology evolves and more and more businesses are seeking this, like ever elusive digital transformation. It's changing the nature of what an IT shop is actually in charge of. Because IT is no longer just a cost center. It's starting to be this like driver of value and that was maybe how engineer's always saw what they were doing. But I think that that value is now being recognized more widely across all of the departments of an organization, the realization that you really need to have a strong technology shop to figure out how you're going to compete in evolving markets.
And so I think that has changed and maybe leveled the relationship a little bit more where I think that IT has maybe more of a seat at the table than they have had in the past. And I think finances started to become more involved in how to actually have IT costs come together.
Corey: While we're talking about the joy that is the... I guess this hearkens back to Gartner's model of Bimodal IT, which has been pretty soundly debunked on a variety of different levels. But something I noticed in talking to different companies and how they structure things is that some companies view it as corporate IT. When you say IT, people hear, oh, the mouse monitor and printer people and other groups think of themselves as engineering, the things that are directly aligned with the various line of business application. I guess the most straight forward example be a SaaS company where what those engineers are building is directly aligned with the thing the company does in order to make money. The strange part is that the way that those two groups even at the same company are treated in my experience and how they're perceived are worlds apart. Does that map into any of the stuff that you're seeing in your part of the industry?
Rachel: I think definitely. I think an engineer's reluctance to be called like an IT person it's often and frequently something that the IT moniker is not something that they have adopted for themselves. It's usually more related to their title or their role or the technologies they work with. And very much they don't want... they're happy to be the person who can fix your printer when you go to visit your grandma at Thanksgiving. But they don't really want to be the person who is seen as somebody who just can fix your tickets. You don't want to be somebody who's help desk.
I just think that one of the things that makes that tricky in terms of that way that most of the organization interacts with the engineering group is that most of the interactions cross departmentally are going to be people who are filing those help desk tickets for things like, "Oh no, I can't log in, I forgot my password." So it feels like maybe some of the deeper work that is maybe more of that value add is more opaque to the people in the finance departments.
Corey: My customers tend to buy us for being SaaS companies and they also tend to largely be the board in the cloud type of companies. That said, that's certainly not all of them. And the strangest part that I've seen as I look at companies that are undergoing a, please pardon the term 'digital transformation' is getting the rest of the business on board with what that transformation tends to look like. I gave a talk about this somewhat recently at the DevOps Enterprise Summit. Where when you have a data center too that you build out to serve an entire environment. Once you've spent an enormous pile of money on building out that data center, you can amortize out what the cost of that is going to be to service your workloads for the next three years almost to the penny.
Whereas when you're paying only for consumption and as you become more and more cloud native, whatever that buzzword means to you, and you get into a serverless style of world, every time I mentioned the word serverless, I get a dollar. Then you wind up having what... what it costs to provide your service is a function of number of users that you have. And the numbers are always way less when done properly, but it's also increasingly challenging to accurately predict and that's not inherently a problem. What is the problem is how that has been communicated back to finance teams, the, I guess, partnership between finance and the engineering side of the house fundamentally has to shift. How are you seeing that play out?
Rachel: Well, I come from a finance world and so I've seen head's role in the finance department when the groups that they are in charge of budgeting missed their budget by a significant amount. Like it's a fireable offense for finance people in certain shops anyways. And so the motivations for people in the finance world can not always be aligned with this whole digital transformation goal because one of the things that they like is that stability and the predictability and the ability to budget and forecast things.
Those are core parts of what these people are tasked with doing as their careers and part of what they are measured on. And so the shift to making their job inherently harder and more opaque and less predictable can sometimes be a hard partnership to communicate about why it is that you are moving to kind of pay as you go pricing versus something that was more known and more understood before.
Corey: The hardest part I see is not that finance can't wrap their heads around this. I mean for God's sake, the entire purpose of finance is to understand the interplay of money, but rather in to be very direct engineering's lack of ability to articulate what is changing in a way that finance can understand.
Rachel: Yeah, so if you think about... Okay I'm going to throw some finance words at people and it won't get scary, I promise I'll explain as we go.
Corey: Let's hit them with that.
Rachel: All right, so if you think about five to 10 years ago, our hardware was mostly capitalized in a data center and that means that we would account for it on our balance sheet and then just pull over pieces of it every month. So we kind of just say, "All right, we're going to pay a whole bunch up front and then we're just going to count little pieces of that towards our profit or towards our costs every month." Software was licensed, same general thing where we would take the entire cost of that license fee upfront and then we would break it out into chunks and so we could really understand what our monthly approach would look like in terms of there was just more known quantities as we would accrue like that.
And to a person who has made their career on understanding the exchange of money. Like those are things that are... accruals and amortization are concepts that they've learned to ever since they were in school. Trying to understand how to price in API gateway and trying to figure out the number of API calls an app is going to make and try to do predictions about that. It's a little bit farther outside of the wheelhouse that they may have been trained in. It's not to say that they can't figure it out, it's just to say that the drivers and the cost drivers are changing and as they change, there needs to be that increase of partnership to help your business partners understand what are your actual variables that are driving usage and helping them understand how to come up with a way to think about how to actually predict and forecast things out.
Corey: Part of the challenge I think is that back when I started my company around, "Oh, I'll fix the AWS bill." That was an expensive problem that my boss would always come screaming into the office on some random date. It's was suspiciously close to the beginning of the month, freaking out about it and fix it, fix it, fix it, fix it, fix it. And I did that as a distraction from what I was normally doing because well my boss told me to, I assumed I knew what was going on. It turns out I didn't. What really happened in those scenarios was my boss was suddenly talked to by her boss and intern he was talked to by his boss.
And you trace it back to the organization and eventually it goes back to someone in finance who has zero context on what engineering is doing. They see a big Amazon bill and their first question is, "Well that sounds like a lot of boxes showing up the office that I haven't seen lately. What's the story? They having them shipped to their houses." The concern is not even from finance. Wow! We overspent over spending too much money. It's okay. It was 20% higher last month, is this the new normal? Is this going to change our projections? Is this just an aberration? Is it a mistake? Tell me the story here.
But playing the game of corporate telephone, by the time it landed on my desk, it was a, "You're spending too much fixed the bill," and it was a very different message that was received than what was transmitted partially because on the engineering side, individual contributors don't think about this, but also because I was never given context to understand the actual problem that the business was facing, which was not spend. It was predictability.
Rachel: Mm-hmm (affirmative). I agree. And I think you also touch on a great one, which is there's just so much more seasonality and variability in a pay as you go pricing model. And so a finance team trying to look at things like they care about things like year over year numbers or month over month numbers. And so trying to understand how those drivers are changing and what's impacting their costs, because they're going to have to sit down and write a variance explanation that's going to go up to the CFO. And so they're just looking for some context on what's happening here. Because all of a sudden I have to explain this huge cost increase to somebody who cares about it and I have no idea what's happening. And if somewhere in that game of telephone, like you said, it comes not so much about understanding why but the message gets morphed.
Corey: Well one of the questions I have too is, is this purely a problem for executives and managers or is this something that individual contributors need to weigh in on? I keep going back and forth on that one from the engineering side, but I don't have the experience of working in a finance department to be able to articulate anything sensible reasonably. You do. Where do you land?
Rachel: I feel like I also am not sure I have the answer there. One of the stories that I loved was from a customer who shall not be named, but they were doing a road show around all of their offices and the C-suite was kind of giving strategy day presentations to the entire company and getting everybody on board with what they were doing next. And then they took Q&A and one of the senior engineers in the front who is absolutely brilliant at building the product raises their hand and goes, "But why do we need to make money?" It's like I heard this story and my finance heart just kind of shriveled a little bit. I was like, "What do you mean? How can you be so smart and not understand that that is like a core part of the business."
But from the perspective of an engineer and you've worked in primarily growth based startups that are venture backed and all you have cared about is getting product out the door and you haven't ever had to care about business model and you really haven't ever had to worry about any of that product market fit or profit, any of those things... then yeah it can be like when you start to present these strategies of like, "Oh like why do we care about revenue?"
It can be a fair question, but it also in my experience then means probably most individual contributor engineers don't need to worry about this. That's kind of what this story tells me. You should probably have a basic understanding of what your company's business model is. Probably you don't need to get super in the weeds on the finance teams, and I think it gets more important the higher up the chain you guess. To me, I kind of view it as a manager and above collaboration area, but I'd love to hear what you think.
Corey: First. I absolutely want to say that that resonates. When I was an engineer, I hated, hated doing anything that looked like cost savings. I think that it wound up coming down to an unfortunate reminder that I was somebody's cost center and working in startups with ping pong tables, which, oh my God, are those the most useless pieces of crap in an open plan office? Why are there a ball under my desk when I'm trying to work? I digress. Tick, tick, tick, tick. But it's not consistent. It just, it drives me up a freaking wall. I don't do open plan offices right out. If you disagree with that, please feel free to go on Twitter and keep your freaking opinions to yourself. But the problem that I had was it was an unfortunate reminder that I had to generate more value than I cost.
And the fact that I wasn't able to work on a project like that while remaining comfortably removed from the fact that I'm super expensive. So ideally the thing I'm doing should be throwing off more money than that was... It was a nice affordance to live in a fantasy land and being removed from that and reminded that, "Oh yeah, there is a P&L involved here," and if you eventually cost more than the value that you deliver, you're not going to be here anymore. It was unfortunate.
The second concern that I see very often when talking with other engineers who have worked on projects like this, they talk about how they decided to spend a couple of weeks fixing the AWS bill and there are two ways that story plays out. One of them was that they wound up playing around it. Oh yeah. They'd knocked out 200 bucks a month off their bill and only two short weeks and they get dinged on their annual review for it because yeah, there was better uses of their time.
Okay. I talked to someone else, similar story and they found 10 million bucks and they were dinged on their review because there was a better use of their time. They should have been working on a different feature. And the fun thing from my perspective is that I am not convinced that those aren't the same story because I was talking to those engineers in a vacuum. Now saving 10 million bucks a year. Maybe that's valuable, maybe it's not, but it does come down to what else would you have done instead, what feature could have shipped sooner because there is a theoretical upside of how much money can I save off of someone's cloud bill of 100% of their cloud bill.
When you're talking about speeding time to market or releasing the right feature at the right time to the right folks, you could double or triple revenue, so cost savings and cost optimization is always going to take a back seat to accelerating what a company is working on from a strategic point of view. The problem I've seen is that I don't see too many people telling these stories in venues where engineers listen.
Rachel: Yeah. And I think that also just it speaks to the way that people run their performance reviews. And if you do want cost optimization, if you want those $10 million savings, which are great, you actually have to reward them. So like I think it depends on like obviously you don't want to spend two weeks of engineering time saving $200 that's suboptimal. You'd love to find the multimillion dollars of savings. That would be great. But you also do need to balance that out with what could I be building at that time. And I feel like performance reviews in particular are not always nuanced enough to capture that. And people are like, if cost savings is something you care about, it has to be something you reward. And the way you reward it is what you incentivize performance review time.
Corey: Oh, most companies seem to do a terrible job performance reviews. And now that I wind up managing people myself over here, I'm starting to understand why. These things are nuanced. There's no manual for doing it. And it's incredibly easy to say something offhand that is interpreted in a way that you didn't intend. So it's... again, from an engineering point of view too, I had a very different relationship with money than I do now that I run a business. The reason behind that is I was making decent money. Sure, don't get me wrong. And I had root access to everything in production and I could with the wrong command take down the entire thing. Remember that business we used to have, whoops, a doozy, but I needed approval from my boss to buy a $50 book that would make my life better.
So in the context of having to worry about costs like that, it seems perfectly natural that, "Oh, my development environments costing 600 bucks a month, I should really spend the time to save that $200." It doesn't actually matter to the business. It's just process and lack of context shining through. I mean, I talk about engineers making poor decisions and doing dumb things in a lot of my talks and stories. The part that I don't say is that over 80% of the time the idiot moron engineer was me. I have my own favorite punching bag when it comes to these things because I didn't see it back then and now that I do see it I think, "Oh, how could I have been so silly and naive," but I wasn't, I just didn't have context. So from that point of view, what should engineers know in order to partner effectively with finance?
Rachel: I think one of the things that's really tricky about partnering with finances, the finance team, often if, especially if you're a public company, there's going to be an inherent lack of transparency because there's a tendency to kind of hold financial results close to the chest because the more people that have them, the riskier it is that there will be a disclosure of non public information. I can make it really hard to actually share that context. And I don't know, at least nowhere that I've ever worked has I ever figured that balance out correctly. But I think it can be useful to start expressing that desire of like, "I'd really love to understand what is my group," the number of people who don't understand what their group's budget is for the year, who have no idea where they kind of sit to see year to date results of how the company overall is doing.
I think all of those things can be shared safely to some degree in a lot of cases, but it's not something that I think most businesses are inherently good or willing to do. You kind of have to ask for that collaboration. But I think that that context in terms of the numbers can be helpful. I think one of the things... so I think that's something finance should know to kind of help how to partner with engineers and give context more effectively. I think one of the things that engineers should know is just understanding those constraints that are hitting their finance team.
I guess just everyone should know. Finance should understand the importance of developer velocity and trying to understand like, oh is your team doing sprints? Do you have to understand what people are trying to build and try to understand how projects are flowing in and out just to have a general sense of what is being built and how that would be great if finance had any sense of that and any sense of importance over why the developers are trying to go quickly.
I think engineering on the other hand should understand the pressure of trying to create a public facing budget in particular. So if you have to give guidance to the street on what you're predicting for the next year, if I'm giving 2020 guidance, I probably as a company started that process the August of the year before, trying to put those numbers together and roll up everybody's individual budgets and going back and forth with all of the groups. It's a process. And so I realize it's fully ridiculous to say that you can have any sense of what's going to be happening 18 months away. Your finance team recognizes that as well, which is why it's always a fun exercise, but it's just one of those nature of the beast things that I think nobody really understands the pressures that are driving the other group.
Corey: I frequently said that multi-cloud is a stupid best practice and I stand by that. However, if your customers are in multiple clouds and you're a platform, you probably want to be where your customers are unless you enjoy turning down money. An example of that is InfluxData. InfluxData are the manufacturers of InfluxDB. A time series database that you'll use if you need a time series database, check them out at influxdb.com.
It always astonishes me when by default, this is how it's set up. Even in AWS accounts. Where I can go in and I can spin up $50,000 a month of resources with zero approvals, zero oversight, it's an API call away or let's face it. I'm terrible in many ways. I'll do it in the console. I click a button. So that's done. It's up and running, but I'm not allowed to see what the bill is. And in the console for those who do not spend their lives there, or even in the API, there is no price tag next to everything. Click this button, it'll cost you X money.
So you are incredibly far removed. So as a result, every time I hear about something I've done having financial impact, it's always A, a trailing function and B after the fact so that I'm yelled at for this thing that didn't wind up that was not surfaced or visible to me. It's ideally there's an alert or an alarm that goes off a day or two later. In practice, it's once the next month bill comes in and then someone kicks the door off the hinges.
Rachel: Yeah, I think that's something that the clouds in general struggle with. And it seems to me that both the individual developer and engineer doesn't have a great sense of what things cost and the finance team is struggling with that too. Like the lack of visibility into what is running based strictly off the tools that the cloud providers give. It's really a lot of people flying fairly blind in terms of trying to figure out what their primary cost drivers are and what's creating problems. And so I think, I would say that both groups struggle with that.
Corey: The hard part for me is how did this get fixed? I mean we talk about... Usually you wind up seeing policies and procedures in organizations that feel like scar tissue from that one time a bad thing happened in advance and now whenever that specific bad thing happened again. So you talk to large companies and well back in our data center days, it took six weeks to get a server provisioned and now that we're in the cloud, it only takes four weeks to get that same server provision. And the challenge you run into there is you're actively incentivizing terrible behavior. Shadow IT is a corporate credit card away before someone can spin something up and get working on it right now. You also will find that if you have a human being in line, that as a provisioning delay, people will bug that person every 10 minutes until they get their resources spun up, but they'll forget to turn things off.
And why would they turn things off when the alternative is to have to go back to that incredible process? Good Lord, last time it took me six weeks to do this again, I might need it again. And they just add it to the collection. Sometimes they'll run something in a loop. I've seen this where it boosts utilization metrics higher than you would expect just so when people do a quick scan, it doesn't look like those systems are sitting there idle and that's messed up. The problem is that as you build out controls, they seem to become gates rather than anything that resembles a guardrail that makes things better.
My firm belief, as I've said, a number of talks now has been that when you build guardrails, they have to be easier to do things the right way than the wrong way because otherwise you're never going to get people on board. Governance inherently has to be a trailing function in this sense, in this to some extent, and you have to accept that there's going to be a fudge factor to budgets. This is often difficult for people to hear when they come from a very hierarchical, regulated command and control style environment. But it's what I keep seeing again and again in the market. Does that map to what you're saying?
Rachel: Absolutely. I feel like you articulated that very nicely, but I think that's one of the things that needs to be communicated to the finance teams is that importance of self service and automation in processes and as a path for developers to do things the correct way and to go through all of the controls that you want to set up, you have to make sure that that self service component stays in place. I think that would be for me, the number one recommendation for making sure that your financial controls are actually effective and people don't just go around them.
Corey: And in some cases you have the luxury of, "Oh, if you wind up exceeding budgets in too far of a... in one direction or another, you'll wind up getting centered or fired, in the federal government, you exceed the budget in the wrong direction you're going to prison." So it's nice to be able to have that level of stick, but I think it's the wrong approach. I think it comes down to understanding what people should be spending on. Very often in my client engagements, it turns into less a story of, "Okay, you should do this, this, and this to save all the money." Very often it's, "Yeah, do those things, but then over here spend more," because previous cost-cutting attempts have durability to the point where, yeah, good work. You're saving a lot of money. You also have no backups. Maybe that's not the right answer.
Now for some data, that's perfectly fine. If you can reconstruct it, no problem. If it's you don't have a company anymore, if that data goes away, it's a different story. It all comes down to context and I still maintain that there's no API for any of this. There's no replacing RedMonk and there's no replacing what I do with software. Sure. Software can help an awful lot of this. But having a discussion with people and being able to understand localized context is critically important.
Rachel: I agree completely. I think there are processes that will help everyone. So like really good tagging and labeling. And that's not something you could necessarily automate but you can kind of build processes around how to do things, but eventually everything's going to come down to some level of human judgment. So I think the goal is to automate what you can and then to have reasonable policies in place to kind of guide decisions the rest of the way. And hopefully that that leads to some policies that make sense for everyone.
I think as much as possible, you want things to be open on the front side, so kind of guardrails rather than gate keeping and try to flag things via templates or solutions that people can have on the front side. Rather than coming at them on the back end after you've overshot. So I think there are some general principles, but really it's going to vary a lot based off of the organization. It'll vary based off of your capital structure. It'll vary based off of the policies you have in place, the size of your teams, how dispersed you are geographically. There's a lot of factors that can come in. So there's really just no clean cut way to put all of this together.
Corey: And there is no easy, straightforward answer. I mean, I'm somewhat disheartened by all of the SaaS companies that are springing up around, "Oh, optimize your AWS bill, save money." But that's not the real business pain. It's not something that people are focusing on as the business objective. Of the successful companies are in fact not even emphasizing the save money. They're emphasizing the story around visibility, around transparency, around being able to know that what you're spending is correct or at least allocate that to various business units. But it's step one. Step two requires conversations. It requires partnerships between engineering and finance. It requires executive stake holding and investment in understanding this brave new world we found ourselves in.
Rachel: Yeah. So question for you. When you work with organizations on their AWS bill, what part of the organization are you usually interacting with?
Corey: Great question. The short answer is yes, it usually starts at an engineering side or I'm inflicted upon someone by finance, but every time someone reaches out with our bill is too high, the question always becomes great, why? Why do you care about the bill? And very often the answer is, "My boss does," great, let's talk to your boss or, "Oh, someone over in finances yelling at us," or "I'm in finance and I don't understand how many books they're buying with that Amazon bill," or they say, "They're optimized and they swear up and down."
When the bill kept climbing and I put a restriction in place, suddenly they cut the bill in half overnight. So what do I do? Do I just set arbitrary targets? Where do we wind up collaborating? So it really is a mixed bag. Historically, it is someone who on some level has P&L responsibility for a division where the bill impacts the performance of their business group and they want to understand it if not correct it.
Rachel: Got you. Fascinating.
Corey: Yeah. I embedded the name titles just because sometimes the smaller companies that C levels, other times it's a VP where that's an important title. Other times a VP means you've been out of college for two years, here you go. Welcome to Bank of America. So there's a very different... like titles are zany across the entire spectrum of things.
Rachel: Mm-hmm (affirmative) Fair enough. No, I think that's a good descriptor. So thank you. It's always nice to hear how people are approaching things. Have you seen any patterns or anti-patterns and how finance and engineering departments have interacted?
Corey: Oh, absolutely. Screaming or we're going to allow they fire someone as an example to the rest is always a strange one. Very often though... one of the things that drives me nuts is I will see the exact same problem being solved the same way in different companies. But no one talks about it publicly. So you're solving these global problems that are not in any way shape or form even remotely resembling competitive advantage, but no one talks about it because if you talk about your bill or how your budgeting works, "Oh, that's destructive and could lead to the downfall of everything we know."
The other big anti-pattern that I see surprisingly is from finance where they'll sit down with me and one of the first questions they'll ask is, "Okay, so it costs us X dollars per monthly active user to service them. How does that benchmark across the world?" And I understand why they ask that question, but it is completely meaningless because if your customer is, let's say a user on Twitter for pets, it's going to cost you next to nothing per active user. It turns out Twitter for pets has no users because dogs don't tweet nearly as much as I thought. So the cost is surprisingly high.
Counterpoint. If you are dealing with B2B and each of your customers is a fortune 500, it could cost you millions of dollars for each monthly active user to service them. There's just no way to... It just depends. Even in the same sector, you still wind up with very different application architectures and controls. So there is no real benchmark, but I'm getting tired of telling people that. So my default position now as a thought leader is that the MAU benchmark is 32 cents. Now everyone can hate me in ops because that is completely unrealistic for almost everyone go with it anyway because I said so on a podcast.
Rachel: Oh good base. I think what that reminded me of is I feel like one of the things that we don't often talk about publicly that is true at every company I've ever worked with in terms of big enterprise organizations is that groups might not have the same understanding or business glossaries for terms. So like does your finance group have the same understanding of the user as your engineering group? Because oftentimes engineers will maybe think about roles a little bit differently. So like a user has someone who has root access and can edit things and they are in the software all the time versus like a VP who is viewing the dashboard from his iPad.
The manager who is trying to go through like the high level dashboards for her team, things like that. So I think that's another one that is tricky. So one of the places I've worked in the past didn't have a unified definition of what a transaction was and there's a whole story behind it. This could be its whole own podcast, but I think that's one that is another area that is a struggle that nobody ever talks about and it's not really one that you can globalize because everyone is going to have a unique struggle, unique to their business. But I do think that it's a problem for teams to just be on basically the same page, let alone doing this deep collaboration.
Corey: It all comes down to people problems. From my perspective, those are the only interesting ones because making a computer do the thing you want, it'll work. It won't work. Eventually you throw it out the window in a fit of rage, but you can't do that with people. Well, not more than once anyway, and I think that that's the interesting part where regardless of how often I see the same things in bills from company to company, the dynamics are always slightly different. The stories and why people care always varies slightly. I get bored working on computers all day. It's nice to be able to go out and talk to humans.
Rachel: Yeah, I feel like there's a lot of engineers who bristle at that a little bit. I'm like, "Oh, you try doing all of this impossibly difficult things that I am making the computer do and I freely admit that I cannot do those things." You do a lot of black magic with the computers engineers and we respect that, but I do think that, I agree. When it comes down to it, it's the people, it's what are your customers trying to do and how is your business trying to actually solve those problems for them? And then how are all of the people in your business interacting to actually solve those problems? That's where it comes down to.
Corey: I started my technology career more or less at in higher ed, running the network for a school. I have an eighth grade education, but dealing with PhDs and faculty with various networking issues was fascinating. Where it's like, I have a PhD, I am the world's leading expert in this very narrowly defined field and that is an incredibly hard field and I am incredibly gifted at this. Therefore, I'm very good at everything else too. And you see that pattern come up with engineers too, they don't even offer a PhD in networking? Well, back then they did. It was called Cisco CCIE Certification, but I digress. It wasn't at all accurate, but we see people who write code for living very often diminishing folks who do not code.
But I think the list of problems that people can solve by writing code is a very small subset of the world we live in. There's so much more out there beyond that and finding ways to apply skills like writing code to other problems is the hard part and I think it's the right answer.
Rachel: Agreed. I think your next podcast needs to be, can technology save us?
Corey: That is a wonderful question. If people want to hear more about what you have to say, where can they find you?
Rachel: You can find me on Twitter at rstephensme, R-S-T-E-P-H-E-N-S-M-E.
Corey: Excellent. And we will throw a link to that in the show notes. Rachel Stevens analyst at RedMonk. Thank you so much for taking the time to join me.
Rachel: Corey Quinn, Analyst at Duckbill Group. Thank you so much for having me.
Corey: Please. I'm a Cloud Economist. At least no one knows what that is. I am Corey Quinn Cloud Economist at The Duckbill Group. This has been another episode of Screaming in the Cloud. If you've enjoyed it, please leave a five star review on Apple Podcasts. If you've hated it, please leave a five star review on Apple Podcasts.
This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.
Announcer: This has been a Humble Pod Production. Stay humble.
