Maintaining an Opinionated Engineering Culture at Heroku with Wes Beary

[00:00:00] Welcome to the Convergence podcast. I'm your host, Ashok Sivanand.

[00:00:05] Cool, ask me sometimes like how did you cut your teeth? Like how did you form those opinions?

[00:00:09] How did you get to understanding what a good API is and my answer was like,

[00:00:13] well, you just like, you consume a bunch of them. You write a bunch of clients against other people's

[00:00:17] APIs. You see what you like and you don't like. On this show, we'll deconstruct the best practices,

[00:00:23] principles, and the underlying philosophies behind the most engaged product teams who ship

[00:00:28] the most successful products.

[00:00:36] This is what teams are made of. Welcome back, folks. On this episode, I'm joined by Wesley Berry from

[00:00:43] Anchor.dev. Wes leads up the Engineering at Anchor who provides an encryption as a service.

[00:00:50] This is particularly useful for engineering teams that don't necessarily have a dedicated

[00:00:56] security and encryption team or service. And this way, all the engineers don't have to do the

[00:01:02] same work required to encrypt your application. And instead can use their SDKs and APIs.

[00:01:08] And ultimately spend way more time building features that delight your customers and

[00:01:13] differentiate your business. Wes also spent 11 years at Heroku. Heroku is a extremely developer

[00:01:21] friendly platform as a service that makes it super easy to deploy and maintain your applications

[00:01:27] in the cloud. And ended up getting acquired by Salesforce. If you talk to engineers about Heroku,

[00:01:35] the folks who have gotten to use the platform will tell you that it's extremely friendly and very

[00:01:40] popular amongst developers for that reason. And some may even tell you about the strong

[00:01:45] engineering culture amongst their team. While at Heroku, Wes worked on their CLI or command

[00:01:52] line interface, he designed their first public API and also worked on a role directly for the

[00:01:59] chief of staff where he was accountable for fostering and maintaining their engineering culture

[00:02:04] as the team grew. So you can imagine I was super excited to talk about building the light full

[00:02:10] developer experiences as well as fostering a culture amongst your engineers and maintaining

[00:02:16] that culture as your team grows. So we get to hear a lot about the principles and some of the

[00:02:23] tips and tricks and techniques that they use there to do both. Some of you Ruby developers may

[00:02:28] also be familiar with Wes because he started fog, which made a really easy single API to interface

[00:02:37] between various clouds whether it be Rackspace, AWS, Google Cloud and so forth. And for those

[00:02:44] of you who are particularly interested in building the light full developer experiences,

[00:02:49] make sure to also go back and check out our episodes with Kenneth Outranberg that we launched

[00:02:53] towards the end of June and early July of 2024 where we get to hear from Kenneth about some of

[00:02:59] the work that he did at Microsoft and Stripe in building really great, surprisingly the light full

[00:03:05] developer experiences as he calls it. Subscribe to the podcast to get future episodes as soon as

[00:03:10] you're published. If you find this helpful, give the podcast a five-star rating on your podcast app

[00:03:15] or hit that like button on YouTube. Well back to the episode now, here is Wes.

[00:03:28] I've been really looking forward to having you on the show and having this conversation

[00:03:31] welcome. Thanks. I'm glad to be here. I'm looking forward to it.

[00:03:37] And so give us a little bit of a backstory of how you got into this space and in your current role.

[00:03:44] Sure. I mean, I've bounced all over the place in some ways. I started actually like really

[00:03:50] wanting to go into game development of all things. There was a lot of like revelations right around

[00:03:54] that time of just like how bad that was culturally. And some ways figured it wasn't for me

[00:04:00] ended up moving more towards sort of like web development and stuff initially. And then

[00:04:03] moving towards infrastructure. And even though I've jumped around a lot, I think a three line for a

[00:04:08] lot of it has been looking at things that are like interesting but painful. I guess and trying to

[00:04:15] like smooth off some of those sharp edges and make it more accessible and really, you know,

[00:04:19] ultimately a lot of what I've tried to do is like empower people to be able to do more and better

[00:04:25] and so in the early days a lot of that actually was in the open source space right as AWS became

[00:04:31] a thing. Like, cloud wasn't a thing prior to that and suddenly cloud was a thing and it turns out

[00:04:35] that the barrier to entry was not small especially initially like nobody knew what it was or

[00:04:40] what to do with it exactly. And so like it felt like a big leap to get to the point of even being

[00:04:46] able to like spin up a server and do some basic stuff all these things that we take for granted now but at

[00:04:51] time it was so new that you know like the learning curve felt really steep and so those are one

[00:04:56] of my first phrase and two a lot of this is basically like how do we make it so that cloud stuff

[00:05:00] is really accessible that it's very easy that you can pick it up and just run with it.

[00:05:04] Partly I think it's just like fun and interesting to do that and partly I think it's kind of like

[00:05:08] the I think it's like fine then maybe has this sort of idea that like if you really want to learn

[00:05:12] something, you should teach it. I think there's something there too of like you know I want to

[00:05:16] learn cloud and so guess what like by trying to build out this like nice interface that made it

[00:05:20] accessible it made me have to understand it on a much deeper level in order to get to that point like I

[00:05:26] couldn't just present an interface on top of something I barely understood and have it be coherent.

[00:05:30] And what we were working on when you were calling making cloud easy, I was at this small startup

[00:05:35] where we were trying to make something to help people write more basically so like provided prompts

[00:05:40] and stuff and helped them to integrate with a bunch of different APIs to post it to whether you're on

[00:05:49] whatever different blogging platforms that were at the time I don't even remember all of them.

[00:05:54] But that that was actually formative in some ways too and that it made me have to actually do

[00:05:58] integrations across a bunch of different APIs and people ask me sometimes like how did you cut your

[00:06:03] teeth like how did you form those opinions, how did you get to like understanding what a good

[00:06:06] API is and my answer was like well you just like you consume a bunch of them you write a bunch of

[00:06:11] clients against other people's APIs you see what you like and you don't like because at the end of the

[00:06:16] like APIs are very slow moving they're the take a long time to build it's very difficult to change

[00:06:21] them after the fact so like you're not going to get that many swings at like a green field from scratch

[00:06:26] API in your career and so instead of doing that I think it's really valuable to say

[00:06:32] you know how can I build up my chops and get a lot more experience a lot faster and yeah

[00:06:37] the sort of consumption and building client side of that feels to me like a much more

[00:06:41] tentable way to very quickly build up experience so the same thing happened in the cloud space I

[00:06:45] did it to be a same image and but then I did rack space and then I did open sack again I did like you

[00:06:51] know I don't know you I think there's like 30 or 40 adapters that are all built on top of

[00:06:55] that stuff that I started with you know like I didn't end up building all of them that's one of

[00:06:58] the nice things about open source but like it exposed me again to a ton of different APIs with

[00:07:02] then I could say oh I really like this part of what they did here and like oh that's really strange

[00:07:06] like is that strange good or is that strange bad like how do I actually feel about this and so then

[00:07:11] you know coming out of it you have more of an intuition you know like the tricky part with intuition

[00:07:15] sometimes is it can be hard to actually like explain to someone why it ought to be that way versus just like

[00:07:22] hey I've done this a few times and like that that ends up sucking like here's a particular way

[00:07:27] that it ends up sucking I couldn't tell you what the first principle is that like leads to that

[00:07:31] necessarily yet I haven't figured that out yet that's another thing that I really enjoyed is just like

[00:07:35] taking ideas from seemingly really disparate places and thinking about reapplying them in some

[00:07:42] way shape or form to whatever I'm doing, whatever the task at hand is. It's not surprising when you say

[00:07:50] interesting but challenging problems and also wanting to empower others that in the technical realm

[00:07:56] API design is one of the places that you will very much end up at and I have worked in mobile

