Podcast appearances and mentions of nickolas means

In this episode, we have a fascinating conversation with Nickolas Means, the VP of software development at Sym. Nickolas shares his insights on software engineering, data liability, and of course, good coffee.Nickolas starts off by sharing his love for audiobooks, particularly those narrated by the talented Wil Wheaton. He also recommends a management book called "Turn the Ship Around" by Admiral David Marche, which explores the importance of autonomy and ownership in improving performance.The conversation then turns to the topic of shame in the software engineering industry. Nickolas emphasizes the impact of shame on silencing voices and discouraging vulnerability within teams. They discuss imposter syndrome and the subjective nature of judging someone's skills, delving into the Dunning Kruger effect.Drawing lessons from physical engineering disasters, Nickolas shares the importance of early recognition and admission of mistakes, highlighting the need for a blameless mindset in software engineering. They also explore the impact of organizational culture on agile processes and the value of implementing meaningful controls for compliance.In addition to his expertise in software engineering, Nickolas shares his passion for pour-over coffee and reveals his obsession with perfecting his daily cup. So grab your favorite brew and join us for this engaging conversation on software engineering, data liability, and the pursuit of excellence. Let's dive into another thought-provoking episode of Data Driven!Show Notes[00:00:00] Nick Means discusses shame and software engineering.[00:04:46] Loud voices silence others; vulnerability is key.[00:09:16] What can we learn from physical engineering?[00:10:01] Engineering disasters teach human error in steel.[00:13:58] VP of software development interested in disasters.[00:16:37] Learn, not blame. Safety 2 perspective.[00:20:16] Big Agile vs. little a Agile explained.[00:25:39] DevOps leads to improved engineering efficiencies and cost savings.[00:29:25] Emergence of data regulations in government and industry.[00:30:33] Spirit of law makes compliance easier, safer.[00:35:51] Useless ash turned profitable by steel mills.[00:38:34] Uncle's Amiga sparked love for computers.[00:40:44] Increasingly humane tech interaction; a historic shift.[00:45:35] Favorite narrators and management book recommendations.[00:48:12] Intriguing episode of data-driven with Nick Means.

Join Eveline Oehrlich and Nickolas Means, VP of Engineering at Sym, to discuss the best practices and challenges of leading an engineering team, collaboration, and more. Nick is the VP of Engineering at Sym, the adaptive access tool built for developers. He's been an engineering leader for more than a decade, focused on helping teams build velocity through trust and autonomy. He's also a regular speaker at conferences around the world, teaching more effective software development practices through stories of real-world engineering triumphs and failures. If you are interested in a Sym demo, please visit: symops.com The Humans of DevOps Podcast is incredibly grateful to be voted one of the Best 25 DevOps Podcasts by Feedspot. Learn more about getting DevOps certified at devopsinstitute.com

On this episode of our SaaS Fuel™ Expert Series this week, we are delighted to have Nickolas Means, VP of Engineering at Sym and a seasoned leader in the software engineering field. Nickolas reflects on the challenges and lessons he has learned throughout his leadership journey in distributed organizations. One of the key takeaways from our discussion is the idea that leaders must find their own style and adapt to the context they operate in. While guidance and signposts are valuable, individuals ultimately need to define their own principles and lead with integrity. Nickolas also highlights the importance of cultural orientation in successful mergers and acquisitions. Creating a positive and enthusiastic environment, as well as understanding and preserving the acquired company's culture, plays a vital role in integration. In addition to these insights, we also discuss the value of creating a safe space for open communication and fostering a collaborative work environment. Furthermore, we explore the rise of remote international teams and how organizations can navigate the challenges and opportunities they present. Join us to discover more practical takeaways from this episode of SaaS Fuel!Key Takeaways[00:08:53] Leadership transitions require adjusting to new feedback loops and finding satisfaction in the work of others.[00:11:28] Leadership growth: learning from mistakes and perspectives.[00:14:25] GitHub fosters empathy through widespread product usage.[00:17:16] Focus on agency, autonomy, and empowering growth.[00:23:25] Setting ego aside, hiring smart people, teamwork.[00:25:12] Tool for healthcare data protection & access control.[00:29:46] Balanced interview process fosters mutual excitement.[00:33:52] Leadership style is subjective, personal, and experiential.[00:35:39] Influential book on leadership transformed my journey.[00:40:01] Leadership lessons from outside books are impactful.[00:41:00] Importance of Learning from the Broader Business CommunityTweetable Quotes"In engineering and in life, flexibility and creativity might just get you to the other side." — Jeff Mains 00:00:24"Moving into a people role, I just found those problems much more interesting and found the leverage that being a leader was much more satisfying to me than the leverage of writing code on a day-in, day-out basis." — Nickolas Means 00:06:51"As a leader, you can't really find satisfaction in IC-style work. Your satisfaction has to start coming from the work that the people you lead are doing." — Nickolas Means 00:08:53"A lot of the work in those situations is, okay, tell me what's important about your culture, tell me what means a lot to you as a company, and let's come up with ways that we can preserve that even as you join this larger culture." — Nickolas Means 00:15:54"I always look at that power as something that the organization is asking me to give...

