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'll talk a little bit more about what Monograph does. You might recognize Ernie's name. It's 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 Cutrello. You're listening to Developer Tea. My goal on the show is to help driven 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, was it 2015 or 16? I can't remember what year Ancient City Ruby was. That sounds about right. Yeah, somewhere in that neighborhood. Somewhere in the middle 2000 teens, 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. I'm working 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 designed to help architects and engineers oversee projects, you know, timesheets, forecasts, 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. Yeah, no, I think, you know, we can actually talk about that. The 40 were, you know, some of those 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, you know. 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 40 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 practice, I'm curious to talk about it. But I do want to back up and say, you know. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. As an engineer, and this is really specific 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. Mm-hmm. Mm-hmm. Yeah. Yeah, I, you know, I, I can imagine that the, those principles are, they, 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 the more appropriate word, uh, about, uh, and, and on the, what we would call the healthy side of dogmat, dogmatism of, we really want to commit to building, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, being iterative as a practice. We really want to commit to learning and staying flexible and quickly changing when we need to. I've always found that often if you're telling somebody about this for the first time, I've actually heard construction building as a point of reference for this is something that we 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. You don't get to have a chance to do that. That's such an interesting opportunity though. You mentioned something that I think is important and can generalize to a lot of cases. The idea that you have these architects in residence or I think that's what you call it, the Slack channel. The idea being, 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 learned something from one of those architects that you just had no idea that that was a part of the decision-making? Or that it could work that way? Have you learned anything like that that was counterintuitive to you? Dr. Justin Marchegiani Dr. David Jockers Dr. David Jockers Dr. David Jockers At the Atomic in a channel called Engineering Reads 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. Failing 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 on a regular basis? Yeah. Very, very much similar. And then, you know, on the flip side or maybe less of a, you know, stressful sort of deadline oriented takeaway 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 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. Yeah. It 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? Just for, for, 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 in really profound and compounding ways, right? We're going to, our lives, 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 see the world. And how we live and how we live is, 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, 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 going to change people's lives. It's kind of a, 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. And so I think that, you know, each and I, 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, um, 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. Um, from an architecture standpoint, when you're designing a building or, or any kind of space, you know, you're thinking about how does this, how does this impact the broader environment or ecosystem in which it, in which it lives or in which it sits? Um, I think about that when it comes to how software fits, but I also think about that when it, when it comes to the team. In fact, 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. Uh, 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, our midweek weekend that we had, that was a really great way to kind of get a sense of what I 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. Uh, I felt like a great sense of achievement the first week, whenever I didn't accidentally schedule any meetings on a Wednesday, uh, that's been an adaptation, but a wonderful one. Um, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, 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, that contract that you've made to say, Hey, this is a day we're not going to work. And yet we need to support our customers that are going to be around, uh, on that day. Uh, we need to support one another in the event that something is, uh, is going wrong for someone. And we need to kind of come in and touch base and sort of fix whatever it might be. Uh, whether it be like, um, 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 there are these chances for things to sort of creep into that space that we're reserving. Um, and you know, 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 like where we can focus really well, um, toward, Oh, let's see, how can I best frame this? We can totally edit this part out. So it'll sound like I have a great thought. I like the, uh, it's a stream of consciousness. Yeah. It's, it's very nice to hear that kind of the, the construction of that thought. Well, so, 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 is intentionality. Yeah. And we have to be very intentional about how we engage in the work during the four days that remain. One of 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, uh, 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? That I, I want us to actually be something, something of a 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, 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. We're not going to be able to do this. We're not going to be able to do this. Uh, four day work week is, is something that's even much, even more empowering for a distributed team, because you have that flexibility, you know, to do, to be wherever you want to be in that day, not to be close to the office, but to be wherever. And, you know, I think about kind of preserving this, this, uh, the sanctity of this day. And, and, uh, you know, the same way that I think about other sort of sustainability efforts for teams, uh, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, I, I've been known to occasionally sneak in a little work on a Wednesday, but I try my best to do it secretly. I do. And because, because it only takes a few times for us to let that sort of thing slip. And then it's gone. Yeah. It's, it's, it's, uh, it's extinct. Like some, it's like some species that, you know, we've overbuilt and, and destroyed the habitat of. So it's worth preserving and figuring out what those things are culturally that you want to, that you want to make sort of, um, non-negotiable in the way that you approach your work, uh, is important to that whole sustainability for teams. I don't want people burning out because we are all in sort of a, a fragile place after this entire pandemic. Yeah. I, I, I wonder, you know, that 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, uh, up to now, the, the fragility may have been there before, but now it's being, you know, it's, we're kind of putting pressure, uh, or, or the pandemic has put pressure on us and it made us maybe reveal the fragility a little bit. Um, and, and a lot of my kind of hope in my roles in the past has been to, uh, I guess, uh, to put a spotlight on the fact that when you try purely to op operationalize people, that's, it'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, uh, on this basis, then we can smooth out, uh, these schedules and we can make everything maintainable. Um, and it's this false sense of opera operationalization that that's, that's a word, isn't it? Operationalization. That's operationalizing, um, that we get that, that gives us, you know, maybe an illusion that everything is going to be consistent or, you know, that, 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, you could predict that. But you know, from company to company, the, probably the better approach, um, 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. We'll come right back after a quick break to talk about today's show. We'll come right back after a quick break to talk about today's show. We'll talk about today's sponsor. Today's episode of developer T is supported by auth zero. 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 a matter of time. 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, 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 the login. You'd rather focus on the core of your product. Maybe 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, auth zero is here to solve your login problems for good. They provide 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. Auth zero supports virtually every style of login you could want from social login to multifactor authentication, single sign on password lists and much more. You can implement auth zero in your application in as little as five minutes. Head over to auth zero.com. That's a U T H zero.com to get started today. Thanks again to auth zero for their support of developer team. 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 and you should feel safe to bring as much of yourself to the, to the job as, as, 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 because that's exhausting putting up that facade for, you know, eight plus hours a day. And one of the things that I just heard this on a news program within the past 24 hours, and I can't remember where, but they were talking about there's this unique aspect of American work culture where we are expected to compartmentalize ourselves in some way. And I didn't realize to be very honest, perhaps this shows how, how unaware I am of the global climate or the global, global, global sort of approach to work, but I didn't realize that was a uniquely American thing, but apparently according to this news program, it is and whether it is or 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. And so I'd rather create a place where people have a degree of safety to, to, to be real. And I think that, you know, because we are more, 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 and out of the blue. One day I received an email saying, I need to, I need to resign. I'm going to resign from my job. And 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, okay, well we accept it. And then to go, if, if, if I am to use your word sort of thinking of them as sort of operationalized resources, right? If I'm thinking of, okay, this is a person, or this is a resource that has been applied to a problem. I must now go find another resource. Then you might, you know, detect them out an amount of contempt for the word resources. It pertains to people by the way, and my voice, I apologize, but it is in fact a real sense of contempt for that word in that usage. But if I think of this person as a resource, then it is simple enough for me to say, okay, well, I am now down one resource. I need to go back and, and figure out what to do. But the very minor adjustment, it's not a huge shift to say, oh, this is a person. And I 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. And when you're overwhelmed, you feel like you must take action, any action to kind of exert control over some aspect of your life. So with your permission, I'd like to decline your resignation for a couple of days. It's not going to happen. 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 and 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? 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. And what is that error? In this case, the person that you're talking about predicted that they needed the 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? 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, the desire to predict. I'm curious about, you know, from your perspective, how do you work with what you have? And how do you, you know, 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, 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. 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. Right? At the end of the day, where I think I'd like to just spend a little time talking about this sort of fallibility and 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 learned, 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... 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. You know, making the short-term, conceptual, and then the long-term, you know, the long-term, you know, the long-term, sessions 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 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. Now, that... 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 will be a thing that we can make a long-term benefit for everyone, it also isn't enough to make me want to, you know, 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. And I spend too much time working, even on a four-day work week, to be disengaged with the actual work itself. So I'm looking for a way to connect the work that we do with the people that are doing it in a way that... That... Suits their own personal goals. And that goes back to... This rant will 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, you know, sort of what skills do you need to achieve those dreams? And some of them are work dreams and some of them are life dreams. In previous jobs, I've had... 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. And in fact, that person was an excellent writer and had fantastic comedic timing. And it all made sense after I learned that that was one of their dreams. And then another person said, I'd like to do aeroponics farming. And I've had all these things that I've learned. And then 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 towards specific projects that we are working on. And so 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, you know, my work has for me, but I can still find ways to, to bend them so that they coincide in some way and, and are, or they collide in some way. And I, you know, purposefully advance along both paths, both my work path and my, and my personal path. So it's that work-life integration, right? Not work, not work-life balance, but work-life integration. Yeah. This, this is something that has been on my mind a lot because of course, as a manager, you think about, you know, how, how, how are the most successful people going to find their way to this team, right? How is, 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, you know, going back to this, 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, for a dollar a year salary, right? So, so at some scale, money is, is a leverage point. At some scale, any benefit is a leverage point, right? If you have, and I think this is, 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, the problematic kind of culture that surrounds that and ways to resolve it. But, you know, I think for, 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, you know, the competitive advantage for company A over company B is unlikely to be, well, 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, in what we're building, you know, either at the team level or at the product level that is, 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, it's 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, uh, I gave a talk ages ago where I talked actually in a couple of talks that I've given where I talk about Martin Seligman and some of the, you know, sort of the positive psychology. And, uh, there was that, uh, what's called PERMA idea, right? The, uh, the sort of scientific theory of happiness where P was positive emotion. E was engagement. Uh, R was relationship. M was meaning and A was accomplishments or achievements. And that meaning thing, um, that's something that we can bring into the work fairly straight in a fairly straightforward manner. If, um, we are intentional about it as, as a team. And so, um, I think that's a really good point. And I think that's a really good point. And I think that's a really good point. And I think that's a really good point. I think that's a really good point. I think that's a really good point. 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 yield, you know, like startups are actually going to make you rich. Uh, 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 is you're trying to make an impact. In some way. And so similarly, when it comes to individual teams, for instance, 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 to set up the services that, uh, that we provided. It was the sort of the, the tactile, uh, 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 this. Right. Yeah. And 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 mattered. 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. Too. Thank you. Ernie Miller for joining me on today's episode of developer team. 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 a U T H zero.com. That's off zero to take care of your login for good. If you'd like to discuss this topic, uh, we've talked about on today's episode and other topics with engineers like you head over to developer t.com slash discord. You can join that community. Totally free. Thanks so much for listening. And until next time, enjoy your tea.