[00:08:04] where there would be executives that hadn't necessarily understood the nuances of customer design

[00:08:12] user experience design and say hey I use mobile apps all the time so I'm going to have a really

[00:08:18] strong opinion on the UI of this mobile app and then as APIs became more popular alongside mobile

[00:08:26] we started to see technical leaders doing the same thing of I consume APIs all the time I know how

[00:08:31] to do this I don't need to talk to anyone and so since you've been really in the thick of this

[00:08:36] I'm curious to know what are some things that maybe it's not good and bad to describe

[00:08:42] your API design but what are some things that you really look for either in terms of

[00:08:48] tactics or in terms of process or discipline around feeling good about putting out an API

[00:08:53] design that's that you feel confident about. I really really try to avoid exceptions

[00:08:58] I'd like to be able to basically give you a document that describes five or ten rules of

[00:09:04] thumb of how you can think about it to help you have a mental model of the way that the API

[00:09:08] more or less works and then ideally stick to those throughout the entire API anytime I'm

[00:09:14] working on something and we're going to add this new resource that didn't exist before

[00:09:18] and this resources mostly going to work like all of the other resources except for

[00:09:23] this particular thing which is going to be completely different some of it comes back to this

[00:09:27] idea of empowerment and not only do you get done what you're trying to get done but you're a little

[00:09:31] bit more capable than you were before you got that interaction right so like I'm building up your

[00:09:36] capability over time it isn't just you now can do this one thing but you can do this one thing

[00:09:40] and you're better equipped to go on to do the thing after that if I learn part of the API like

[00:09:45] one resource I understand how it works I come to the next one and there's an exception not only do

[00:09:49] I like have a harder time learning that new piece but it also puts me in a place of like

[00:09:54] wait a second did I even understand the first piece right how do I make it so that you use my

[00:10:01] AWS library in order to be able to do some AWS stuff but you also understand a little bit

[00:10:05] better like how cloud works and how you would interact with clouds and that sets you up so that if

[00:10:09] you want to then go use open stack or rap space or whatever yeah and that's certainly a principle

[00:10:16] I think that comes from game design as well right of yeah sort of the gradual real and it's like the

[00:10:21] tutorial at the beginning of a video game or something that's like I don't expect that you just

[00:10:24] say like here is a boss or something like good luck it's like oh no like I learned this one

[00:10:30] weapon and then I got this new ability and then there was a level where I just use that ability

[00:10:35] until I became competent and comfortable with it and then I got the next one and you know like

[00:10:39] yeah there's definitely like more of a building in a sense of progression I got so as opposed to

[00:10:43] just a sense of this sort of one-off did a task finish the task did a task finish the task you know

[00:10:50] and then the other piece I think I heard was having a uniformity and consistency around some of

[00:10:56] the underlying primitives and principles that are not just for that API but across the set of

[00:11:02] APIs and that developer experience my hearing that part right yeah you know goes back to this sort of

[00:11:07] idea of knowledge transfer if you learned something about how a cloud server works in AWS hopefully it teaches

[00:11:12] you at least a little bit about how a cloud server works in GCP or you know Azure or whatever that might be

[00:11:19] granted there are discrepancies among them but there's also a lot that's in common there are

[00:11:24] sharp edges that come out of making too many assumptions about how similar they are but

[00:11:29] I think there's a lot of value and you know providing some of that transfer or giving you some

[00:11:33] leg out basically to not have to start from scratch every time. I don't know if you're familiar with

[00:11:38] how the AI infrastructure company grock grock with the queue they their API almost mimics the

[00:11:47] Open AI API and so when I was transitioning some of my apps to try some of the different models

[00:11:56] that grock makes available versus versus the chat chip ET models it was super easy right

[00:12:03] to change the code it's like more configuration than rewriting any code and do you have an opinion on

[00:12:10] that in terms of how it falls into that knowledge transfer there. I do it's a somewhat complicated one

[00:12:18] I guess so I don't have direct experience with grock but I think there are some parallels actually to

[00:12:23] again in the cloud space where a lot of this experience from me comes from there are ton of providers

[00:12:28] that ended up providing what they call at least and S3 compatible storage layer and it gets

[00:12:40] storage layer except for they don't actually implement these four features and this one other

[00:12:45] part doesn't actually work the same way that S3 does and you're like okay so what is like S3 compatible

[00:12:50] mean then it means that the API is 90% the same or something and you know it's always lagging too

[00:12:56] it's not like S3 compatible as of you know Q2 2023 it just says S3 compatible and you're like okay

[00:13:04] but they just shipped a new feature do you have that new feature yet well obviously not we haven't had time

[00:13:07] to we ever have that new feature well you know TBD right so you know there is that value of transfer

[00:13:16] I'm more DPS I guess in terms of like I don't know it's the same thing I guess I was saying with

[00:13:21] like if you have like this notion of a server in GCP versus you know AWS like there are a bunch

[00:13:29] of caveats or like it's it's imperfect but in those cases at least like for better or worse like

[00:13:35] what I did was kind of sort of like an ORM I don't know if you're familiar with that like an object

[00:13:39] relation a little mapper it's like a thing from development we're basically like you have

[00:13:44] usually it's more for like a database and so like you have the database and then you have a thing

[00:13:48] that maps from the table of cats or whatever to a cat object right so that's the object relation

[00:13:54] mapper regardless of which database is underneath the cover so we can have the same thing that

[00:13:58] like reads cats out right and you get a cat object regardless of what database it came from so that's

[00:14:05] that felt I guess a little bit more tentable to me where it wasn't trying to have the compatibility

[00:14:11] at the API level like let each provider have their own API we'll do that at our layer where

[00:14:17] then we have more control over it and we can like make those tweaks and things and

[00:14:22] fiddle with things to try to make them more similar where we can in order to maybe

[00:14:27] call out and and make obvious to you where there are different and maybe you need to care about that

[00:14:31] right so compatibility yes whether or not it should happen at the API level I guess is a harder

[00:14:38] cell for me unless you're actually operating the same software trying to provide the same API

[00:14:43] interface to it seems like it's a piece proposition yeah there's obviously the benefit of

[00:14:50] very minimal switching costs and then I hear a lot of the risks and trade-offs associated

[00:14:54] when you're thinking kind of beyond the switching phase if you're just trying to get user adoption

[00:14:59] which I think is probably what Grop is doing probably what the S3 compatible folks were doing like

[00:15:04] yeah that initial transfer is easy it's more when you get into the I actually want this

[00:15:09] advanced feature oh it's not there I would feel much more comfortable if there was like an open

[00:15:13] standard or something about what cloud storage provider should do and a bunch of people implemented

[00:15:18] that standard that seems like a much more straightforward way to have a shared understanding of

[00:15:24] what that actually means to have a clear definition of what it means and to like not have

[00:15:29] weird deviation all over the place here in it so I want to make sure that the the naming of it

[00:15:35] is authentic so there's like lesser surprises we want the surprise to be delightful versus disappointing

[00:15:41] and then having mindfulness around the risks of the exceptions that arise as well as how much

[00:15:50] strange you're applying to your future road maps in terms of how you like continually

[00:15:55] tethered now to S3's road map or at some point can you start to innovate on your own and

[00:16:01] when adverse is being handcuffed by it when you mentioned the ORM something that jumped out of me was

[00:16:08] when I was at pivotal the cloud foundry was a platform as a service that could sit on multiple

[00:16:14] infrastructures whether it was your data center or the major cloud providers and we had a service

[00:16:19] broker that kind of worked in a similar way I think in terms of providing compatibility to those

[00:16:24] features and that was of course cloud foundry came out much later than haroku and so

[00:16:31] maybe let's zoom out a little bit and care a little bit more about your time at haroku