Nickolas Means, VP Engineering at Sym, joins Corey on Screaming in the Cloud to discuss how Sym is looking to solve the most common and most frustrating elements of compliance. Nick reveals why he finds it valuable to focus on making it easy for people to do the right thing over preventing them from doing the wrong thing, and why he feels the true spirit of compliance involves helping teams collaboratively come up with mutually beneficial solutions. Corey and Nick also dive into the common problems that engineers experience as a result of traditional compliance methods, and why historically the compliance industry has gotten a bad rap. About NickolasNickolas Means loves nothing more than a story of engineering triumph (except maybe a story of engineering disaster). When he's not stuck in a Wikipedia loop reading about plane crashes, he leads the engineering team at Sym, helping create the building blocks engineering teams need to build delightful developer access and approval workflows.Nick has been leading software engineering teams for more than a decade in the healthtech and devtools spaces. His focus is on building distributed organizations defined by their cultures of high trust and autonomy. He's also an international keynote speaker, having shared his unique brand of storytelling with audiences around the world. He works remotely from Austin, TX, and spends his spare time going on adventures with his wife and kids, running very slowly, and trying to brew the perfect cup of coffee.Links Referenced: symops.com: https://symops.com Twitter: https://twitter.com/nmeans TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Developers are responsible for more than ever these days. Not just the code they write, but also the containers and cloud infrastructure their apps run on. And probably the billing on top of that - which is neither here nor there. And a big part of that responsibility is app security — from code to cloud.That's where Snyk comes in. Snyk is a frictionless security platform that meets teams where they are, automating application security controls across their existing tools, workflows, and the AWS application stack — including seamless integrations with AWS CodePipeline, Amazon EKS, Amazon Inspector and several others.Deploy on AWS. Secure with Snyk. Learn more at snyk.co/scream. That's S-N-Y-K-dot-C-O/scream. And my thanks to them for sponsoring this ridiculous nonsense!Corey:  LANs of the late 90's and early 2000's were a magical place to learn about computers, hang out with your friends, and do cool stuff like share files, run websites & game servers, and occasionally bring the whole thing down with some ill-conceived software or network configuration. That's not how things are done anymore, but what if we could have a 90's style LAN experience along with the best parts of the 21st century internet? (Most of which are very hard to find these days.) Tailscale thinks we can, and I'm inclined to agree. With Tailscale I can use trusted identity providers like Google, or Okta, or GitHub to authenticate users, and automatically generate & rotate keys to authenticate devices I've added to my network. I can also share access to those devices with friends and teammates, or tag devices to give my team broader access. And that's the magic of it, your data is protected by the simple yet powerful social dynamics of small groups that you trust.Try now - it's free forever for personal use. I've been using it for almost two years personally, and am moderately annoyed that they haven't attempted to charge me for what's become an essential-to-my-workflow service.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends over at Sym, and into my verbal grist mill, they have thrown their VP of Engineering, Nickolas Means. Nickolas, thank you for joining me.Nickolas: Thank you so much for having me, Corey. And feel free to call me Nick.Corey: I certainly shall. So, let's begin at a high level. When you're starting a company and trying to, sort of, bootstrap and raise initial rounds of funding and the rest, you're trying to save money in a bunch of places. And one of the most expensive things you can buy when starting a company is, of course, a vowel. You wound up not naming the company—or the vowel, really—the y is sometimes a vowel, sometimes not. It's S-Y-M. What is it you folks do exactly? What do you folks start? Where do you stop?Nickolas: So, the name of the company comes from the idea of helping humans and machines work together more effectively. And that's really nice and high level; it doesn't tell you any information about what we do.Corey: It feels like we're—we'd assume that most startups pivot at some point; we're just going to set—Nickolas: [laugh].Corey: —[crosstalk 00:01:33] seeds for that nice and early on, and dive on in.Nickolas: So, what we actually do, the two co-founders and myself all have a background in highly compliant industries. I've done VPN stints at a couple of health tech startups; they've done similarly. And all three of us ended up building sort of a certain set of things every time we were at one of these companies. Because you have to be compliant with things, and in order to be compliant with things, you have to have a set of controls, you have to restrict certain things: how people get to production, how people access customer data. And those controls, by and large, all suck. They're all painful and every company ends up building something from scratch at some point to make them not suck quite so bad. And it seemed like there was a product opportunity there.Corey: I would argue there absolutely is. One of the big problems that I've found throughout the time that I've been fixing AWS bills on a consultancy basis has been, we're really talking about cloud governance. But even now, by using the phrase cloud governance, three-quarters of the audience immediately wound up skipping to the next podcast over on their playlist because it sounds like it is one of those incredibly boring things. And to be fair, usually, when it comes to compliance, you want some of the most boring, least creative people in the world overseeing that. Like, when you wind up talking to someone at a company and they have a great sense of humor and they are constantly cracking jokes constantly, it's like, “What do you do?” Like, “Oh, I'm the CFO.” All you hear from that is, “Oh, I'm about to go to prison. Awesome.”Like, you want the wild, cutting-loose CEO to have three drinks and then confide, “I really like typing the number six.” You want them [laugh] to be predictable in a whole bunch of ways. And it always feels like compliance takes that entire mindset of, it's always about risk management, it's about wanting to make sure that people don't go off script in a bunch of weird ways, but as an engineer, what I always heard from that is slow down, don't be creative, go ahead and do things in very predictable ways. Only release things once a quarter, et cetera, et cetera. And yes, that's one way to meet compliance goals, but it's a crappy way, in my experience. I'm going to guess, though, that you have a lot more experience with the compliance world than I do because having worked a few times now, for big regulated finance companies, I wanted to get the hell out of the compliance universe.Nickolas: Yeah, I mean, you used an interesting turn of phrase there. You used the phrase, “Avoid going off script,” and I think there's a subtle turn there that actually makes all of this work a lot better. Instead of focusing on keeping people from going off script, you focus on keeping them on script. You focus on making it easier to do the right thing than to do the wrong thing. And that takes away a significant amount of the pain involved in compliance stuff.You look at implementing controls—and everybody has the exact same reaction you just brought up about governance—because there's so much FUD around this stuff. Everybody has been slowed down by one of these silly rules that makes no sense, that's checking a box and not actually meeting the spirit of any kind of meaningful improvement.Corey: Oh, cloud has absolutely doubled our speed of iteration because it used to take six weeks to get a server racked in the data center and we moved our processes to cloud and now to spin up an EC2 instance, it only takes three weeks of approvals. And at that point, it's what are you really doing? You wind up with people building on shadow IT. It's part of what contributed to the rise of cloud in the first place. Well, I can go through the annoying thing that this company wants me to do, or I have a corporate credit card and by the time it raises the level of spend to a point where it gets scrutiny, it's in production serving customers and what are they going to do?Some of the very early AWS sales conversations with customers started off as, “Well, why should we build on top of your cloud?” asks the exec, and they say, “Oh, sorry, you have 87 different accounts throughout your organization currently with us. We're just trying to give you some unified view into it and possibly some discounting if you want.” Yeah, these days, that's a fast track to getting yourself fired in some companies, if you wind up deviating from that story. But also, people are not doing this out of malfeasance; they're trying to get their job done.And as soon as guardrails start increasing friction, making it harder to do things the right way than to go around it, people will not comply. I strongly believe that, whether it's cost—which is my universe, and frankly, only a business hours problem—or actual governance issues with some compliance regimes, which get those wrong and hope you enjoy some time in prison.Nickolas: Yeah, exactly. I mean, you know, if you look at SOC 2, for example, there's a lot of companies out there that are willing to sell you a program that will help you become SOC 2 compliant. They show you all the steps you need to take, all the programs you need to put in place. The thing they don't do is help you establish the controls that are required. They'll tell you that you have to have somebody formally approving before software goes out to production. They won't give you any guidance whatsoever on how to put that control in place. And so, it's really easy for a compliance person that's not looking to collaborate with engineering just to go, “Okay, I need you to put a button in the deploy process and I need the CTO to click that button.”Corey: Yes. We've always seen that as reactions to different things. I was at a company once where there were some outages caused by bad deploys, so they decided that a VP had to sign off on every deploy. Now, I come from the sysadmin ops world, which explains so much about my cynical perspective on life, so the way we got that overturned within two days is we did the malicious compliance thing, where oh, we need to deploy this. Great, we are walking into the middle of a senior leadership team meeting to get them to—with a tablet or comput—laptop—“I need you to click the button right now.”And doing that out of hours and all kinds of other things, it's oh. Yeah. How about we wind up only doing that for significant large changes? How about that? Maybe you don't need to wake someone up at home in the middle of the night when there's a deploy going out that fixes a typo on the marketing page; little things like that.And at some point, you're always felt like the goal of governance was either ossified scar tissue around all the ways that things have failed before, or through a, frankly, misguided belief that if we wind up distilling everything down to processes and procedures, eventually, someday, we can have a bunch of trained monkeys doing this job instead of people who are expensive and, you know, cynical, and difficult to please. I feel like that is not the right way to think about these things.Nickolas: Well, I mean, the thing about those controls, you know, it's exactly what you just said. Nowhere in SOC 2 does it say that your VPN [unintelligible 00:07:56] or CTO has to approve all code deploys, that's not in there. But that's the reality of life at a bunch of companies. In reality, if you just follow a software development life cycle that has multiple people looking at code before it gets deployed, multiple people signing off on that code being okay to deploy and you have a staging environment before you hit production, you've met the control. And SOC 2 gives you so much flexibility in how you write the control.So, I think the thing that I've seen that makes compliance so much less painful, is when you have somebody that is 95% the boring persona like you're talking about, but 5% creative. 5% willing to kind of get their hands dirty, empathize with the engineering team, collaborate with the engineering team, and find a way to put some of these controls in place that doesn't just bring things to a grinding halt.Corey: I have to assume that, given that you've built an entire product slash company around this idea, that you have some opinions other than doing what I do, which is sitting in my lofty ivory tower and oh, you should, in this idealized case, do things a little bit differently. But it's going to be bespoke and the answer to any complex question, the more senior you get is, “It depends.” You, of course, have built something that scales out in a bunch of different ways. How do you view that in a way that makes it not either completely useless or overly prescriptive?Nickolas: We focus on giving the power to engineering teams and giving the security complexity [unintelligible 00:09:23] the power to oversee those things. You know, it would be easy to give somebody, like, a clickbox UI, let them design controls for SOC 2 or whatever, end-user interface, but that's not how engineers think; engineers think and express ideas and code. So, we've made the rather controversial decision in the face of a bunch of no-code tools to go low-code instead. So, to build a compliance workflow in Sym, you're going to write some Terraform, you're going to write a little bit of Python—a lot less than if you were building it from scratch—but you're going to end up with something that perfectly fits the way that you already work versus having to shift your work practices around to fit the tool.Corey: If you have inadvertently stumbled upon one of my hot buttons. There's a lot of people that take a perspective around low code. And I just want to say that that perspective is often garbage. Like, oh, that's not a real program—great. Hypothetically, if you have an idea for a business or a product or something, and involve software as most things seem to these days, maybe having to go to a boot camp for six months first as a prerequisite is not the best path forward.“Well, you're never going to build something hyperscale in a low-code environment.” Great, how many things that we built that actually need to be hyperscale that don't go through 16 different architectural iterations between ridiculous idea one day and thing that is actually hyperscale? It's an early optimization. I have an entire production pipeline in Retool that I built using low code. I think that that is a very powerful thing. And this idea that, “Oh, that's not real code.” Cool. What's your point?Nickolas: Well, and for us, one of the things that we're trying to enable is for software engineering teams, ops teams, whoever is building these controls, to interact with a security person or a compliance person, for them to be able to read the code, understand what it does, understand the way that the control has been implemented. And so, we provide a bunch of frameworks around that and a bunch of things. Like, you don't have to go and build a Slack workflow from scratch and nobody has to understand that code because it's buried in the platform. The only thing that the security or compliance person has to understand is the business logic that's been put into place. Who can approve it? Who can't approve it? How does that change after hours? How does that change if there's an incident? All of that is in very simple Python that you don't have to be an experienced programmer to be able to read.Corey: One of the big powerful things behind that is it really reduces the interrupt volume of someone coming by to an engineer who is deep in the middle of something else, and, “Hey, guess what I have? A surprise context switch for something that's going to take you probably 30 seconds, but then you're going to be distracted by all of this.” If you give people the ability to self-serve, everything tends to work a lot more smoothly.Nickolas: Yeah, absolutely. And, you know, that's one of the ways we use Sym at Sym: we've got it in front of our AWS production environment, so if you need to go and do anything in production, you just have to get approval from any other engineer that happens to be in the approval channel, sort of a two-keys-to-launch-a-missile model. And that works fine for our compliance needs and it avoids there being a single point of failure that every time you need to go and get into production, you have to go and say, “Mother, may I?”Corey: Exactly. It's one of those things where every time you wind up with something that injects friction, people are going to find ways around it. And in some cases, this leads to positive outcomes where, when you're subject to PCI, which is a lot more prescriptive than a number of other compliance regimes, it's, great; this is a lot of things that don't necessarily reflect how we work, how we want to work, et cetera. We can ignore it, which is not a great plan, we can wind up having to slow everything down, which is the common case, or the right answer is, we're going to build the PCI environment that is very self-contained, just the critical stuff that needs to be in there is going to be in there, and then we can build everything that touches it around it in ways that are a lot more aligned with how we believe software should be built.Nickolas: Yeah, absolutely. I mean, you silo off those high-control places, but there are controls that have to extend into the rest of the business. And one of the things that I'm a very firm believer in is, if you're going to impose a control upon somebody, they need to have the agency to shape and to change that control so that it lets them work the way that they want to work.Corey: I just want to call out how wonderful that is because I had a belief that looked borderline heretical, 12 years ago, when I said that, “Okay, simple rule. If you want me on call, I am empowered to change the thing that wakes me up.” Whether that is the code itself, the system itself, the paging threshold and frequency, or ultimately, I'm turning the physical pager off. It's one of those things where I decide what's an emergency outside of hours on that point. If it's going to wake me up, I need the power to make sure it never does. Otherwise, you have no agency. It just feels like you're being victimized by the stuff.Nickolas: Yeah, absolutely. I mean, there was a wave of on-call regimes that ran through large companies for a while where there would be a centralized on-call team that would be responsible for responding to hundreds of services. And thankfully, we are maturing past that; we're distributing on-call rotations so that teams that actually build services are responsible for them. And it's the same mindset, right? If you're going to be participating, if you're going to be working with a system or working with a control, then you need to be able to change it, you need to be able to make it work the way that you think that it ought to work.And in the context of compliance, you need to bring somebody along with you. You need to bring the person that's responsible for the controls that actually has to sign on the dotted line at the end of the audit period, saying that we do all of these things. So, you have to be able to explain what you're doing to them. But you have to be able to iterate.Corey: I have to ask, given that what you are building is going to have heavy involvement from engineering, how do you respond to the probably most common engineering objection I imagine you get, which is, “Well, this doesn't look hard. I could build this in a weekend.”Nickolas: You know, it's funny. We joke that our biggest competitor is build in-house, right? It's pretty easy to start looking at what it takes to build a from scratch workflow in Slack to build a Slack app, to understand the cost of building it in-house. Because nothing about building an elegant user interface in Slack is easy or cheap. That API is difficult to work with and hard to get good user experience out of.And we've spent a lot of time polishing a lot of places in the platform: we've got good documentation, we've got a good SDK, we've got good integration with third-party services that make all of this stuff easy to do. And it does look easy on the surface, it does look like ‘I can build it,' but we've had customers that have had that objection gone and tried to build it and come back. Because it's not as easy as anybody thinks.Corey: My biggest competitor for fixing AWS bills has always been Microsoft Excel. It's the, we're going to do it ourselves—badly—internally. Okay, great. If that works for you, terrific—Nickolas: Yeah.Corey: —but very often it doesn't. I mean, I think a classic case study of this is, in the terms of something that is well designed but is almost mind-bogglingly complex—and we're getting a case study in it this year—is Twitter because it looks from the outside, very simple. I wind up writing a thing and I hit the post button and it shows up in a timeline. And then other people can subscribe to it or not, and they see it themselves. That sounds like something you can build on a weekend. And we look at all the ways it's now exploding and collapsing and having weird bugs that no one anticipated, to realize, oh, this is a very challenging, very sophisticated application. But because it was well designed at one point, it looks easy.Nickolas: Yeah. Yeah, it continues to run despite the fact that it's having less than a quarter of the staff that originally maintained it, maintaining it because the services were well designed in the first place. They're resilient on their own and they're self-healing in a lot of cases. It's the same thing with Sym. You can build these tools in-house, you can build them yourself, but then you've got more software to maintain. Because once you build something, you own it, forever. And the cheapest code is no code; the cheapest code is code that you don't have to write.It's easy to look at a simple use case and understand a little bit of the cost of this. If you want a Slack workflow that gives you access to production in AWS, you can wire that up fairly quickly. Those APIs are not all that difficult. Now, let's say you want to add an integration where if you're on-call in PagerDuty, you can get to production without having to get an approval. Okay, well, now you've got a new API that you need to wire in.And let's say that every time that happens, you want to open a Jira ticket so that you can record that that's happened. Well, there's another API that you've got to wire in.j, whereas with Sym, it's just, it's right there. It's a few lines of code to wire it all together. And it deploys in Terraform alongside the rest of your infrastructure, so you manage it the same way you're used to managing things.Corey: It reminds me of my earlier career when I was deep in the configuration management weeds with Puppet and SaltStack, where the biggest competitor we had any of those projects was always someone writing a bash script to do it themselves. And yes, you can do that, but then the requirements change, or you're going to hit a point of scale that was surprising. And one of the valuable parts of it is that when the future is uncertain, as it always is—Nickolas: Always.Corey: Having folks who work in environments that aren't just yours who encounter a lot of those edge cases you're going to stumble into and can build things in is incredibly valuable. I don't think I've ever met anyone who ran an infrastructure that said, “I would build it the same way if I had to start over again.” They always want to, “I would fix these annoying things.” Well, by having a product focused on a space like this, it's yeah, today, you can have that VP click the approve button inside the GitHub Actions workflow. Good for you.But when you get just a little bit further down the path, you aren't going to want to do that anymore. There needs to be some decision-making it builds into it, and for certain high-risk changes, maybe a second person and so on. How do you build that logic engine? How do you build that workflow approach? How do you have a break glass thing for middle of the night when the site is down? Et cetera, et cetera, et cetera.And that's exactly the sort of thing that I would expect something like Sym to get very right, just because there's always a bigger fish. You've seen this [unintelligible 00:19:17] before in other shops. And more to the point, if there's something I want to do as a part of this that Sym doesn't support and you are looking at me strangely if I asked how to do it, that's usually a good early warning sign that maybe there's something I'm not thinking about here. Because whatever the problem space is, I'm probably not the only person that has to do this. How are other companies solving for this? And it turns out that all my copy of our SOC 2 report has a typo on it. That would explain a lot. That's a ‘can' instead of ‘can't.' Nevermind. Or something like that.Nickolas: Well, and the flip side of that is also true. I mean, the interesting thing about working on something that is sort of wide open with what you can wire up and build with it is we're always learning from our customers. We're always learning from the things that they're doing. And so, you know, when somebody approaches us of, “Hey, we need to solve this particular problem,” if we don't have a ready answer, we brainstorm and help figure that out. And to your point, that always extrapolates to other customers finding the same sort of thing useful.The other bit of this that's really interesting beyond the durability and the ability to kind of rapidly evolve these workflows is the audibility. It's helpful in a lot of these compliance regimes to have a third-party tracking this data for you. So, when somebody accesses AWS production, who approved that access? When somebody deploys code, who approved those deploys? Well, we sit there as kind of a third party on the side, observing all of this, taking all these notes for you, and piping them into whatever audit tool that you want.So, you've got that data long-term and when it comes time to audit, you've got all the evidence you need; it's already there, already collected. You don't have to go through and write a regex to parse a bunch of logs to get the information you need.Corey: And invariably, that regex is always going to be different, depending upon the log stuff. It's great having a unified central approach that is the trusted repository for this stuff. As you've been going to market and talking to your earlier customers and seeing the problems that you folks solve, what have you learned about the market space since you've gone into this direction? Because I feel like this is one of those products where you start designing and thinking you know a lot about the space, and you learn so much more just from the customer conversations and seeing that you can build the most finely crafted torque wrench in the world and the customer complains because it turns out, you built a crappy hammer.Nickolas: So, I think what's been really interesting to me is how much use our Lambda integration gets. We have a lot of first-party integrations with things like IAM and IAM identity center and Aptible and a bunch of tools that you can interact with, but a lot of our customers have wanted to do very specific things inside their infrastructure and put those things behind an approval. And the Lambda integration turns out to be a great Swiss army knife to do that because you can wire it up—it runs inside your firewall—to take essentially whatever action that you need it to. And that gets a ton of use. Probably more than half of our customers have at least one Lambda workflow in production, and I would not have expected that going in.Corey: It's wild to me just how pervasive Lambda has become. And even from a compliance perspective, it's great because unlike, “Well, it's a script that runs on a server somewhere,” yeah, it's immutable. It's versioned. There's a way to conclusively prove that at invocation, this is the code that ran, the end, with the following parameters. Done.There's no, “Well, looking at the timestamp on the file”—like, no. None of that nonsense. It's arguable that something that I have seen has been that Lambda is one of those rare technologies where you're seeing faster adoption in the enterprise and you are in startup land.Nickolas: Yeah, I would say that's true. I mean, it's so great for running undifferentiated workloads. I just need this one thing to happen really quickly and I don't want to mess with standing up a server to run this thing that runs once a week. Okay, well, here's a computer that will run just long enough for you to run this thing and then go away. It tracks exactly what ran, exactly when it ran, exactly how it got kicked off.And in our case, it has access to all of the internal AWS APIs that we wall off in our platform because we obviously don't want you using those things in the Sym runtime. But you can do anything that you want to your AWS environment from your own Lambda and we will gladly provide the approval step ahead of kicking that job off.Corey: Are you seeing people use Lambda-based workflows to manage on-premises things or is it more heavily in environments that are already within the AWS boundary?Nickolas: The Lambda stuff that we see is almost entirely—I think it is entirely for things that are within the AWS boundary. I can't think of an instance when somebody is managing something on-prem with it.Corey: I am increasingly discovering, through the magic of Tailscale—among a few other things—that I can use that for things on-premises that talk directly and interface with my Raspberry Pi in the spare room, et cetera. Which is—I think some people call it hybrid, which is the business enterprise term for ‘horrifying—Nickolas: Yep.Corey: —because it's a terrible pattern in some ways. But it's so convenient and it's so nice not to have to worry about some of these things, just an infrastructure point of view. One thing that I think that AWS has done very well at, as they've evolved, has been with AWS Artifact, which ties directly to their own compliance reports, where in the early days when I was responsible for SOC 2 controls at a company, I found myself answering security questionnaires from vendors as if I was running in a data center. And sure enough, they wanted to tour us-east-1. And it turns out, you can't really do that.So now, just pointing them to the stuff that comes out of Artifact, it's written by auditors for auditors and they go away and leave you alone without having to explain your bespoke artisanal nonsense to them. There's something very pleasant about being able to throw the lion's share of the work over to someone who already knows how to do it.Nickolas: Our audit period is ending here shortly and I have recently been and spending time in Artifact. So yes, a hundred percent.Corey: It used to be that you would only be able to get those things under explicit NDAs, you'd have to talk to your account manager for every one, it was a back-and-forth process, and you didn't really know if what you were going to get was going to answer the questions that they had. Now it's, you show up, you click things three times, and you're done. The hardest part is sorting out which ones you need from the hundreds of things available within Artifact.It's like, okay, that's great, but this one is in Spanish for some reason. And that's awesome, but on some level, it feels like that should be an easy filter option. But yeah, no one ever accused AWS of building a good user interface. But once you get the thing you need and can pass it off, great. Job over. It's one of my favorite services that most people who are what we know as ‘happy' don't know exist.Nickolas: Yeah well, and that, it points to a larger industry trend, right, that companies are getting SOC 2 specifically earlier and earlier because it is becoming table stakes to be able to sell into other companies. They want to see your SOC 2 report before they're willing to work with you before they're willing to let your software touch their infrastructure. And there is a lot of value in these compliance programs as essentially a stamp of approval that you're taking these things seriously, even with as much flexibility as SOC 2 has, just the stamp that we've thought about these things and we have serious answers to them is a pretty important signal to be able to send to somebody that's wanting to buy your software.Corey: We've toyed with the idea of going through the process ourselves because we get asked about it all the time, but it feels like the procurement processes that ask us for it expect us to come in with a whole software suite and the rest. And yeah, if that's the world we're operating in, it makes a lot of sense. We're a services-based consultancy; we come in as individuals, we have conversations with people, and we talk about this and we have no write access to anything in your environment and give you scoped-down permissions for what we talk to because we don't want the responsibility of that stuff.And a lot of companies get that intrinsically, but there's occasionally a few you have to go round and round and round with. It just it feels like it's one of those, okay, you're not quite there yet. You're trying to view everything through this very specific worldview. Maybe it works for your constraints and requirements, but I've never understood it. And I've learned the older I get, the more time I spend around this, I used to have such a negative perspective on compliance.And now it's, you know, everything's nuanced. There's a reason that these things are there. It's not just a make-work project for an industry that wants to slow everyone else down. It's, there are risks here; these things exist for a reason. There's a reason that you can go start Twitter for Pets tonight and not be regulated, but the same is not true of First Bank of Twitter Pets.It's okay, yeah, one of those things is going to require a fair bit of regulatory scrutiny, and as a society, we want that. Now, the counterargument that I don't necessarily want to get too far into is, should Twitter for Pets be regulated?Nickolas: [laugh].Corey: And that's a can of worms that I think we'll leave for another episode.Nickolas: Yeah, I mean, that's—you know, the people that hate compliance the most are the people that are on the sharp end of compliance, people that are having to actually deal with the controls that are imposed upon them by these compliance regimes and by somebody who's taking a very literal view in interpreting the things that some of these compliance programs say that you'd have to put in place. And I think, you know, that's—kind of bring the conversation full circle—that's the thing that we want to change more than anything. If we can wave a magic wand and change the compliance universe, the thing that I most want is to help compliance and security people collaborate with their engineering teams and come up with mutually beneficial solutions. Things that actually—the spirit of compliance.Corey: Oh, yeah. My first PCI audit was a little bit of a challenge, just because the auditor wasn't really conversant with anything that wasn't a large company. So, they show up at our twelve-person start off, and, “Okay, where's the Active Directory?” It's like, “We don't have one of those.” “Okay, well how do you authenticate to the WiFi?” It's like, “Oh, the password's on the wall.”It's, “Well, what happens if I get on that WiFi?” It's, “What can I do that I couldn't do from anywhere else?” Like, “Use that printer over there. That's it.” Because everything else was the idea of the security boundary was built on identity, not on what blessed network you happened to be on; there was no special permissioning that didn't apply to the Starbucks WiFi next town over.But that was one of those things where at first they thought this was a horrifying problem and they were not going to be able to certify us, and it turned into no, we had significantly advanced culture of security compliance, oversight, separation of duties, all the things you really care about. We just didn't have the trappings that usually came across with when you're thinking about this or starting—or having the temerity to start a company, you know, longer than 18 months ago at a place that wasn't San Francisco on the latest version of a MacBook Pro running the bleeding edge version of Chrome. It turns out that there's a big universe out there. And not that there's anything wrong with either side of it, until they start forgetting that not everyone operates the way that they do.Nickolas: Yeah. I mean, you know, we talked about checkbox compliance a lot and I think that's probably the biggest problem is there is a lot of checkbox compliance out there. And people have seen it not actually solve anything and just make everything harder. And so, compliance gets a bad rap.Corey: Oh, for me, the one that I've been picking fights on social media about for a few years now is encryption-at-rest in the cloud. Like, yes, you want full-disk encryption turned on your laptops, your phones, your tablets, et cetera. Someone steals it from the coffee shop, you want to be out the cost the hardware. The end. But if you can get a hard drive intact out of an AWS facility and then reassemble it with the right number of drives in the right places, without… and hasn't been encrypted. Congratulations, you earned it. As far as I'm concerned, that's yours. You can keep it.Because AWS employees aren't able to do that, let alone third parties. But it is easier by far to click the box to enable encryption-at-rest and not spend half an hour arguing with the auditor… and just get on with your day. And recently in S3, for example, they wound up making that a default. Good for them. It's just, can we please focus on the part of the story that's relevant and germane to our business? Because that is not the threat model of modern attacks.Nickolas: Yeah, I mean, for a long time, how much of the internet ran on unencrypted HTTP, but it was being served off of an encrypted disk? Great. What have we solved?Corey: Oh, absolutely. It's wild to me. Even now, I still we feel like there should be a reasonable way to handle—to [unintelligible 00:31:17] basically encryption between two points that doesn't depend on the third-party CA's with expiring certs and the rest. Drives me up a wall every time because it's always the worst possible time. It causes the strangest issues and there is something deeply and profoundly wrong with the fact that the failure mode from the user perspective between, “Your connection is being intercepted by a third party,” and, “Holy shit. This certificate expired two hours ago.” Like, those are very different use cases, but the scary warnings have trained people to treat them the same way.Nickolas: Yep. Yep, exactly the same. Ugh.Corey: I really want to thank you for being so generous with your time. If people want to learn more, where's the best place for them to find you?Nickolas: Yeah, so the best place to find out more about Sym is our website, symops.com, SYMOPS dot com. And I should mention that Sym is completely free for teams of up to ten people. If any of you out there listening check it out, please reach out. We'd love to hear about your experiences, help any way we can. And if you want to get in touch with me directly, the best place to do that for now, while it lasts is still Twitter. I'm on there as @nmeans.Corey: And we will, of course, include a link to that in the [show notes 00:32:27]. Thank you so much for agreeing to talk to me about all this stuff. I really appreciate it.Nickolas: Yeah. Thanks so much for having me on, Corey. It's been a lot of fun.Corey: Nick Means, VP of Engineering at Sym. I'm Cloud Economist Corey Quinn, and this has been a promoted guest episode, brought to us by our friends at Sym. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry bitter comment that will get posted in six weeks, after you track down your elusive VP to click the approve button.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Dylan and Chris check in since the last episode together, chat about machinery and employees, and digging out of the hole of work. Both discuss the most recent #withintolerancebookclub book "Extreme Ownership" by Jocko Willink and Leif Babin and share lessons learned from the book, and applications to their businesses. Check out Zap's IG @zap.consulting Check out the Nickolas Means talk on 3 mile island - https://youtu.be/1xQeXOz0Ncs ----------------------------------------- Help support the podcast www.patreon.com/withintolerancepodcast

