NOEL: Hello and welcome to Episode 21 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and want to help other people find it, we would really appreciate that and the best way to do that is to please leave us a review on Apple Podcasts. If you'd like to be notified when new episodes are released or if you just like to get in touch with us, probably the best way to do that is to follow us on Twitter at @Tech_Done_Right. To learn about past episodes or leave comments, you can find us online at TechDoneRight.io. We really love hearing from you. Today on the show, I'm talking to Betsy Haibel, a software engineer who got her start as a theatrical set designer. We're going to talk about how set design can inform software architecture and about how the various constraints and communication needs of one field can inform the other. I love a good theater metaphor and this one comes as a practical advice for running software teams. Betsy, do you want to tell everybody who you are? BETSY: Yeah. I'm Betsy. I used to work as a set designer and as a scenic artist, which is a fancy way of saying the person who paints the sets. Before I did tech, I've been a software engineer for a decade now and recently, co-founded my own consultancy, Cohere. NOEL: We're actually here to talk about the intersection of the set design career and the tech career. Maybe we could start by explaining what kinds of decisions or what kinds of creative work you do as a set designer and then go from there. BETSY: Yeah. The joke I always make about the crossover there is that my work as a set designer and as a general backstage worker was about 20% artistic decisions and about 80% negotiating with directors to figure out a way to communicate their artistic vision that was on budget and physically possible. Usually, people make the parallel with product managers for me and I don't need to do that but there's deeper parallels that go beyond soft skills, I think and those are what I'm most interested in talking about today. NOEL: I love a good theater metaphor. Theater is a great metaphor for a lot of things because it has a lot of people collaborating together and it's not competitive, normally. It's not competitive the way sports are. But normally, I'm used to thinking of set design and that kind of stuff as metaphors for user interface design but that's not the kind of thing you want to talk about it as, correct? BETSY: No. When you're a set designer, what you're doing is literally shaping the space that people move through. I think it's easy to think about set design as like you painted the backdrops, you drew pretty pictures and that's part of it. There are some backdrops that I've painted that are very pretty and I'm very proud of them but the important part it turns out, once you get really into it, isn't about the skin of it. I hate going to something that would make sense as a user interface metaphor but just as the colors you pick for a user interface aren't the core of the UX, the real part of set design is the way that the scenery is arranged in a space. One of my favorite examples here is a production of The Merry Widow that I worked on, that one of my mentors designed. The reason that it's one of my favorite examples is that there was this long promenade at the back of the stage, such that the only two ways for people to enter or exit were entering along the grand promenade and announcing themselves and being very public about the fact that they were making this movement on stage or kind of skulking in through the sidelines. That makes it really explicit. When the director is blocking the show later is setting up the specific paths that the actors are supposed to take and saying, "You're going through here when you give the speech. You're going to then exit through the wings, using that exit." Having really defined spaces to move through means that the movement the director is setting when they block the show mean specific things contextually. Another really great example I like to use is Man of La Mancha, which is one of my favorite musicals ever. Almost every production of Man of La Mancha has a high catwalk that surrounds the stage. The play is a show within a show and the kind of frame story takes place within a prison. It's really important that you feel during the entire time that even if we're telling this magical fantasy story within the prison, we're in a prison the entire time, that the guards are looming menacingly and looking down on the prisoners. When Cervantes leaves at the end, it's ambiguous as to whether he's climbing up into some kind of heaven or not and you can't do that if you haven't set up the space to enable those kinds of artistic choices. NOEL: Set design makes concrete certain kinds of design decisions, certain kinds of things that might otherwise be subtextual or might be implied. It has a possibility of making them very physically concrete in the way that the performers move across the stage. BETSY: Yes, exactly. The thing I really like about that as a metaphor for what we do as software engineers, that aspect of the design literally has no meaning without the actors on it. The fact that you did the scenery for Stuart Little like a kid's book style, that exists even without the actors. It's cute, it's nice, whatever but the fact that you did the scenery for this particular production of Stuart Little, in a way that let the actors move the wagons, the bits of scenery that are movable, around to rearrange the space so that it was playful. That's something that only exists once you actually have people working in the space. I really like that as a metaphor for grander software architectures because for a software architecture to be meaningful, it can't just be, "We're going to use Model/View/Controller for this." It can't just be, "We're going to use functional service objects for this part of our business logic." It has to be interpreted in the context of how the actual implementing engineers are implementing things. NOEL: The design choices you made as a software architect, you are making them in a way so as to make meaningfully constrain the activities of the engineers who are working on it. You have a vision for how they should move, how data should move, how workflow should move and you are structuring the design of the code to make that explicit. Is that a fair way of expressing the metaphor? BETSY: Yeah. NOEL: How did you come to be an architect position where you started thinking, "This feels a lot like set design." BETSY: How I came to be in an architect position is entirely accidental because I was interviewing for a lead engineering position at a startup and the person who was interviewing me who was also a lead engineer there, the idea was that we would split lead engineering roles, the role in half, and each take charge for a different section of the app. He kept on reassuring me that my title was going to be architect but they didn't mean it like that. He meant it as a paring role and guidance role and then I got the job. It quickly became clear that just wasn't workable. You can have ideals about, "I'm going to be the kind of lead engineer who's very hands off and gently mentors and guides." But you can't gently mentor and guide a dozen of people or as it was eventually, 30 people. One-on-one with very meaningful pairing sessions every day is not scalable. There's only one human in here. What I needed to do was I needed to find an interpretation of software architecture as a path that still fit in with my values about bottom-up design and empowering the creativity of line engineers because, I think everyone has the stereotype in their head about some horrible waterfall engineer from the bad old days. The person who draws a bunch of unrealistic diagrams and then you have to write Java to this very precise class structure, whether or not that class structure works in practice. I was terrified of being that to someone or doing that to someone. NOEL: Yeah, or in some cases you built all the code and then you draw up the architecture diagram and pretended it happened the other way around. BETSY: Right and that's not adding any value to the process. NOEL: That's actually a strange theater metaphor -- the actors come together, they build the set and then everyone goes home. BETSY: Right and that doesn't -- NOEL: It doesn't quite work, yeah. It's funny. You made me think of this like one of the first things I ever learned about being in a leadership role in any context was when I was actually directing a one-act play in college. I was convinced that I was going to be the cool director. I was going to let the actors collaborate on all the choices, we were going to be in this together and about a week or so in, I asked a friend of mine who was in the cast like "how am I doing. He was like, "Noel, I think you're doing great but we'd really like if you direct sometimes." BETSY: Right. I'm laughing behind my hand because you need a strong central spine in these kinds of situations. Otherwise, everyone is looking to each other and to the ether and no one, or worse, the loudest person in the room takes charge. NOEL: Yeah. I completely understand that the kind of tension that you feel that you want to have this collaborative environment. You want people to feel their creativity is respected and you need people to have their creativity respected because everybody's creativity is important on a collaborative project. But yet at the same time, the projects often go so much better if there is a clear vision that one person is sort of in charge of curating, I guess might be the best word. I think about that random conversation I had with my friend twice a month in the context of the things that I do now. We have architect as a very well-defined term outside of software and a somewhat ill-defined term inside of software and we're drawing all these metaphors between various different kinds of design. Are there other dimensions to the metaphor or other kinds of work that can participate in this metaphor? BETSY: One of the things that I really like about this metaphor specifically now that I've thought of it is the way it emphasizes continuous collaboration and feedback loops. Admittedly, I've never worked in a traditional construction environment and perhaps I'm stereotyping but the received wisdom we get from that very traditional architecture metaphor is there is a long planning process and the architect is the well-paid genius who just makes all things go and there's a lot of like great man theory nonsense all wrapped up in that that I don't want to unpack but think it's really gross. Then all of the builders execute the plans as faithfully as possible. That's fine in the context of a real physical building because if you don't do that with a real physical building, then the real physical building falls down and kills a lot of people and that's not desirable but -- NOEL: It's much harder to refactor a wall. BETSY: Exactly. NOEL: I mean it's not impossible, right? BETSY: Not impossible and people do things with that after the fact but people in software do the best they can with inflexible legacy designs and move around what they can and work within those constraints, like no building ever stays the way its original architect planned it to be. But it's a process that emphasizes guessing what people will want, guessing what people will be able to work effectively within upfront because ultimately, you need a very strong, well-engineered plan if you want the building to stay up. I don't think that that's true in most software applications. In set designs, you're still constrained by physical reality, right? Like you're building much smaller structures but they still do need to have structural integrity--see above about the 80% of the job negotiating with directors to make sure actors stay safe. NOEL: Right, otherwise you have Spider-Man: Turn Off the Dark. BETSY: Turn Off the Dark, yeah. Definitely whenever I use that, I flashback to a show I stage managed and there was a need for a flying entrance. There was no way to make the harness that we had for this actress as she was flying and look like anything other than a diaper and that was not good because she was supposed to be coming in like this ninja avenging angel, very spy and then go and beat up someone and trying to figure out a way to hide the very diaper-like harness during her flying entrance, so that it actually looked cool was this hell of a challenge and there was no way around it. We could not change the structural elements of the harness because otherwise, we would kill Michelle and we really didn't want to kill Michelle. NOEL: Right, among other things, it makes the next show much harder to put on. BETSY: Right. NOEL: You know, set design is an interesting metaphor here because the things do have to have the structural integrity of a building-building but they need to have a flexibility. They often need to have a flexibility that is to me in my head, much more like software than a building. Pieces of set need to move. They often need to get on stage and off stage. They often need to be carried by actors. I'm a total sucker for theater where the actors move set pieces around, which has nothing to do with anything. I just like saying it. How does this change the way that you approach software architecture or software design? What would you say to somebody listening to this is like, "I am thinking about software design, as set design," like how would I do that? What is a change in the way that you put the practice? BETSY: One of the biggest things is -- and this is very agile doctrine but it's important so I'll frame it this way -- the importance of paying attention to the way that design is actually being used. In a traditional building, you design it, you build it, people move in and the architect has left the project by that point. People are moving furniture and saying, "I don't like that closet where it is. I'm going to move it to the other end of the room," and all of that, but it's totally after the phase when the architect has been on the project. Instead, in set design, there's this whole, long rehearsal process in which you're getting constant feedback. Set design is somewhat unique among the theater disciplines in that a large part of the design is completed before the actors go in to rehearsal, again because you need to have the spaces the actors are going to be moving through before you block the actors. You need to be able to tape out where the large set pieces are in their rehearsal space so that people know I'm not going to be able to walk into this while they were rehearsing. You need to also start building the actual scenery but there's wiggle room. There usually isn't budget or time budget to do super intense rework but things like, "This movable set piece, which thank God is moveable, will live much better on this side of the stage during this scene." That's a flexible thing and that's something that you can figure out during the rehearsal process. NOEL: Is it something that you design for too? Do you design for a certain amount of flexibility? BETSY: Absolutely. NOEL: With the way that we might talk about in software design, keeping our design open, is there an analogous process? BETSY: Absolutely and that part is easier in plays where you're going for a very aggressive modernist aesthetic. One of the -- NOEL: Which means sort of minimalistic? BETSY: Minimalistic or also abstract, like the play I'm thinking of here is a play called On The Verge. One of the traditional ways that the sets for that can be designed is -- and this is really difficult to express in the audio but it looks really cool -- there will be mirrors across the back of the stage and billowing pieces of fabric on pulleys and those get manipulated to form things like mountains and etcetera during the show so things like that. These very hyper-abstract sets that are actively manipulated that gives you a lot of room to play with the shapes you're actually making during the rehearsal period. But even in a more traditional kind of thing, you're going to have often, a lot of literal moving pieces. For example, the production of Stuart Little that I did that alluded to earlier, the design was three wagons, three moving set pieces that contained New York skyscrapers on one side and scenes from the countryside on the back and those would move around this kind of triangular stage area and there was also a background with more skyscrapers. What we could do was just rearrange it arbitrarily at a given point. The important parts of it, the fact that the skyscrapers were way, way taller than any of the kids who were attending and therefore, it'd make them go, "Oh, this is very big," and the big reveal when we went into the countryside and they spin around and you can see trees on them and stuff. Those parts would remain constant and those parts, we need to make a decision on fairly early in the process so that we could build the scenery. But because it was designed as a set with a lot of moving parts, there was a lot of room for us to play around we thought that was. There's a phase toward the end of any theater and rehearsal process called technical rehearsals, which is where all of the designers are present -- NOEL: Yeah, they're long, usually. They're very long. BETSY: Yep and it's really boring as a set designer. The lighting designer is working pretty much constantly during those 10-hour rehearsals but you're just sitting there and taking notes on, "Oh, that actually kind of works. Oh, that's ugly. We need to fix that," but there's also in between every scene you're like walking up to the director and negotiating and physically moving things across the stage while the director goes, "No, I like it better here" and you go "but this," so you're collaborating with the pieces you have. You can't change the pieces you have very much at that point, usually because you're also running behind on the build of the scenery so one of the things you're figuring out while you're sitting here taking those copious notes is what things from your vision you can practically cut to get the scope to something that will actually be 'finished' when the play opens. Like I said, the software metaphors just kind of fall out of the story naturally. NOEL: It sounds very much like a beta test and load test and all of the things that you need to do. I want to stay away from the UI metaphor but in this case, if we're talking more of the architecture metaphor, the way that the software becomes is or isn't modifiable as new change requests come in, as a test of the architecture. BETSY: Right, exactly. NOEL: The show that actually keeps bouncing through my head is the relatively recent Broadway revival of Falsettos, which they filmed and was in movie theaters over the summer. BETSY: How did I miss that? NOEL: It's okay. It will be on PBS sometime soon. The set was essentially a bunch of, basically foam blocks that started off in a cube that the performers would continually take out and rearrange into chairs and tables and couches and whatever and would occasionally bring back together for more abstract effects but there is actually a very, very nice effect at the end that they do out of it. They comes out of nowhere. But that's strikes me as being particularly software-like and that they're literally moving blocks around in different configurations to get different functionality and to reset the area that they're working in. That feels like particularly, metaphorically apt to me. I just keep flashing on it as we're talking. BETSY: Yeah and one of the things that that makes me think of is the way that even a very aggressively flexible design, one that's designed to give you as much to modify as you can as you're building the software or rehearsing a play. That's not the absence of the design. That's a design that's optimizing for flexibility. NOEL: Right and one of the things about that kind of flexibility that would be true in both a set and a software context is that it opens you up to a lot more potential decisions. If you have big chunky set pieces, there's relatively few amount of things you can do with them but if you're set is a bunch of basically foam blocks, there's infinite amount of fiddling that you can do. BETSY: Right, so what happens in those circumstances is that that forces the director to make the same spatial decisions that otherwise the set designer would be making in concert with director anyway. One of my favorite shows I've ever worked on, I didn't do the set for because the set was two chairs, literally two folding chairs so crediting anyone as the set designer would be very silly but that was still a set design. Even though those two folding chairs could move anywhere in the playing space during the show, in practice there were a few points that the chairs kept on returning to. NOEL: We might call them patterns. BETSY: Patterns. Exactly. Just because you could do anything, it didn't mean it made sense to do everything. The audience's subconscious isn't going to react well to a show in which the actors are just all over the place and there's no thematic resonance to the fact that they're standing in the same place for the scene that they were in that other scene because they're not -- there's no spaces that have built up thematic resonances to them. The director in that show, needed to do a lot to actively shape the space, even though there wasn't scenery in the way forcing them to make those decisions. NOEL: Right, that's harder. It's been a really long time since I actively did theater, although I miss it tremendously but I have done a couple of directing those kinds of things and I did direct a one-act show in college or high school that was basically just a bench but there is a design there, though because you have to come up with things like stepping forward means this, stepping to the side means this, this side means this, because otherwise it's just madness and you kind of build up a grammar of the way space is used and again metaphorically back to the software, the relationships between the blocks of your design, the modules, the different applications, the relationship between them, you have to make some specification as to what those interactions mean and what those pieces mean because otherwise, anybody can do anything and you have chaos. BETSY: Right and that can be fine for small teams or even on personal software because you know what all the different pieces of the chaos mean. But once people actually start working on your stuff, then it's a different story. One of the things that I thought really, really firmly as like an article of doctrine before I started doing software architecture work was that all designs needed to emerge organically and things like that. Then I started actually being in a position of technical leadership. The things about the differences between this style of presenter object and this other style of presenter objects that I'd previously dismissed as not useful because they should all emerge organically in these broad ideals, where suddenly things I needed to do to communicate to people what the structures here were. It wasn't about finding the best structure, which usually doesn't even exist. It was about deciding, "But here is the structure we are using" and communicating that out to people so that everyone could follow that structure. NOEL: Yeah. I find that there's two kinds of things like organic emergent design can happen but it's kind of risky and it takes a long time. That sometimes like you're saying with presenter objects, the difference is between the best and the second best are swamped by the differences between picking one and going for it and running around in circles for two weeks. One thing I was thinking about that I think you almost certainly can speak to better than I can is what are the differences in scaling between working in a set design in a small environment versus in a larger environment where there are more people? Does that have anything to speak to you the way the teams scale in software design? BETSY: Oh, absolutely. There are a lot of different set design practices that can happen, like I would say, a show I worked on at one point, Tent of Dreams, where the design meeting and most of the actual design emerged where the director and I went to Five Guys and then we went to the Home Depot across the street from the Five Guys and we wandered through the halls of the Home Depot and pointed at things and went, "Yes, I like that. No, I don't like that," and when we were done with that two-hour trip, we had a bunch of PVC piping and some rope and I knew what I was going to do with all of those things plus the cardboard we're going to scavenge later. This was about the Occupy Movement so this actually makes a lot of sense. That worked for that show because it was a show about the Occupy Movement so wanted a very aggressively, scrappy aesthetic but also worked for that show because it was a show that was being produced by a company of 10 people overall. I was the set designer and also, the person responsible for building the set and doing all of the painting and decoration of which there really wasn't much because you're probably getting the impression about our budget from this process that I'm describing and that impression is very accurate. NOEL: I think the phrase scavenged cardboard definitely set a tone there. BETSY: And that kind of very fluid give and take process works when establishing the design. It can fundamentally be about a conversation between you and your director because your director needs to understand where things are going to be and you need to understand what the pieces you're building are and then you go off and you build them and you don't need to do much further communication because it's all in your head and your director's head. But once you start bringing in a lot more people, then all of the sudden, it becomes much more important to have that upfront planning to do a full drafted out blueprints of every set piece, possibly with exploded views and/or alternate isometric views. I'm flashing back now to the time I made the mistake of designing something that had a raked surface with a curved edge because trying to hand draft in isometric -- NOEL: I'll translate the lingo there, the raked surface means it was angled. BETSY: Right or tilted. NOEL: Not a flat surface. BETSY: Yes and it had a curved edge so there really wasn't any way to let the construction shop know what the hell was going on, short of having all of these different views were very hard to project out in a hand draft form because this was two or three years before CAD software was a thing in the theater world. Even a decade ago, we were still basically hand drawing all of our blueprints. NOEL: The interesting thing to me about that is that you do have all these diagrams and you have all of this added structure and ceremony but they're all there for a reason. There's a specific communication reason why you need to do a blueprint because somebody else is actually going to build this and they need to know precisely what you want. To me, I think that a lot of times what goes wrong in ceremony in software projects is you do all of these things for no real reason, just because somebody thinks that you should. If you start thinking about the communication needs of the documentation you're producing, of the diagrams you're writing, of the planning documents you're creating, then you have a much better chance of doing the right amount of stuff and not spending time on communication artifacts that will never get used. BETSY: Right, because communication artifacts need to be about communication first and foremost. The right level of communication is very dependent on team and I'm not just talking about scale here when I talk about that. A team that skews more toward junior developers who want and need a lot of guidance is going to require a more intense planning process, more detailed ticket breakdowns, more implementation guidelines in those tickets, than a team that is largely composed of ornery senior developers. Then the correct architecture communications artifacts are going to be more a lot of conversations where you're building consensus because your role as an architect in that position isn't telling people what to do, especially if those are people who actually know a little bit more about the space you're working in. Then you are as the person is keeping everyone coordinated, your role is making sure that everyone is on the same page about what is going to be done in a macro level at why, at how that serves the business, at how that fits into the broader whole. In that context, I think that being a little lower documentation, a little more emphasis on face-to-face or video chat conversations makes more sense than developing a huge communication artifact because there's a lot of nuance in, "Yes, I understand that you would prefer this way for theoretical purposes but we can't do it this way because X other architectural constraint that you didn't know about because you're not working holistically on the entire system." That kind of thing works much better when you're actually talking to a person, than when you're just delivering this directive from on high. NOEL: Right, you have this back and forth between the person who has the grand vision: the director or the set designer and the people who have to carry out individual pieces of it. BETSY: Right. NOEL: Actors for example. You might have an actor wondering why they need to be in a particular place in a particular time, which might be the director or the set designer's vision but then you also might have the actor saying like, "I can't move that quickly without injuring myself." Because he's going to go both top down and bottom up. BETSY: And sometimes, the actor is going to be saying that, not only because they can't move that quickly, which is a thing you need to respect but because for some reason, their gut is telling them, "No, this is wrong. This doesn't work." Then the fruitful conversation you need to have with that actor is why they're feeling that. Maybe, the movement feels very inorganic to them but because it serves a greater need, they need to keep on doing it and just deal with it but maybe, they are having a piece of intuition that needs to be brought up and will actually serve the play really well after it's been brought up and maybe they shouldn't actually move in that way and you can't know until you've talked to them. NOEL: Yes. That's interesting. I think that's a way of looking at it that I hadn't really thought about before, where you have in the software world, you have people whose job it is to sort of advocate for the work that they're currently doing and people whose job it is to advocate for the greater whole and those are going to be in tension sometimes but they could be in tension either way. They could happen in both cases, like the clients can advocate for the client wants, the database developer is going to advocate for the needs of the database. I'm going to advocate for... probably.. the joke didn't come fast enough. But that's the sign of a healthy team, though, or at least it can be, that everyone feels like they can advocate for their piece and there's a mechanism for having all of those individual perspectives merge with the global perspective to produce something better. BETSY: I think the difference there is the difference between, "Can advocate for their piece," and, "Must advocate for their piece." I see you're saying about, "It can be unhealthy," and I think that that happens when people get so desperate and they feel like their voice isn't going to be heard unless they dig in their heels about their one specific piece and that is very destructive. But if they can feel confident and safe that when they say, "This doesn't feel good to me. Why are we doing things this way?" It's going to be taken as them sending up the signal from the line and we're going to have a conversation now because everyone's perspective is valuable, then that's a super productive conflict. NOEL: I agree. You have that tradeoff between the top level and the bottom level and sometimes, in the theater world or sometimes in the software world, that gets framed as a distinction between purity and reality. How do you approach that? How does your set designer experience help you approach that? BETSY: Right. This is actually something where my theater training has served me well throughout my career as a software engineer, rather than just as I worked as an architect. One of the things that when I was being formally trained in theater, our professors kept on emphasizing to us is that your role isn't to make art. Your role is to tell the story. If something doesn't serve telling the story or something doesn't serve the craft of getting what is going on with these characters in this place, in this time across as effectively as possible, then you're going off on a piece of artistic nonsense and you should probably not do that because it's you being pretentious, rather than doing your job, which is telling the story. The audience can in fact pick up on these things, whether you have a bunch of pretentious artistic stuff in the way. One of the things, when I was talking at this topic with my co-founder, Jennifer actually that she brought up was that until I had explained this metaphor to her, she had never quite understood why she likes the scenery at her local repertory theater a lot more than she had like the scenery that the college productions she'd seen at MIT had done because the college productions at MIT had typically been better budgets and had been much flashier pieces of scenery. But they were flashy pieces of scenery and that was the problem. They were MIT theater nerds trying to develop interesting pieces of engineering, rather than people trying to do things that might be incidentally clever but existed in the service of the story. NOEL: I would imagine you get some unique kind of theater nerds at MIT theater productions. BETSY: Oh, my God. Yeah, right. NOEL: As software developers, there's always that sort of tension of like, "Do we try the new thing? Do we do this clever, clean code trick? Do we try to make this code as concise as possible?" All of these decisions that don't necessarily serve the end product but served a lot of show how clever we are to other developers. BETSY: Right. Some of that's honestly healthy, I think. You need to keep up with the field and to some extent, you can take this much too far very fast. Making choices that let you grow as a software developer serves the product indirectly because it means that later on, you have a larger tool kit with which to address product problems. But fundamentally, your role to build the product is to fulfill whatever needs your customers or clients have sought you out to fulfill and technical choices that don't contribute to that aren't. NOEL: Yeah, we have that tension all the time here, where our clients generally are uninterested in our technical choices. We try to keep them in things that have rich infrastructures but we need to move ourselves forward and our technical skills forward to protect against the next thing. BETSY: If you're setting the client up with the best of yesterday's technologies, then you're not actually serving them but its a tension. NOEL: Well, Betsy, I'm really glad that I finally got a chance to talk to you about this. I have been looking forward to this for a while. Can you tell people where they can reach you online? BETSY: Yeah. I can be found on the internet at @BetsyTheMuffin on Twitter and at BetsyHaibel.com. The company I just co-founded is Cohere: WeCohere.com. You can sign up for a newsletter there. I recommend it. There's a lot of my writing as well as my co-founders there. NOEL: Great. Thank you very much for being on the show. Tech Done Right is a production of Table XI and it's hosted by me, Noel Rappin. I'm at @NoelRap on Twitter and Table XI at @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter at @Tech_Done_Right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to story brands. Find us at TableXI.com where you can learn more about working with us or working for us. We still do have job listings open as I record this. We'll be back in a couple of weeks with the next episode of Tech Done Right.