[00:16:37] and let's start with your opinion in terms of like the importance of platform as a service

[00:16:42] and multiple infrastructures and we'll start there coming into haroku I'd already been doing

[00:16:49] the cloud thing for a little while so you know to my benefit in terms of open source and everything

[00:16:54] else like it was a pretty might maybe might easiest interview basically have lied over to haroku

[00:16:59] and they said oh yeah you wrote fog which is the cloud library that that i'd written you know like

[00:17:04] we actually use it for basically all of our infrastructure management stuff like

[00:17:07] we've seen the code we use the code like when can you start right so that being said I was also

[00:17:14] like I've been doing basically nothing but fog for the last two or three years I'm ready for a change

[00:17:18] and so coming in initially actually like pitched and got accepted to work on the CLI ever

[00:17:23] ok so I think the CLI for them was pretty well known for being a good developer experience overall

[00:17:29] but I you know being I guess as into the weeds and some of the other things that we were talking

[00:17:35] about before like it bugs me that there were some inconsistencies and some other things that

[00:17:40] just felt like they could be a bit better um and some of that just comes from the nature of

[00:17:45] small startups and shared ownership and other things I mean it's the same issue that I've seen with

[00:17:50] API is in a lot of cases where there wasn't a person that necessarily owned it and so therefore

[00:17:56] when a team needed to add a feature to it they came in and added a feature but they'd may or may not

[00:18:02] have been totally consistent with what was there before because they you know we're pretty focused

[00:18:05] on just getting done what they needed to get done and it's hard to keep track of all you know

[00:18:09] the broad scope of history and whatever else so a lot of convenience that sat right next to each other

[00:18:14] didn't always look exactly the same they felt a little bit different you know like there were

[00:18:19] just discrepancies there were you know you know getting to a really narrow clear example

[00:18:25] in some places you would say like create as the thing to generate a new object and in some places

[00:18:32] you would say add and you know like that's just a small one for me where it's sort of like okay

[00:18:36] like we don't need to different verbs unless they're to distinct concepts like if these should be

[00:18:44] something that we want the user to think about in the same way like let's just use the same word

[00:18:48] we actually wrote like a style guide for the CLI so you know people I think mostly thinking

[00:18:53] about style guys in terms of I don't know like a magazine or newspaper you know a website right

[00:18:57] like this is how things should be styled this is what titles should look like this is what

[00:19:01] headers should look like this is what a quote should look like something like that so I'm trying

[00:19:04] to do the same thing with CLI where we said you know if you're looking at help like this is how

[00:19:08] we want to organize and structure the help the output from commands should look kind of like this

[00:19:13] so if it's outputting this sort of thing like this is what we would expect and so again just

[00:19:17] trying to provide sort of a template that people could look at and follow along so that even if it was

[00:19:23] getting back to the world of like so and so came in and implemented this because they needed for

[00:19:27] a feature it would be less likely to be way out there it would be more likely to be more similar

[00:19:33] to what we were doing elsewhere um I ended up after that moving on to the API team where we had

[00:19:38] the same problem the API hadn't really been owned by anyone per site it was really intended for

[00:19:44] internal use and almost all of it had been developed actually to support the CLI so

[00:19:49] just like people came into add something to CLI because they needed a feature they would at the same time

[00:19:54] add the you know correspondence API in point so that the CLI could get the access to the stuff

[00:19:59] it needed and then they would go back to whatever else was their primary responsibility and

[00:20:05] hodge pods of different styles and different preferences and opinions and other things and so

[00:20:10] a lot of the work of bringing the heroicu API to the public what we called the V3 if the I was

[00:20:16] how do we sort of reconcile that and try to move off the edges and make it more consistent

[00:20:21] from one resource to another so that people could have an easier time knowing what to expect and that

[00:20:25] then hopefully moving forward um people will also be easier have an easier time developing the next

[00:20:32] end point and the one after that because they won't have to figure all that stuff up from scratch

[00:20:36] or whatever there'll be plenty for them to draw on and to work forward from heroku of course

[00:20:41] extremely successful got acquired by Salesforce having been on the inside what are maybe one

[00:20:47] of the couple of things that you can think of that led to so much popularity and adoption of the

[00:20:52] platform. What drew me to it in some ways was you know what I talked about in terms of like really

[00:20:57] empowering people to have access to these powerful underlying things or in some ways like I was doing

[00:21:03] that and continuing to sort of like move up the stack in terms of where I was doing it at in order

[00:21:08] basically be able to reach more people and have a bigger impact so when I was doing all the

[00:21:12] open source stuff that was great obviously Haroku was using that you know as their underpinning

[00:21:16] stuff to do infrastructure but like the number of people that were ever going to get to the point

[00:21:22] to reaching that deep death and to do stuff is like pretty limited versus moving up to the platform level

[00:21:27] it's more like the utility level on some ways I have a web application that I need to run just like

[00:21:33] I have lights in a computer that I need to run. I want somebody to give me electricity. I don't

[00:21:37] really care too much where that electricity comes from. I want to pay somebody in received electricity.

[00:21:43] The platform is a service model as much closer to that. I have a web application. I want it to run

[00:21:47] in the cloud. I want the you know the cost to be understandable. I want to be easy to say

[00:21:53] out of database if I need to or whatever without having to provision a bunch of new servers and figure out a

[00:21:57] bunch of security group rules and all of this other stuff to even connect the machines together

[00:22:02] and so on and so forth. So the idea with a lot of the Haroku stuff was you know like basically

[00:22:07] you give us the code and we take care of the underpinning stuff to get it up and running. Right?

[00:22:12] You need to scale, you just tell us how much scale you need we give it to you. It worked really

[00:22:16] well made it much more accessible for a lot of people but the challenge on the other side I think

[00:22:21] sometimes is that it ended up in some ways being so magical that people didn't value it. There's two

[00:22:27] groups of people I guess that you interacted with and the early days it was very easy because like

[00:22:31] people had the experience of trying to do the cloud stuff themselves and so if you set that next

[00:22:35] to a Roku you're like well obviously I'm going to choose Roku because I don't want to have to deal

[00:22:38] with all of that stuff unless it's like core to my business. I want to be able to focus on whatever it is

[00:22:42] that I want to focus on but eventually like you know I guess maybe one of the pains of success or something

[00:22:47] like people started to be that they had never had any experience but they were okay one and so they

[00:22:52] didn't understand how hard and painful it was to do themselves and because they didn't understand that

[00:22:58] it started to break down how much the Anderson with the value proposition even was right they would say

[00:23:03] okay sure like you're hosting my side or whatever but like I could just do that on Amazon and it would be

[00:23:08] cheaper. Well yeah I mean we're re-selling Amazon so we can't be cheaper than them that's like a hard

[00:23:12] limit on what we're doing but we think that we're providing quite a lot above them that makes it

[00:23:18] worth this price differential. I don't want to force you to be aware of all those details just for

[00:23:24] it could be aware of them because that is not a good experience but at the same time like if I

[00:23:29] can educate you about those details it better helps you to appreciate what I'm doing hopefully

[00:23:33] but it also helps you to be again sort of more empowered so they're coming out of that if you do

[00:23:38] need to switch to a different thing and you do need to do it yourself. You understand what that would mean

[00:23:42] you know you have the vocabulary you have a sense of like all the moving pieces even if you haven't

[00:23:47] had to manipulate them yourself you have a sense of like what is actually going on I think there was

[00:23:52] you know that that downside of time to her who were sort of like get push-for-roke master

[00:23:57] your site comes up turns out actually underneath the covers a hell of a lot of stuff happened

[00:24:01] to make that work right but you just weren't aware of that and I wonder sometimes if they would be

[00:24:07] better served with making some of that clear right educating these are a little bit more about like

[00:24:11] what are the underpinning things how does that work like you know people are just interested in that