So much of the tech world went remote at the start of the pandemic, and many of those jobs (and engineers) show no sign of ever going back into an office. Building successful teams in this environment takes a different approach, one defined by autonomy and trust. In this segment, Nickolas Means, VP of Engineering at Sym, will share insights from more than a decade of leading distributed teams to help us all thrive in a world where distributed is the new normal.   The White House recently revealed their National Cybersecurity Strategy and its 5 pillars. Some is straightforward - some is more controversial. Josh helped with it and wrote a blog about it. Adrian read that post and asked Josh to come discuss it. So here we are. Segment Resources: https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf https://claroty.com/blog/consequential-cybersecurity-brace-yourself-for-the-white-house-national-cybersecurity-strategy   In the enterprise security news, early stage startup funding stays constant, but late stage is nowhere to be found. Cisco, XM Cyber, and Mastercard make acquisitions. YouTube channels keep getting hacked. Microsoft fails to use Azure securely. Organizations are making progress on zero trust, but slowly. Finally, more discussion on AI threats, concerns, and predictions.   Visit https://www.securityweekly.com/esw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/esw311

So much of the tech world went remote at the start of the pandemic, and many of those jobs (and engineers) show no sign of ever going back into an office. Building successful teams in this environment takes a different approach, one defined by autonomy and trust. In this segment, Nickolas Means, VP of Engineering at Sym, will share insights from more than a decade of leading distributed teams to help us all thrive in a world where distributed is the new normal.   The White House recently revealed their National Cybersecurity Strategy and its 5 pillars. Some is straightforward - some is more controversial. Josh helped with it and wrote a blog about it. Adrian read that post and asked Josh to come discuss it. So here we are. Segment Resources: https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf https://claroty.com/blog/consequential-cybersecurity-brace-yourself-for-the-white-house-national-cybersecurity-strategy   In the enterprise security news, early stage startup funding stays constant, but late stage is nowhere to be found. Cisco, XM Cyber, and Mastercard make acquisitions. YouTube channels keep getting hacked. Microsoft fails to use Azure securely. Organizations are making progress on zero trust, but slowly. Finally, more discussion on AI threats, concerns, and predictions.   Visit https://www.securityweekly.com/esw for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly   Show Notes: https://securityweekly.com/esw311

