<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Culture on Brave New Geek</title><link>https://bravenewgeek.com/tag/culture/</link><description>Recent content in Culture on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 14 Nov 2024 13:47:29 -0700</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/culture/index.xml" rel="self" type="application/rss+xml"/><item><title>Platform Engineering as a Service</title><link>https://bravenewgeek.com/platform-engineering-as-a-service/</link><pubDate>Thu, 14 Nov 2024 13:47:29 -0700</pubDate><guid>https://bravenewgeek.com/platform-engineering-as-a-service/</guid><description>&lt;p&gt;Like most industry jargon, “DevOps” means a lot of things to a lot of different people. While many folks view it as specific to certain tooling or practices, such as CI/CD or Infrastructure as Code (IaC), I’ve always viewed it as an organizational model for how software is built and delivered. In particular, my interpretation is that DevOps is about shifting more responsibilities “left” onto developers, moving away from the more traditional “throw it over the wall” approach to IT operations. No doubt this encompasses tooling or practices like CI/CD and IaC, which are responsibilities that developers now shoulder, perhaps with the support of dev tools, productivity, or enablement teams—some companies just call this the “DevOps” team.&lt;/p&gt;</description></item><item><title>SRE Doesn’t Scale</title><link>https://bravenewgeek.com/sre-doesnt-scale/</link><pubDate>Wed, 06 Oct 2021 09:44:55 -0600</pubDate><guid>https://bravenewgeek.com/sre-doesnt-scale/</guid><description>&lt;p&gt;&lt;a href="https://bravenewgeek.com/wp-content/uploads/2021/10/sre-book.jpeg"&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2021/10/sre-book.jpeg"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;We encounter &lt;em&gt;a lot&lt;/em&gt; of organizations talking about or attempting to implement SRE as part of our consulting at Real Kinetic. We’ve even discussed and debated ourselves, ad nauseam, how we can apply it at our own product company, &lt;a href="https://witful.com/"&gt;Witful&lt;/a&gt;. There’s a brief, unassuming section in the &lt;a href="https://sre.google/sre-book/table-of-contents/"&gt;SRE book&lt;/a&gt; tucked away towards the tail end of &lt;a href="https://sre.google/sre-book/evolving-sre-engagement-model/"&gt;chapter 32&lt;/a&gt;, “The Evolving SRE Engagement Model.” Between the SLIs and SLOs, the error budgets, alerting, and strategies for handling change management, it’s probably one of the most overlooked parts of the book. It’s also, in my opinion, one of the most important.&lt;/p&gt;</description></item><item><title>Structuring a Cloud Infrastructure Organization</title><link>https://bravenewgeek.com/structuring-a-cloud-infrastructure-organization/</link><pubDate>Mon, 07 Dec 2020 11:21:46 -0600</pubDate><guid>https://bravenewgeek.com/structuring-a-cloud-infrastructure-organization/</guid><description>&lt;p&gt;Real Kinetic often works with companies just beginning their cloud journey. Many come from a conventional on-prem IT organization, which typically looks like separate development and IT operations groups. One of the main challenges we help these clients with is how to structure their engineering organizations effectively as they make this transition. While we approach this problem holistically, it can generally be looked at as two components: product development and infrastructure. One might wonder if this is still the case with the shift to DevOps and cloud, but as we’ll see, these two groups still play important and distinct roles.&lt;/p&gt;</description></item><item><title>We suck at meetings</title><link>https://bravenewgeek.com/we-suck-at-meetings/</link><pubDate>Tue, 10 Nov 2020 13:16:18 -0600</pubDate><guid>https://bravenewgeek.com/we-suck-at-meetings/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2020/11/dilbert.gif"&gt;&lt;/p&gt;
&lt;p&gt;I’ve worked as a software engineer, manager, consultant, and business owner. All of these jobs have involved meetings. What those meetings look like has varied greatly.&lt;/p&gt;
&lt;p&gt;As an engineer, meetings typically entailed technical conversations with peers, one-on-ones with managers, and planning meetings or demos with stakeholders.&lt;/p&gt;
&lt;p&gt;As a manager, these looked more like quarterly goal-setting with engineering leadership, one-on-ones with direct reports, and decision-making discussions with the team.&lt;/p&gt;
&lt;p&gt;As a consultant, my day often consists of talking to clients to provide input and guidance, communicating with partners to develop leads and strategize on accounts, and meeting with sales prospects to land new deals.&lt;/p&gt;</description></item><item><title>Digitally Transformed: Becoming a Technology Product Company</title><link>https://bravenewgeek.com/digitally-transformed-becoming-a-technology-product-company/</link><pubDate>Wed, 05 Feb 2020 09:46:47 -0600</pubDate><guid>https://bravenewgeek.com/digitally-transformed-becoming-a-technology-product-company/</guid><description>&lt;p&gt;More and more established businesses are attempting to reinvent themselves as technology companies. At the heart of this is the &lt;a href="https://trends.google.com/trends/explore?date=all&amp;amp;geo=US&amp;amp;q=digital%20transformation"&gt;digital transformation&lt;/a&gt;, a journey many organizations are undertaking in order to better compete and serve their customers. As a result, companies are pouring tons of cash into digital transformation strategies. For some, this means broader adoption of agile or DevOps practices. For others, it’s modernizing product offerings or moving to the cloud. Regardless of the changes, many are struggling to find success transforming themselves due to low throughput, quality issues, or failing to deliver the right thing at the right time. In a few cases, digital transformation has ended in &lt;a href="https://www.theregister.co.uk/2019/04/23/hertz_accenture_lawsuit/"&gt;&lt;em&gt;outright disaster&lt;/em&gt;&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Planting Perennials Next to Potholes</title><link>https://bravenewgeek.com/planting-perennials-next-to-potholes/</link><pubDate>Fri, 26 Apr 2019 14:35:24 -0500</pubDate><guid>https://bravenewgeek.com/planting-perennials-next-to-potholes/</guid><description>&lt;h4 id="silos-bikesheds-and-focusing-on-what-matters"&gt;&lt;strong&gt;Silos, bikesheds, and focusing on what matters&lt;/strong&gt;&lt;/h4&gt;
&lt;p&gt;If you’ve ever flown into Des Moines then you’ve had the privilege of driving on what might be the most decrepit major road in the metro area. An important artery, Fleur Drive is the &lt;em&gt;only&lt;/em&gt; way to get to and from the airport, and the pavement is marginally better than that of a dirt road. Cars weave back and forth to dodge potholes and massive cracks in the asphalt as people race to catch their flights. There always appears to be some kind of construction going on somewhere along the six mile stretch of road, and yet, it never seems to actually &lt;em&gt;improve&lt;/em&gt;. The road is also located in a major floodplain, so sometimes the city just closes it when the nearby river rises too much. It’s basically what you’d get if you agiled your way through urban planning.&lt;/p&gt;</description></item><item><title>Operations in the World of Developer Enablement</title><link>https://bravenewgeek.com/operations-in-the-world-of-developer-enablement/</link><pubDate>Thu, 24 Jan 2019 11:28:40 -0600</pubDate><guid>https://bravenewgeek.com/operations-in-the-world-of-developer-enablement/</guid><description>&lt;p&gt;&lt;a href="https://blog.realkinetic.com/scaling-devops-and-the-revival-of-operations-d647ba6e2374"&gt;&lt;em&gt;NewOps&lt;/em&gt;&lt;/a&gt; is not a replacement for DevOps, it’s an evolution of it by &lt;a href="https://www.youtube.com/watch?v=JUy3GYkPfto"&gt;looking at Operations through the lens of product&lt;/a&gt;. It’s what I’ve come to call “Developer Enablement” because the goal is to shift the focus of Ops teams from being masters of production to &lt;em&gt;enablers&lt;/em&gt; of production. Through Developer Enablement, teams are enabled—and tasked with the responsibility—to control their own destiny. This extends far beyond just the responsibility of building products. It includes how we build, test, secure, deploy, monitor, and operate systems.&lt;/p&gt;</description></item><item><title>How to Level up Dev Teams</title><link>https://bravenewgeek.com/how-to-level-up-dev-teams/</link><pubDate>Thu, 03 Jan 2019 11:21:05 -0600</pubDate><guid>https://bravenewgeek.com/how-to-level-up-dev-teams/</guid><description>&lt;p&gt;One question that clients frequently ask: how do you effectively level up development teams? How do you take a group of engineers who have never written Python and make them effective Python developers? How do you take a group who has never built distributed systems and have them build reliable, fault-tolerant microservices? What about a team who has never built anything in the cloud that is now tasked with building cloud software?&lt;/p&gt;</description></item><item><title>GCP and AWS: What’s the Difference?</title><link>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</link><pubDate>Tue, 17 Jul 2018 11:58:21 -0500</pubDate><guid>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</guid><description>&lt;p&gt;AWS has long been leading the charge when it comes to public cloud providers. I believe this is largely attributed to &lt;a href="https://gist.github.com/chitchcock/1281611"&gt;Bezos’ mandate of “APIs everywhere”&lt;/a&gt; in the early days of Amazon, which in turn allowed them to be one of the first major players in the space. Google, on the other hand, has a very different DNA. In contrast to Amazon’s laser-focused product mindset, their approach to cloud has broadly been to spin out services based on internal systems backing Google’s core business. When put in the context of the very different leadership styles and cultures of the two companies, this actually starts to make a lot of sense. But which approach is better, and what does this mean for those trying to settle on a cloud provider?&lt;/p&gt;</description></item><item><title>Scaling DevOps and the Revival of Operations</title><link>https://bravenewgeek.com/scaling-devops-and-the-revival-of-operations/</link><pubDate>Wed, 18 Apr 2018 10:07:42 -0500</pubDate><guid>https://bravenewgeek.com/scaling-devops-and-the-revival-of-operations/</guid><description>&lt;p&gt;Operations is going through a renaissance right now. With the move to cloud, the increasing amount of automation, and the increasing &lt;em&gt;importance&lt;/em&gt; of automation, Ops as we know it is reinventing itself out of necessity. Infrastructure is becoming more and more sophisticated—and commoditized—and practices are just now starting to grow up around that. So while some worry about robots taking our jobs, the reality is more about how automation will help augment us to build better software and focus on higher-value things. It’s not so much about the &lt;em&gt;distant&lt;/em&gt; future—whatever that may hold—so much as it is about the next five to ten years, what Operations looks like in that timeframe, and why I think it has to retool.&lt;/p&gt;</description></item><item><title>Plant Trees Before You Need the Shade</title><link>https://bravenewgeek.com/plant-trees-before-you-need-the-shade/</link><pubDate>Mon, 29 Jan 2018 11:12:18 -0600</pubDate><guid>https://bravenewgeek.com/plant-trees-before-you-need-the-shade/</guid><description>&lt;p&gt;Like humans, companies go through phases. There’s the early seed and development phase. Founders are so preoccupied with a problem they go crazy. They consider solutions and the feasibility of a business. There’s the startup phase, when a business is actually born, and it stumbles towards product/market fit. There’s the growth and scaling phase, as we try to close more and more deals while, at the same time, hiring the right people. If we’re lucky, we reach the later stages. There’s the expansion phase, as we attempt to land and expand or attack new verticals or geographies. This is when things get really interesting—and &lt;em&gt;hard&lt;/em&gt;. &lt;em&gt;Who&lt;/em&gt; are the right people to hire? &lt;em&gt;What&lt;/em&gt; are the right products to build? The formula that got us here almost certainly won’t get us there. Lastly, there’s maturity, which is when the business has really hit its stride. Maybe there’s an exit, and very likely there’s new leadership involved.&lt;/p&gt;</description></item><item><title>Software Is About Storytelling</title><link>https://bravenewgeek.com/software-is-about-storytelling/</link><pubDate>Wed, 04 Oct 2017 17:20:59 -0500</pubDate><guid>https://bravenewgeek.com/software-is-about-storytelling/</guid><description>&lt;p&gt;Software engineering is more a practice in archeology than it is in building. As an industry, we undervalue storytelling and focus too much on artifacts and tools and deliverables. How many times have you been left scratching your head while looking at a piece of code, system, or process? It’s the &lt;em&gt;story&lt;/em&gt;, the legacy left behind by that artifact, that is just as important—if not &lt;em&gt;more—than&lt;/em&gt; the artifact itself.&lt;/p&gt;
&lt;p&gt;And I don’t mean what’s in the version control history—that’s often useless. I mean the real, &lt;em&gt;human&lt;/em&gt; story behind something. Artifacts, whether that’s code or tools or something else entirely, are not just snapshots in time. They’re the result of a series of decisions, discussions, mistakes, corrections, problems, constraints, and so on.  They’re the product of the engineering process, but the problem is they usually don’t capture that process in its entirety. They rarely capture it &lt;em&gt;at all&lt;/em&gt;. They commonly end up being nothing &lt;em&gt;but&lt;/em&gt; a snapshot in time.&lt;/p&gt;</description></item><item><title>Engineering Empathy</title><link>https://bravenewgeek.com/engineering-empathy/</link><pubDate>Sat, 03 Jun 2017 18:17:06 -0500</pubDate><guid>https://bravenewgeek.com/engineering-empathy/</guid><description>&lt;p&gt;This was a talk I gave at an internal R&amp;amp;D conference my last week at Workiva. I got a lot of positive feedback on the talk, so I figured I would share it with a wider audience. Be warned: it’s long. Feel free to read each section separately, though they largely tie together.&lt;/p&gt;
&lt;p&gt;Why do you work where you work? For many in tech, the answer is probably &lt;em&gt;culture&lt;/em&gt;. When you tell a friend about your job, the culture is probably the first thing you describe. It’s culture that can be a company’s biggest asset—and &lt;a href="https://www.recode.net/2017/2/19/14665076/ubers-travis-kalanick-susan-fowler-sexual-harassment-investigation"&gt;its biggest downfall&lt;/a&gt;. But what &lt;em&gt;is&lt;/em&gt; it?&lt;/p&gt;</description></item><item><title>On Hireability and Recruiting</title><link>https://bravenewgeek.com/on-hireability-and-recruiting/</link><pubDate>Sun, 01 Feb 2015 15:00:12 -0600</pubDate><guid>https://bravenewgeek.com/on-hireability-and-recruiting/</guid><description>&lt;p&gt;Developers deal with recruiter emails on a daily basis. It’s frustrating because it’s almost always a shotgun approach, but occasionally you get something that strays from the path and, delightfully, &lt;em&gt;it stands out&lt;/em&gt;. It’s refreshing to have someone who has actually taken the time to determine your skill set, technology background, and how you spend your free time with respect to software. You feel like they at least have an &lt;em&gt;inkling&lt;/em&gt; of who you are. On the other hand, it’s irritating to be bombarded by contract-to-hire offers which aren’t even &lt;em&gt;remotely&lt;/em&gt; tailored to you. What’s worse is when it’s ten different emails from ten different people working for the same recruiting agency.&lt;/p&gt;</description></item></channel></rss>