[00:24:15] but also you know helps them to understand the value that they're seeing.

[00:24:24] Fosturing and engage product organization and aligning them with the principles around lean

[00:24:30] human center design and agile will more than likely lead to successful business outcomes for your

[00:24:37] organization but getting started or getting unblocked can be hard this podcast is brought to you

[00:24:47] build amazing product teams and ship products in artificial intelligence cloud web and mobile.

[00:24:56] listeners to the podcast can head on over to integral.io slash convergence and get a free

[00:25:03] product success lab during the session the integral team will facilitate a problem solving exercise

[00:25:09] that gives you clarity and confidence to solve a product design or engineering problem that's

[00:25:16] a girl dotio slash convergence now back to the show.

[00:25:27] You touched on something that I wonder about way more than I maybe should and I want to know

[00:25:31] your opinion of there are infrastructure companies and then there's platform companies and

[00:25:37] and I find that when I start working with a startup or with the team that the interplay or

[00:25:44] interchanging of those two terms of infrastructure and platform can lead to a bunch of

[00:25:50] downstream issues in terms of casting the vision to the team and helping everyone know how which

[00:25:55] way we're going and how can I most be helpful. I'm curious if you have come across any sort of

[00:26:01] definition or checklist to kind of determine whether hey are we building infrastructure or

[00:26:05] building a platform. It seems like you know every startup that gets to a certain scale

[00:26:09] suddenly they have an internal platform team for it that is in charge of whatever platform

[00:26:14] means to them maybe you guys back to what I was saying in terms of like the sort of utility model

[00:26:18] like at the end of the day I think ideally what you have is a situation where most

[00:26:22] if it'll not all of your development team can focus on doing whatever it is that is of value

[00:26:26] to your business and not necessarily have to spend a lot of time and effort keeping the

[00:26:30] lights on right and so what platform means to you is going to vary depending on what kind of business

[00:26:37] you're in. So if you're running like I don't know relatively straightforward

[00:26:43] web-based e-commerce site or something right like you probably don't care in a lot of cases

[00:26:48] about the nitty-gritty of the infrastructure that's running that right like you're going to

[00:26:52] care a lot more about I don't know recommendations and other things that are at a higher level

[00:26:57] and it makes sense to focus there and so maybe that platform is actually a quite high level

[00:27:01] of abstraction but for something like a Roku obviously like we were providing a platform

[00:27:05] but like we couldn't have anywhere near that level of abstraction internally because we actually

[00:27:10] needed to care about all those details and needed to get into the nitty-gritty so like

[00:27:15] you know I think that's it just depends basically a lot on who your customer is and so if you have

[00:27:20] an internal platform team the customer is the other developers and it's sort of like what is the

[00:27:24] level of abstraction they need that will allow them to do what they need to do without being

[00:27:31] you know without hiding the details that matter to them I guess right like that's that's

[00:27:36] but that's the tricky part like you know we even talked about with Horoku like

[00:27:39] I would argue in some cases it was probably hiding details that didn't matter to you like maybe

[00:27:44] you don't need to make those choices but not even knowing or understanding them I think you know

[00:27:48] it was a limitation of times so like maybe that was too far for some people but also they were

[00:27:52] trying to hit like this really broad audience so it's hard to like do the right level setting

[00:27:56] versus internally it's a lot easier I think words like I know you know our 50 developers are

[00:28:01] something of this company like I have a pretty strong sense of exactly what they need

[00:28:04] which levers and knobs they need to be able to you know twittle and flipper whatever

[00:28:09] in order to get done what they need to get done without spending a lot of time getting into

[00:28:14] the weeks because the last thing you want is like well we have this development process where

[00:28:19] every single developer actually has to do a bunch of basically the same exact work as each other

[00:28:23] just because reasons you know like whoa what is the value that's really being provided by

[00:28:28] for instance every developer maintaining their own testing and staging environment in the cloud

[00:28:34] or something right like is that really providing a lot of value to all of us like are we

[00:28:37] learning a lot from that or we selling a lot because of that like probably not right so then those

[00:28:41] are the places where it sort of like we should do something internally to provide a better

[00:28:46] developer experience where you know one person or a small group of people takes on owning that

[00:28:53] and in a sense like sort of productizing it like if we need to be able to spend a development

[00:28:56] environments somebody should just own a process that like spends up development environments

[00:29:00] and we can maintain them and keep them consistent whatever and it's just like

[00:29:05] developed in environments as a service right and like that makes way more sense in terms of just

[00:29:10] you know specialization of labor everybody being able to focus on what they really care about

[00:29:14] you know doing the best you can with each of the pieces because it has its own focus and

[00:29:18] own ownership and that sort of thing. I've seen this kind of be a risky slippery slope

[00:29:24] where something that starts out with the intent of being an enabler can then become a gatekeeper

[00:29:30] and leave it or not I've seen it at enterprises where it's easier to believe but also

[00:29:34] it's smaller companies that are trying to be intentional and I'm curious if there's like an

[00:29:39] underlying advice that you have for delivery leaders or engineering leaders around

[00:29:44] having a naablers continue to be a naablers and mitigating that risk of them slipping into

[00:29:49] becoming gatekeepers that actually slow us down the long term. It's something that I

[00:30:00] companies that I've seen is that an internal solution is developed and then mandated.

[00:30:05] It's not a oh yeah of course I'm going to use the internal like you know developer

[00:30:11] environment as a service thing because it's so much easier and it gives me exactly what I want

[00:30:15] like why would I possibly roll my own. If that's the situation I think you're much more like

[00:30:18] like you know in the situation where it will probably end up being pretty good because like they

[00:30:24] liver die on whether or not there's internal adoption right like it you know if that's the

[00:30:28] you set it up and you basically say like your job is to try to you know productize and make

[00:30:32] this a thing that our internal developers care about and want to use if you can't do that then

[00:30:37] will just spend down the team we'll say that we didn't succeed we'll move on but instead yeah

[00:30:41] a lot of times it's sort of like well we rolled this thing out and now we're just going to mandate

[00:30:44] it and whether you intend to or not you end up in the situation where it's like well it's kind

[00:30:48] of shitty but we don't really have to fix it because everybody has to use it like you know

[00:30:53] like they were told that they have to use it so like I don't have to necessarily go to the

[00:30:58] trouble of making a great experience I don't have to necessarily compare it to what came before

[00:31:02] or like they have to use it so they have to use it so you get to this sort of like MVP that is not

[00:31:08] a great experience but technically works and then you yeah clean your hands of it and you walk away

[00:31:14] and you go back over to whatever else you were doing right versus it a goal really is to have this

[00:31:18] be something that people want to use or if they want to use it then adoption and whatever else

[00:31:23] and like enablement like we're done like you know people have been enabled because they want to use it

[00:31:27] it's giving them what they want right I think that's that feels like where that disconnect often happens

[00:31:32] so I don't know that that's always the case but that's what I've seen anyway yeah adoption is really

[00:31:37] easy to drive up if you mandate it right where yeah yeah we're going to get yelled at by your boss

[00:31:42] if you don't do it and so there's a few things that I think that maybe aren't given enough

[00:31:49] credit one of them is I clearly stated goal or problem that's being solved the second one is like

[00:31:55] one person or really small team that gets to make the decisions around how we're going to go out

[00:32:01] and achieve that goal solve that problem and then I think the third one which is maybe even the

[00:32:05] hardest to to apply or adopt is then we'll spin down the team if it doesn't work out because I think

[00:32:11] a lot of the reason that folks kind of continue on this way and double down is because of maybe

[00:32:16] some cost fallacy or yeah a cultural reason where spinning down a team is not quite that fluid and

[00:32:22] that ends up being for folks with the best intentions around being agile and nimble