So much of the tech world went remote at the start of the pandemic, and many of those jobs (and engineers) show no sign of ever going back into an office. Building successful teams in this environment takes a different approach, one defined by autonomy and trust. In this segment, Nickolas Means, VP of Engineering at Sym, will share insights from more than a decade of leading distributed teams to help us all thrive in a world where distributed is the new normal.   Visit https://www.securityweekly.com/esw for all the latest episodes! Show Notes: https://securityweekly.com/esw311

So much of the tech world went remote at the start of the pandemic, and many of those jobs (and engineers) show no sign of ever going back into an office. Building successful teams in this environment takes a different approach, one defined by autonomy and trust. In this segment, Nickolas Means, VP of Engineering at Sym, will share insights from more than a decade of leading distributed teams to help us all thrive in a world where distributed is the new normal.   Segment Resources: https://symops.com/?utm_campaign=eswp&utm_medium=social&utm_source=podcast   Visit https://www.securityweekly.com/esw for all the latest episodes! Show Notes: https://securityweekly.com/esw311

Nickolas Means is Vice President of Engineering at Sym. He has been leading software engineering teams for more than a decade in the HealthTech and DevTools spaces. Nick also co-hosts the Managing Up podcast. In this episode, Nick talks about the importance of autonomy and trust in distributed engineering teams and how companies facilitate the development of both. He also shares his thoughts on how to turn failures into learning lessons, leveraging a blameless mindset, and how best engineering can work alongside product and compliance teams. Sym https://symops.com/ The Managing Up Podcast https://www.managingup.show/ The Secure Talk Cyber Security Podcast https://securetalkpodcast.com/

  Guest info Name and Title: Nickolas Means, VP of Engineering at SYM Email/Social Media Contact: @nmeans on Twitter, @nmeans@ruby.social on Mastodon Time Zone (if other than Pacific): Central (Austin, TX)   Show Topic Summary / Intro We welcome Nickolas Means to the stream. Nick is the VP of Engineering at Sym, the adaptive access tool built for developers. He's been an engineering leader for more than a decade, focused on helping teams build velocity through trust and autonomy. He's also a regular speaker at conferences around the world, teaching more effective software development practices through stories of real-world engineering triumphs and failures. He's also the co-host of “Managing Up” a podcast with  Management tips, stories, and interviews to help navigate the challenges of managing creative and technical teams.   Questions and potential sub-topics (5 minimum): 'blameless environment' during an incident. We can discuss working an incident and if a 'blameless' environment the exception or the rule (stories from the trenches are always welcome) Building a compliance program without tanking your engineering velocity... I'd like to speak about that in terms of overall security (product security, scanning, license checks, and more) Is there a playbook to building more efficient dev and security teams? Can cross training dev in basic security, or security in sprint planning processes make a better experience for all? Will we ever solve ‘shifting left'? What does Shifting Left really mean to engineering teams, or is that a term security people created to try and speak ‘dev/eng'?  ‘Managing Up'... security is often asked to do a lot. Be STO when you don't manage the resources, timeline, etc. When teams are small, you're either in the operational/tactical, when management wants a ‘tactical/strategic' view. What can the overall business do to create a good working relationship out of the gate? “Make a dashboard” is all well and good, except when your org lacks maturity across the board. What are some realistic expectations management should have when the company is small?  (I will provide additional context during the stream)   Additional information / pertinent Links (would you like to know more?): https://managingup.show/ - Managing Up Podcast “Management tips, stories, and interviews to help navigate the challenges of managing creative and technical teams.“ https://symops.com/ - Adaptive access management tools built for engineers https://www.ted.com/talks/brene_brown_the_power_of_vulnerability?language=en https://www.terraform.io/ https://news.stanford.edu/2022/12/05/explains-recent-tech-layoffs-worried/    Show Points of Contact: Amanda Berlin: @infosystir @hackershealth  Brian Boettcher: @boettcherpwned Bryan Brake: @bryanbrake @bryanbrake@mastodon.social Website: https://www.brakeingsecurity.com Twitch: https://twitch.tv/brakesec  Youtube: https://youtube.com/c/BDSPodcast   

