What does it mean to play out your values to operationalize your culture? That's what we're talking about with today's guest, Ernie Miller. Ernie is the head of engineering at a company called Monograph. We talk a little bit more about what Monograph does. You might recognize Ernie's name because he's been on the show before and I've enjoyed having discussions over the years with Ernie here and there. Thanks so much for listening. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on the show is to help Jordan developers like you find clarity, perspective, and purpose in their careers. Let's get straight into the interview with Ernie Miller. Ernie, welcome back to Developer Tea. Hey, thanks Jonathan. It's good to be here. So I guess the last time we talked was a 2015 or 16, I can't remember what year Agent City Ruby was. That sounds about right? Yeah, somewhere in the neighborhood. Somewhere in the middle 2000 teams, right? That's right. It seems like a wildly different world and so many things have happened since then, but I'm mostly curious about, you know, what are you doing these days in your career, but also what are the things that you're thinking about the most as an engineer? Right. So first off, what am I doing? I'm about six weeks in as the head of engineering at a company called Monograph, which is a practice operations platform. If you're wondering what that is, that's a platform design to help architects and engineers oversee projects, you know, time sheets, forecast all in one sort of integrated and simple interface. So that's what it is when we talk about practice operations. And I'm leading a small but mighty engineering team at the moment and working with some really fantastic founders. So yeah, six weeks in, really loving it there. We have a four day work week, by the way, wink, wink, nudge, nudge, if anyone's looking for a great role. Wait, is advertising allowed on this? Never mind. Okay. Yeah, no, I think, you know, we can actually talk about the four day work. Some of the decisions around why is it that way? You know, I think a lot of people are probably looking at jobs right now. And I know you care a lot about that process about hiring and what it means to find a good culture. And, you know, it is fairly, I would say still fairly rare to find, for example, a four day work week, especially at an early stage startup, but one that is funded. I can imagine a, you know, founders saying, oh, yeah, we're going to work four days. Why not? You know, but to actually be hiring with that as a, as kind of a, a practice. I'm curious to talk about it, but I do want to back up and say, you know, as an engineer, and this is really specific to, to your product that you're working on, we have all of these kind of principles that are enabled by the fact that the product that we work on is iterable by nature, and architecture, I guess physical architecture is less so. Do you find that, do you find that like you're having to work on this kind of, I guess, such a different kind of mindset for the people using that kind of management software than what you would use in order to build it? I feel like that's an interesting juxtaposition. Do you find yourself kind of looking at that on a regular basis? Yeah, you know, I think that's a great question because what I benefit from is that we have about, I think about a quarter of our employees have some kind of connection to architecture or where architects themselves prior to joining. And so we have a lot of, like for instance, there's a, there's a Slack channel that just specifically is called resident architects and anyone who is an architect at the company can answer questions so we can better understand, get kind of insights into how the architecture world works. And I think that helps a lot sort of bridge those gaps. You're right though that when you're building with, say, brick and mortar, it's, it's a lot different than software, which is very malleable. But when it's architecture, the architecture side of the house, anyway, before you're actually constructing a project, it is still, you know, it's still very, you know, it's still very design focused. It's still a very creative iteration definitely occurs as folks are working with their, their customers, you know, and trying to figure out what it is that they want. And so in a lot of ways, there is a similar culture. And I think one of the interesting things too is that so many architects, they're really design-minded. They think in terms of usability, they think in terms of beauty and, and, and fitness for purpose and all the other types of things that we think about as software engineers. So while there are differences when it comes to the actual construction of the project, the way that I have had, and in the conversations that I've had since I joined anyway with architects, I've been surprised by how much overlap there is just culturally and in the ways that we think about things. Yeah, yeah, I, you know, I can imagine that the, those principles are, they can be so important to us as engineers and they're almost, it's easy to get religious about things or, or at least dogmatic, I guess, is, is more appropriate word about. And on the, what we would call the healthy side of dogmatism of, we really want to commit to being iterative as a practice. We really want to commit to learning and, and staying flexible and, you know, easily, not easily, but quickly changing when we need to. And I've always found that, you know, often if you're, if you're kind of telling somebody about this for the first time, I've actually heard building, you know, construction building as a point of reference for this is something that are, you know, we kind of have an intuitive mental model for design and build because it's inflexible, but software is different. It is malleable. It's hard to refactor brick and mortar, right? It's, it doesn't really, you know, you don't get to have a chance to do that. And that's, that's such an interesting opportunity though. You mentioned something that I think is important and can kind of generalize to a lot of cases. The idea that you have these architects in residence or, or, I think that's what you call it. Right. The resident architects channel. Yeah. Architects and residents is a great agreement. Yeah. And, and the idea being, you know, I can accept that I don't know a lot about this space, but I need to go and talk to somebody who does, has there been a moment where you learn something from one of those architects that you just had no idea that that was a part of, you know, the decision making process or, you know, that it could work that way. Have you learned anything like that that was counterintuitive to you? Oh gosh. Um, every day I'm learning, I'm learning something like that. One of the first things that I did when I, when I joined was ask for book recommendations because it's really important, you know, where if I'm working to build software that's going to be used by other engineers, like I had my last job, the software that I was building was being used by other technology firms. So I could think pretty, pretty clearly about what the user really expected. But when it came to building for architects, that's a very different. So one of the first books that got recommended to me by one of our co-founders was a book called Professional Practice. And it's a book written about the, really about the art of running an architecture firm. And some of the things that really surprised me, I think early on, I started quoting bits of the book as I was reading it in a channel called Engineering Reads. It's because I found like this is actually engineering relevant. So there's a couple of things that resonated really well with me, right? For instance, schedules and budgets are real and important to clients. Learning to meet them has quantifiable negative impact. If you think clients will forgive you for late over budget projects because the finished design is brilliant, think again. I mean, does that sound like something you might encounter in software engineering? Or databases? Yeah. Very much similar. And then, you know, on the flip side, or maybe less of a stressful sort of deadline oriented take away is it's rewarding to see people whom you like and care about enjoying the results of your work. It provides important feedback about spaces and relationships of spaces to each other and to the landscape about what works and what doesn't and about how your intentions became or didn't become reality. I mean, I found that this book is, it waxes quite poetic about the, the field, right? But so much overlap with how software engineers think about balancing the fact that there is both an artistic side to the work, but also a practical side to the work. I love that over budget projects, you know, because the finished, if you think the clients will forgive you for late over budget projects because the finished design is brilliant, think again, certainly has been my experience as a software engineer. It doesn't matter how wonderful things are if they show up at a time that they're not actually delivering the value that's needed. Right. Yeah. Yeah. What book was that again? Oh, I'm going to go and buy it. Yeah. It's called professional practice. Okay. Yeah. You know, I find that these kind of analogous insights, there's often a slightly adjusted lens to this and for architecture in particular, when we think about physical architecture, I think we very quickly can see, like for example, my wife and I built a home, obviously it's a little different than probably what, you know, the more formal architecture role might be, but similar concerns, right. We're talking about designing a space that people are going to be in and the way that that is built changes our day to day experience and really profound and compounding ways, right. We're going to our lives are going to change based on where we put a wall. And I know it sounds trivial about where do you put the wall? But when you're thinking about this is something that you interact with every single day of your life, right, or every, every, you know, third day, if it's some distant room in the house or something, that really can change the way you see the world. And in minor ways, but in total, in a pretty major way, where we live and how we live is very much so affected by that. And I think that is something that is kind of commonly accepted in the world of architecture, maybe I'm wrong about that, but I think it seems to be, you know, when we think about designing a green space, for example, in a downtown city, that's something that everyone says this is going to change people's lives. Where when we think about software, we don't think about it in those terms of this is kind of a structure that you interact with regularly. So often that a very big part of your life is going to change if this thing changes, or if we, if we build it in this way versus that way, how we design notifications, for example, that's a very kind of intrusive part of somebody's life. And if you design it wrong, it can be really detrimental to people's health in some total. So I think that, you know, each and I bring that up because thinking about software from the perspective of physical architecture and saying, okay, what are some of the mental models or the angles that people see with physical architecture that we could use better or that we could apply to software in a more effective way. And that is one that stands out to me. Do you have anything that you see as kind of applicable that is often just kind of ignored or forgotten? Well, the thing that's been on my mind a lot lately is sustainability. From an architecture standpoint, when you're designing a building or any kind of space, you know, you're thinking about how does this impact the broader environment or ecosystem in which it lives or in which it sits. I think about that when it comes to how software fits, but I also think about that when it comes to the team. Back one of the things that drew me to monograph was the fact that we made this bet on the four day work week and thinking about that. So I came from my previous job with no break into monograph. I had just the weekend and then jumped right into it. And there were really great reasons why, why that had to happen for this particular situation. But knowing that I had the ability every Wednesday, that's our midweek weekend that we have, to sort of unplug, kind of pop my head up, look around and see sort of what, whether the things that I started the week out doing are really the right things to do, just to kind of get perspective on things in general, that has been incredibly valuable for me, kind of gradually returning to some sort of sense of normalcy. I felt like a great sense of achievement the first week whenever I didn't accidentally schedule any meetings on a Wednesday. That's been an adaptation, but a wonderful one. But it goes back to the sustainability thing. So those types of things are delicate, they're fragile. When you think about sort of that contract that you've made to say, hey, this is the day we're not going to work. And yet, we need to support our customers that are going to be around on that day. We need to support one another in the event that something is going wrong for someone, and we need to kind of come in and touch base and sort of fix whatever it might be, whether it be like, hey, I'm stuck, I'm shifting my day off this week to a Friday, and I'm working on Wednesday, and I'm blocked, can someone help me? And so that these chances for things to sort of creep into that space that we're reserving, and we're specifically kind of setting aside as sort of sacred for our kind of recovery. And being able to know what is the right amount of energy to put in on a day like that, or where we can focus really well toward, let's see, how can I best frame this? We can totally edit this part out. So it'll sound kind of like. I actually like the stream of consciousness. Yeah, it's very nice to hear the kind of the construction of that thought. Well, so where I'm kind of going with this is because this is fragile, and because I think it's something worth preserving, we have to be very intentional, which is one of our company's values as intentionality. We have to be very intentional about how we engage in the work during the four days that remain. So the things that I've been saying repeatedly to my team is, and it's kind of fun to say. So I'll admit that because it makes people raise their eyebrows, but for the four day work week to work, we have to work four days a week, and we have to work four days a week. Yeah. And you'll hear the emphasis on the two, right? I want us to actually be something about beacon in the community to say like, hey, there are different ways of working that can be more sustainable for the long haul. We've been over the past year and a half plus incredibly drained as a society, really as a people, as a species. And so when I look at the ways that we can reimagine what work could look like as we move forward, these types of things open up much more readily in a world where remote work is no longer this thing that people are regularly saying, oh, that can't possibly work for our industry. One day work week is something that's even more empowering for a distributed team because you have that flexibility to do, to be wherever you want to be in that day, not to be close to the office, but to be wherever. And I think about kind of preserving this sanctity this day and the same way that I think about other sort of sustainability efforts for team structure. I've been known to occasionally sneak in a little work on a Wednesday, but I try my best to do it secretly if I do. And because it only takes a few times for us to let that sort of thing slip and then it's gone. Yeah. It's extinct like some species that we've overbuilt and destroyed the habitat of. So it's worth preserving and figuring out what those things are culturally that you want to make sort of non-negotiable in the way that you approach your work is important to that whole sustainability for teams. I don't want people burning out because we are all in sort of a fragile place after this entire pandemic has been used. Yeah. I wonder, you know, that's an interesting thing. I think we are in a fragile place on the tail end of this. I think it's also kind of putting a microscope on maybe something we've denied up to now. The fragility may have been there before, but now it's being, you know, it's we're kind of putting pressure or the pandemic is put pressure on us and it made us maybe reveal the fragility a little bit. And a lot of my kind of hope in my roles in the past has been to, I guess, to put a spotlight on the fact that when you try purely to operationalize people, that's it's easy to kind of create this false sense of, okay, if we can put people at work for X number of hours on, you know, on this basis, then we can smooth out these schedules and we can make everything maintainable, you know, and it's this false sense of operationalization that's a word, isn't that operationalization? That we get that gives us, you know, maybe an illusion that everything is going to be consistent or, you know, that we're going to be able to produce at this perfect rate. And maybe if you look at the sum total of 20 companies, you could predict that. But, you know, from company to company, the probably the better approach is to look at people as people and not try to operationalize them too heavily, right? What are the operations that we can do that not only accept that we're people, but take advantage of that fact? Look I'm right back, I'm trying to quick break to talk about today's sponsor. Today's episode of Developer Tea is supported by OnS0. Identity is the front door of every user interaction. Login experience is critical to a user's experience with your app. And as a software engineer, you've probably spent countless hours on this incredibly important interaction. It's not just one interaction either. Login has gotten harder to do and it's still not done. No matter how much time you seem to spend on it, seems like there's always something new to add, a problem to solve. And if you're like most teams, you don't want to spend all your time on login. You'd rather focus on the core of your product. If you don't have the expertise you need to make your login experience seamless or maybe you are concerned about security or the constantly evolving nature of login that you can't keep up with, the builder by decision on login is essentially a no-brainer, especially as you start to scale your application. Even better, if you can solve this before you adopt a bunch of technical debt or hidden security issues with a homegrown login solution, OnS0 is here to solve your login problems for good. It provides simple, secure and adaptable login for applications and businesses, freeing you up to focus on the problems you are best suited to solve in your product. OnS0 supports virtually every style of login you could want. From social login to multi-factor authentication, single sign on, password list, and much more, you can implement onS0 in your application in as little as five minutes. Head over to auth0.com, that's auth0.com to get started today. Thanks again to auth0 for their support of Developer Tea. Yeah, there's something that you touched on there. I think it is absolutely true that this has existed all along. I've regularly said to people, we hire a whole person when we hire you. You should feel safe to bring as much of yourself to the job as you want. Not to feel like there's this sort of, well, there's the professional me and then there's the real me. That's exhausting putting up that facade for eight plus hours a day. One of the things that I just heard this on a news program within the past 24 hours, and I can't remember where. They were talking about there's this unique aspect of American work culture where we are expected to compartmentalize ourselves in some way. I didn't realize, to be very honest, perhaps this shows how unaware I am of the global climate or the global approach to work. I didn't realize that was a uniquely American thing, but apparently according to this news program, it is. Whether it isn't, the idea that we need to be someone else for eight hours is that that's just on the face of it seems somewhat unsustainable. I'd rather create a place where people have a degree of safety to be real. I think that because we are maybe feeling more fragile, maybe a little more afraid than we otherwise would have been after all of these experiences, we're seeing a little more of that human element. I remember in my last job, in fact, there was an individual who was on my team who was going through some personal things. Out of the blue one day, I received an email saying, I need to resign. I'm going to resign from my job. It doesn't take a lot to just bring a certain human element to the work. It would have been easy for me as a manager to say, well, we accept it. If I am to use your word, thinking of them as operationalized resources, if I'm thinking of, this is a person, this is a resource that has been applied to a problem. I must now go find another resource. You might detect an amount of contempt for the word resource as it pertains to people, by the way. My voice, I apologize, but it is, in fact, a real sense of contempt for that word in that usage. If I think of this person as a resource, then it is simple enough for me to say, okay, while I am now down one resource, I need to go back and figure out what to do. The very minor adjustment, it's not a huge shift to say, oh, this is a person. Remember, I slept on it, and then I responded the next morning, and something to the effect of, I don't know exactly what you're going through, and I don't need to know. But I do know what it feels like to be a person who is overwhelmed. When you're overwhelmed, you feel like you must take action, any action, to kind of exert control over some aspect of your life. With your permission, I'd like to decline your resignation for a couple of days. It's not going to make a difference to our roadmap one way or the other. If those two days, you know, you still make the same decision, but it will make every bit of difference to you in being able to get a little distance and perspective. That person wrote me back that Friday and said, you know, thank you for the time. And if it's okay with you, I'd like to come back to work on Monday. I'm realizing that work is exactly the distraction that I need from this particular situation that I'm going through right now. And in fact, stepping away would be worse for me than staying. Which is hard for us to predict. I think this gets into, you know, what a lot of people are trying to do in their careers, they're trying to do with their reports, they're trying to do with their projects, is predicting the future. And humans are notoriously bad, especially about predicting how we will feel in the future. I imagine that we're going to feel either very good or very bad. We purchase things with the expectation that we're going to, you know, garner some incredible sense of fulfillment from that thing. And how many things do we have? Right. And that's not, you know, I'm not going to go on an anti-materialist rant or anything like that. But instead to say that prediction is very often not necessarily wrong wholesale, right? Maybe that thing was something that you enjoy. You know, maybe your prediction that this job was going to be the best thing that ever happened to you, it was a good thing that happened to you. But certainly it's hard to get the category of the absolute best. And so these predictions that we make have errors in them. What is that error? In this case, the person that you're talking about predicted that they needed this space to think about something. Well, perhaps the prediction was wrong in the sense that they needed the space to not think about the thing, right? It's right. Right. And I think that we make these errors and then we make decisions off of our predictions. And I wonder, you know, I have my opinions about ways that we can work against that tendency to the desire to predict. I'm curious about, you know, from your perspective, how do you work with what you have and avoid, you know, trying to over-predict, you know, what's going to happen in the future? Yeah, that's a really tricky challenge. It could go in a lot of different directions this conversation from this point because we can now discuss the merits and pitfalls of software estimation. Sure. We could talk about the predictions of, you know, what we think our goals are individually in taking a job and where we think we're heading. Where I think I'd like to just spend a little time talking about this sort of, you know, fallibility in our ability to predict things is that it's often the case. So for instance, actually, this is a great, great way for me to describe this. So when I joined, I joined monograph, that is, I learned that we had a specific plan in mind for how we were going to structure our teams. And when I tend to think about team structure, I tend to think about whether or not the team can articulate a mission that they can get behind in some way. Is there something that conveys some sort of long-term goal that necessitates this team that pushes this team forward towards something? And those kinds of predictions, if they become too narrow, they can themselves be so changeable that suddenly you look up one day and you're like, why does this team even exist? Like why are we here? So you need to broaden them out a little bit and give them room to sort of evolve and shift as we learn more. And so there's a difference between sort of effective project management and then what it looks like to build a team that has a longer-term mission. Making the short-term concessions around how we staff a given team in order to move a particular project forward shouldn't throw into confusion the point of why we're all here. If in the smaller team or at least in the larger team, in the larger site, in this case, maybe we have a specific team breakdown at monograph, but there's also the fact that we are all working at monograph and on the same sort of path. No. That means that for any individual that joins, for instance, if I'm interviewing someone and their primary reason for wanting to come to monograph is because of the four-day work week, I think, well, that could be problematic in the long run because while I believe that the four-day work week will remain and that that will be a thing that we can make a long-term benefit for everyone, it also isn't enough to make me want to get up for work every morning. Boy, I sure am glad I've got that extra day off. It's not the thing that makes me kind of connect to doing something good in the world with the work that I do. I spend too much time working, even on a four-day work week, to be disengaged with the actual work itself. I'm looking for a way to connect the work that we do with the people that are doing it in a way that suits their own personal goals. That goes back to this rant. We'll go only a few moments longer, but that goes back to how we think about setting personal goals in the first place. I remember at my previous job having a conversation around what are your dreams and then sort of what skills do you need to achieve those dreams? Some of them are work dreams and some of them are life dreams. In previous jobs, I've had people say things like, well, you know, I'd love to be a comedy writer, which I found delightful to learn about. In fact, that person was an excellent writer and had fantastic comedic timing. It all made sense after I learned that that was one of their dreams. Then another person said, I'd like to do aeroponics farming. I've had all these things that I've learned. When you lay out the skills that you need to grow in in order to be effective in these things, many of them are also skills that will help you in your work life and in toward specific projects that we are working on. When you connect this to a bigger, you know, more holistic view of the person and where they want to grow, the person stops working for you. They're working for them. And that is something that makes all the difference in terms of this sustainability that we were talking about earlier. In terms of this being able to understand that my plans for myself don't have to be identical to the plans that my work has for me, but I can still find ways to bend them so that they coincide in some way or they collide in some way. And I purposefully advance along both paths, both my work path and my personal path. So it's that work life integration, not work life balance, but work life integration. Yeah, this is something that has been on my mind a lot because of course as a manager you think about how are the most successful people going to find their way to this team? Right? How does this team succeed? What kinds of people would be on? And this team meaning really any team. And I think to your point, going back to this idea that somebody is going to work at Monograph for the four day work week. There's benefits, right? There's competitive benefits. Nobody virtually, well very few people are going to work for a dollar a year salary. Right? So at some scale money is a leverage point. At some scale any benefit is a leverage point, right? If you have, and I think this gets into and I don't want to dive into it because it's been kind of talked about endlessly the idea of unlimited PTO and the problematic kind of culture that surrounds that and ways to resolve it. But I think if you were to line up four companies or five companies as companies begin to compete with each other, there's some kind of optimization thing that a person runs when they have three or four options. And I think the competitive advantage for company A over company B is unlikely to be while we pay 2% more because company A may have a change in situation. Now they pay 2% more, right? And you end up in this kind of dead end game. The competitive advantage is this is something that you can overlap your, you know, not just interest, but there's something that we do that other people don't necessarily want to do, right? Or something in what we're building, you know, either at the team level or at the product level that is not a space that somebody else is going to try to get into or at least it's, it's, there's a limited, you know, a limited number of people. And that's a very different, like you said, it's working for me because I care about this, you know, whatever it is that we're, that we're making or I care about this team that I'm cultivating. Well, there was that, I gave a talk ages ago where I talked, actually a couple talks that I've given where I talk about Martin Selecman and some of the, you know, sort of the positive psychology. And there was that, what's called perma idea, right? The sort of scientific theory of happiness where P was positive emotion, E was engagement, R was relationship, M was meaning, and A was accomplishments or achievements. And that meaning thing, that's something that we can bring into the work fairly straight in a fairly straightforward manner if we are intentional about it as leaders, right? If we actually say, okay, there's, there's a bigger purpose to what we do here. Otherwise why did we start a company? Right? Why would you found a company, you don't found a company to get rich because so few companies, you know, like startups are actually going to make you rich. You may as well go buy a lottery ticket, but you do found a company because you have something to say in the world and to do in the world and to, to, to, to change in the world. If you're a founder, that's what you're doing. You should try to make an impact in some way. And so similarly, when it comes to individual teams, for instance, I, I, I led a team at my last job, um, that we called application engineering. And it didn't take a lot of reflection to realize that we were in a unique space at that company, which was largely infrastructural in nature in that this was the company that owned all of the customer facing API and UI work for, for the underlying infrastructure. So where so much of what the company did was invisible to the user unless it went wrong, what we did had the opportunity to potentially delight the customer in new, uh, and exciting ways because it was making the first impression as you were going through the setup of the services that, uh, that we provided. It was the sort of the, the, the tactile area of the application, right? The place where there was actual surface area. And so by being able to talk to the team about like, this is the bigger picture of like why we're doing what we're doing in the power that this particular part of the work has. There was a certain resilience to that team, even once I moved on around, they, they understood why what they did matter. And that doesn't take, it doesn't take as much energy as a leader, as you might think it would to spend a little time doing the necessary research and reflection to, uh, do the storytelling that connects us to the bigger purpose of what we do. A huge thank you to Ernie Miller for joining me on today's episode of Developer Tea. Make sure you listen to the next episode for part two of my discussion with Ernie. Thanks again to off zero for their support of today's episode. Head over to auth0.com that's off zero to take care of your login for good. If you'd like to discuss this topic, we talked about on today's episode and other topics with engineers like you head over to developer.com slash discord. You can join that community totally free. Thanks so much for listening and until next time, enjoy your tea.