[00:32:29] leading to sticking with things that they maybe all kind of sense doesn't make sense anymore

[00:32:35] but we're kind of pressuring through I know you've gotten to work a lot on the culture side

[00:32:40] of things on internal teams I don't want to dig into that but let's start maybe with this of

[00:32:44] around spinning down teams when something doesn't make sense how what's your advice about making

[00:32:51] that maybe a non-event or part of life or maybe some of the nuances that folks don't

[00:32:56] necessarily think about if they're jumping into it that you want to also caution them about

[00:33:01] sure I mean it's a bitter pill too swallow for sure I think I mean some of it I think

[00:33:08] and you know like the amount of times I've gotten to practice this I guess it's similar to the

[00:33:12] I think you don't get a lot of swings necessarily hopefully don't have a lot of swings in terms

[00:33:16] of like making teams that need to respond down but one of the things I think about a lot I

[00:33:21] think is really an exercise in framing like when you establish that cheat team you make

[00:33:28] their charter or whatever like what is their goal stated to be because there are ways to do that

[00:33:33] I think where even if ultimately the team is spun down it's not seen as a failure necessarily

[00:33:37] like the goal might actually be you know the charter might be basically like

[00:33:42] in effect like figure out if we can do this in a way that will be appealing to these or

[00:33:47] enough that they will do it instead of doing it themselves you know basically like

[00:33:53] our you know hypothesis basically is that by centralizing this and having a team do it

[00:33:58] we can do something that will take fewer total resources than it would if everybody had to do it

[00:34:02] individually and we'll have a better outcome that's where I have hypothesis so our goal is to

[00:34:07] basically test that hypothesis and find out if that is true or not right and so you can find out

[00:34:12] if that's true or not and succeed in having done that and still spend on the team at the end

[00:34:17] right because the goal wasn't necessarily to end up with the you know the the solution that we

[00:34:22] had was to build this team out and build a platform and so like that is successor not instead you're

[00:34:28] saying like our goal is actually to like learn whether or not this is true right and so

[00:34:33] that informs how you approach it but I think it informs how you walk away from it too like you

[00:34:38] can get to the end of that like I said and be like hey we tried a bunch of stuff when we learned

[00:34:41] that it's just not worth it like it would take way too much time and effort and like the amount

[00:34:45] of centralized stuff we would have to throw at it in order to maintain and keep that up is just

[00:34:51] not worth it versus the number of you know the number of developers we have right now or whatever

[00:34:54] like you know one hour for each of them per year is less than one full-time engineer for the year or

[00:35:01] thing so let's just leave it the way that it is right for now like maybe we'll revisit this decision and

[00:35:07] you know I highly recommend you know scheduling a revisit of decisions like that it's like

[00:35:11] this is where we're at now so we're gonna do this for the next six months or year or whatever but

[00:35:15] at that time like maybe let's you know drag or you know thesis that describes our hypothesis

[00:35:22] in what we learned and whatever else back out and see if anything's changed I think a lot of

[00:35:26] that sort of like framing thing and also like relating to what you're talking about a minute ago

[00:35:31] like this problem that can come up of what I've often heard called sort of like solution hearing instead

[00:35:36] of really being crisping clear on what is the problem that we're trying to solve and then giving

[00:35:42] some freedom to the people that actually need to do it to figure out how to do that right like

[00:35:47] there's these times where somebody comes in and says like oh I saw a company who saw this problem

[00:35:53] by creating an internal dev services as a platform thing so that's what you need to do.

[00:36:01] Strips a lot of autonomy makes it harder to learn things because you're not really trying to like

[00:36:05] figure out a new thing you're trying to emulate an existing thing which is not going to give you

[00:36:09] as many opportunities to innovate and explore and then you know at the end of the day like

[00:36:13] your judge is on whether or not you succeeded in delivering this emulated thing you're now tied to

[00:36:18] somebody else's roadmap among other things and like can you ever succeed in that context like

[00:36:22] maybe in some limited fashion but you know it doesn't feel like it's really setting up for success

[00:36:25] in the same way of like we think you're sure team to do dev tooling would be helpful.

[00:36:31] Here's our sense of like some of the things that would be indicators of success here are some

[00:36:35] of the things that were concerned about like let's give it a shot like we'll commit to it for

[00:36:40] the next two quarters and well revisit and see where we're at and decide if we want to

[00:36:46] reinvest there or we learn some stuff and that's not something we want to do right now or

[00:36:49] whatever but you know like creating the right scope and expectations and framing coming in

[00:36:54] and giving the right guidance basically so that people will be able to do that well hopefully

[00:36:59] and then you'll be able to judge whether or not it's succeeded I think that all feels like a more

[00:37:05] generative productive way to approach it I guess. Yeah I wish I had this super powers one

[00:37:10] that I'm consistently striving for of having both the conviction of whatever I'm working on

[00:37:17] being like something that is very purposeful and meaningful and worth solving while also having

[00:37:22] the curiosity of hate this might not be the right approach this might not be even the right problem

[00:37:27] and being able to sort of pivot away and that that is a hard balance for me and certainly

[00:37:35] has been a hard balance to kind of foster amongst the team as well and kind of brings me to this

[00:37:40] whole that you had at Heroku where you were you were in charge of culture in some way working

[00:37:48] for the the head of engineering and I might have butchered the the titles there specifically so

[00:37:54] tell me a little bit more about that role I think it's quite fascinating. I joined Heroku

[00:37:58] after the sales for acquisition but when we were still pretty small and operating pretty independently

[00:38:03] so I think when I came in we were around maybe 70 people and low and behold when you're at that

[00:38:09] size it's pretty easy to get involved in anything and everything you might want to planning for

[00:38:14] off-site for instance and I was like I'm actually kind of interested in like what that means

[00:38:18] and how we would do that and so you know it's low and behold I'm suddenly on like the offset

[00:38:23] committee or whatever rate and going to these meetings even though you know I'm otherwise an

[00:38:27] engineer in my day to day life with off-site there were some of that so like one of the big things

[00:38:31] that we ended up doing frequently was I would end up coordinating for us to do lightning talks

[00:38:36] or to have these sort of like breakout discussions where it's especially in the early days when

[00:38:40] there weren't that many of us like for those that aren't familiar with this kind of stuff like

[00:38:44] we could basically just have like a bunch of posted notes and all of us would get in a room

[00:38:48] basically for uh to kick off the afternoon or something you'd write up a bunch of posted notes

[00:38:54] of just like here's an interesting idea related to whatever we're doing these days that I would

[00:38:58] like to talk to other people about right you'd throw them all up on a board and then you'd basically

[00:39:02] say all right everybody you get like five votes just go around and put tally's on any of the

[00:39:06] topics that you're interested in uh then you grab the top uh sort of boat getters I guess and say all

[00:39:13] right this discussion is going to happen in that room this discussion is going to happen in that

[00:39:17] room like we'll see you guys in an hour you know this evolved over time in terms of my thoughts

[00:39:21] on offsights and things like that but really a lot of it at its core was you know what are the

[00:39:26] things that we can uniquely do when people have together because we were increasingly a remote

[00:39:30] organization so like together was uh you know the exception not the rule so if we're going to be

[00:39:36] together like what can we do then like I kind of would continue to push back against like let's just

[00:39:41] do presentations at these people if you're just trying to like transmit information like there's

[00:39:45] plenty of ways to do that remote or in person but like a lot of like getting people in a room

[00:39:50] and having a discussion and sharing knowledge like that is not going to happen remotely or

[00:39:54] not that is not going to happen but it's a way harder there's something to be said for

[00:39:59] especially um implicit knowledge so like tacit knowledge is sort of like I know this it's

[00:40:03] clear I can like write it down I can tell you directly like um implicit knowledge is sort of like