You ever make a mistake at work and not notice it for a few hours? You feel terrible. Or, if you're the engineers working at Three Mile Island, you cause a nuclear meltdown.  Chip and James change up the format a bit this week and tackle the same subject as they figure out central Pennsylvania almost got turned to an even bigger wasteland. SOURCES: Frontline, Weird History, New York Times, Nickolas Means (https://www.youtube.com/watch?v=hMk6rF4Tzsg), Wikipedia

This week Dylan is joined by Adam Balogh, Department Chair of Machine Technology at Laney College aka @Laneymachinetech on Instagram. Adam shares with us his backstory, starting in something surprisingly different than machining, to working with Tom Lipton at Lawrence Berkeley National Lab, to teaching young aspiring machinists. Adam talks about his projects, 3d printing, keeping students inspired, and more. Nickolas Means talk on 3 mile island: https://youtu.be/hMk6rF4Tzsg Laney College Machine Technology Department Website: https://laney.edu/machine_technology/ Instagram: @laneymachinetech (2x) YouTube Channels: Machine Tech Video Blog; Laney Machine Tech Berkeley Center for Magnet Technology at Lawrence Berkeley National Laboratory: https://bcmt.lbl.gov/ NYC|CNC Tour of Lawrence Berkeley National Laboratory: https://youtu.be/FmmNRaKpBTI East Bay Municipal Utility District (Local Water/Wastewater Utility with Repair Machine Shop): https://www.ebmud.com/ Terminal Manufacturing Co. (CNC/Manual Job Shop): https://www.terminalmanufacturing.com/ Book Mentioned: "The Instructor, the Man and the Job: A Hand Book for Instructors of Industrial and Vocational Subjects" by Charles Allen (Available @ https://archive.org/details/instructormanjob00allerich) Source for Inexpensive Quality Surplus Optics: www.surplusshed.com Dan Gelbart's Precision Air Bearing Lathe: https://youtu.be/sFrVdoOhu1Q Adam's YouTube Series on Autocollimators: https://youtube.com/playlist?list=PLL-aWzAbmoUn435Fq3MEAClddgrsPfXPO