[00:40:08] those intuitions and stuff I was talking about with API is another thing I couldn't always put

[00:40:12] my finger on exactly why it was that I liked that API but I knew that I liked it or that I didn't

[00:40:16] like this other API like that that was more my implicit knowledge so it was really valuable then you know

[00:40:21] like we would get into a room and I'd be having a discussion with folks that were working on a

[00:40:25] new API right and they would say we're thinking about doing x, y, and z and I would say oh like

[00:40:31] I don't know about that have you considered this thing like I can't tell you exactly why but

[00:40:35] I've done things like that before and ended up being painful in these ways so like you know

[00:40:40] you do you like I'm not trying to tell you how to do your job or whatever but like

[00:40:44] here is some information that you wouldn't otherwise have that you should factor into that decision

[00:40:48] right um and that ended up being hugely valuable like one of the big things that came out of one of

[00:40:55] Dogwood but it came like the sort of like enterprise like spaces product so and the early days

[00:41:00] of America like um basically everybody was in a shared platform and then moving on into the Dogwood era

[00:41:09] we got into a place where basically each company or whatever could have their own private space

[00:41:15] like VPN basically that just had their instances on it that weren't in this broader public pool

[00:41:21] so a lot of that came out of one of those discussions of like different people that touched different

[00:41:25] pieces of the thing that might not otherwise have a conversation because they're not on the same

[00:41:29] team or whatever else said oh like we actually have this thing that we're not really using right now but

[00:41:34] it's like very possible that we could use it like all of it pieces aren't air we just aren't really

[00:41:39] using it yet and you know the other person saying oh that's interesting we also have these other

[00:41:43] pieces and oh we're hearing about this customer need and suddenly they're like hey I think there's like

[00:41:47] actually like a new product here like a new feature set that we hadn't really considered before

[00:41:52] like what would this take and so you know like coming out of that within I don't know a couple of weeks

[00:41:57] or something like this was a new major work stream and like a new product in one of our next

[00:42:01] huge feature launches right that I'm not sure what have happened if we hadn't had that like

[00:42:06] intermixing of people from different areas that were talking through this and you know I think

[00:42:11] there's just a lot of value too to that you know sort of like I have some hard one knowledge about

[00:42:15] this thing I know you aren't doing exactly the same thing but it's near enough that I

[00:42:18] all of us can guarantee that I'll be able to tell you something that will be interesting or

[00:42:21] you're just holding up. So having that sort of glue or shared context across is really

[00:42:29] important but it doesn't show up as an urgent priority necessarily right we're oftentimes looking

[00:42:34] back and saying oh man I wish I had told you about that I wish I had talked to you about this

[00:42:39] and so forth and it tends to be hard as much as like organizations get hierarchical

[00:42:45] and it tends to be hard for anyone person to hold all of that context and I'm curious to know

[00:42:51] given this role was way more on the important side I would say on that spectrum versus urgent

[00:42:58] how it was justified to have you kind of not working out whatever you were working on before

[00:43:05] or going forward if you were trying to convince someone to invest in a similar kind of role

[00:43:11] what you might want them to think about around prioritizing that sooner than later.

[00:43:18] Sure I mean maybe this again is like a may sound kind of strange or something but in terms

[00:43:25] of like borrowing from different areas to pull together like I would make a very similar argument

[00:43:29] I think to your argument that I made about like having an internal developer services platform

[00:43:36] is a service kind of thing right where with a lot of this stuff it's like I think we agree on

[00:43:41] some level that doing some of these sort of like cultural things is a value but do we think

[00:43:46] that we're going to get as much bang for our buck if we basically asked every individual manager

[00:43:52] or every individual team to do this versus having a centralized resource that is focused on

[00:43:57] and trying to do this better and the other thing too you know is like one of the things that comes

[00:44:02] in both of those contexts actually is like how much does it matter if there is deviation.

[00:44:07] If one team has this culture that is this way and this team has this other culture that's a very

[00:44:13] different way how much does it matter right and it depends like their aspects of the culture

[00:44:18] that should be open to the team to decide but there are other effects where coordination and knowledge

[00:44:25] transfer and other things just like don't happen or break down if there isn't some amount of

[00:44:30] shared practice and understanding of like how all those things flow so there's definitely a scale

[00:44:35] aspect to it so something that I've been thinking about as the notion of like in a lot of ways it

[00:44:41] feels like that sort of like shared implicit knowledge when you're small is just like something

[00:44:45] that you have like as you grow past a certain point it feels like that shared implicit knowledge

[00:44:51] is something that you do like you don't get it for free by virtue of like everybody's just close

[00:44:57] enough to each other that they're sort of rubbing up against each other as they're working on things

[00:45:00] and you just see things happening and you you know pick up a little bit from that you ask a question

[00:45:04] because you're like oh that's interesting that's how not how I would have done it could you tell me

[00:45:07] more about that oh okay well factor that in the next time I do something right like that stuff

[00:45:12] stops happening I get into what you were kind of mentioning get the silos you get people divided

[00:45:16] up not because they want to be necessarily but because you know like done bars number and all these

[00:45:22] things you know like you get to a certain scale and it's just like impossible to keep track of everything

[00:45:25] right and so you know the argument that I would make in really is that like by centralizing

[00:45:31] that function and having focus on it and trying to do some of those things in a consistent way

[00:45:35] across the organization we could do it in a way that was basically more bang for a buck than

[00:45:40] was happening otherwise similarly you know like with pushing it out to individual managers which

[00:45:46] is the counter argument that I've kind of heard in a lot of cases it's sort of like okay but

[00:45:50] like where on their priority list is that exactly like and in a lot of cases because of the

[00:45:56] incentives and stuff within the organization it was not very high on that list so it wasn't just

[00:46:00] that we were asking each individual manager to do it but that they didn't really have the capacity

[00:46:06] to do it right so it ended up that in a lot of cases it was just like falling off into the

[00:46:15] situation where things continue to just go as they have been they tend to start to deviate more and

[00:46:23] more afraid like you know this this team is kind of going deeper and deeper into their rabbit hole

[00:46:26] and they're going deeper and deeper into their rabbit hole and never the two show me right and

[00:46:31] again there are like aspects of the culture and stuff that should be more autonomous that should

[00:46:35] be free like I don't think you should dictate everything but there are some things where it's sort of like

[00:46:39] especially like hey we want to have more and better ways to break down those silos at least some

[00:46:43] time you know like we don't want to spend all of our time doing that that's not the right thing to do

[00:46:47] but we want to have like some understanding of like hey I actually would like to request a silo bus

[00:46:53] right now like what would that mean like how would we go about doing that how would you you know

[00:46:59] understand that that's a normal reasonable thing to do in the organization and that we encourage it

[00:47:04] right so there's a lot of value to you know having somebody that is organizing that that provides

[00:47:10] some structure and understanding about what it would do that there's a lot of value to like

[00:47:14] giving that a name so like I think it's maybe British petroleum calls that a peer assist

[00:47:19] and there's this expectation that like yeah peer assist um peer assist got it we as a team

[00:47:26] I think the example that I saw was like we're about to like put a new deep sea oil well in the

[00:47:31] Gulf of Mexico right uh we've never done this before we're trying to figure it out um and we know

[00:47:37] these other folks have done a deep sea well and kind of the Mediterranean Sea or something right

[00:47:43] um so we know that their experience isn't totally directly applicable to us but

[00:47:49] there's almost assured something we can learn from that number so then in that context basically

[00:47:53] the idea is like when we're doing our initial planning and stuff we actually just like invite a couple

[00:47:58] of members of that team to come and sit in on planning and participate directly to give us feedback

[00:48:04] to tell us like the gotchas that they ran into or to share ideas about what happened right

[00:48:08] to transfer that implicit knowledge and they you know have it built into the culture enough that

[00:48:12] it's sort of like you don't have to do anything crazy in terms of like getting permission from a

[00:48:18] bunch of different managers to sign off on those people being on loan you don't have to worry

[00:48:22] about like who's gonna pay for the budget for them to travel or whatever like all of those things

[00:48:26] are like figured out normal common things that just happen and so then you know when you get to a

[00:48:32] situation of like we're kicking off a new big project about something we haven't done before

[00:48:35] is there someone else around that's done it that we can identify yes okay well there's like a

[00:48:39] known existing process by which we bring those people in and we have them participate in this because

[00:48:44] we think that that will lead to better outcomes right and that's the sort of thing where it's like

[00:48:48] seems like it can be incredibly valuable but seems unlikely to just sort of like organically

[00:48:53] you know come up from one individual team like there are too many uh

[00:49:01] that need to happen it's like I was trying to I guess provide a menu of things that people could do

[00:49:08] that had been tested out that were valuable to a lot of teams I wasn't telling the had to do it

[00:49:15] that is like hey if you're in the situation that you need to drive consensus around a big

[00:49:21] important decision we did something called an RFC request for comment process it's based off of

[00:49:28] a similar idea from the iETF so it's this notion of like it's kind of this head you

[00:49:32] handed in some ways process but there's clear expectations of like I'm gonna come forth and

[00:49:36] I'm gonna say here is what I'm proposing who has feedback or thoughts or whatever else

[00:49:41] or any collect feedback and thoughts for a while you process and integrate all of that you do

[00:49:45] that a couple times and then you basically publish and say like here is what we have agreed

[00:49:49] is like the way that we're going to move forward on this everybody who wanted to had an opportunity

[00:49:53] to chime in we dare about to be clear about how we ultimately made the decision transparent about

[00:49:59] it right and now all of us feel pretty good about it and we get this artifact that we can refer

[00:50:03] back to in the future when we say why in the world do we do this again right isn't just like

[00:50:07] yet another skeleton then closet right everybody cares about this a little bit but no one

[00:50:12] person cares about enough to be the one to like step out and try to actually do something about it

[00:50:17] especially again incentives and stuff being what they are it's like I do care about that I really

[00:50:21] but I'm not gonna get rewarded if I do it and I will actually basically get punished because

[00:50:26] I'll be doing things that you know I could the time that I could otherwise spend on things that

[00:50:30] would reward me I'll be spending on this and so it just doesn't happen so yeah a lot of

[00:50:35] that is like look like somebody needs to be on the hook to do these things and I think

[00:50:40] having somebody focused on that role is great but you know it's similar to that like innovation

[00:50:45] everywhere thing like I don't think they should be the one that has to do all of the stuff

[00:50:49] some of it is actually just like seeing when some team is the bright spot that is doing something

[00:50:54] that's amazing and like solves an issue that was valuable and like just surfacing that and being like

[00:51:00] you guys should give a talk at the next offsite about this thing you're doing because that is great

[00:51:04] like maybe not everybody's gonna do it again we're not really looking for like

[00:51:08] everybody to conform to a particular thing or whatever that's not the goal but like we want this

[00:51:12] to be a tool that is in people's toolbox so awesome I think there's a number of cool things

[00:51:17] that you've touched on or really insightful things one of them being I like this RFC process

[00:51:23] there are requests for comments I think a lot of folks are hesitant in part because well it's

[00:51:29] pulling people away from stuff and especially if you're trying to do it in person and there's

[00:51:33] travel and budgets and the time goes disproportionately higher there's an investment but my

[00:51:39] hunch is that it's more around disappointing folks who provide input or maybe provide solutions

[00:51:46] and you're taking a different path and that's the piece that I have add to overcome myself and then

[00:51:54] teach others the same around hey it's okay you're asking for input you're not asking for solutions

[00:51:59] so number one frame your questions in a way that you're gathering context versus direction

[00:52:04] number two I think what you mentioned that was really cool was when you arrive at your synthesis

[00:52:10] and you're providing that next iteration Mac that you're providing context as well and so

[00:52:16] that helps the folks to continue providing input and feedback and being just as enthusiasticly

[00:52:21] engaged of wanting for you to succeed while also providing them context around how that decision was made

[00:52:28] and I didn't think about the artifact element where X number of months or years later when someone

[00:52:33] picks us up and tries to change this this could be a great starting point for them to get familiar

[00:52:38] I should what the original intent was what the success looked like how is this decision made

[00:52:42] what is the jenga puzzle look like and so forth so that they feel a little bit more empowered

[00:52:47] and confident and subsequently creative around how you know how ambitious they can be around making

[00:52:52] changes so that is I think a it really awesome process that has a lot of counter-intuitive

[00:53:00] benefits to it so we're talking about culture a lot and I think there are a lot of folks that are

[00:53:05] transitioning away from working for their sort of consumer and internet giant companies into

[00:53:11] some of them into startups some of them into the enterprise and when I talk to folks about

[00:53:17] leaving maybe a job at meta and taking up a job at a Fortune 500 culture is one of the biggest

[00:53:25] fears or concerns they have and there is necessarily you know I don't know if you can call it

[00:53:31] good or bad in terms of culture if you were to now join a new team or get familiarized with a new

[00:53:38] team what's your advice for what you tend to look for around getting a transparent sense of

[00:53:46] what the culture really is like yes it's a great and difficult question had the experience I

[00:53:54] guess I was going to say like fortune room is fortune I don't know sometimes which it was but

[00:53:58] all the way off to that and a couple years ago right so I was back on the job market

[00:54:02] and because of you know my interest in all these things and like how much my head is

[00:54:08] in that space I guess I even tried to do as much as I could basically during the interview process

[00:54:13] to try to assess that out right I didn't want to wait until I was like inside the doors of the

[00:54:19] company to find out that it wasn't going to be a fit so um so there's a couple things there one is just

[00:54:24] like something that I learned from my partner actually who does we're advising at the University

[00:54:29] is I almost always tried to do what she would call an informational interview so like you know

[00:54:35] outside of like the formal interview process or whatever try to see if I can find a person that is

[00:54:40] like at that company hopefully doing like a somewhat similar role and just like have us it down

[00:54:44] with them and like what is it in the life like right like what do you like what do you not like what

[00:54:50] is like something in your work that you're really excited about what's something that you're really

[00:54:54] frustrated about right like and that can paint quite a picture um I think especially like uh it

[00:55:00] relates to this other tool that I like a lot called in dance circles which is this notion of like

[00:55:05] especially with like more implicit knowledge like you might not be able to put your finger on

[00:55:09] exactly what it is that you don't or do or don't like about the culture but in a lot of cases I

[00:55:14] can say can you just tell me a story about like a time when uh you were like super excited about

[00:55:21] what was happening at work and you felt like really empowered and that you know things were

[00:55:24] just going your way and you know especially if you can get more than one story from more than one

[00:55:29] person you can start to see maybe some patterns that emerge of like oh they tend to feel empowered

[00:55:33] in this situation okay well what's the time when you felt really frustrated actually about what was

[00:55:38] going on at work and they tell you and you know you're like oh so mandates are really a thing

[00:55:43] at this company and that is often what people are frustrated about like huh like that is uh not

[00:55:48] something that I feel super enthusiastic about it feels like enough of an issue maybe I'm going to

[00:55:52] pass on this one you know that kind of thing um and you can get into some of it sometimes in the

[00:55:56] formula review process but again it's like they have a pretty strong idea in a lot of cases of like

[00:56:00] what they want to do with the formula review process so how much you can mold that or get your

[00:56:04] questions in you know it's like times almost up do you have any questions right makes it

[00:56:09] a sense and I imagine you may or may not did that as you decided to join the team at anchor

[00:56:16] so tell us a little bit about the company first and maybe you're all there yeah I mean