In this episode, Dave and Jamison answer these questions: Questions I’m not a developer, and have never worked with developers. I have four years of systems/IT experience (ansible, bash, python, windows, etc). I got hired in a devops role at a company with many developers. How can I make sure I’ll have meaningful discussions (and a good learing experience) with software developers in my upcoming devops role at a new company? Will they notice that I don’t know what an enterprise communication bus is if just don’t ask but instead scribble something in my notebook? I just watched “How to crash an airplane” by Nickolas Means. It is about how the flight crew of an airplane crashed in 1989 yet saved 189 lives. The learning is that there are no heroes and teams can succeed only with inputs from all members in the team. All opinions need to be heard. And he also emphasizes that the captain used “we” in all his speeches. When it comes to interviews, the expectation is to talk about your personal experience. Using “we” during interviews would look like negative, right? Especially in leadership interviews, this is difficult since leaders are successful only with their team. Can you give us some strategies to balance this the best?

Parent Driven Development Episode 043: Pressure and Considerations Around Leaving a Job for Ethical Reasons. Welcome, Nick Means (https://twitter.com/nmeans)! Nickolas Means loves nothing more than a story of engineering triumph (except maybe a story of engineering disaster). When he's not stuck in a Wikipedia loop reading about plane crashes, he spends his days as a Senior Engineering Manager at GitHub working on Security and Compliance tooling for our users. He's also a co-host of the Managing Up podcast, a show about leading and managing in the world of technology. He works remotely from Austin, TX, and spends most of his spare time hanging out with his wife and kids, going for runs, or trying to brew the perfect cup of coffee. 01:54 How do you approach management with parents on your team? Treating your team as you would want to be treated as a parent Setting examples to your team as a manager Evaluate the job performance on the work actually done, and not clock a few hours taken off for kid responsibilities Flexibility and trust in team members and manager 07:12 Work life balance and work life integration Work sometimes becomes an escape from parenting life Self care for parents! No kids included, you need you 11:35 How do you encourage your team members to take time for themselves Ask the right questions to figure out what will fill their cup? As a manager, you’re more aware of the state of your team members and can identify things quicker Applaud team members when you see them take the effort for PTO 17:18 When you’re the only parent on the team.. How to make others understand Speak with kindness, set boundaries, have trust Time zone issues Setting boundaries with your team members How to structure workflow with team members in different zones 26:20 Managers making it explicit that it is OK to be done when you leave your workstation 28:02 Managing for non-remote teams Inflexibility when have to go into office Complexity for parents when they are totally out of the convo when working in an office 31:40 Moms vs. Dads double standard Putting family time on calendar Single parenting, the lack of help 33:40 How can managers support parental leave Encouraging more time for first time parents The job to support parents starts when they decide to have kids, not just during the leave Twins 37:50 Genius // fail Chris Sexton, how do you spell drop? #fail Josh had the sex talk…. but bombed on the timing with his daughter #geniusfail Allison has a nice turkey day with kids and neighbors, building her more positive memories! #genius Chris Arcand makes his nanny wait on her scheduled time off #fail Mandy gets a puppy… and it's a beautiful new experiences to share with her daughter Nick and his wife forget about homework… his son gets it done, but they all struggle the next day #fail Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com). Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel Allison McMillan (https://twitter.com/allie_p) Chris Arcand (https://twitter.com/chrisarcand) Josh Puetz (https://twitter.com/joshpuetz) Mandy Moore (https://twitter.com/therubyrep) Chris Sexton (https://twitter.com/crsexton) Special Guest: Nick Means.

Таймкоды: 04:50 - How to scale yourself as a first-time leader | Poornima Vijayashanker (https://youtu.be/LKkohgxsZdI) 19:15 - Bridging the gap between engineering and customer success | Annie Cook (https://youtu.be/5Bj4TLcBjnU) 27:10 - The four components of high performing teams | Lisa van Gelder (https://youtu.be/HcB7IeUClEk) 49:20 - Hiring junior developers remotely | Romina Suarez (https://youtu.be/4KMsgTQ6EaM) 01:03:00 - Splitting the monolith | Jimmy Bogard (https://youtu.be/oyY3Iec5IAc) 01:07:50 - The race to Mach 2.0 at scale | Nickolas Means (https://youtu.be/2sIzfGzf_50) 01:24:00 - Lessons from flying for engineering leadership | Rebecca Murphey (https://youtu.be/Tk1LFnoPvxM) 01:35:00 - On motherhood and leading engineering teams | Tara Feener (https://youtu.be/YdYZnvw7GGs) Мы в соцсетях: 1. Telegram: https://t.me/proConf 2. Youtube: https://www.youtube.com/channel/UCvasfOIImo7D9lQkb1Wc1tw 3. SoundCloud: https://soundcloud.com/proconf 4. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466 5. Twitter: https://twitter.com/ProconfShow

Nickolas Means likes to tell stories. His conference talks [1] often center around a curious anecdote, but he deftly weaves both technical and organizational relevancy into them. Nickolas talks about how he builds a talk from conception to execution and goes over some fundamentals of good presentation slides. The goal is to provide a narrative without overwhelming the user with too much textual content. He continues with advice for novices and experts alike, including how to craft a CFP that will increase the likelihood of your talk being accepted. He suggests that new speakers choose a larger conference to speak at, rather than a smaller one, as they have more capacity to provide mentoring. Even if you're not a Ruby or Rails developer, their conferences tend to be very welcoming, and he suggests taking a look at rubyconferences.com to find one that fits. Links from this episode Nickolas’ conference talks Nickolas Means on Confreaks TV How to Talk to Developers by Ben Orenstein What Your Conference Proposal Is Missing by Sarah Mei Better talk proposals in 3 easy steps

Travis and Brandon welcome new co-host Nickolas Means, Engineering Manager at GitHub, to talk about the tracks in engineering management, and the differing roles and responsibilities of the CTO and VP of Engineering. Show Notes: Eric Brooke: Software Engineering Leadership https://ericbrooke.wordpress.com/2018/09/16/software-engineering-leadership/ Camille Fournier: The Manager's Path https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897 Lara Hogan: Engineering Ladders at Meetup https://medium.com/making-meetup/engineering-ladders-at-meetup-caacbea4916e Camille Fournier: Rent the Runway's Engineering Ladder http://dresscode.renttherunway.com/blog/ladder

Failure Management and Response with Nickolas Means TableXI is offering training for developers and product teams! For more info, email workshops@tablexi.com. Guest Nickolas Means (https://twitter.com/nmeans) | nickol.as (http://nickol.as/) | VP of Engineering at MuveHealth (http://www.muvehealth.com/) Summary How can you learn from an engineering team's failure? Can you take the examples of how others have dealt with engineering problems to improve your team's day-to-day operations. Our guest is Nickolas Means, a software manager at Muve Health, who is fascinated by engineering failures. We talk about what you can learn from studying disasters, how to create a company culture in calm times that will works smoothly in stressful times, and how a successful engineering team communicates using stories and how they handle mistakes. Along the way, we talk about the recent incident at the Seattle Airport, the CitiCorp building in Manhattan, Three Mile Island and other engineering and team missteps. We have, I hope, a successful show about failure. Notes 02:12 - Learning From Engineering Team Failure Seconds From Disaster (https://en.wikipedia.org/wiki/Seconds_From_Disaster) 04:49 - Self-Reporting of Near Accidents How a change in hospital policy saved thousands of lives (https://www.vox.com/2017/10/23/16387300/hospital-policy-saved-thousands-lives-central-line-infection) 06:54 - First Story/Second Story RailsConf 2018: Who Destroyed Three Mile Island? by Nickolas Means (https://www.youtube.com/watch?v=YBRiffheLXE) The Field Guide to Understanding Human Error 2nd edition Edition (https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648257) 08:46 - How the Airline Worker Who Stole a Plane in Seattle Exposed a Security Risk (http://time.com/5368847/airline-security-risks/) 13:44 - The Design Flaw That Almost Wiped Out an NYC Skyscraper (http://www.slate.com/blogs/the_eye/2014/04/17/the_citicorp_tower_design_flaw_that_could_have_wiped_out_the_skyscraper.html) RubyConf 2016 - The Building Built on Stilts by Nickolas Means (https://www.youtube.com/watch?v=-ES1wlV-8lU) 99% Invisible Podcast: Structural Integrity (https://99percentinvisible.org/episode/structural-integrity-2/) 16:33 - Focusing on Blamelessness and Building a Learning Culture on a Team 21:04 - Overpaging Engineering Teams Charity Majors on overpaging (https://twitter.com/mipsytipsy/status/1028131196826349568) 25:21 - Story Communication Jeff Bezos Banned PowerPoint in Meetings. His Replacement Is Brilliant (https://www.inc.com/carmine-gallo/jeff-bezos-bans-powerpoint-in-meetings-his-replacement-is-brilliant.html) 29:44 - Helping Team Members Make Better Decisions The Boring Software Manifesto (http://www.noelrappin.com/railsrx/2016/5/26/the-boring-software-manifesto) Dan McKinley: Choose Boring Technology (http://mcfunley.com/choose-boring-technology) 34:29 - How to Behave When Things Go Wrong The Johnson & Johnson Tylenol Crisis (https://www.ou.edu/deptcomm/dodjcc/groups/02C2/Johnson%20&%20Johnson.htm) Related Episodes Developers from the Perspective of Product Owners (http://www.techdoneright.io/29) The Social Responsibility of Coding with Liz Abinante (http://www.techdoneright.io/25) Agile Teams and Escaping Velocity with Doc Norton and Claire Podulka (http://www.techdoneright.io/15) Special Guest: Nickolas Means.

We catch up with Nick Means at RailsConf and discuss storytelling, "human error", advice for job seekers, and the idea of licensing software developers. Nick on Twitter The Bike Shed #71: It's a Total Hack - Our earlier episode discussing Nick's previous keynote at RailsConf Skunk Works by Nickolas Means Skunk Works: A Personal Memoir of My Years at Lockheed The Field Guide to Understanding 'Human Error' Atomic Accidents: A History of Nuclear Meltdowns and Disasters Retro Report | Go or no Go: The Challenger Legacy Three Mile Island accident Southwest's Fatal Accident Prompts Scrutiny of Engine Inspections People wearing oxygen masks wrong xkcd: Compiling The Making of the Atomic Bomb: 25th Anniversary Edition Don't Get Distracted - Caleb Thompson

We wonder why writing parameterized associations in Rails is not easy, and discuss the difficulty in eliminating no-op queries in ActiveRecord. Plus, we discuss how you can give a great RailsConf talk proposal that doesn't have anything to do with Rails. RequestStore The IDs writer patch Derek sent Sean Skunk Works by Nickolas Means It's a Total Hack The Bike Shed episode inspired by Skunk Works Hanami Thank you to our sponsor this week, FreshBooks!

Inspired by Nickolas Means' fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin's Skunk Works projects and our software development projects. Sean's DXRacer Chair Skunk Works by Nickolas Means Lockheed Martin F-35 Lightning II Big Design Up Front Kelly's 14 Rules and Processes Rules Made Up by You - Kelly's rules as applied to modern software development Factory, Workshop, Stage by Sarah Mei The Tyranny of Structurelessness How to Crash an Airplane by Nickolas Means

Nickolas Means talked about airplanes, and in doing so, he connected them with code in beautiful and interesting ways. In this interview, Nick explains how to take seemingly disconnected subjects and put them together in compelling talks, and how he uses his public speaking training to turn these talks into inspiring performances. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Ruby Conf 2015 Brandon Hays Strunk and White's Elements of Style Here Be Dragons Scott Hanselman Conway's Law Skunkworks by Nickolas Means CodeNewbie Logo Contest NPR One App Codeland Conf Codeland 2019

While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews. Katrina Owen Katrina's conference talks Make the change easy, then make the easy change Skunk Works by Nickolas Means Factory, Workshop, Stage by Sarah Mei The Product Design Sprint Exercism.io Exercism GitHub Organization