[00:56:23] I got to cheat a little bit so I worked with the co-founder is both at engineer and at

[00:56:28] heroku for many years so I've known them for like 15 years or whatever so turns out you don't have

[00:56:32] to ask him as many questions about what the control would be like when she like know the founders

[00:56:35] really well so I had a pretty good sense from that of what I was going to be getting into

[00:56:40] they brought me in initially really with the focus towards CLI and API design right so it's a

[00:56:47] anchor's current focus is really on developer tooling to make um to empower developers to do encryption

[00:56:55] right so there's I think a long history of people just kind of noeping on doing encryption stuff

[00:57:04] especially locally because it's a pain and it's not a one-time pain it's an ongoing pain steep learning

[00:57:10] curve and then you get some stuff working and it's like the worst of all worlds really because it's

[00:57:15] like you finally get everything working and then your certificates are going to expire in like six

[00:57:19] months by which point you will have totally forgot everything you just learned and you have to start

[00:57:22] over again from scratch basically and you know again like relating also to that notion of like

[00:57:28] distributing the pain versus one team owning it kind of it's like guess what if you're like relying

[00:57:33] on this for your development for your team there's a good chance that not only is this like

[00:57:37] painful expertise ramp to find the getting it to work to forgetting everything to painful ramp again

[00:57:43] happening for dot one developer it's actually happening for every individual developer on your

[00:57:47] entire team isn't a good luck isn't a good feel and so in a lot of cases people just would turn it off

[00:57:52] I mean like again like I have a big background in open source I don't know how many like open

[00:57:56] source libraries I've looked at that are basically like and here is how you turn off the SSL options

[00:58:01] and you're like but is that what I really want to do and like yeah probably because it's just

[00:58:05] like too painful to do the right thing so just do they not so right thing because in the development

[00:58:11] environment like not having SSL is maybe good enough and there's you know other things that

[00:58:17] push in that direction to like browsers if you use low-glose straight like in a lot of cases

[00:58:21] they have a kind of secure context they basically like turn off some of the security features

[00:58:27] that would otherwise be on but not all of them so like you get into things like especially

[00:58:31] if you're doing payment processing or things like that they won't let's you just like use the

[00:58:35] pseudo secure context of you know a low-glose they want you to truly have us here context so

[00:58:42] anyway yeah a lot of this is like you know similar to all of the other problems I was talking

[00:58:46] about like empowering people it's a better understanding encryption to make it easier to make it

[00:58:50] not that every person has this big learning curve that they've done for getting have to start over again

[00:58:55] you know like how do we make that really easy for people to get on board to get running tell us a

[00:58:59] little bit about who's that kind of ideal customer their customers that are too big or tend to be too

[00:59:04] small that that tend to kind of be in the sweet spot of having this problem we're hoping at least

[00:59:11] for there to not be a too small I guess so like part of our initial offering is actually LCL.host

[00:59:16] eight can go to that webpage now and download the tool and basically there's one command that you

[00:59:22] just run that will set you up so that you can have encrypted development for your app and you know

[00:59:29] again the hope is that it's like pretty drop in pretty easy to do pretty easy to maintain because

[00:59:34] we are keeping track of thanks for you and then in terms of too big on the other side I mean I think

[00:59:40] with a lot of this encryption stuff similar to some of the other stuff we talked about like once

[00:59:44] companies get to a certain size in many cases they'll actually build out a team to manage this for them

[00:59:49] and to do things like managing all the certificates to build out you know basically private CA stuff

[00:59:57] if you're at that point probably we're not necessarily going to be the solution you

[01:00:01] need or want at least not yet maybe we'll get there but really I think it's more like this

[01:00:06] small to medium companies that are really going to benefit from this but it doesn't make sense for them to

[01:00:10] try to build it unless and that we all learn from Heroku is you know we were talking about

[01:00:14] reasons that people want to use it one of the other big reasons is basically just like trying to have

[01:00:19] dev fraud parity the more ways that your development environment and your production environment are

[01:00:23] different the more likely you get the whole like works on my machine kind of situation which is

[01:00:28] it's not a good look when you deploy something to production and it crashes and that's the response

[01:00:32] that you can give like ideally things are more in line and so even for our unsut up we use it where

[01:00:38] we have a go-back end and a Ruby on Rails front end and they actually use our technology to talk

[01:00:47] encrypted to each other whether in development staging production we use it in all of the

[01:00:51] environments so we're dog fooding, champagne, you know, tents who ask I guess what terminology

[01:00:56] use there but like making sure that all works and that helps us to have the confidence that it's

[01:01:00] going to meet the needs of other people. What's a recent product or service that you got to

[01:01:06] use that just kind of blew your socks off that you were very delighted by? This could be at home or work

[01:01:10] or both if you can think of one of the one. Yeah and one that I've been enjoying a lot lately here

[01:01:15] but next to me I'll grab it is I mean I've been a longtime Kendall user and so I recently

[01:01:23] transitioned though I have one of these uh recouping coba this now it's the so this one like

[01:01:31] it does a couple things so one is it's a color screen so that's novel compared to the Kendall

[01:01:38] but the other things are like it actually also like it has a silice so you can actually write on it

[01:01:44] and write like directly into the book if I want to take notes that way I can do highlights in it

[01:01:49] but there were a couple other things that also like attracted me to it compared to the Kendall

[01:01:52] ecosystem one is that they have a partnership with iFixit where they actually like released

[01:01:59] instructions for how to repair a lot of stuff. Oh yeah I've been enjoying that and also

[01:02:04] maybe it was just like maybe I was doing it wrong with Kendall but um I felt like it was always

[01:02:09] like on me to go figure out what I was going to read next or whatever and with this it seems like

[01:02:13] been doing a good job of like providing recommendations and stuff in terms of delight or whatever

[01:02:17] like just being exposed to new and different books and stuff has been fun. Awesome I actually

[01:02:22] transition from a remarkable to the Kendall scribe because they're Markable broke and it's a

[01:02:28] broke for a silly reason and I felt like a good time to try a different device largely because

[01:02:33] I was excited about having both my Kendall books and the ability to write on the books at the

[01:02:40] Kendall's scribe you'd be surprised about how hard they make that to do despite

[01:02:44] it having a stylist that works relatively well and the Kendall library so that's uh it's a scary

[01:02:50] question for me to ask my guess because I inevitably end up going and filling something else in my place

[01:02:55] here. How can our guests get a hold of you or your team at anchor? Sure I mean for me I'm

[01:03:02] genus on most stuff so g-like giraffe you like elephant you like elephant and like monkey you like

[01:03:09] I don't know Utah I guess and S like snake we'll say so I'm genus on like get hub is one of the

[01:03:17] big ones because again I have a big open source background still pretty involved in open source

[01:03:21] like that's that's one good way and then LinkedIn also I think it's you know slash

[01:03:27] and slash genus or whatever I think we'll get to meet because that LCL dot post is great to

[01:03:32] check out if you just want to see what it is that anchor does and get a nice introduction to doing

[01:03:37] local encryption like it shows you exactly what you need to do it's very concise very to the point

[01:03:44] so sweet we will make sure to have links to all of that stuff in my show notes as well

[01:03:50] so that's great thank you so much for making the time this was a super fun conversation

[01:03:53] hope you have fun out there empowering folks and working on problems that are interesting with

[01:03:58] painful yeah yeah thanks thanks for having me I really enjoyed it

[01:04:08] thank you for joining me on the convergence podcast today subscribe to the convergence

[01:04:13] podcast on apple podcast Spotify YouTube or wherever you get your content

[01:04:20] if you're listening and found this helpful please give us a five-star review

[01:04:24] and if you're watching on YouTube hit that like button and tell me what you think about what

[01:04:28] you heard today