Podcasts about Pivotal Labs

Artificial intelligence is radically transforming software development. AI-assisted coding tools are generating billions in investment, promising faster development cycles, and shifting engineering roles from code authors to code editors. But how does this impact software quality, security, and team dynamics? How can product teams embrace AI without falling into the hype? In this episode, AI assisted Agile expert Mike Gehard shares his hands-on experiments with AI in software development. From his deep background at Pivotal Labs to his current work pushing the boundaries of AI-assisted coding, Mike reveals how AI tools can amplify quality practices, speed up prototyping, and even challenge the way we think about source code. He discusses the future of pair programming, the evolving role of test-driven development, and how engineers can better focus on delivering user value. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... Mike's background at Pivotal Labs and why he kept returning How AI is changing the way we think about source code as a liability Why test-driven development still matters in an AI-assisted world The future of pair programming with AI copilots The importance of designing better software in an AI-driven development process Using AI to prototype faster and build user-facing value sooner Lessons learned from real-world experiments with AI-driven development The risks of AI-assisted software, from hallucinations to security Mentioned in this episode Mike's Substack: https://aiassistedagiledevelopment.substack.com/ Mike's Github repo: https://github.com/mikegehard/ai-assisted-agile-development Pivotal Labs: https://en.wikipedia.org/wiki/Pivotal_Labs 12-Factor Apps: https://12factor.net/  GitHub Copilot: https://github.com/features/copilot Cloud Foundry: https://en.wikipedia.org/wiki/Cloud_Foundry Lean Startup by Eric Ries: https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898 Refactoring by Martin Fowler and Kent Beck https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599 Dependabot: https://github.com/dependabot Tessl CEO Guy Podjarny's talk: https://youtu.be/e1a3WuxTY-k  Aider AI Pair programming terminal: https://aider.chat/ Gemini LLM: https://gemini.google.com/app Perplexity AI: https://www.perplexity.ai/ DeepSeek: https://www.deepseek.com/ Ian Cooper's talk on TDD: https://www.youtube.com/watch?v=IN9lftH0cJc Mike's newest Mountain Bike IBIS Ripmo V2S: https://www.ibiscycles.com/bikes/past-models/ripmo-v2s Mike's recommended house slippers: https://us.giesswein.com/collections/mens-wool-slippers/products/wool-slippers-dannheim Sorba Chattanooga Mountain Biking Trails: https://www.sorbachattanooga.org/localtrails Subscribe to the Convergence podcast wherever you get podcasts, including video episodes on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5-star review and like the podcast on YouTube. It's how we grow.

As we put the final touches on our Season 2 premiere with Mike Gabbard, we're bringing you a replay of our conversation with Farhan Thawar, VP of Engineering at Shopify. Shopify has been a power user of AI coding assistants, gaining early access to GitHub Copilot before its general release. This episode is packed with insights on Shopify's culture, leadership, and how they leverage AI to ship better software faster. If you missed it the first time, now's the perfect chance to catch up—especially as it sets the stage for next week's discussion with Mike Gehard on AI-assisted product development. Enjoy, and we'll see you next week for the Season 2 premiere! -- In this episode of the Convergence Podcast, host Ashok Sivanand welcomes Farhan Thawar, the Vice President of Engineering at Shopify. Farhan's journey to Shopify came through the acquisition of Helpful, a company he co-founded. With a rich background in leadership roles at Microsoft, Trilogy, and as Vice President of Engineering at both Extreme Labs and Pivotal Labs—where Ashok had the pleasure of collaborating with him—Farhan brings a wealth of experience in building high-performing, engaging technical teams. This episode explores how Shopify, under Farhan's leadership, operates like a colossal experiment, constantly pushing the boundaries of experimentation and research and development across the company, not just within the product and engineering teams. Listeners will gain insights into Shopify's innovative use of generative AI to enhance customer and team experiences, the integration of tools like Copilot for pair programming, and the effective cultivation of a culture that fosters simplicity in code and robustness in product delivery. Farhan's approach to leadership has not only scaled to accommodate hundreds, if not thousands, of team members but has also maintained a strong focus on recruitment, attracting what he terms "F— yes candidates." The conversation also covers how Shopify's leadership remains deeply connected to their work and maintains technical sharpness, driving a culture where both the product and the people behind it thrive. Inside the episode... The learning mindset at Shopify.  Code isn't the artifact. The learning is the artifact.  Complexifiers versus simplifiers  Increasing leverage as an engineering leader Leaders should be involved in recruiting. How to get the best leverage on your time, and how to bring the support teams like HR and finance along to work like with an R&D and product mindset Pragmatic framework around process Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Farhan Thawar is the head of engineering at Shopify, where he oversees more than 1,000 engineers and a platform that powers over 10% of all U.S. e-commerce. Before Shopify, he was VP of engineering at Pivotal Labs and Xtreme Labs, and co-founder of Helpful.com. In our conversation, Farhan shares:• Why choosing the harder path leads to better outcomes• How to create intensity within your org (without burnout)• Why every company should be embracing pair programming• How he hires without interviewing• How he built the world's largest internship program• His mission to create a “crafter's paradise” for engineers• Much more—Brought to you by:• DX—A platform for measuring and improving developer productivity• Persona—A global leader in digital identity verification• Vanta—Automate compliance. Simplify security—Find the transcript at: https://www.lennysnewsletter.com/p/how-shopify-builds-a-high-intensity-culture-farhan-thawer—Where to find Farhan Thawar:• X: https://x.com/fnthawar• LinkedIn: https://www.linkedin.com/in/fnthawar—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Farhan's background(05:38) Choosing the hard path(09:37) Getting comfortable with looking dumb(13:20) Lessons from working with visionaries(19:19) Creating intensity in organizations(22:06) The power of pair programming(29:18) Shopify's culture of intensity(37:18) Meeting Armageddon: revolutionizing company meetings(39:46) Reducing distractions(41:10) Deleting 1M+ lines of code(49:05) Three buckets of building(57:45) Remote work and trust battery(01:00:29) Finding stability in uncomfortable times(01:03:14) Hiring philosophy(01:11:41) Internship programs and co-op systems(01:15:32) Lessons from managing 120 direct reports(01:20:40) Failure corner(01:27:46) Lightning round and closing thoughts—Referenced:• The Steve Jobs quote about connecting dots: https://www.goodreads.com/quotes/463176-you-can-t-connect-the-dots-looking-forward-you-can-only• Shopify: https://www.shopify.com/• GitHub: https://github.com/• Farhan's “questions to ask” framework: https://x.com/fnthawar/status/1514193402828574721• Palantir: https://www.palantir.com/• Joe Liemandt: https://www.linkedin.com/in/liemandt• Chamath Palihapitya: https://en.wikipedia.org/wiki/Chamath_Palihapitiya• Xtreme Labs: https://www.xtremelabs.io• Parkinson's law: https://www.verywellmind.com/what-is-parkinsons-law-6674423• Pair programming: https://dev.to/documatic/pair-programming-best-practices-and-tools-154j• Cody Fauser on LinkedIn: https://www.linkedin.com/in/codyfauser• How Shopify builds product: https://www.lennysnewsletter.com/p/how-shopify-builds-product• Chaos Monkey: We look at Shopify's new ‘culture of focus': https://www.siliconrepublic.com/careers/shopify-chaos-monkey-meetings-culture-deann-evans• Empowering devs with AI: How Shopify made GitHub Copilot core to its culture: https://www.youtube.com/watch?v=wVKBwcm5dbw&t=2318s• Tobi Lütke of Shopify: Powering a Team with a ‘Trust Battery': https://www.nytimes.com/2016/04/24/business/tobi-lutke-of-shopify-powering-a-team-with-a-trust-battery.html• Brian Chesky's new playbook: https://www.lennysnewsletter.com/p/brian-cheskys-contrarian-approach• Stop Being Deceived by Interviews When You're Hiring: https://www.forbes.com/sites/forbesleadershipforum/2012/02/07/stop-being-deceived-by-interviews-when-youre-hiring/• Shopify's made the Life Story a major part of their interview: https://news.ycombinator.com/item?id=39294140• Internships at Shopify: https://internships.shopify.com• Nick Adams on LinkedIn: https://www.linkedin.com/in/nick-adams-32b28139• React Native: https://reactnative.dev• Swift: https://www.swift.org• Acquired podcast: The Mark Zuckerberg interview: https://www.acquired.fm/episodes/the-mark-zuckerberg-interview• The Power of Performance Reviews: Use This System to Become a Better Manager: https://review.firstround.com/the-power-of-performance-reviews-use-this-system-to-become-a-better-manager• Airbnb's Vlad Loktev on embracing chaos, inquiry over advocacy, poking the bear, and “impact, impact, impact” (Partner at Index Ventures, Airbnb GM/VP Product): https://www.lennysnewsletter.com/p/impact-impact-impact-vlad-loktev• The Secret to a Great Planning Process—Lessons from Airbnb and Eventbrite: https://review.firstround.com/the-secret-to-a-great-planning-process-lessons-from-airbnb-and-eventbrite• How to do great work: https://www.paulgraham.com/greatwork.html• Challengers on Prime: https://www.amazon.com/Challengers-Luca-Guadagnino/dp/B0CX5MZ9M4• Halt and Catch Fire on Prime: https://www.amazon.com/Halt-Catch-Fire-Season-1/dp/B0CKXZNT96• Meta Ray-Bans: https://www.meta.com/smart-glasses/shop-all• Making Meta | Andrew ‘Boz' Bosworth (CTO): https://www.lennysnewsletter.com/p/making-meta-andrew-boz-bosworth-cto—Recommended books:• The Undoing Project: A Friendship That Changed Our Minds: https://www.amazon.com/Undoing-Project-Friendship-Changed-Minds/dp/0393254593• Range: Why Generalists Triumph in a Specialized World: https://www.amazon.com/Range-Generalists-Triumph-Specialized-World/dp/0735214484• Manna: Two Visions of Humanity's Future: https://www.amazon.com/Manna-Two-Visions-Humanitys-Future-ebook/dp/B007HQH67U• Business Adventures: Twelve Classic Tales from the World of Wall Street: https://www.amazon.com/Business-Adventures-Twelve-Classic-Street/dp/1504000021—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

How can teams unlock elite productivity while navigating the complexities of DevOps? Expert consultant Xing Zhou reveals how DORA metrics—from deployment frequency to change failure rate, drive performance and bridge gaps between leadership and the team members. Xing's impressive career spans companies like Amazon, Pivotal Labs, and Integral. He currently serves as  Xing has led high-performing teams, implemented cutting-edge DevOps strategies, and helped organizations make meaningful progress toward elite DORA benchmarks. Xing and Ashok discuss actionable steps for C-Suite leaders and product teams, focusing on SLAs, CI/CD, behavior-driven development, and event storming workshops to drive alignment and enhance productivity. Packed with real-world examples, this conversation is essential listening for anyone aiming to turn metrics into a reflection of team health and organizational success. Inside the episode... A clear explanation of Dora metrics: what they are and why they matter. How SLAs and SLOs empower teams while aligning with organizational goals. Continuous delivery (CD): balancing technical capability with business priorities. The difference between pull request (PR) and trunk-based development for CI. Behavior-driven development (BDD) and its role in improving test automation. Event storming: how this simple tool drives clarity in business processes. Practical strategies for introducing new practices like BDD or event storming to your team. Mentioned in this episode: Behavior-Driven Development (BDD) Gherkin language for test automation Event storming Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Edward Hieatt (@edwardhieatt, Chief Customer Officer @mech_orchard) talks about app modernization and the advancements and developments to increase progress.SHOW: 867Want to go to All Things Open in Raleigh for FREE? (Oct 27th-29th)We are offering 5 Free passes, first come, first serve for the Cloudcast CommunityRegistration Link - www.eventbrite.com/e/916649672847/?discount=Cloudcastfree  Instructions:Click reg linkClick “Get Tickets”Choose ticket optionProceed with registration (discount will automatically be applied, cost will be $0)SHOW TRANSCRIPT: The Cloudcast #867 TranscriptSHOW VIDEO: https://youtube.com/@TheCloudcastNET CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS" SHOW NOTES:Mechanical Orchard (homepage)Startup led by ex-Pivotal CEO lands $50M to modernize apps (TechCrunch)Topic 1 - Welcome to the show. Tell us about your background, and then give us a little bit of background on Mechanical Orchard.Topic 2 - Many of the MO team come from Pivotal (especially Pivotal Labs), as well as being involved with the Agile Manifesto, Extreme Programming, etc. How did the mission of the company get focus on modernizing existing applications?Topic 3 - Modernization projects have traditionally been really costly, with a low success rate. Why is now the right time to focus on this area?Topic 4 - I'm really interested in how MO technology works. It seems like a variation of a digital twin, mixed with some AI capabilities. Give us the big picture of how this is a different approach to modernization.Topic 5 - How much culture/process change is needed with MO to be successful? Topic 6 - What do the stages of success look like with your approach to application modernization?FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

Farhan Thawar, VP & Head of Engineering @ Shopify, was our first-ever ELC pod guest, so it's fitting that he's here to join us for this culmination of our series tackling the Top 10 challenges that engineering leaders face in a rapid-fire, high-energy format! Farhan shares insights into individual challenges, including motivating others after a reorg or period of uncertainty, why always being willing to learn & help is key for managing in any direction, strategies for creating buy-in, and best practices for coaching / mentoring. We cover team challenges, such as working cross-functionally to identify a shared truth and vision, using demos to measure dev productivity, and maintaining high velocity without losing quality. Farhan also dives into org-wide challenges, like understanding team topologies & building out your org's resources.ABOUT FARHAN THAWARFarhan Thawar (@fnthawar) is VP, and Head Engineering at Shopify via the acquisition of Helpful.com where he was co-founder and CTO. Previously he was the CTO, Mobile at Pivotal and VP, Engineering at Pivotal Labs via the acquisition of Xtreme Labs. Farhan is an avid investor and advisor to startups in Toronto and San Francisco, including being a mentor at yCombinator and First Round Capital. Previously, Farhan held senior technical positions at Achievers, Microsoft, and Trilogy. Farhan completed his MBA in Financial Engineering at Rotman and Computer Science/EE at Waterloo.Join us at ELC Annual 2024!ELC Annual is our 2 day conference bringing together engineering leaders from around the world for a unique experience help you expand your network and empower your leadership & career growth.Don't miss out on this incredible opportunity to expand your network, gain actionable insights, ignite new ideas, recharge, and accelerate your leadership journey!Secure your ticket at sfelc.com/annual2024And use the exclusive discount code "podcast10" (all lowercase) for a 10% discountSHOW NOTES:Strategies for motivating your team after reorgs, rifts, or other uncertain times (2:37)Farhan's favorite quick wins & ways to re-engage with your team (4:48)Managing up & sideways by being transparent and always looking to help (7:31)Be dedicated to learning / bouncing ideas around with others (9:59)Frameworks for identifying the long-term, winning opportunities to pursue (12:13)How to influence & create buy-in around ideas (15:26)Navigating situations where your idea / perspective is facing resistance (18:18)Best practices for messaging a pitch when working cross-functionally (21:03)Utilizing individual frameworks when mentoring & coaching (23:10)Questions to ask when developing a personal career development framework (27:30)Approaching performance-related conversations (29:11)How to use demos to measure developer productivity (32:09)Methods for maintaining high velocity without losing quality (35:21)Insights on team topologies & identifying / building the needs of your org (37:14)This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/

In this episode of Product Coffee, Kevin Gentry interviews Scot Przybylski, a seasoned designer and product manager with extensive experience in UX and product design. Scot discusses his journey from graphic design to UX design, his work with notable companies like Dish Network and Pivotal Labs, and the challenges and strategies involved in transforming traditional product teams into empowered, collaborative units. He shares insights on change management, the critical role of design in product development, and the importance of innovation and psychological safety within teams. Scot highlights specific examples of successful transformations and innovations in product design and development, offering valuable advice on managing relationships, fostering accountability, and driving organizational change. Find out more! - Find Scot on LinkedIn - Find Kevin on LinkedIn Timeline: 00:00 Introduction to Product Coffee 00:27 Meet Scot: A Journey in Product Design 01:08 Transitioning to UX and Product Management 02:39 Challenges in Organizational Change 04:56 Implementing Agile and Change Management 06:56 Design's Strategic Importance 08:35 Wins from Design and Usability Improvements 11:27 Building Effective Product Teams 14:12 Facilitating Design Critiques and Psychological Safety 16:13 Fostering Innovation in Product Development 21:21 Empowered Teams and Leadership Training 25:20 Accountability in Product Teams 27:48 Design Practices for Product Managers 30:37 Coaching and Mentoring in Design 33:59 Final Thoughts and Homework Follow us on ⁠⁠LinkedIn⁠⁠, ⁠⁠Instagram⁠⁠, or ⁠⁠X⁠⁠ & check out our website @ ⁠⁠productcoffeepodcast.com⁠⁠ ☕️ --- Send in a voice message: https://podcasters.spotify.com/pod/show/product-coffee/message

In this episode of the Convergence Podcast, host Ashok Sivanand welcomes Farhan Thawar, the Vice President of Engineering at Shopify. Farhan's journey to Shopify came through the acquisition of Helpful, a company he co-founded. With a rich background in leadership roles at Microsoft, Trilogy, and as Vice President of Engineering at both Extreme Labs and Pivotal Labs—where Ashok had the pleasure of collaborating with him—Farhan brings a wealth of experience in building high-performing, engaging technical teams. This episode explores how Shopify, under Farhan's leadership, operates like a colossal experiment, constantly pushing the boundaries of experimentation and research and development across the company, not just within the product and engineering teams. Listeners will gain insights into Shopify's innovative use of generative AI to enhance customer and team experiences, the integration of tools like Copilot for pair programming, and the effective cultivation of a culture that fosters simplicity in code and robustness in product delivery. Farhan's approach to leadership has not only scaled to accommodate hundreds, if not thousands, of team members but has also maintained a strong focus on recruitment, attracting what he terms "F— yes candidates." The conversation also covers how Shopify's leadership remains deeply connected to their work and maintains technical sharpness, driving a culture where both the product and the people behind it thrive. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Access Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... The learning mindset at Shopify.  Code isn't the artifact. The learning is the artifact.  Complexifiers versus simplifiers  Increasing leverage as an engineering leader Leaders should be involved in recruiting. How to get the best leverage on your time, and how to bring the support teams like HR and finance along to work like with an R&D and product mindset Pragmatic framework around process Subscribe to the Convergence podcast wherever you get podcasts including video episodes on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow. 

Welcome to the Convergence podcast! I'm Ashok Sivanand and I've created the Convergence podcast to help you build the most engaged product teams who can ship the most successful products. My passion for products and timing stems from a combination of my working in Japanese manufacturing, building IoT software products for lean manufacturers, and working at industry powerhouses in product like Pivotal Labs. This passion led to founding Integral in 2017, a product engineering consultancy that enables our clients to harness technology to develop better products, grow their revenue streams, and enable new business models. We've had the pleasure to collaborate with brands like Ford, Honda, Rocket Mortgage, Airstream, and Bosch to enable their teams and build some amazing products in artificial intelligence, cloud, mobile, and web. On the Convergence podcast, I'll be speaking with industry leaders, as well as sharing insights from my team on deconstructing the best practices, principles, and philosophies that lead to building the best product teams. If you're a chief product officer, a chief technology officer, or a VP of engineering, or you're growing towards one of those roles, I highly recommend you subscribe to the Convergence Podcast and get some of the insights that will help you lead your product teams and enable them to consistently ideate, validate and ship products that your customers love. Products that will help you grow your business. Thanks a lot for listening.

We talk with Raquel Breternitz about her love for comics. Raquel has a particular interest in indie comics and autobiographical work, appreciating how they can tell unique and often painful stories. She recounts her personal history with comics, starting with reading them as a child, and rediscovering her passion for them during college through works that profoundly impacted her life. She reflects on how comics blend the literary and visual arts, creating a unique medium that matches the complexity of human communication. The conversation touches on the comics community's openness and supportiveness, Raquel's evolving taste in comics, and her current reading list.Guest BioRaquel Rubio Breternitz (she/they) is an award-winning designer with a unique bent for research-driven work built with craft and polish. She is dedicated to inclusion, accessibility, and keeping tech human (and human-focused).With a diverse background in purpose-driven work across product design and brand, Raquel has served as Design Director for Senator Elizabeth Warren and has contributed to organizations including the United States Citizenship and Immigration Services, Shopify, the New York Times, Pivotal Labs, and IBM. Currently, they are a founding lead designer at GoodDay software.In addition to her professional accomplishments, Raquel is a writer, public speaker, panel moderator, and sketchnoter. In their free time, they draw comics, tear through fiction novels, play rhythm guitar, and take waaay too many photos of their cat.LinksRaquel on Twitter/X: https://twitter.com/RaquelDesigns/Raquel on Instagram: https://www.instagram.com/raquelbreternitz/Alison Bechdel and Fun Home: https://dykestowatchoutfor.com/fun-home-2/Black Hole: https://50wattsbooks.com/products/black-hole-pantheon-graphic-libraryGhost World: https://www.fantagraphics.com/products/ghost-world-softbackAdrian Tomine: http://adrian-tomine.com/Booksandcomics.htmlLenore Yerkes: https://lenorayerkes.com/aboutJillian Tamaki: https://www.jilliantamaki.com/books; Mariko Tamaki: http://marikotamaki.blogspot.comSquire: https://sara-alfa.com/books/squire/- and writer Nadia Shammas: https://www.nadiashammas.com/comicsEden ii, K. Wroten: https://www.fantagraphics.com/products/eden-iiTillie Walden: https://www.tilliewalden.com/booksCreditsCover design by Raquel Breternitz herself!

Au risque d'enfoncer une porte ouverte : partager du feedback est essentiel pour faire grandir son équipe. Mais vous sentez vous toujours à l'aise lorsqu'il s'agit d'en donner (ou d'en recevoir

Sign up for The Automotive Leaders Letter Watch the full video on YouTube - click hereEmbark on an automotive innovation journey with Ashok Sivanand, Founder and CEO of Integral, as we explore how he actively shapes the future of product design, technology, and leadership in the automotive industry.In this episode, Ashok shares his insights on:

In this episode of Product Coffee, Kevin welcomes Adam Oliver, Founder, and CEO of Crafted, a product development consultancy. Adam shares his product management journey, the challenges of transitioning into a leadership role as a founder, and offers insights on product development, advocating for a lean, iterative approach. He also discusses the importance of balanced teams, stressing the need for product design engagement. As a leader in times of economic uncertainty, Adam recommends a careful approach to spending and decision-making. He envisions AI and ML having an impactful role in product development in the future. 00:00 Introduction and Guest Introduction 00:53 Adam's Journey into Product Management 02:25 Adam's Experience with Pivotal Labs 03:35 Adam's Transition from Real Estate to Tech 04:59 Discussion on Extreme Programming 07:13 Adam's Experience with Pivotal Labs' IPO 09:56 Challenges and Benefits of Consultancy Work 13:44 Importance of Regular Product Hygiene 17:37 Staying Scrappy in Product Development 23:34 Balanced Teams for Project Success 24:31 The Importance of UI/UX in Software Development 25:04 The Evolution of Software and the Role of Engineers 25:47 The Impact of UI/UX on Engineering Efficiency 27:33 The Role of UI/UX in API Development 28:38 The Slow Recognition of UI/UX Importance in the Industry 29:11 The Concept of Iteratively Shipping Products 31:55 The Role of Product Marketing in Bridging the Gap 33:45 The Shift to Profitability and EBITDA Focus 38:28 The Challenges of Transitioning to a Founder Role 45:59 The Future of Product Development --- Send in a voice message: https://podcasters.spotify.com/pod/show/product-coffee/message

Recording Date: 2023-11-15 Hosts: Tony Hansmann && Jesse Alford Guest Name: Thomas Squeo Social media: LinkedIn: https://www.linkedin.com/in/thomassqueo/   Previous interview on Youtube.com: https://youtu.be/iZCPAHwhTWI?si=CfjhBEkyqN69x4eF Guest: Thomas Squeo Title: Let's Play “Bet your Badge” with Thomas Squeo (01h:30m) One of the greatest things about being in the field for Cloud Foundry was meeting leaders who were deploying not just Cloud Foundry but an array of transformation solutions.  Thomas Squeo's roots in XP go back to the early 2000s when he was an early Beck practitioner who worked with both Pivotal Labs and Thoughtworks. What sets Thomas apart is that he has done everything from being a line developer to being the CTO of Entrado, a global 911 provider, among other things. Jesse and Tony talk about what it takes to not just do XP but also what the IRL challenges you will face when transforming an organization. Grab a notebook and buckle up.

Recording Date: 2023-11-13 Hosts: Tony Hansmann && Jesse Alford Guest Name: Drew McManus Drew has a 30+ year career with orgs that are serious about software. He got involved with Pivotal Labs around 2006 and shepherded the practice until 2020.  Social media: LinkedIn: https://www.linkedin.com/in/drewmcmanus/

Chelsea placed the start of her journey in undergrad with the insightful tale of an introduction to programming class involving a peanut butter & jelly sandwich. We then discussed how one teacher cut her wings by telling her she "lacked the intellectual firepower" to become a dev. She went on to study to become a spy instead. Just before entering this world, she realized she had missed the feeling she had had during this first programming class and decided to embrace development in a boot camp. We talked about her learning habits and how they helped her get a job at Pivotal Labs; we talked about legacy code and how those learning habits helped her become excellent at gaining context.Here are the links from the showhttps://www.twitter.com/HeyChelseaTroy@heychelseatroy@social.clawhammer.nethttps://chelseatroy.com/Peter Michael Oseara https://osera.cs.grinnell.edu/https://chelseatroy.com/2014/10/03/pairing-with-the-pros-a-day-at-pivotal-labs/https://chelseatroy.thinkific.com/collectionsOn September https://www.thestrangeloop.com/ Felienne (https://github.com/Felienne)'s annotation tool https://annotate.codereading.club/#/https://www.oreilly.com/live-events/legacy-code-boot-camp/0636920086297/https://www.oreilly.com/live-events/technical-debt-first-steps/0636920058624/0636920058623/https://anyonecanlearntocode.com/Music cover: Legends by HoliznaCC0 is licensed CC0 1.0 Universal License.The Imposter Syndrome Network PodcastFun conversations about technology careers that inform and inspire. =) Listen on: Apple Podcasts SpotifySupport the show Become a supporter of the show on Patreon or on Buzzsprout (our hoster). Gift the podcast a rating on the platform of your choice. Your host is Timothée (Tim) Bourguignon; more about him at timbourguignon.fr.

Robby has a chat with Nadia Odunayo (she/her/hers), the Founder and CEO at The StoryGraph. Nadia starts off by highlighting solid test coverage, up-to-date GeM language platform versions, all security patches, and proper documentation as some of the few common characteristics of maintainable software. She talks about when it makes sense to document debugging processes for your future self, the tradeoffs made when you're the solo developer and founder of a software project, how she approaches product management, how working within Pivotal Labs influenced her approach, and the differences one experiences going from an environment of constant pairing to being a solo developer.They also dive into why every engineer should be comfortable clearing out their product's icebox, the realities of being a solo developer and thinking about vacations, the fine line between premature and proactive optimization, and everything that The StoryGraph app has to offer. Nadia's engineering wisdom will be super insightful so don't miss out!Book Recommendations:Nonviolent Communication by Marshall B. RosenbergThe Eighth Life (for Brilka) by Nino HaratischwiliHelpful Links:Nadia's Websitehttps://www.thestorygraph.com/Nadia on TwitterThe StoryGraph on TwitterSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

On this episode of Ruby for All, Andrew and Julie have joining them, Dave Paola, Founder of Sierra Rails, a Ruby on Rails Software Development Agency. Today, Dave talks about his experience coaching Junior Developers and Early Career Developers.  There's a discussion on the success of Pivotal Labs and the importance of hiring Early Career Developers in pairs.  Dave tells us about his Junior Developer Bootcamp and his aspirations to help Junior Developers kickstart their careers. Andrew, Dave, and Julie discuss the importance of hiring Junior Developers in pairs to improve their onboarding experience, and the value of retro meetings or biweekly team meetings to improve team culture and processes.  We'll also hear about Dave's experimental program, The Agency of Learning, which focuses on helping Early Career Developers prepare for their first job through a volunteer-based pilot. Press download to hear more! [00:00:55] Dave tells us a little bit about himself, why he prefers Early Career Developer versus Junior, and Julie explains why she prefers Early Career Developer.  [00:04:23] We hear a story that Dave shares about the success of Pivotal Labs, which is gone, and their great approach to hiring in pairs, starting a Junior Developer Bootcamp,  and how this evolved into him writing a book.[00:07:17] What made Pivotal Labs so prolific back in the days?[00:11:20] Dave explains why he believes in pairing Juniors together.[00:12:10] Andrew shares his pairing story when he first started out, and Dave shares a story as to why he thinks psychology has a lot to do with hiring in pairs.[00:16:16] We hear some experiences Andrew had in computer science school with people being put in impossible situations and they end up quitting, and then the positive experience he had when he started at Podia. Julie shares her school experience working in groups.[00:20:12] Dave stresses the benefits of holding weekly retro meetings to improve team culture and processes. [00:21:58] Andrew tells us at Podia they do biweekly developer meetings which he finds more helpful than weekly retro meetings. He stresses the importance of getting the team together, especially for the Juniors or Early Career Developers. Dave highlights the benefits of meetings for developers to come together and share challenges and ideas.[00:24:52] Julie tells us about her biweekly engineering meetings, where there's no leadership, but teams, and the engineers get together and just be real.[00:25:57] Dave talks about his experiment, The Agency of Learning, which is a volunteer-based pilot for Early Career Developers who are looking for their first job. He's looking for coaches, so if you're interested, please reach out to him.  [00:29:26] Find out where you can follow Dave online. Panelists:Andrew MasonJulie J.Guest:Dave PaolaSponsors:HoneybadgerAvoLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. WebsiteDave Paola TwitterDave Paola LinkedInDave Paola Websitedave@sierrarails.comSierra RailsThe Agency of Learning

Ashok Sivanand is the CEO of Integral, a digital transformation firm that helps businesses with embedding a technology DNA to their culture, processes, and experiences by collaborating to build delightful products and high-performing product teams. Ashok is a student of the automotive and manufacturing industry and has worked as a forklift driver on the line, developed applications at a General Motors plant, and various product roles at an industrial IoT startup called Shoplogix. Ashok transitioned this knowledge of lean manufacturing to lean-agile software while serving on the leadership team at Pivotal Labs. At Pivotal, Ashok visited Detroit from Toronto to help Ford build a development lab called FordLabs; loved Detroit so much that he decided to stay and start Integral here. Integral also sponsors integratedetroit.org to help bridge the race and gender gap amongst Detroit's technologists. Connect with Behind Company Lines and HireOtter Website Facebook Twitter LinkedIn:Behind Company LinesHireOtter Instagram Buzzsprout

В 44 выпуске подкаста Javaswag поговорили с Алексеем Нестеровым о работе в Pivotal, разработке Спринга и переходе на Golang 00:02:30 О себе 00:04:36 Переход в Pivotal Labs, апологет Agile, TDD, Lean разработки 00:12:58 Парное программирование 00:20:10 Как начал пилить Spring Framework 00:27:12 Лучшая команда Спринга 00:32:22 Что нравится и бесит в Спринге 00:35:58 Пишем на аннотациях а не на Джаве 00:46:40 Полумикросервисный подход 00:50:06 Нативная компиляция 00:53:32 Будущее 00:55:50 Почему Го 01:00:56 На Джаве же можно тоже писать простой код 01:05:14 Почему писать код удобней 01:09:18 Бинарник в Го или нативная компиляция в Джава 01:12:30 Гонка веб-серверов 01:18:20 Почему в Голэнге один нормальный сборщик мусора 01:20:54 if err != nil 01:24:54 Скучная архитектура 01:26:09 Что бесит в Го 01:29:38 Unpopular Opinion Гость - https://twitter.com/alek_sys Кип сейф! 🖖

Welcome to Remote Ruby and thanks for joining us! It's a full house this week as Jason, Chris, and Andrew are back together! They also have a great guest joining them, Nadia Odunayo, who's the Founder, CEO, and Software Developer of The StoryGraph, a book tracking, and recommendations app. Nadia spoke at the Rails SaaS Conference and her talk was titled, “Getting to one million users as a one-woman dev team.” After listening to this episode, you'll understand why she's such an engaging speaker.  Today, Nadia shares her journey of how she got into programming and building software apps, to being the Founder of The StoryGraph.  She shares some interesting things about scaling and Elasticsearch, we'll hear about her project Speakerline, and we'll find out how she got into public speaking and how her approach to conference speaking is like product building. Download this episode now to learn more! [00:04:07] Nadia tells us her background, what she does, and why she created The StoryGraph app.[00:07:24] We hear a great story on how Nadia got into programming. [00:11:31] Nadia explains how she first experienced Ruby at the Code First Girls program, and at the boot camp that was Ruby and Rails focused.[00:12:19] We learn about Nadia's journey from working at Pivotal Labs to where she is today with The StoryGraph. [00:15:38] In Nadia's talk she mentioned “financial independence” and Andrew wonders what kind of journey she takes when she builds these kinds of software apps.[00:19:59] The StoryGraph is written in Ruby and Jason wants to know if Nadia is still happy with her decision to use Ruby all these years later. [00:22:55] Nadia shares some interesting things about scaling.[00:29:13] Find out about Nadia's journey with Elasticsearch. [00:36:00] Dark Mode is brought up which is the most requested feature on the app and Nadia tells us that she has been working on it. Andrew of course loves it, and he tells us about using Radix colors. [00:38:18] We hear how Nadia got into public speaking, a story about meeting Sarah Mei, her project Speakerline, and she shares advice to people who think public speaking is not for them.[00:47:42] Nadia tells us her approach to conference speaking is like product building, Jason tells us his talks got better when he started bringing other people in, and Andrew highly recommends Speakerline. [00:54:00] Find out where you can follow Nadia onlinePanelists:Jason CharnesChris OliverAndrew MasonGuest:Nadia OdunayoSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterNadia Odunayo WebsiteNadia Odunayo TwitterNadia Odunayo InstagramThe StoryGraphThe StoryGraph TwitterThe StoryGraph InstagramThe StoryGraph TikTokThe StoryGraph MastodonCode First GirlsRadix colorsSpeakerlineSarah Mei-What Your Conference Proposal is MissingRuby Radar TwitterRuby for All Podcast

Ben Brennan, QSTAC CEO, author, and former IT exec at Yahoo and Verizon Media, is a world traveler, a musician, and a trained psychologist with passions for philosophy and psychotherapy. Not exactly the traditional background for an IT leader. Early roles at Pivotal Labs and Jawbone taught Ben that bringing humanity to technology is the future of work. He since published Badass IT Support and started QSTAC to measure the employee experience. Listen and learn...What Ben learned managing 100 people and supporting 15,000 employees at YahooHow the culture at Pivotal Labs inspired Ben's philosophy on quantifying the employee experienceHow Ben convinced a former Apple leader why QSTAC is better than NPSWhy CSAT scores don't actually correlate with how satisfied employees are at workHow the principles of Design Thinking can be used to run ITWhat IT must do to avoid being "Uber-ed" like the taxi industryReferences in this episode...Dion Hinchcliffe on AI and the Future of WorkTim Crawford on AI and the Future of WorkMatt K. Parker on AI and the Future of WorkO'Reilly's 2021 AI adoption in the enterprise surveyQSTAC

Rob sits down with Drew McManus, CEO of 33 Teams to discuss Agile development. Hear stories from Drew's time at Pivotal Labs and the valuable lessons he's taking with him. This episode covers how to suggest change, finding the best Agile practices for you, and how working with the right people may be worth a career shift. Tune in today!Have a topic you want us to discuss? Someone you want us to interview? Reach out to us on Twitter @circleci!

Matt K. Parker, author and engineering leader formerly at Pivotal Labs, profiled 13  collaborative work cultures in his book A Radical Enterprise. They're devolving control to employees and rethinking traditional organizational structures to give teams unprecedented levels of freedom. Not surprisingly, they're more successful than their peers. Listen and learn:What is a radical enterprise and what is radical collaboration?Why do employees do better work when they have freedom to define their own rules?What are the benefits of embracing the concepts of self-organizing and self-managing teams?Why do traditional performance management techniques like annual reviews create implicit threats in the workplace that demotivate employees?What does it mean to make every employee "a company of one"?Why, according to Deming, "a bad system will beat a good employee every time."References in this episode:Matt's website and a link to his Slack communityA Radical Enterpise published by IT RevolutionGary Bolles on AI and the Future of WorkJason Corsello from Acadian Ventures on AI and the Future of WorkTurn the Ship Around by L. David Marquet

128 Step-by-step fundraising process with Nathan Beckord Nathan Beckord Earlier in my career, I started two companies, an early web catalog provider and a clinical trial software company. I also worked in investment banking, and was involved in three technology IPOs and nearly 40 acquisitions. On the content side, I produce the popular "How I Raised it" podcast found on iTunes, SoundCloud and Spotify. I also organize various startup events such as FundingV2.com, StartupBD.com and StartupExits.com. Previously, with Pivotal Labs, I produced the ProjectStartup series. I have an MBA in Entrepreneurship, a BSC in Finance, and I am a Chartered Financial Analyst (CFA). I'm on the Board of Hands On Bay Area, a non-profit. Aside from startups, my passion is sailing, and I've logged more than 10,000 coastal and offshore nautical miles. My longest sail was a 22-day non-stop Pacific Ocean crossing to French Polynesia. Currently, I race on a Knarr team in the SF Bay. Other adventures include climbing 19,340-ft. Mt. Kilimanjaro in Africa and trekking in Peru, Chile, New Zealand and the Himalayas of Nepal. I've also toured the U.S., Vietnam, Cambodia, Mexico, and Nicaragua by motorcycle. Specialties: Venture capital, startups, entrepreneurial finance, business planning, business development, financial modeling, raising capital, corporate development, strategic partnerships and alliances, exit strategy, startup acquisitions, pitch coaching, investor presentations, startup strategy, go to market planning, startup M&A, private equity, angel capital. Foundersuite brings structure, speed and efficiency to fundraising and investor relations. Used by 2500+ startups worldwide including those in YCombinator, Techstars, 500 Startups, FundersClub and more, Foundersuite also has product features for investment bankers, VCs and funding advisors. Features Include: - Investor CRM - Investor Database - Investor Updates - Pitch Deck Hosting - Send Email Tools - Deal Docs - Founders Market - Virtual Data Room I mainly work with early stage Internet, B2B software, mobile, and consumer product startups, and I have a strong interest in platforms, markets, and networks.     We talk about   Why are such a small percentage of companies able to raise any type of funding? If there was one key difference that sticks out between a company that can raise funding and one can't, what would it be? Which fundraising steps do startup founders skip or have the most issues with? During the outreach, how often should one be updating the materials they are sending, and should they be customized depending on who it is being sent to or is that too time consuming? What are all the documents a startup should have ready when they go out to raise capital   And much more...   Connect with Nathan Beckord https://www.linkedin.com/in/nathanbeckord/ nathan@foundersuite.com https://foundersuite.com/

How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) Why has trust become so rare in the software industry? Developers don't trust their own ability to program, teammates don't trust each other to write quality code, and organizations don't trust that people are working hard enough to deliver on time. This talk by Justin Searls is a reflection on the far-reaching consequences distrust can have for individuals, teams, and organizations and an exploration of what we stand to gain by adopting a more trustful orientation towards ourselves and each other. 01:57 - Justin's Superpower: Having Bad Luck and Exposing Software Problems 04:05 - Breaking Down Software & Teams * Shared Values * Picking Up on Smells to Ask Pointed Questions * Beginner's Mindset * RailsBridge (https://www.bridgetroll.org/) 12:49 - Trust Building * Incremental Improvement * What Got You Here Won't Get You There: How successful people become even more successful by Marshall Goldsmith (https://www.amazon.com/What-Got-Here-Wont-There/dp/1846681375/ref=asc_df_1846681375/?tag=hyprod-20&linkCode=df0&hvadid=312118059795&hvpos=&hvnetw=g&hvrand=6049806314701265278&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9006718&hvtargid=pla-525029467829&psc=1) * Credibility * Reliability * Intimacy * Selfless Motivation * Authenticity * Detecting Authenticity * Laziness Does Not Exist (https://humanparts.medium.com/laziness-does-not-exist-3af27e312d01) 29:14 - Power Politics & Privilege * Leadership Empathy * Safety * Exposure; “Don't Cross The Net” * Masking (https://en.wikipedia.org/wiki/Masking_(personality)) 42:06 - Personal Growth & “Bring Your Whole/True Self” * RubyConf 2019 - Keynote: Lucky You by Sandi Metz (https://www.youtube.com/watch?v=c5WWTvHB_sA) How to Trust Again – Justin Searls (https://www.youtube.com/watch?v=mu8KmhPa5Oc) This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: PRE-ROLL: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams. And you can help! Test Double is hiring empathetic senior software engineers and DevOps engineers based in the United States and Canada. We work in Ruby, JavaScript, Elixir and a lot more. Test Double trusts developers with autonomy and flexibility at a remote, 100% employee-owned software consulting agency. Looking for more challenges? Enjoy lots of variety while working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/greater. That's link.testdouble.com/greater. JACOB: Hello and welcome to Episode 270 of the Greater Than Code podcast. My name is Jacob Stoebel and I'm joined with my co-panelist, Mae Beale. MAE: And I'm joined with another panelist, Chelsea Troy. CHELSEA: Hi, I'm Chelsea and I'm here with our guest, Justin Searls. He's a co-founder and CTO at Test Double, a consulting agency on a mission to improve how the work writes software. His life's work is figuring out why so many apps are buggy and hard to use, why teams struggle to foster collaboration and trust, and why it's so hard for organizations to get traction building great software. The Test Double Agents work with clients to improve in all of these ways and more. Hi, Justin! How are you today? JUSTIN: Hello. I'm great. Thank you so much for having me. CHELSEA: Of course. So we like to kick off our sessions by asking you, what is your superpower and how did you acquire it? JUSTIN: Well, one superpower might be that I like to give counterintuitive answers to questions and [laughs] my answer to this would be that I have really, really bad luck software and hardware. My entire life has just fallen over for me left and right. Bugs come and seek me out. In college, I was in the computer science program and so, I was around a lot of computers, like Linux data centers and stuff, and I think I went through either personally, or in the labs that I used 20 hard drive failure years in 4 years. People started joking that I had an EMP around me. So I started to just decide to lean into that not so much as an identity necessarily, but as a specialty of root cause analysis of like, why do things fail? When I see a bug, what does that mean? And to dig in to how to improve quality in software and that then extended to later in my career, when I was working on delivery teams, like building software for companies and institutions. That meant identifying more root causes about what's leading to project failure, or for teams to break down. Now I'm kind of moving, I guess, popping the stack another layer further. I'm starting to ask what are the second and third order consequences of software failing for people having for others? I see this in my family who are non-software industry family members, when they encounter a bug and I'm watching them encounter a bug, their reaction is usually to think that they're the ones who screwed up, that they're stupid, that they just can't figure it out. I'm literally watching software that somebody else wrote far away just fail and that's just no good, right? So I think that the fact that I just so easily expose problems with software and sometimes the teams that make it almost effortlessly, it's really given me a passion and a purpose to improve and find opportunities to just make it a little bit better. MAE: When you talk about software and/or teams breaking down and you're mentioning bugs. So I'm assuming that that's mostly what you mean by breaking down? I'm curious if you have kind of a mental model of software always breaks down these four ways. Teams always break down these three ways. I don't know if you have any reference texts, or things that you've come across as far as like a mental model for what is the world of breaking down? How do we characterize it? JUSTIN: That's a great question and I feel like having been basically doing this for 15 years now, I should be prepared with a better answer. I've always resisted building I guess, the communicative version of an abstraction, or a framework for categorizing, simplifying, and compartmentalizing the sort of stuff that I experience. In some ways, my approach [laughs] is the human version of machine learning where I have been so fortunate, because I've been a consultant my entire career, to be exposed to so many companies and so many teams that that has developed in me a pattern recognition system that even I don't necessarily understand—it's kind of a black box to me—where I will pick up on little smells and seemingly incidental cues and it'll prompt me to develop a concern, or ask a pointed question about something seemingly unrelated, but that I've come to see as being associated with that kind of failure. I think your question's great. I should probably spend some time coming up with quadrants, or a system that distills down some of this. But really, when I talk about bugs, that is a lagging indicator of so many things upstream that are not necessarily code related. One of the reasons I want to be on the show here and talk to you all the day is because I've been thinking a lot about trust and interpersonal relationships starting with us as individuals and whether we trust the work that we're doing ourselves, or trust ourselves to really dive in and truly understand the stuff that we're building versus feel like we need to go and follow some other pattern, or instructions that are handed to us. To kind of try to answer your question more directly, when I see teams fail, it usually comes down to a lack of authentic, empathetic, and logical targeted relationships where you have strong alignment about like, why are we in this room? Why are we working together? How do we best normalize on an approach so that when any person in any role is operating that is consistent with if somebody else on the team had been taking the same action that they would operate in the same way so that we're all marching in the same direction? That requires shared values and that requires so many foundational things that are so often lacking in teams as software is developed today, where companies grow really fast. The pay right now is really, really high, which is great, but it results in, I think a little bit of a gold rush mentality to just always be shipping, always be hustling, always be pushing. As there's less time for the kind of slack that we need to think about—baking in quality, or coming back to something that we built a couple weeks ago and that maybe we've got second considerations about. Because there's that kind of time, there's even less time sometimes for the care and feeding that goes into just healthy relationships that build trust between people who are going to be spending a third of their life working together. CHELSEA: You mentioned picking up on little smells that then lead you to ask pointed questions. I think that's really interesting because that kind of intuition, I've found is really essential to being a consultant and figuring out how to ask those questions as well. Can you provide some examples of situations like that? JUSTIN: Yeah. I'll try to think of a few. I had a client once that was undergoing—this is 10 years ago now—what we called at the time, an agile transformation. They were going from a Waterfall process of procuring 2 year, $2 million contracts and teams to build big design upfront systems that are just thrown over a fence, then a team would go and work on it, and then it would go through a proper user acceptance testing onto something more agile, I guess. Adopting Scrum and extreme programming, interpersonal process, and engineering practices. That was just meant to be more, I guess, iterative of course, innovative, collaborative, more dynamic, and able to let the team drive its own destiny. All that sounds great and you walk into the team room and they just invested millions of dollars into this beautiful newly restored historic building. I sit down with everyone and I look at them and they've got the cool desks at the time and cool open office because those were still considered cool. I sat down and I couldn't help, but—[chuckles] this is real silly. I couldn't help but notice that there was a pretty strong smell, [laughs] body odor throughout the whole room and it wasn't one person. I'm not picking on somebody here. It was that the interpersonal relationships were so afraid, the fear of failure was so strong, and the deadline pressure that had been exerted from on high was so overwhelming that there was no safety in the room. People were just scared at their job all day long and it was having a material impact that only an outsider who's walking in at 2:00 PM on a Friday detect because everyone else had acclimated. So I walked in and I was like, “Well, what do I –?” [laughs] Obviously, I'm not going to be like, “Hey, it stinks in here.” I've got to figure out a way to understand why do people feel unsafe and maybe I didn't have that sentence go through the voice in my head, but it definitely put me on a path towards to maybe the less privileged people in the room, the people who are not the managers to understand what's really going on, what pressures are they under? MAE: I love that the example includes legit real smell. So many times, especially in our industry and part of what this podcast is counteracting, is getting in touch with the fact that we are people and humans. Anyway, I love that you brought [chuckles] that home that way. Also, I wanted to say from earlier, I wasn't trying to corner you into expecting to have a philosophy. I thought you might and it was worth asking. But I recently got asked a similar question about my management philosophy and which authors do I appreciate most, or something. I've been a manager for 25 years and I'm like, “Uh. I don't know. I figure out what is needed and then I deal with that.” I don't understand how to answer. So I just want to give some – pay you back and apologize. I didn't mean to get you – [overtalk] JUSTIN: Not at all and it becomes one of those you know it when you see it. I struggle with this a lot because somebody introduced the concept years ago of beginner's mindset to me where sometimes if I'm a beginner at something, the best person to help me is not the expert—the person who's been doing it for 20 years. It's somebody who's just a few hours, or a few days, or a year, or two ahead of me because they can still remember what it felt like to be where I am right now. Because I talk a lot, because I tweet a lot, because I show up in a lot of places, and I have an outward facing sales role to potential clients and candidates, I meet a lot of people who come to me and they're like, “How do I learn how to code?” And I'm like, “I can tell you the 15-year version of this story, but it's probably going to be really depressing.” I've taken as a responsibility to like try to—and I need to do a much better job of this—be armed with either resources, or people that I trust, that I can refer folks to so that I'm not totally leaving them hanging. MAE: I love that and yes. Speaking of teaching people how to code and what you said, there's a name for it that I'm forgetting about being a teacher. If you are closer to the student, you actually are a more effective teacher. So there's just two comments. The first one is I'm a part of RailsBridge I helped found the Southeast regional chapter. So if anybody, any listeners out there still want to learn how to code, or are having that same, I don't know how to tell you about my [chuckles] zigzag story and ideally, they wouldn't all be depressing, [laughs] but I'm sure they all include some real low moments. But RailsBridge, which is bridgetroll.org, has recurring events where people can go all over the country and obviously, in pandemic times it's not as much in person, but yeah. And on the comment about teaching and when you mention talking to the people with the least privilege in the room, I'm just really sensitive and appreciative of your sensitivity to power politics and how much they impact so much of what is happening and trust. So for anybody out there who's being asked to help new people and you feel like you're still the new person, you're probably in a better position to help. So just want to offer some encouragement there. I have personally found a lot more confidence in helping people who are just behind me and that anytime you're teaching, you're learning. So just want to put those in. I love that actually your answer, instead of a quadrant, is really just the one word of trust and I appreciated the ways in which you were mentioning trust can be different things. Trust in what you're building. Trust in who's asking you to do it. Chelsea asked for a couple examples and I interrupted. So I apologize, but what are some trust building exercises that you have encouraged, or examples? Maybe even continuing that same story. Six months later, was it a fresher air in there and what are some things they did to make that happen? JUSTIN: Yeah, that story, like so many teams and companies in our industry, didn't undertake the redemption arc that I wish I could convey. I think in fact, to see a big picture problem and the desire to connect that with a big picture tidy solution, a future state where it's all rainbows and unicorns and everyone really getting along well. Sometimes that sets, for me personally and when I see consultants who are less experienced, who can see that end state in mind and they know maybe the top three hit list of stuff that needs to happen to help that organization get to where they need to be. We can sometimes set the bar so high for ourselves in terms of expectations of like, what does it mean to help them become better, that we can't help, but lose sight of the value of just incremental improvement. If I can just help restore relationship between two people on a team. I had one client years and years ago, [laughs] they were also undergoing a pretty big transition and they brought me in a – I think that what they thought they were hiring me for was to be a test-driven development coach to teach them that particular practice of TDD. They got, instead on day one, there was a room of 30 interdisciplinary cross-functional teams—some developers, some non-developers, and stuff—and I could just tell that they were like, it was a big epic rewrite from a Perl codebase that, I think they were moving to no JS and Angular as well as a chewing of cloud infrastructure at the same time, as well as Agile software practices at the same time. They were overwhelmed, they've seen this fail before, they felt a ton of pressure from the business, and they didn't even really understand, I don't think, the future business model. Even if they were successful, it wasn't clear this was going to solve systemic problems for the company. And I'm like, “Well, I can teach you all TDD. [laughs] But instead what my commitment to you all will be is that six months from now, you'll either have been successful and learned all of these things and built the thing as the business has asked you to do and then the business takes off, or I will have helped equip you with skills and ways of thinking about this industry and our work that will set you up to get much better jobs next time.” Again, the company didn't totally come together. It didn't take off like a rocket ship. The team was successful in the rewrite, which doesn't happen very often. But then you saw almost a diaspora of dozens of highly skilled people—and this was in Central Ohio—who then went to venture backed startups, some went to big, established enterprise-y kind of companies, some left the region and went elsewhere. That turned into, if I had to count, probably eight, nine additional Test Double clients [laughs] down the road where they came in and they could spot in a minute, this is a way that an outside perspective, who is here to help us at a moment of tremendous need, can move the needle just a little bit. By setting expectations realistically, being humane about it, and focused on what's best for the people involved because at the end of the day, all companies are is collections of humans. That was, I guess, more my orientation. CHELSEA: So Justin, I'm interested in your thoughts on this. I appreciate what you just shared. I worked at Pivotal Labs for a while—original labs when it was sort of a generalist's enablement. JUSTIN: Sure. CHELSEA: Very heavy on that kind of thing. One of the things that we ran into relatively frequently was similar to what you've just described wherein one of two things would happen. Either the clients were successful and there was a vastly improved, I guess, software delivery culture among the people that we were working with, or if that didn't work out, then there were individuals who took to it very well and had gained variety of skills that allowed them to go elsewhere. It happened enough times that then we would have to establish trust with potential new clients around this whole additional access, which was effectively, is this going to cause a diaspora of all of these engineers, designers, and PMs that I've managed to scrape together for this project? Do you find Test Double ever facing that, or how do you address either beforehand if product owners are aware of it, or after it happens, how do you address that with clients? JUSTIN: That's a fantastic question. Pivotal Labs was one of the companies that we looked at. We started Test Double 10 years ago. I was at the time, just starting to speak at user groups and conferences and I spent a lot of time with the people at the Boulder office at Pivotal Labs. Great people. I really appreciated the focus and the rigor and in fact, made to answer a question earlier about process, or abstraction about like, “Hey, boil it down for me.” Pivotal Labs sold a very branded, very discreet process for like, this is the way to build software and, in a sense, some of the decisions that we made when we started Test Double were a response against that. Just to say we trust the people closest to the work to make the right decisions based on tremendous experience and skills. Frankly, as we get bigger and more successful, having some somebody like me at the top of an organization who only talks at the beginning of a client relationship, which is the moment that we know the least and I've got the least amount of context, for me to go and say, “Well, this is the way that we got a test,” or whatever it is would just be ineffective and inappropriate. So to answer your question, Chelsea. Fortunately, our brand power, isn't nearly as strong as Pivotal Labs so no client has ever come to us in advance with that as a question to say, “Hey, I'm worried that you're going to train our people in this particular methodology and then they're going to leave for higher paying jobs,” or something. That's never come up in advance. In fact, one of the things that we talk a lot about is that because our consultants join client engineering teams to work with them inside of their own process, using their own tools, and their own system is we just try to be model citizens of somebody on that team. We trust our clients like, “Whatever your process is, it's apparently working for you. So let's just try it and if we have ideas for how to make that better, we will listen, we'll write them down.” But then only once we've built trust and rapport with the people on that team, will we start to share, “Hey, I've got a rainy-day list of a few things that you might want to try.” What that's actually done is has a detoxifying effect where from a context of high trust, the incongruity, the distrust, the kind of backchannel frustrations that our people pick up on because we're kind of “in the trenches” with our client folks, we're able to have multiple pathways into that client organization to help make it a better place to work. We got one of the best poll quotes that I've ever seen on our website recently. One of our clients is Betterment. They're a great financial management firm in New York where it's kind of an autopilot savings vehicle. The director of engineering, Katelyn, there said that she saw on the teams where testable people were deployed, attrition actually went down and I think it's because we help those teams to perform better. An old friend of mine named Leon Gersing, he used to have a thing he'd say. He'd said, “You can either change where you work, or you can change where you work.” Meaning you can either make the place that you're at better, or you can go find gainful employment elsewhere and we're in the make the place where people work better business, wherever possible as a first avenue. MAE: You're reminding me of a book that I'm reading right now called What Got You Here Isn't Going to Get You There. Are you all familiar with it? JUSTIN: I was so proud of my wife, because she asked for that on Audible earlier this week because I'm the person with the Audible credit and I'm like, “Oh, this is quoted in business leadership contexts left and right and all over the place. So it'll give us a touchstone to talk about.” MAE: Yeah. Well, the TLDR is so much of especially management focused and leadership focused thought is about things that you should do and this book is probably along your lines, Justin of giving the counterintuitive answer. This is here's 20 things that you might want to consider not doing and then replace it with the good behavior because that is such a stretch in real life to actually do that. It's how about you just pick a couple of these that you're a repeat offender and just stop. Just try to not do it. That's the main first thing and I've found that, a refreshing take on how to think about how to guide in ways that are building more trust and offering more safety. So definitely recommend that book. I don't know that it came out of this book, but the person who recommended it to me, my VP Scott Turnquist, who is amazing, shared that there are really four categories of things that can help build trust and it's definitely all done incrementally. So picking up on that word you said earlier, Justin, too. But the four kind of axes are credibility, reliability, intimacy, and selfless motivation. If you can demonstrate those recurringly, that is how to establish and/or course correct into a state of increased trust. So anyway, that was partly why my original statement was like, do you have this down? Because I've heard some things lately that I've been thinking about. JUSTIN: I really appreciate your perspective there and it makes me feel better because one of my commitments in life is to never write a book. But if I were to write a book, I'd probably have to come up with a tidy quadrant, a Harvard Business Review two by two, or something like that to I guess, support the good work at the people at CliffsNotes and Blinkist to boil down years' worth of work into a 13-minute podcast. I think that the advice as you expressed, it is completely valid and there's one thing that I think is a core ingredient to trust. Trust of ourselves, trust of people that we work with directly, and then trust of leadership and the people who run the organizations that we're a part of. The hardest, in my opinion, is authenticity. If you're not, I think you said credible. If you combine credible, intimacy, vulnerability, those are really useful words to prompt what I mean when I say authenticity. If I'm talking to somebody and I can lock eyes with them and I believe that what they're saying is what they actually feel and it's their true self and they believe it, then all sorts of other background processes in my head of trying to read the tea leaves of what's going on here, all the passive analysis I might do to try to understand what's the subtext that this person's operating from. That's just the form of kind of armor, or a guard that it depletes my cognitive ability to talk to the person. Authenticity is a signal that we pick up on as humans and this is why it's a miracle that we have video chat in this era and it's why I really relish one-on-one in-person interactions when I can have them. Authenticity is a signal that I can drop that guard a little bit. It's that I can really look and really listen to what the person's saying and take it at face value. The problem with just saying, “Oh, okay, well just be authentic. Just be your true self,” is that that is useless advice and way more likely to trigger somebody's defenses, or their self-doubt. When I think about authenticity in the context of a team, or an organization is that the people who are maybe not in a position of power, people who report up the chain, if they don't come across as authentic to their leaders, the leaders should not look at that as a failing of the person, but as a failure of their ability to figure out how to promote and draw out authenticity from the people who report to them. Maybe they don't have safety in the room to speak their true mind. Maybe they feel like the things that make them different from the other people that they work with are a liability, or a risk and so, they can't really bring their true self to work. It's the leader's job, when they spot inauthenticity, rather than go on a hunt like a political backchannels to try to figure out why is this person lying. What's under here? Figuring out what is it about the person's context, the environment, kind of the system that they are operating in. What could possibly be an explanation for why I can't develop an authentic connection with this person? And until you run out of every single possible explanation in that investigation, including self-reflection of what is it that I'm individually doing and how I communicate to this person that's getting in the way. Only then is it really useful to start thinking about maybe this person's not a good actor, maybe they're being duplicitous, or something. Because once you've hit that button, it is really hard to go back. So when we talk about authenticity, we often talk about the individual's responsibility to present it, to be it. If you can fake authenticity, then you can do anything, right? That is advice. It's fine. I hope that everyone feels the safety. Like I'm a cishet white dude who's pretty powerful in my little corner of the small pond. I have no problem just spouting off and being my true self and so, I should just tell other people to do that too. That's not fair. I think that what is better advice for people who are maybe not in positions of power is to be really good at detecting authenticity. When you detect authenticity and people are making their true selves known to you and you're feeling a connection with them, whether they're peers, or managers, spend more time with them, invest into those relationships, and use those people as anchors of trust. So that when you're failing to make that connection elsewhere, when you have doubts about others in the organization, you can have more points of perspective on how to best address it. MAE: I read an article yesterday that says, “Laziness Doesn't Exist.” That's the title of it and it essentially says that that same thing of what's the context in which this is happening. People don't procrastinate for fun. In fact, it usually takes more work and starting from a place of what shoes are you in, but I especially love the in what way am I impacting that person's ability to be themselves? Also, I must have said the word authenticity, because this list is credibility, reliability, intimacy, selfless motivation, but authenticity and credibility in all of these things do also have to do with the thing that I loved you bringing up about identity, power politics, and what happens and your environment is not allowing you to be credible. So another way in which people can as good peers, mentors, managers, and above can do is in what way am I bolstering these people's credibility? So always flipping it back to how are we the perp [laughs] and that's very similar to social justice, racial justice. The more we see how we are perpetuating and disenfranchising, regardless of our identity, that's where there's some hope for the humans in my mind. CHELSEA: Yeah. One of the things that I appreciate that you've both brought up, Justin and Mae, is the degree to which power gradients play a role in the way that we deal with these things. There are demographic power gradients with regard to race, with regard to gender. There are also power gradients with regards to our position in the company, with regard to technical privilege, with regard to our level of skill, with regard to the size of our network. We also, I think live in this individualist culture that has a tendency to place the responsibility on individuals to do what they can to resolve. For example, what you were saying, Justin, about how we effectively coach people to just be authentic. Maybe that coaching works fine in some context, but that's a subset of the context in which we're asking people to apply it and asking individuals to resolve this from the bottom up sometimes as opposed to looking for the systemic reasons why this is a thing that has to be solved in the first place. I'm curious as to whether you have thoughts on what a person can do, who finds themselves in a position of power, in a position of leadership in a company, for example, to address those sorts of questions with other folks who are working there. JUSTIN: I think one thing that can be helpful – and I realize your question is about what can a leader do. One thing that can be helpful is for those leaders to empathize and put themselves in the shoes of people who might not have the same privileges as you described and what would it take to—I'm waiting outside my area of expertise here—would be to think about what are the things that are in a given person's sphere of direct control, what isn't, what am I setting up, and what am I communicating in terms of expectations that I have of them? An example that came up a lot in our industry was the number of drink up events in tech in the early 2010s where there was sort of an assumption that everyone likes alcohol and when people in public drink alcohol, good things happen, which turns out isn't true, but it can also be the case. There are invisible expectations that we communicate because I'm a big fan of granting people autonomy to solve problems in their own way, to approach work the way that they feel is best. Our company has been remote from day one and a big part of that was we want people in control of everything from where they work to their home network, to the computers that they use. Because when I had that control pulled away from me in the role as developer, it just sapped my motivation, my drive, my engagement, my sense of control over the stuff that's right in front of me. When I now in a role of influence over other people, whenever I speak, I have to think about the negative space of what are the expectations that I might be conveying that are not explicit. I need to be careful of even expressing something like hobbies, or shows that I like, or stuff – especially in this remote world, we want to develop connectedness. But a challenge that I keep running into is that our ability to find mutual connection with people about stuff other than work, it rides the line really closely of communicating some other allegiance, or affiliation whether that's we talk about sports a lot because that's an obvious one, but even just interest in hobbies. So I find myself – and I realize Chelsea, I'm doing a really poor job, I think of answering the question as you asked it. I find myself only really able to even grapple with like what can leaders do to set the tone for the kind of environment that's going to be inclusive and safe for other people by really digging in, empathizing with, calling up, and dredging up what their own experience was when they were not in a position of power. If I have a secondary superpower, is I had a real rough start to my career. I was in really, really, really rough client environments that were super hostile. I had a C-level executive at a Fortune 500 company scream at me until his face was red in a room one-on-one with a closed door on a regular basis. The sorts of stuff that developed callus on me, that I look back at a lot of those experiences and I'm like, “I learned a bunch.” It's supercharged my career as an individual because it strengthened me. So the challenge that I have is what can I take from those really, really harsh experiences and translate them for people who are coming up in a way that they don't have to go through the same trials and tribulations, but that they can take away from it the lessons that I learned. And for me, it's all about not just safety for the sake of safety, but safety by which myself and others can convey the useful growth that people want to see in themselves, their skills, and their abilities that isn't diluted. That can convey the truth, the difficulty, and the challenge and how hard – Programming is really, really hard for me and I've been doing it for a long time. A lot of stuff about this is just not easy. The relationships are not easy. Like you're going to run into situations where there's massive differences between where people stand on stuff and what those perspectives look like. Navigating that is hard enough without adding a whole layer of toxicity and hostile work environment. So what's a way to promote that learning environment without just totally insulating somebody from reality. That's been, I think a challenge and attention that I see a lot of other like-minded leaders in tech trying to figure out how to create. MAE: You reminded me of a meme that someone shared with me that says, “What doesn't kill you can just regulate your nervous system, trap itself in your body, steal your sense of self, make you wish it did.” I don't know what makes you stronger means, but let's stop glorifying trauma as a life lesson we've been blessed with. [chuckles] Definitely along the same lines. JUSTIN: Yeah. Relatable. MAE: There's a thing, too about putting oneself in another's shoes and this is a place where I'm someone that can read people really well, but that makes that tricky. Because I start to trust my sense of it and I have a similar architecture going if I don't feel like I'm getting the whole story. So what's the read between the lines thing. But without a lot of exposure to a lot of very different people, and most people have not had a lot of exposure to a lot of different people, when they put themselves in the other person's shoes, they come up with a different conclusion. So I will feel hurt by people who do things that were I to put myself in their shoes would not have done that to me, or if they did, it's because of X, Y, Z about who they are, or what they think, or what is their whole context and environment. All of that is there's a tactic that we use at True Link Financial called “don't cross the net.” So you say and claim the story I tell myself about that is dot, dot. When leaders, who haven't had a lot of exposure to a lot of different people and a lot of different ideas, try to empathize and find themselves limited in that, there are other options which include one of the things you said earlier. Making it so that people can say the things on their mind so whether, or not that's persons being their authentic self this is a whole another level, but creating a place where we expect that we're all messing up and that it's okay to talk about uncomfortable things is one of my real soapboxes. It's totally okay. Yes, we are all racist. We are all sexist. We are all homophobic. There is no way to not be as a result of being in the culture we're in. We could do things to mitigate it. We can do things to name it. But if we just start from yes, we're all failing. This for me, it lowers the stakes because so many people feel that if someone brings up, “Hey, that's kind of sexist,” or “This is not supporting me in this way,” or “My credibility is not being seen because of this.” In the absence of already, yo, we're going to talk about some negative stuff sometimes, that's an introduction of negativity to the “positive, happy rainbow unicorn workplace” that you were talking about before. So one of my hopes and dreams is that we get some clouds to rain on the land to allow things to actually grow [chuckles] and this includes, yo, we are not perfect. And we are definitely doing things we don't intend all the time. JACOB: That made me think about authenticity again, because sopen about imperfection. I'm a neurodiverse person so I probably am autistic. If someone were to say to me at work, “We really want you to bring your authentic self,” probably the thing I would think is you don't want that person, [laughs] or at least without getting to know me a lot better. There's a concept called masking where it's basically, there are behaviors and traits that are exhibited by neurotypical people that just come naturally to them. By learning the hard way, I've sort of learned to do them, even if they don't feel natural at all like making eye contact, smiling at people when talking, things like that. So I think that complicates authenticity for me, which is that I'm intentionally not hiding, but choosing what parts of myself to show and what parts I just don't want to bring to work. [laughs] I don't have a clean answer for that, or a solution to that, but I think that just complicates things for me. JUSTIN: I thank you so much for sharing that and I think it's a really important perspective to bring, which is I talked earlier about sure, plenty of people's true, authentic selves, even if they were to bring them, they might be in a job, or in a space, or in a team where that wouldn't be understood as such, or appreciated, or literally safe. It's hard to tell people, “Hey, you should feel safe” when the truth when spoken would be an unsafe thing. That would be setting people up for risk, for danger, and it would be a seed of distrust, which is what we're all here to talk about avoiding. So I really appreciate you sharing that. When I talked about empathy earlier, Mae, in my brain, all that really comes through it is the E-M part of that word, like the root for emotion. I never really have been able to assume that I can get somebody's context, their perspective, and the moment that they're in into my brain well enough to role play and do a re-dramatization in black and white, sepia tones and slow motion, like this is what Justin would do if he was here. That's one reason why we trust people at our company to just do the work, because we know that they're going to have such a richer amount of data and context than we'll ever have. But one thing that I'm grateful for is that I've been able to experience what I feel like is a pretty broad range of emotion. [laughs] I'm a real emotionally volatile person. I go super high highs, super low lows and I'm just like, it's how I've been. I can't help it. So when I'm empathizing with people, I'm just trying to get in the mindset of how do they likely feel right now so that I can understand and try to do a better job, meeting them where they are. A big part of that is learning there are differences and so Jacob, of course, it's like if I worked with you, I understand that it might not be productive to bring all of yourself to work all the time. But I would hope to develop a trusting relationship with you where you can share enough so that I can know what are the boundaries that are going to be productive for you, productive for me so that we can make a connection and it's something – To make this a little bit more personal. I don't know where my career is going to go next. I founded Test Double with my partner, Todd. I was only 26 years old and we've been doing this for 10 years now. 2 years ago, we embarked on a journey of transferring a 100% of the equity of the company to our employees. So we're on an employee stock ownership plan now, it's ESOP, or any of the stuff, it is complicated because it's well regulated. We have to have outside auditors, a valuation firm, we have a third-party trustee to make sure that our people and the value of the company is transferred appropriately, treated right, and managed well. So it's naturally raised, especially in my circle of friends and family who realize that, this means that there's not an end date, but there's a moment at which I can start thinking about what my life is going to be next. The people who knew me when I was 25, 26, who look at me now, it's not that I've changed radically, or my identities are radically different, or anything. It's like, I am a very different kind of person than I was at 26, than I was at 20 before I got into this industry. I have changed in healthy ways and in maladaptive ones and in response to maybe drama and stress such that the ideal retirement that I would've imagined earlier in my life looks a lot different now where I've just kind of become habituated. I'm a really, really different person than I used to be and I'm grateful for that in almost every way. I feel like I've grown a lot as a person, but the thing about me that I really look at as an area of change is that I just work too much. [chuckles] I'm online all the time. I'm very focused on – I've optimized productivity so much that it's become ingrained in me. I understand that whatever I do next, or even if it's just changing my role inside my company, I need to find a way to create more space for slower paced asynchronous thought and learning how to, in the context of a career, not just bring your true self – I'm kind of curious Chelsea, Mae, and Jacob's perspectives. That true self might be changing [laughs] intentionally. There's a directionality and the growth isn't just learning new skills necessarily, but it might be changing core things about ourselves that will alter the dynamic of the relationships that we bring to work. CHELSEA: Yeah. I have two thoughts on that, that I can share. The first is the extent to which bringing my true self is a productive thing to do at work. So for example, my career prior to tech, I did a variety of different things to make ends meet, really a wide variety of things. I graduated directly into one of the bigger recessions. I won't tell you the exact one, because I don't feel like being aged right now, but [chuckles] it wouldn't take too much research to figure it out. I was trained to do a government job that was not hiring for the next 18 months at a minimum. I needed to figure out what to do and was trying to make ends meet. In my first year of employment, I got laid off/my job ended/something like that on four separate occasions in my first year of work and that resulted in, I do not trust when managers tell me that everything is fine. I have not ever effectively and that is something that I don't foreground that in work discussions for a variety of reasons. I don't want to scare other people. I don't want them to think I know something that they don't know about what's going to happen because I don't usually. When managers tell me, “Oh, everything's great, we're doing great,” all that kind of stuff, I just don't listen. I don't. My decisions do not take that's statement into account and I find that that's the kind of thing that I think about when I'm asked to bring my whole self, my authentic self to a place is that there are things that just sort of similar to what Jacob is saying. I'm like, “Trust me, trust me on this you don't want that.” So that's kind of the first thought in that realm. The second thought that I have around this is the degree to which work should really encompass enough of our lives to require, or demand our authenticity. So I had a variety of full-time jobs in tech and then I quit one of those full-time jobs and I was an independent consultant for a while bolstered chiefly, and I was lucky for this, by folks who had read my blog and then folks who had worked with me when I was at Pivotal. So the consulting effect of people knowing what it's like to work with you is real. That experience felt very different from a full-time position insofar as at the external validation of my work was naturally distributed in a way that it's not in a full-time position and I found that distribution is extremely comforting. Such that even though I now have a full-time job, I also continue client work, I continue teaching, and I continue writing and doing workshops and those kinds of things. This is not the chief reason that I do that, but one of the nice things about it is the diversification of investment in the feedback that I'm receiving and validation that I'm receiving. In order to do that, I have an amount of energy that I put to each of the things in my life and part of it is work, of course. But another reason that I think it works for me is that I no longer have to expect all of my career fulfillment from any one position, from any one employer, from any one place, which has worked out very well because I think that we pedal this notion implicitly that you bring your whole self to work and in return, work provides for your whole career fulfillment. But most places really kind of can't and it's not because they're terrible places to work. It's just because the goals of a company are not actually to fulfill the employees, they're just not. That's not the way that that works. So it has allowed me and I think would allow others to approach the role that a given employment situation plays in their life, from what I think is a more realistic perspective that ends up helping keep me more satisfied in any given work relationship. But it doesn't necessitate that I – I guess, for lack of a better term, it limits the degree of emotional investment that I have in any one thing, because I'm not expecting all of my fulfillment out of any one thing. But I think that to say that explicitly sometimes runs at best, orthogonal and at worst, maybe contraindicates a lot of what we talk about when we talk about bringing our whole selves to work and looking for those personal connections at work. I think there is pragmatic limit past which we maybe impose more guilt than we need to on ourselves for not doing that. JUSTIN: Yeah. Thank you so much for sharing that. I think Mae used the phrase “lower the stakes” earlier and I think that one of the problems with authenticity, the phrase “bring your whole self-trust” is that the stakes are super high because it seems like these are bullion contracts between parties. For example, you said that you don't trust managers. If I was filling out a form, like a personality inventory, or something, it's like, “Do you trust managers?” I'd say no and I think 90% of people would say no. It's sort of the economy right now. I think the economy approval rating of is the economy good, or bad is at 23%. But individuals are saying at roughly 60% levels, that they are individually doing okay in this economy. I would say the same. Like, do I trust my manager? Oh, hell yeah. I completely trust my manager right now. And to lower the stakes even further, when I've been talking about trust, it's not so much about where do I find fulfillment, or who what's my identity, or who am I being, it's about a snap orientation. It's the most immediate sphere. “Oh man, this PostgreSQL query is really slow and I can't figure it out.” Is my snap reaction, or my orientation to think, “I believe in myself enough to dig into this to figure it out”, or is it doubt myself and just kind of get lost in a sea of a thousand Stack Overflow tabs and just slowly lose my whole evening? When in a team, maybe working with them and we were in planning, or something, or maybe we're in a higher stake, let's say, a code review session and somebody makes a comment about something that I did. Is my snap reaction to doubt their motivations and think “Ah, they're just trying to passive aggressively shoehorn in their favorite architecture here,” or this is politics and gamesmanship, or is my snap reaction is to be like, “Nope, let's try to interpret the words that they're saying as literal words and take it on its face”? Like I said, I'm a highly emotionally volatile person, the weather vane shifts with me all the time and sometimes I can control it and sometimes I can just merely observe it. But the awareness of the out has been really helpful to understand [chuckles] when I hear a leader say something about the company, my reaction is I think that they've got ulterior motives and that they are probably not speaking in literal truth. If that's my snap reaction, I'm just trying to communicate that as that's a potential blind spot. Because I have a long rut of past companies that I worked for that had mission statements and vision statements that were kind of bullshit and that no one really believed in, that were just in a bronze plaque on a wall, or whatever. That's baggage that I carry. I just have to acknowledge that baggage and try to move forward. The best I can do is just be present in every moment that I'm in and to understand when I have a snap reaction, am I oriented towards what might lead me to a good outcome, or a bad one? MAE: Holy moly, so many amazing things have been shared today and Jacob, especially kudos to you for walking us into a deeper level of authenticity. Love it. Thank you. I'm, to answer some of your questions, Justin very similar to Chelsea in that tech was not my first rodeo. I didn't become a programmer until I was 37 years old and I am now 45. I'm totally fine with aging myself. Prior to tech, I did put a lot more of my identity in my job and I would usually do that job pretty much all of the hours possible and I've always worked for mission driven organizations. A lot of the things that we're talking about as far as job fulfillment and whether, or not it's a good environment, or if it's a toxic environment, there's a lot of privilege in what we're talking. My parents were paper mill workers and it was not pretty. They had me when they were 19, so they didn't have another option. That was the highest paying gig in our region and they had no education. So it was never an option to even change that. So I am someone who wants to put my whole self into what I do. It's a very working-class mode and gaining identity through what it is I'm able to do. It's also a pretty capitalist [laughs] mentality that I work to move around. But as a manager, when I am a manager, or in management, or managing managers, I'm never encouraging this everybody needs to bring their whole self to work. Although, I had this really instructive experience where one person truly did not want to have any of their self at work, that they truly only wanted to talk about work at work. We're not a family, nicely nice. I don't want to crochet together, or whatever. That is the most challenged I've ever been as a manager because my natural things are always to figure out what people need and want, and then amalgamate that across the group and see how we can do some utilitarian math and get it so that people are being encouraged in ways they would like, they are not being disadvantaged, and they have space to say when that's happening. But even still, I'm always going with the let's be buddies plan and it's not for everyone. So figuring out how to not have all of your eggs in any basket, no matter how many hours the job is, is definitely a tactic that has been successful for me. But what happens is I then am involved in so many things [chuckles] in all of the moments of life. So I still do that, but I do it by working more, which isn't necessarily the best option. The thing about the mission that I just wanted to pivot for a second and say is, we are no longer in a world where we allow failure. This is a little bit back to my earlier soapbox. The energetic reality is whatever anybody's mission statement is, that is the thing they are going to fail at, like the seamstress never has the best hemmed clothes. So when we write off anyone, or any company based their flawed attempt at the mission, we're discounting that flaws exist, [chuckles] contradictions exist. It's about where are we orienting and are we incrementally moving toward that, or away from it and not in this moment, are we this thing that we have declared because it's more of a path is how I see it than the declaration of success. JUSTIN: Yeah. Thank you so much for that, too. Because I think that one thing we didn't touch on is the universe – and we're talking a Greater Than Code podcast so it's software industry adjacent at least. The universe of people who got to stay home during this whole pandemic. The universe of people who are “knowledge workers”, or “white collar”, especially if you look at the population of the world, is vanishingly small. There was a season in my life where I was the person that you just described managing, where I just viewed myself as I was burnt out. I always wanted to be a mercenary. I had this mindset of I show up at work. “You want some great code? I'll sling you some great code.” Like I was a short-order cook for story points and feature development and that was the terms, right? I didn't want to bring my feelings to work. I didn't want to make friends with people because then God forbid, it would be harder to leave. I didn't have that available to me as a capacity at that time, but I went long enough and I realized it's not that I was missing something, or not being fed in some way by not having this emotional need filled at work. It was that I was failing to acknowledge when you say privilege, the literal privilege, that I get to wake up in the morning and think for a job [laughs] and the impact that I can have when I apply all of the skills, capabilities, and background asynchronous thoughts that are not literally in my job description. When I can bring those things to bear, I'm going to have a much, much bigger impact because what am I except for one person thinking and staring at a matted piece of glass all day, but somebody who is in a small community, or a group of a bunch of people who are in the same mode. So when I'm in a meeting, I can just be the mercenary jerk who's just like, “Hey, I'm just doing this,” and feeling like that's an emotionally neutral thing. When in fact, that negativity can be in an emotional contagion that could affect other work negatively, or and I'm not exactly – My friends who know me, I'm a stick in a mud, I'm a curmudgeon, I'm super negative. I complain constantly and I have taken it upon myself to strive to be a net increase in joy in the people that I talk to and that I interact with at work. Because it is a resource that is draining all of us all day long on its own and it needs to be filled up somehow. I have the capacity right now to take it upon myself to try to fill that tank up for the people that I interact with. So I want to touch on that because I just think it's super lucky that I get to work on a computer and talk out of a screen all day long. If I didn't have that, we wouldn't be having this conversation, I suppose, but I'm just here to make the most of it, I guess. MAE: I love that. And you reminded me of Sandi Metz's closer, Lucky You. JACOB: Tell us about it. MAE: She gave the closing talk a couple years ago and it's called Lucky You and it goes through how did we all come to be sitting in this room right now and what about redlining? What about the districting? What about all of these things that led to us to experience being here as lucky? I know you weren't saying it in that way, Justin, but it reminded me of that piece, too, which is relevant, but the talk is completely amazing and I definitely recommend it. JUSTIN: I think I mentioned it once before. The thing that brought me and our marketing director, Cathy, to think that this would be a great forum to talk a little bit about trust at work is that we're about out to – and I think that actually the day that this podcast publishes is the day that we're going to publish a new conference talk that I've prepared called How to Trust Again and we're going to post it to Test Double's YouTube channel. So we might not have a direct link for the show notes necessarily, but it'll probably be at the top of that as well as the top of our blog when the show goes live. I hope that anyone [laughs] who enjoyed this conversation will also enjoy the kind of high paced, frenetic, lots of keynote slide style that I bring to communicating about a lot of these topics while still understanding that it's just like n equals one. I'm sharing my experience and hopefully, as food for thought to maybe help you look back at your own experience and understand what connects from my experiences, my perspectives, and my context that might be useful and I hope that you'll find something. Special Guest: Justin Searls.

00:36 - Panelist Consulting Experience and Backgrounds * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) * Happy and Effective (https://www.happyandeffective.com/) 10:00 - Marketing, Charging, and Setting Prices * Patreon (https://www.patreon.com/) * Chelsea's Blog (https://chelseatroy.com/) * Self-Worth by Salary 28:34 - GeePawHill Twitter Thread (https://twitter.com/GeePawHill/status/1478950180904972293) - Impact Consulting * Casey's Spreadsheet - “Matrix-Based Prioritization For Choosing a Job” (https://docs.google.com/spreadsheets/d/1qVrWOKPe3ElXJhOBS8egGIyGqpm6Fk9kjrFWvB92Fpk/edit#gid=1724142346) * Interdependence (https://www.merriam-webster.com/dictionary/interdependence) 38:43 - Management & Mentorship * Detangling the Manager: Supervisor, Team Lead, Mentor (https://dev.to/endangeredmassa/detangling-the-manager-supervisor-team-lead-mentor-gha) * Adrienne Maree Brown (https://adriennemareebrown.net/) 52:15 - Explaining Value and Offerings * The Pumpkin Plan: A Simple Strategy to Grow a Remarkable Business in Any Field by Mike Michalowicz (https://www.amazon.com/Pumpkin-Plan-Strategy-Remarkable-Business/dp/1591844886) * User Research * SPIN Selling: Situation Problem Implication Need-payoff by Neil Rackham (https://www.goodreads.com/book/show/833015.SPIN_Selling) 55:08 - Ideal Clients Reflections: Mae: The phrase “indie”. Casey: Having a Patreon to help inspire yourself. Chelsea: Tallying up all of the different things that a given position contributes to in terms of a person's needs. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: CHELSEA: Welcome to Greater Than Code, Episode 267. I'm Chelsea Troy, and I'm here with my co-host, Mae. MAE: And also with us is Casey. CASEY: Hi, I'm Casey. And today's episode, we are our own guests. We're going to be talking to you about our experiences in consulting. To get this one started, how about we share what got us into consulting and what we like, don't like about it, just high-level? Chelsea, would you mind going first? CHELSEA: Sure. So I started in consulting, really in a full-time job. So for early in my programming career, I worked for several years for a company called Pivotal Labs and Pivotal Labs is chiefly, or was chiefly at the time, a software engineering consulting organization. My job was to pair program with folks from client teams, various types of clients, a lot of health insurance companies. At the time, there was a restaurant loyalty app that we did some work for. We did some work for General Motors, various clients, a major airline was also a client, and I would switch projects every three to six months. During that time employed by Labs, I would work for this client, pair programming with other pivots, and also with client developers. So that was my introduction to consulting and I think that it made the transition to consulting later, a little bit easier because I already had some consulting experience from under the Labs' umbrella. After I worked for Labs, I moved on to working at a product company for about 2 years and my experience at that product company burned me out on full-time programming for a little while. So in my last couple of months at that job, I realized that I was either going to have to take some time off, or I was going to have to find an arrangement that worked better for me for work, at least for the next little while. And for that next little while, what I decided I wanted to try to do was work part-time because I was uncomfortable with the idea of taking time off from programming completely. I felt that I was too early in my career and the skill loss would be too great if I took time off completely, but I knew I needed some space and so, I quit my full-time job. After I quit the full time—I probably should have done this before I quit the job, but I didn't—I called an organization that I had previously done some volunteer work with, with whom I discussed a job a couple of years prior, but for a couple of different reasons, it didn't work out. I said to them, “I know that you're a grant-funded organization and you rarely have the funding and capacity to bring somebody on, but just so you're aware, I like working with you. I love your product. I love the stuff that you work on. All our time working together, I've really enjoyed. So if you have an opening, I'm going to have some time available.” The director there emailed me that same day and said, “Our mobile developer put in his two weeks' notice this morning. So if you have time this afternoon, I'd really like to talk to you,” [chuckles] and that was my first client and they were a part-time client. I still work with them. I love working with them. I would consider them kind of my flagship client. But then from there, I started to kind of pick up more clients and it took off from there after that summer. I spent that summer generally working 3 days a week for that client and then spending 4 days a week lying face down in a park in the sun. That helped me recover a little bit from burnout. And then after that, I consulted full-time for about 2 years and I still consult on the side of a full-time job. So that's my story. Is anyone feeling a penchant for going next? MAE: I can go. I've been trying to think how am I going to say this succinctly. I've had at least two jobs and several club, or organization memberships, or founding, or positions since I was 16. So wherever I go, I've always been saying, “Well, I've done it these 47 ways already [laughs] even since I was a teenager.” So I've sort of always had a consulting orientation to take a broader view and figure out ways in which we can systematize whatever it is that's happening around me. Specifically for programming, I had been an administrator, like an executive leader, for many years. I just got tired of trying to explain what we as administrators needed and I just wanted to be able to build the things. I was already a really big Microsoft access person and anybody who just got a little [laughs] snarky in there knows I love Microsoft Access. It really allowed me to be able to offer all kinds of things to, for example, I was on the board of directors of my Kiwanis Club and I made a member directory and attendance tracker and all these things. Anyway, when I quit my executive job and went to code school in 2014, I did it because I knew that I could build something a lot better than this crazy Access database [laughs] that I had, this very involved ETL things going on in. I had a nonprofit that I had been involved with for 15 years at that point and I had also taken a database class where I modeled this large database that I was envisioning. So I had a bunch of things in order. I quit my full-time job and went to an income of $6,500 my first year and I hung with that flagship customer for a while and tailored my software. So I sort of have this straddling of a SaaS situation and a consulting situation. I embed into whoever I'm working with and help them in many ways. Often, people need lots of different levels of coaching, training, and skills development mixed with just a place to put things that makes sense to them. I think that's the brief version [laughs] that I can come up with and that is how I got where I am and I've gone in and out of also having a full-time job. Before I quit that I referenced the first year I worked a full-time job plus at least 40 to a 100 hours on my software to get it ready for prime time. So a lot of, a lot of work. CASEY: Good story. I don't think I ever heard these fuller stories from either of you, even though I know roughly the shape of your past. It's so cool to hear it. Thanks for sharing them. All right, I'll share about me now. So I've been a developer, a PM, and I've done a lot of design work. I've done all the roles over my time in tech. I started doing programming 10, 15 years ago, and I'm always getting burnt out everywhere I go because I care so much and we get asked to do things that seem dumb. I'm sure anyone listening can relate to this in some organization and when I say dumb, I don't use that word myself directly. I'm quoting a lot of people who would use that word, but I say either we're being asked to do things that don't make sense, aren't good ideas, or there are things that are we're being asked to do that would make sense if we knew why and it's not being communicated really well. It's poor communication. Either one, the other, or both. So after a lot of jobs, I end up taking a 3-month sabbatical and I'm like, “Whatever, I got to go. I can't deal with caring so much anymore, and I'm not willing to care less either.” So most recently, I took a sabbatical and I finished my book, Debugging Your Brain, which takes together psychology ideas, like cognitive behavioral therapy and programming ideas and that, I'm so proud of. If you haven't read it yet, please check it out. Then I went back to my job and I gave them another month where I was like, “All right, look, these are things need to change for me to be happy to work here.” Nothing changed, then I left. Maybe it's changing very slowly, but too slowly for me to be happy there, or most of these past companies. [laughs] After I left, this last sabbatical, I spent three to six months working on a board game version of my book. That's a lot of fun. And then I decided I needed more income, I needed to pay the bills, and I can totally be a tech consultant if I just deal with learning marketing and sales. That's been my… probably six months now, I've been working on the marketing in sales part, thinking a lot about it. I have a lot of support from a lot of friends. Now I consult on ways to make teams happier and more effective and that's my company name, Happy and Effective. I found it really easy to sell workshops, like diversity, equity, and inclusion workshops to HR departments. They're pretty hungry for those kinds of workshops and it's hard to find good, effective facilitators. It's a little bit harder to get companies to pay for coaching for their employees, even though a new EM would love coaching and how to be a good leader. Companies don't always have the budget for that set aside and I wish they would. I'm working with a lot of companies. I have a couple, but not as many as I'd like. And then the hardest, my favorite kind of client is when I get to embed with the team and really work on seeing what's going on me on the ground with them, and help understand what's going on to tell the executives what's happening and what needs to change and really make a big change. I've done that once, or twice and I'd love to do that more, but it's the hardest. So I'm thinking about easy, medium, hard difficulty of selling things to clients. I would actually make plenty of money is doing workshops, honestly, but I want the impact of embedding. That's my bigger goal is the impact. MAE: Yeah. I basically have used my software as a Trojan horse for [laughs] offering the consulting and change management services to help them get there because that is something that people already expect to spend some money on. That, though has been a little problematic because a few years in, they start to think that the line item in the budget is only for software and then it looks very expensive to them. Whereas, if they were looking at it as a consultant gig, it's incredibly inexpensive to them. CASEY: Yeah. It's maybe so inexpensive that it must not be a quality product that they're buying. MAE: Yes. CASEY: Put it that way implicitly. MAE: Definitely, there's also that. CASEY: When setting prices, this is a good general rule of thumb. It could be too low it looks like it'll be junk, like a dollar store purchase, or it can be too high and they just can't afford it, and then there's the middle sweet spot where it seems very valuable. They barely can afford it, but they know it'll be worth it, and that's a really good range to be in. MAE: Yeah. Honestly, for the work that I do, it's more of a passion project. I would do it totally for free, but that doesn't work for this reason you're talking about. CASEY: Yeah. MAE: Like, it needs to hurt a little bit because it's definitely going to be lots and lots of my time and it's going to be some of their time and it needs to be an investment that not hurt bad [laughs] but just be noticeable as opposed to here's a Kenny's Candy, or something. CASEY: I found that works on another scale, on another level. I do career coaching for friends, and friends of friends, and I'm willing to career coach my friends anyway. I've always been. For 10 years, I've reviewed hundreds, thousands of resumes. I've done so many interviews. I'm down to be a career coach, but no one was taking me up on it until I started charging and now friends are coming to me to pay me money to coach them. I think on their side, it feels more equitable. They're more willing to do it now that I'm willing to take money in exchange for it. I felt really bad charging friends until I had the sliding skill. So people who make less, I charge less for, for this personal service. It's kind of weird having a personal service like that, but it works out really well. I'm so happy for so many friends that have gotten jobs they're happy with now from the support. So even charging friends, like charging them nothing means they're not going to sign up for it. MAE: Yes, and often, there is a bias of like, “Oh, well, that's my friend.” [laughs] so they must not be a BFD.” CASEY: Yeah. But we are all BFDs. MAE: Exactly! How about you Chelsea? How did you start to get to the do the pricing thing? CHELSEA: Yeah, I think it's interesting to hear y'all's approaches to the marketing and the pricing because mine has been pretty different from that. But before I get off on that, one thing I do want to mention around getting started with offering personal services at price is that if it seems too large a step to offer a personal service to one person for an amount of money, one thing that I have witnessed folks have success with in starting out in this vein is to set up a Patreon and then have office hours for patrons wherein they spend 2 hours on a Sunday afternoon, or something like that and anyone who is a patron is welcome to join. What often ends up happening for folks in that situation is that people who are friends of theirs support their Patreon and then the friends can show up. So effectively, folks are paying a monthly fee for access to this office hours, which they might attend, or they might not attend. But there are two nice things about it. The first thing about it is that you're not – from a psychological perspective, it doesn't feel like charging your friends for your time with them. It feels more indirect than that in a way that can be helpful for folks who are very new to charging for things and uncomfortable with the idea. The second thing is that the friends are often much more willing to pay than somebody who's new to charging is willing to charge. So the friends are putting this money into this Patreon, usually not because they're trying to get access to your office hours, but because they want to support you and one of the nice things about Patreon is that it is a monthly amount. So having a monthly email from Patreon that's like, “Hey, you we're sending you—” it doesn't even have to be a lot. “We're sending you 40 bucks this month.” It is a helpful conditioning exercise for folks who are not used to charging because they are getting this regular monthly income and the amount is not as important as receiving the regular income, which is helpful psychological preparation for charging for things on your own, I think. That's not the way that I did it, but I have seen people be effective that way. So there's that. For me, marketing was something that I was very worried about having to do when I started my business. In fact, it was one of those things where my conviction, when I started my consulting business, was I do not want to have to sell my services. I will coast on what clients I can find and when it is no longer easy, I will just get a full-time job because selling traditionally conceptualized is not something that I enjoyed. I had a head start on the marketing element of things, that is sort of the brand awareness element of things, my reputation and the reason for that is that first of all, I had consulted at Labs for several years, which meant that every client team that I had ever worked with there, the director remembered me, the product owner remember me. So a lot of people who had been clients of Labs – I didn't actually get anybody to be a client of mine who was a client of Labs, but the individuals I had worked with on those projects who had then changed jobs to go to different companies, reached out to me on some occasions. So that was one place that I got clients from. The other place that I gotten clients from has been my blog. Before I started my business, I had already been writing a tech blog for like 4, or 5 years and my goal with the tech blog has never actually been to get clientele, or make money. My goals for the blog when I started it were to write down what I was learning so that I would remember it and then after that, it was to figure out how to communicate my ideas so that I would have an easier time communicating them in the workplace. After that, it became an external validation source so that I would no longer depend on my individual manager's opinion of me to decide how good I was at programming. Only very recently has it changed to something like, okay, now I'm good enough at communicating and good enough at tech that I actually have something to teach anybody else. So honestly, for many years, I would see the viewership on my blog and I would be like, “Who are all these people? Why are they in my house?” Like, this is weird, but I would get some credibility from that. CASEY: They don't expect any tea from me. CHELSEA: Yeah. I really hope. I don't have enough to go around, [laughs] but it did help and that's where a lot of folks have kind of come from. Such that when I posted on my blog a post about how I'm going to be going indie. I've quit my job. I didn't really expect that to go anywhere, but a few people did reach out from that and I've been lucky insofar is that that has helped me sustain a client load in a way that I didn't really expect to. There's also, I would be remiss not to mention that what I do is I sling code for money for the majority of my consulting business, at least historically and especially in the beginning was exclusively that, and there's enough of a demand to have somebody come in and write code that that helped. It also helped that as I was taking on clients, I started to niche down specifically what I wanted to work on to a specific type of client and to a specific type problem. So I quickly got to the point where I had enough of a client load that I was going to have to make a choice about which clients to accept, or I was going to have to work over time. Now, the conventional wisdom in this circumstance is to raise your rates. Vast majority of business development resources will tell you that that's what you're supposed to do in this situation. But part of my goal in creating my consulting business had been to get out of burnout and part of the reason for the burnout was that I did not feel that the work that I was doing was contributing to a cause that made me feel good about what I was doing. It wasn't morally reprehensible, but I just didn't feel like I was contributing to a better future in the way that my self-identity sort of mandated that I did. It was making me irritable and all these kinds of things. MAE: I had the same thing, yeah. CHELSEA: Yeah. So it's interesting to hear that that's a common experience, but if I were to raise my rates, the companies that were still going to be able to afford me were going to be companies whose products were not morally reprehensible, but not things that coincided with what I was trying to get out of my consulting business. So what I did instead was I said, “I'm specifically looking to work with organizations that are contributing to basic scientific research, improving access for underserved communities, and combating the effects of climate change,” and kept my rates effectively the same, but niche down the clientele to that. That ended up being kind of how I did it. I find that rates vary from client to client in part, because of what you were talking about, Casey, wherein you have to hit the right price in order to even get clients board in certain circumstances. CASEY: Right. CHELSEA: I don't know a good way to guess it. My technique for this, which I don't know if this is kosher to say, but my technique for this has been whoever reached out to me, interested in bringing me on as a consultant for that organization, I ask that person to do some research and figure out what rate I'm supposed to pitch. That has helped a lot because a lot of times my expectations have been wildly off in those circumstances. One time I had somebody say to me, this was for a custom workshop they wanted. I was like, “What should I charge?” And they were like, “I don't know, a few thousand.” I was like, “Is that $1,200? Is that $9,000? I don't know how much money that is,” and so they went back and then they came back and they were able to tell me more specifically a band. There was absolutely no way I would've hit that number accurately without that information. CASEY: Yeah, and different clients have different numbers. You setting your price standard flat across all customers is not a good strategy either. That's why prices aren't on websites so often. CHELSEA: Yeah. I find that it does depend a lot. There's similarly, like I said, a lot of my clients are clients who are contributing to basic scientific research are very often grant funded and grants funding is a very particular kind of funding. It can be intermittent. There has to be a skillset on the team for getting the grant funding. A lot of times, to be frank, it doesn't support the kinds of rates that somebody could charge hourly in a for-profit institution. So for me, it was worth it to make the choice that this is who I want to work with. I know that my rate is effectively capped at this, if I'm going to do that and that was fine by me. Although, I'm lying to say it was completely fine by me. I had to take a long, hard look in the mirror, while I was still in that last full-time job, and realize that I had become a person who gauged her self-worth by the salary that she commanded more than I was comfortable with. More than I wanted to. I had to figure out how to weaken that dependency before I was really able to go off and do my own thing. That was my experience with it. I'm curious whether y'all, well, in particular, Casey, did you find the same thing? CASEY: The self-worth by salary? CHELSEA: Yeah. CASEY: I felt that over time, yeah. Like I went from private sector big tech to government and I got a pay cut and I was like, “Ugh.” It kind of hurt a little and it wasn't even as much as I was promised. Once I got through the hiring process, it was lower than that and now I'm making way less. When I do my favorite impact thing, the board game, like if I made a board game about mental health for middle schoolers, which is something I really want to do, that makes less than anything else I could with my time. I'll be lucky to make money on that at all. So it's actually inverse. My salary is inversely proportional to how much impact I can have if I'm working anyway. So my dream is to have enough corporate clients that I can do half-time, or game impact, whatever other impact things I'm thinking about doing. I think of my impact a lot. Impact is my biggest goal, but the thing is salary hurts. If I don't have the salary and I want to live where I'm living and the lifestyle I have, I don't want to cut back on that and I don't need to, hopefully. CHELSEA: Right. CASEY: I'm hoping eventually, I'll have a steady stream of clients, I don't need to do the marketing and sales outreach as much and all those hours I kind of recoup. I can invest those in the impact things. I've heard people can do that. I think I'll get there. CHELSEA: No, I think you absolutely will. Mae, I'm curious as to your experience, because I know that you have a lot of experience with a similar calculation of determining which things are going to provide more income, which things are probably going to provide less income, and then balancing across a bunch of factors like money, but also impact, time spent, emotional drain, and all that stuff. MAE: Well, Chelsea. [laughter] I am a real merry go round in this arena. So before I became a programmer, I had a state job, I was well paid, and I was pretty set. Then I was a programmer and I took huge pay cut because I quit. I became a programmer when I was 37 years old. So I already had a whole career and to start at the beginning and be parallel with 20-year-old so it's not just like my salary, but also my level and my level of impact on my – and level of the amount of people who wanted to ask me for my advice [laughs] was significantly different. So like the ego's joking stopped and so when you mentioned the thing about identity. Doing any kind of consulting in your own deal is a major identity reorganization and having the money, the title, the clout, and the engagement. Like a couple years, I have spent largely alone and that is very different than working at a place where I have colleagues, or when I live somewhere and have roommates. But I have found signing up for lots and lots of different social justice and passion project things, and supporting nonprofits that I believe in. So from my perspective, I'm really offering a capacity building grant out of my own pocket, my own time, and my own heart and that has been deeply rewarding and maybe not feel much about my identity around salary. Except it does make me question myself as an adult. Like these aren't the best financial decisions to be making, [chuckles] but I get enough out of having made them that it's worth it to me. One of the things probably you were thinking of, Chelsea, we worked together a little bit on this mutual aid project that I took on when the pandemic started and I didn't get paid any dollars for that and I was working 18 hours a day on it, [chuckles] or something. So I like to really jump in a wholeheartedly and then once I really, really do need some dollars, then I figure something else out. That is kind of how I've ebbed and flowed with it. But mostly, I've done it by reducing my personal overhead so that I'm not wigged about the money and lowering whatever my quality-of-life spending goals [chuckles] are. But that also has had to happen because I have not wanted to and I couldn't get myself to get excited about marketing of myself and my whole deal. Like I legit still don't have a website and I've been in operation now since 2014 so that's a while. I meet people and I can demonstrate what it is and I get clients and for me, having only a few clients, there's dozens of people that work for each one. So it's more of an organization client than a bunch of individuals and I can't actually handle a ton. I was in a YCombinator thing that wanted me to really be reporting on income, growth rates, and all of these number of new acquisition things, and it just wasn't for me. Those are not my goals. I want to make sure that this nonprofit can help more people this year and that they can get more grant money because they know how many people they helped and that those people are more efficient at their job every day. So those are harder to measure. It's not quite an answer to your question, [laughs] but I took it and ran a little. CHELSEA: No, I appreciate that. There is a software engineer and a teacher that I follow on Twitter. His name is GeePawHill. Are y'all familiar with GeePawHill? MAE: No. CHELSEA: And he did a thread a couple of days ago that this conversation reminds me of and I found it. Is that all right if I read like a piece of it and paraphrase part of it? MAE: Yes, please. CHELSEA: Okay. So this is what he says. He says, “The weirdest thing about being a teacher for young geek minds: I am teaching them things…that their actual first jobs will most likely forbid them to do. The young'uns I work with are actually nearly all hire-able as is, after 18 months of instruction, without any intervention from me. The problem they're going to face when they get to The Show isn't technical, or intellectual at all. No language, or framework, or OS, or library, or algorithm is going to daunt them, not for long. No, the problem they're going to face is how to sustain their connection to the well of geek joy, in a trade that is systematically bent on simultaneously exploiting that connection while denying it exists and refusing any and all access to it. It is possible, to stick it out, to acquire enough space and power, to re-assert one's path to the well. Many have done it; many are doing it today. But it is very hard. Very hard. Far harder than learning the Visitor pattern, or docker, or, dart, or SQL, or even Haskell. How do you tell people you've watched “become” as they bathed in the cool clear water that, for some long time, 5 years or more, they must…navigate the horrors of extractive capitalist software development? The best answer I have, so far, is to try and teach them how and where to find water outside of work. It is a lousy answer. I feel horrible giving it. But I'd feel even more horrible if I didn't tell them the truth.” CASEY: I just saw this thread and I really liked it, too. I'm glad you found it. MAE: Oh, yeah. I find it honestly pretty inspiring, like people generally who get involved in the kinds of consulting gigs that we three are talking about, which is a little different than just any random consulting, or any random freelancing. CASEY: Like impact consulting, I might call that. MAE: Yeah. It's awesome if the money comes, but it's almost irrelevant [chuckles] provided that basic needs are meant. So that's kind of been my angle. We'll see how – talk to me in 20 more years when I'm [chuckles] trying to retire and made a lot of choices that I was happy with at the time. CASEY: This reminds me of a conversation I had with a friend who's an executive director of an orchestra in the nonprofit space and he was telling me that so many nonprofits shoot themselves in the foot by not doing enough fundraising, by not raising money, and that comes from not wanting to make money in a way because they're a nonprofit, money is not a motive, and everybody's very clear about that. That's noble and all, but it ends up hurting them because they don't have the money to do the impactful things they would as a nonprofit. Money is a necessary evil here and a lot of people are uncomfortable with it. Including me a lot of the time. Honestly, I have to tell myself not to. What would I tell a friend? “No, charge more money.” Okay, I guess I'll tell myself to do that now. I have this conversation with myself a lot. MAE: Yeah. I've been very aware that when I become anti-money, the well dries up. The money well. [laughs] CASEY: Yeah. MAE: And when I am respectful of and appreciative of money in the world, more comes my way. There is an internal dousing, I think that happens that one needs to be very careful about for sure. CASEY: One of the techniques I use with myself and with clients is a matrix where I write out for this approach, this thing that I'm thinking about how much money will it make, how much impact will it have on this goal, and all the different heuristics I would use to make the decision, or columns and all the options arose. I put numbers in it and I might weight my columns because money is less important than impact, but it's still important. It's there. I do all this math. In the end, the summary column with the averages roughly matches what's in my head, which is the things that are similar in my head are similar on paper, but I can see why and that's very clarifying for me. I really like being able to see it in this matrix form and being able to see that you have to focus on the money some amount. If you just did the high impact one, it wouldn't be on the top of the list. It's like, it's hard to think about so many variables at once, but seeing it helps me. CHELSEA: It is. GeePaw speaks to that some later in the thread. He says, “You've got to feed your family. You've got to. That's not negotiable. But you don't got to forget the well. To be any good at all, you have to keep finding the well, keep reaching it, keep noticing it. Doesn't matter whether it's office hours, or after hours. Matters whether you get to it. The thing you've got to watch, when you become a professional geek, isn't the newest tech, and it sure as hell isn't the org's process. You've got to watch whether, or how you're getting to the well. If you're getting to the well, in whatever way, you'll stay alive and change the world.” I think I'm curious as to y'all's thoughts on this, but like I mentioned earlier, I have a full-time job and I also do this consulting on the side. I also teach. I teach at the Master's program in computer science at University of Chicago. I do some mentoring with an organization called Emergent Works, which trains formerly incarcerated technologists. The work situation that I have pieced together for myself, I think manages to get me the income I need and also, the impact that I'm looking for and the ability to work with people and those kinds of things. I think my perspective at this point is that it's probably difficult, if it's realistic at all, to expect any one position to be able to meet all of those needs simultaneously. Maybe they exist, but I suspect that they're relatively few and far between and I think that we probably do ourselves a disservice by propagating this idea that what you need to do is just make yourself so supremely interview-able that everybody wants to hire you and then you get to pick the one position where you get to do that because there's only one in the entirety of tech, it's that rare. Sure, maybe that's an individualist way to look at it. But when we step back and look more closely, or when we step back and look more broadly at that, it's like, all right, so we have to become hypercompetitive in order to be able to get the position where we can make enough while helping people. Like, the means there seem kind of cutthroat for the ends, right? [laughs] CASEY: This reminds me of relationships, too and I think there's a lot of great parallels here. Like you shouldn't expect your partner to meet all of your needs, all of them. MAE: I was thinking the same thing! CASEY: Uh huh. Social, emotional, spiritual, physical, all your needs cannot possibly by one person and that is so much pressure to put on that person, CHELSEA: Right. CASEY: It's like not healthy. CHELSEA: Right. CASEY: You can choose some to prioritize over others for your partner, but you're not going to get a 100% of it and you shouldn't. CHELSEA: Well, and I find that being a conversation fairly regularly in monogamous versus polyamorous circles as well. Like, how much is it appropriate to expect of a partner? But I think it is a valid conversation to have in those circles. But I think that even in the context of a monogamous relationship, a person has other relationships—familial relationships, friend relationships—outside of that single romantic relationship. CASEY: Co-workers, community people, yeah. CHELSEA: Right. But even within that monogamous context, it's most realistic and I would argue, the most healthy to not expect any one person to provide for all of your needs and rather to rely on a community. That's what we're supposed to be able to do. CASEY: Yeah. MAE: Interdependence, not independence. CHELSEA: Right. CASEY: It's more resilient in the face of catastrophe, or change in general, mild, more mild change and you want to be that kind of resilient person for yourself, too. Just like you would do a computer system, or an organization. They should be resilient, too. MAE: Yes. CASEY: Your relationship with your job is another one. MAE: Totally. CHELSEA: Right. And I think that part of the reason the burnout is so quick – like the amount of time, the median amount of time that somebody spends at a company in tech is 2.2 years. MAE: I know, it's so weird. CHELSEA: Very few companies in tech have a large number of lifers, for example, or something like that. There are a number of reasons for that. We don't necessarily have to get into all of them, although, we can if you want. But I think one of them is definitely that we expect to get so much out of a full-time position. Tech is prone. due to circumstances of its origin, to an amount of idealism. We are saving the world. We, as technologists, are saving the world and also, we, as technologists, can expect this salary and we, as technologists, are a family and we play ping pong, and all of these things – [laughter] That contribute to an unrealistic expectation of a work environment, which if that is the only place that we are getting fulfillment as programmers, then people become unsatisfied very quickly because how could an organization that's simultaneously trying to accomplish a goal, meet all of these expect for everybody? I think it's rare at best. CASEY: I want to bring up another example of this kind of thing. Imagine you're an engineer and you have an engineering manager. What's their main job? Is it to get the organization's priorities to be done by the team, like top-down kind of thing? We do need that to happen. Or is it to mentor each individual and coach them and help them grow as an engineer? We need that somewhere, too, yeah. Or is it to make the team – like the team to come together as a team and be very effective together and to represent their needs to the org? That, too, but we don't need one person to do all three of those necessarily. If the person's not technical, you can get someone else in the company to do technical mentorship, like an architect, or just a more senior person on, or off the team somewhere else. But we put a lot of pressure on the engineering managers to do that and this applies to so many roles. That's just one I know that I can define pretty well. There's an article that explains that pretty well. We'll put in the show notes. MAE: Yes! So what I am currently doing is I have a not 40 hours a week job as an engineering manager and especially when I took the gig, I was still doing all of these pandemic charity things and I'm like, “These are more important to me right now and I only have so many hours in the day. So do you need me to code at this place? I can, but do you need me to because all those hours are hours I can go code for all these other things that I'm doing,” and [laughs] it worked. I have been able to do all three of the things that you're talking about, Casey, but certainly able to defer in different places and it's made me – this whole thing of not working full-time makes you optimize in very different ways. So I sprinkle my Slack check-ins all day, but I didn't have to work all day to be present all day. There's a lot that has been awesome. It's not for everyone, but I also have leaned heavily on technical mentorship happening from tech leads as well. CASEY: Sounds good. MAE: But I'm still involved. But this thing about management, especially in tech being whichever programmer seems like the most dominant programmer is probably going to be a good needs to be promoted into management. Just P.S. management is its own discipline, has its own trajectory and when I talk to hiring managers and they only care about my management experience in tech, which is 6 years, right? 8, but I have 25 years of experience in managing. So there's a preciousness of what it is that we are asking for the employees and what the employees are asking of the employer, like you were talking about Chelsea, that is very interesting. It's very privileged, and does lead a lot of people to burnout and disappointment because their ideas got so lofty. I just want to tie this back a little bit too, something you read in that quote about – I forget the last quote, but it was something about having enough to be able to change the world and it reminded me of Adrienne Maree Brown, pleasure activism, emergent strategy, and all of her work, and largely, generations of Black women have been saying, “Yo, you've got to take care [chuckles] of yourself to be able to affect change.” Those people have been the most effective and powerful change makers. So definitely, if you're curious about this topic, I urge you to go listen to some brilliant Black women about it. CASEY: We'll link that in the show notes, too. I think a lot about engineering managers and one way that doesn't come up a lot is you can get training for engineering managers to be stronger managers and for some reason, that is not usually an option people reach for. It could happen through HR, or it could happen if you have a training budget and you're a new EM, you could use your training budget to hire coaching from someone. I'm an example. But there's a ton of people out there that offer this kind of thing. If you don't learn the leadership skills when you switch roles, if you don't take time to learn those skills that are totally learnable, you're not going to have them and it's hard to apply them. There's a lot of pressure to magically know them now that you've switched hats. MAE: And how I don't understand why everyone in life doesn't have a therapist, [laughs] I don't understand why everyone in life doesn't have multiple job coaches at any time. Like why are we not sourcing more ideas and problem-solving strategies, and thinking we need to be the repository of how to handle X, Y, Z situation? CASEY: For some reason, a lot of people I've talked to think their manager is supposed to do that for them. Their manager is supposed to be their everything; their boss. They think the boss that if they're bad, you quit your job. If they're good, you'll stay. That boss ends up being their career coach for people, unless they're a bad career coach and then you're just stuck. Because we expect it so strongly and that is an assumption I want everyone listening to question. Do you need your manager at work to be that person for you? If they are, that's great. You're very fortunate. If not, how can you find someone? Someone in the community, a friend, family member, a professional coach, there's other options, other mentors in the company. You don't have to depend on that manager who doesn't have time for you to give you that kind of support. CHELSEA: So to that end, my thinking around management and mentorship changed about the time I hit – hmm. It was a while ago now, I don't know, maybe 6 years as a programmer, or something like that. Because before that, I was very bought into this idea that your manager is your mentor and all these types of things. There was something that I realized. There were two things that I realized. The first one was that, for me, most of my managers were not well set up to be mentors to me and this is why. Well, the truth is I level up quickly and for many people who are managers in a tech organization, they were technologists for 3 to 5 years before they became managers. They were often early enough in their career that they didn't necessarily know what management entailed, or whether they should say no based on what they were interested in. Many managers in tech figure out what the job is and then try to find as many surreptitious ways as possible to get back into the code. MAE: Yeah. CHELSEA: Additionally, many of those managers feel somewhat insecure about their weakening connection to the code base of the company that they manage. MAE: Yeah. CHELSEA: And so it can be an emotionally fraught experience for them to be mentor to someone whose knowledge of the code base that they are no longer in makes them feel insecure. So I learned that the most effective mentors for me – well, I learned something about the most effective mentors for me and I learned something of the most effective managers for me. I learned that the most effective managers for me either got way out ahead of me experience wise before they became managers, I mean 10 years, 15 years, 20 years, because those are not people who got promoted to management because they didn't know to say no. Those are people who got promoted to management after they got tired of writing code and they no longer staked their self-image on whether they're better coders than the people that they manage. That's very, very important. The other type of person who was a good manager for me was somebody who had never been a software engineer and there are two reasons for that. First of all, they trended higher on raw management experience. Second of all, they were not comparing their technical skillset to my technical skillset in a competitive capacity and that made them better managers for me, honestly. It made things much, much easier. And then in terms of mentors, I found that I had a lot more luck going outside of the organization I was working for mentors and that's again, for two reasons. The first one is that a lot of people, as they gain experience, go indie. Just a lot of people, like all kinds. Some of my sort of most trusted mentors. Avdi Grimm is somebody I've learned a lot from, indie effectively at this point. GeePawHill, like I mentioned, indie effectively at this point. Kenneth Mayer, indie effectively at this point. And these are all people who had decades of experience and the particular style of programming that I was doing very early in my career for many years. So that's the first reason. And then the second reason is that at your job, it is in your interest to succeed at everything you try—at most jobs. And jobs will tell you it's okay to fail. Jobs will tell you it's okay to like whatever, not be good at things and to be learning. But because if I'm drawing a paycheck from an organization, I do not feel comfortable not being good at the thing that I am drawing the paycheck for. MAE: Same. CHELSEA: And honestly, even if they say that that's the case, when the push comes to shove and there's a deadline, they don't actually want you to be bad at things. Come on! That doesn't make any sense. But I've been able to find ambitious projects that I can contribute to not for pay and in those situations, I'm much more comfortable failing because I can be like, “You know what, if they don't like my work, they can have all their money back.” And I work on a couple projects like that right now where I get to work with very experienced programmers on projects that are interesting and challenging, and a lot of times, I just absolutely eat dirt. My first PR doesn't work and I don't know what's wrong and the whole description is like somebody please help and I don't feel comfortable doing that on – if I had to do it at work, I would do it, but I'm not comfortable doing it. I firmly believe that for people to accelerate their learning to their full capacity for accelerating their learning, they must place themselves in situations where they not only might fail, but it's pretty likely. Because that's what's stretching your capacity to the degree that you need to get better and that's just not a comfortable situation for somewhere that you depend on to make a living. And that ended up being, I ended up approaching my management and my mentorship as effectively mutually exclusive things and it ended up working out really well for me. At this particular point in time, I happened to have a manager who happened to get way out ahead of me technically, and is willing to review PRs and so, that's very nice. But it's a nice-to-have. It's not something that I expect of a manager and it's ended up making me much more happy and manage relationships. MAE: I agree with all of that. So well said, Chelsea. CHELSEA: I try, I try. [laughs] Casey, are there things that you look for specifically in a manager? CASEY: Hmm. I guess for that question, I want to take the perspective inward, into myself. What do I need support on and who can I get that from? And this is true as also an independent worker as a consultant freelancer, too. I need support for when things are hard and I can be validated from people who have similar experiences, that kind of like emotional support. I need technical support and skills, like the sales I don't have yet and I have support for that, thank goodness. Individuals, I need ideally communities and individuals, both. They're both really important to me and some of these could be in a manager, but lately, I'm my own manager and I can be none of those things, really. I'm myself. I can't do this external support for myself. Even when I'm typing into a spreadsheet and the computer's trying to be a mirror, it's not as good as talking to another person. Another perspective that I need support on is how do I know what I'm doing is important and so, I do use spreadsheets as a mirror for that a lot of the time for myself. Like this impact is having this kind of magnitude of impact on this many people and then that calculates to this thing, maybe. Does that match my gut? That's literally what I want to know, too. The numbers aren't telling me, but talking to other people about impact on their projects really kind of solidifies that for me. And it's not always the client directly. It could be someone else who sees the impact I'm having on a client. Kind of like the manager, I don't want to expect clients to tell me the impact I'm having. In fact, for business reasons, I should know what the impact is myself, to tell them, to upsell them and continue it going anyway. So it really helps me to have peers to talk through about impact. Like that, too types of support. What other kinds of support do you need as consultants that I didn't just cover? MAE: I still need – and I have [laughs] hired Casey to help me. I still need a way to explain what it is that I am offering and what the value of that really is in a way that is clear and succinct. Every time I've gone to make a website, or a list of what it is that I offer, I end up in the hundreds of bullet points [laughs] and I just don't – [overtalk] CASEY: Yeah, yeah. MAE: Have a way to capture it yet. So often when people go indie, they do have a unique idea, a unique offering so finding a way to summarize what that is can be really challenging. I loved hearing you two when you were talking about knowing what kinds of work you want to do and who your ideal customer is. Those are things I have a clearer sense of, but how to make that connection is still a little bit of a gap for me. But you reminded me in that and I just want to mention here this book, The Pumpkin Plan, like a very bro business book situation, [chuckles] but what is in there is so good. I don't want to give it away and also, open up another topic [laughs] that I'll talk too long about. So I won't go into it right now, but definitely recommend it. One of the things is how to call your client list and figure out what is the most optimal situation that's going to lead toward the most impact for everybody. CASEY: One of the things I think back to a lot is user research and how can we apply that this business discovery process. I basically used the same techniques that were in my human computer interaction class I took 10, or 15 years ago. Like asking open ended questions, trying to get them to say what their problems are, remembering how they said it in their own words and saying it back to them—that's a big, big step. But then there's a whole lot of techniques I didn't learn from human computer interaction, that are sales techniques, and my favorite resource for that so far is called SPIN selling where SPIN is an acronym and it sounds like a wonky technique that wouldn't work because it's just like a random technique to pull out. I don't know, but it's not. This book is based on studies and it shows what you need to do to make big ticket sales go through, which is very different than selling those plastic things with the poppy bubbles in the mall stand in the middle of the hallway. Those low-key things they can manipulate people into buying and people aren't going to return it probably. But big-ticket things need a different approach than traditional sales and marketing knowledge and I really like the ideas in SPIN selling. I don't want to go into them today. We'll talk about it later. But those are two of the perspectives I bring to this kind of problem, user research and the SPIN selling techniques. I want to share what my ideal client would be. I think that's interesting, too. So I really want to help companies be happier and more effective. I want to help the employees be happier and more effective, and that has the impact on the users of the company, or whoever their clients are. It definitely impacts that, which makes it a thing I can sell, thankfully. So an organization usually knows when they're not the most happy, or the most effective. They know it, but my ideal client isn't just one that knows that, but they also have leadership buy-in; they have some leader who really cares and can advocate for making it better and they just don't know how. They don't have enough resources to make it happen in their org. Maybe they have, or don't have experience with it, but they need support. That's where I come in and then my impact really is on the employees. I want to help the employees be happier and more effective. That's the direct impact I want, and then it has the really strong, indirect impact on the business outcomes. So in that vein, I'm willing to help even large tech companies because if I can help their employees be happier, that is a positive impact. Even if I don't care about large tech companies' [chuckles] business outcomes, I'm okay with that because my focus is specifically on the employees. That's different than a lot of people I talk to; they really just want to support like nonprofit type, stronger impact of the mission and that totally makes sense to me, too. MAE: Also, it is possible to have a large and ever growing equitably run company. It is possible. I do want to contribute toward that existing in the world and as much as there's focus on what the ultimate looking out impact is, I care about the experience of employees and individuals on the way to get there. I'm not a utilitarian thinker. CASEY: Yeah, but we can even frame it in a utilitarian way if we need to. If we're like a stakeholder presentation, if someone leaves the company and it takes six months to replace them and their work is in the meantime off board to other people, what's the financial impact of all that. I saw a paper about it. Maybe I can dig it up and I'll link to it. It's like to replace a person in tech it costs a $100K. So if they can hire a consultant for less than a $100K to save one person from leaving, it pays for itself. If that number is right, or whatever. Maybe it was ten employees for that number. The paper will say much better than I will. CHELSEA: I think that in mentioning that Casey, you bring up something that businesses I think sometimes don't think about, which is some of the hidden costs that can easily be difficult to predict, or difficult to measure those kinds of things. One of the hidden costs is the turnover costs is the churn cost because there's how much it takes to hire another person and then there's the amount of ramp time before that person gets to where the person who left was. CASEY: Right, right, right. CHELSEA: And that's also a thing. There's all the time that developers are spending on forensic software analysis in order to find out all of the context that got dropped when a person left. CASEY: Yeah. The one person who knew that part of the code base, the last one is gone, uh oh. CHELSEA: Right. CASEY: It's a huge trust. And then engineering team is often really interested in conveying that risk. But if they're not empowered enough and don't have enough bandwidth time and energy to make the case, the executive team, or whoever will never hear it and they won't be able to safeguard against it. MAE: Or using the right language to communicate it. CASEY: Right, right. And that's its own skill. That's trainable, too thankfully. But we don't usually train engineers in that, traditionally. Engineers don't receive that training unless they go out of their way for it. PMs and designers, too, honestly. Like the stakeholder communication, everybody can work on. MAE: Yeah. CASEY: That's true. MAE: Communication. Everyone can, or not. Yes. [laughs] I learned the phrase indie today. I have never heard it and I really like it! It makes me feel cool inside and so love and – [overtalk] CASEY: Yeah, I have no record label, or I am my own record label, perhaps. MAE: Yo! CASEY: I've got one. I like the idea of having a Patreon, not to make money, but to have to help inspire yourself and I know a lot of friends have had Patreons with low income from it and they were actually upset about it. So I want to go back to those friends and say, “Look, this prove some people find value in what you're doing.” Like the social impact. I might make my own even. Thank you. MAE: I know I might do it too. It's good. That's good. CHELSEA: Absolutely. Highly recommended. One thing that I want to take away is the exercise, Casey, that you were talking about of tallying up all of the different things that a given position contributes in terms of a person's needs. Because I think that an exercise like that would be extremely helpful for, for example, some of my students who are getting their very first tech jobs. Students receive a very one-dimensional message about the way that tech employment goes. It tends to put set of five companies that show remain unnamed front and center, which whatever, but I would like them to be aware of the other options. And there is a very particular way of gauging the value of a tech position that I believe includes fewer dimensions than people should probably consider for the health of their career long-term and not only the health of their career, but also their health in their career. CASEY: One more parting thought I want to share for anyone is you need support for your career growth, for your happiness. If you're going to be a consultant, you need support for that. Find support in individuals and communities, you deserve that support and you can be that support for the people who are supporting you! It can be mutual. They need that, too.

Today's show marks our 36th and final episode of the Design To Be Conversation podcast before we come back in February 2022. Before we dive into our episode for today, I want to take a moment to say thank you. Thank you for listening and supporting Design To Be Conversation and thank you to each of our incredible guests who have made each episode so insightful and impactful. I'm extremely excited for the future of Design To Be Conversation. We have an incredible lineup of guests planned for next year, so be sure to follow us along on social at design_tobe or head to designtobeconversation.com to be the first to know when we return. Now, let's get into today's episode.Today, we are wrapping up our show with Raquel Breternitz. Raquel is an award-winning design leader and strategist with a resume spanning years of purpose-driven work experience from serving as Design Director for US Senator Elizabeth Warren to private sector credits at the New York Times, Pivotal Labs, and IBM. Raquel is a public speaker with works and topics connected by a passion for accessibility and inclusion, research-driven design thinking, and a hunger for tackling complex and challenging problems. She has spoken at Lesbians Who Tech, PluralSightLIVE, Wonder Women in Tech, and O'Reilly Design.We dive into what it means to connect with your passions and ideals in design, the importance of prioritizing rest and well-being to manage burnout, and intentional ways to practice self-care that provides purpose and joy.  

Welcome to our community's FIRST DEBATE! Farhan Thawar (VPE @ Shopify) & Jerry Krikheli (Sr. Director of Engineering @ Facebook) hash out which org structure should rule them all… Should you go flat? Or should you become a hierarchy? You'll hear how each structure impacts culture, innovation, and velocity! FARHAN THAWAR, VP OF ENGINEERING @ SHOPIFY Farhan Thawar is currently VP, Engineering at Shopify via the acquisition of Helpful.com where he was co-founder and CTO. Previously he was the CTO, Mobile at Pivotal and VP, Engineering at Pivotal Labs via the acquisition of Xtreme Labs. He is an avid writer and speaker and was named one of Toronto's 25 most powerful people. Prior to Xtreme, Farhan held senior technical positions at Achievers, Microsoft, Celestica, and Trilogy. Farhan completed his MBA in Financial Engineering at Rotman and Computer Science/EE at Waterloo. Farhan is also an advisor at yCombinator and holds a board seat at Optiva (formerly Redknee). JERRY KRIKHELI, SENIOR DIRECTOR OF ENGINEERING @ FACEBOOK Prior to Facebook, Jerry was VP of Engineering at Houzz where he oversaw all infrastructure, platform, and engineering across Consumer, Marketplace, and Industry Solutions initiatives. Jerry was also an engineering director at Google responsible for developing early versions of the display ad serving infrastructure and launching YouTube ads as well as video ads on mobile apps. He has a passion for building high-performing systems, products, and people. SHOW NOTES The rules of the debate (2:45) Opening Statement: Why hierarchical organizations? (3:39) Opening Statement: Why flat organizations? (6:25) Culture in flat organizations (9:09) Culture in hierarchical organizations (10:55) Culture rebuttals (14:19) Innovation in flat organizations (19:49) Innovation in hierarchical organizations (22:01) Innovation rebuttals (24:57) Velocity in hierarchical organizations (26:05) Velocity in flat organizations (28:42) Closing Statements on Flat vs. Hierarchical (30:16) BROUGHT TO YOU BY... Listen to our Bonus Episode w/ Guillermo Fisher, Director of Engineering, Infrastructure @ Handshake on internal mobility, mission-driven decisions, & self-service infrastructure! Listen HERE: https://spoti.fi/3zdNnXn Special thanks to our exclusive accessibility partner Mesmer! Mesmer's AI-bots automate mobile app accessibility testing to ensure your app is always accessible to everybody. To jump-start, your accessibility and inclusion initiative, visit mesmerhq.com/ELC Looking for other ways to get involved with ELC? Check out all of our upcoming events, peer groups, and other programs at sfelc.com! --- Send in a voice message: https://anchor.fm/engineeringleadership/message

Nadia Odunayo is the founder and CEO of The StoryGraph, the new website that helps you to track your reading and choose which book to read next. She previously worked at Pivotal Labs as a software engineer and originally learned to code at Makers Academy in London. In her spare time she loves to take dance class and, naturally, read!Follow The StoryGraph on Twitter @thestorygraph and Instagram @the.storygraph.Visit Nadia’s website: https://www.nadiaodunayo.com/Connect with Charnaie online in the following places:Blog: http://hereweeread.comPersonal Website: charnaiegordon.comPodcast Email Address: hereweereadpodcast@gmail.comFind Charnaie on the following social media platforms under the username @hereweeread: Instagram, Facebook, Twitter, PinterestFeel free to share this podcast on your social media platforms to help spread the word to others.  Thanks for listening!

Shopify VP of Engineering Farhan Thawar shares his thoughts on a variety of topics related to managing software teams. He discusses fully remote software teams, pair programming, how to innovate within a company of Shopify's scale, and the benefits of engaging with a team like VMware Tanzu Labs (Thawar was at Pivotal Labs until 2015). He's joined by guest hosts Saad Ahmed and Joe Moore of VMware Tanzu Labs, who also offer their perspectives on what they're seeing in the field.

Shopify VP of Engineering Farhan Thawar shares his thoughts on a variety of topics related to managing software teams. He discusses fully remote software teams, pair programming, how to innovate within a company of Shopify's scale, and the benefits of engaging with a team like VMware Tanzu Labs (Thawar was at Pivotal Labs until 2015). He's joined by guest hosts Saad Ahmed and Joe Moore of VMware Tanzu Labs, who also offer their perspectives on what they're seeing in the field.

Shopify VP of Engineering Farhan Thawar shares his thoughts on a variety of topics related to managing software teams. He discusses fully remote software teams, pair programming, how to innovate within a company of Shopify's scale, and the benefits of engaging with a team like VMware Tanzu Labs (Thawar was at Pivotal Labs until 2015). He's joined by guest hosts Saad Ahmed and Joe Moore of VMware Tanzu Labs, who also offer their perspectives on what they're seeing in the field.

Beyond the Ocean podcast is back after a short, snowboarding-rich hiatus with Episode 7, featuring Ross Hale. Ross is a technology leader, coder, and lifelong surfer with creative and thoughtful ideas on how digital can help shape the future of surf parks.  About Ross: A veteran technologist with more than 15 years of experience, including multiple CTO positions, Ross has worked in both high growth venture-backed startups and in partnerships with major enterprise companies. Before founding Artium, he helped take Pivotal from startup to IPO and ran multiple Pivotal Labs regions, including its flagship office in San Francisco.  He is currently based out of Santa Monica, CA where he lives and surfs with his wife and two children. Website and LinkedIn page 

Product Management | Psychological Safety | High Performing Teams | Product Executive | Women and Earnings | In this interview, we discuss with Soumeya Benghanem the role of a product manager, learnings from Soumeya’s career, and how to create psychological safety to support high-performing teams. In the second part of the conversation, we also discuss the topic of women and earnings. Some of the questions we consider are: Are you happy with your earnings, are you unsure whether to ask for more money in your discussion with your manager, what do you feel about money & earnings in your life? This is a part of the discussion that sparked some important learnings, such as seeing money as a tool to live the life you want to live. Soumeya Benghanem is a Product Management executive with 20 years of experience building product teams and software. She is currently a Product Management Practice Leader at Pivotal Labs, a Division of VMware. She has been the Chief Product Officer and Head of Product at startups in Financial Services and Healthcare. Some of the organizations that she has worked with include The United States Space Force, Merrill Lynch, The Bank of NY Mellon, and Paypal.Takeaways:What is the range of pay in my role? “I use a range because I think it is more important than the average. Average implies there are many people above and many people below. If you get an offer in the average, you should counteroffer or negotiate for higher.”  “Do not let money concerns or inequity pass because it multiplies. In one role, you are underpaid. You will probably be underpaid in the next role. So make sure to take care proactively in every role you get.”"Some of the most challenging things I had to go through were thinking the situation was a zero-sum game. You are either a winner or a loser. When in reality, there is complexity. The zero-sum game is an unhealthy mindset to have. Yet very typical when you grow up competitive or do not think about the complexity of a situation. Most of the challenges I had in my career were around situations that I treated like either I would win or lose. "Follow Soumeya's updates on LinkedIn: https://www.linkedin.com/in/soumeyab/ Follow Soumeya's updates on Clubhouse: @soumeya Episode Timeline:02:00 What is product management, and how did the field develop in the last years?03:48 How did you decide to move into product management? What are some of the peculiarities of the role? 06:30 How would you define the product space to somebody completely new to it?09:55 Managing high-performing teams: How do you create high-performing teams? 12:40 How do you create psychological safety?17:41 Any advice for teams in the remote-work era? How to implement psychological safety in this new setup? 21:20 DRIP Framework for 1-on-1 meetings. 23:10 What was the biggest surprise of your career?25:46 Learnings from Soumeya’s current executive role at VMware.28:05 Upbringing and learnings from Soumeya’s life.  33:00 Women and Earnings.38:00 Bias towards women if they ask for money. Being greedy versus being confident. 47: 00 Challenging situations and how you navigated the scenario.50:00 What advice do you have for those who want to follow in your path?55:00 Anything you wish you knew at the beginning of your career? 

Listen now | Farhan Thawar is VP Engineering for Channels and Mobile at Shopify. Previously he was the CTO and Co-Founder at Helpful, CTO Mobile at Pivotal and VP, Engineering at Pivotal Labs. He was named one of Toronto's 25 most powerful people. Apple Podcasts | Get on the email list at www.softwareatscale.dev

Nate's work is inspired and influenced by art brut, abstract expressionism, graphic design, comic art, geometric abstraction, and the onslaught of imagery of that pours down on him from his perch in Chicago Illinois. Primarily known for his dense and illustrative cityscapes on panels, Nate also has been developing multiple painting styles of his own for years. Nate had a career in teaching people with disabilities until the pull of art became too great and he became a full time artist and illustrator three years ago. Nate has had solo shows at Vertical Gallery and Adventureland Gallery in Chicago and has done work with Basecamp, Soho House, Pivotal Labs and other really impressive people. He has also participated in group shows in New York, Los Angeles, Madrid, and elsewhere. Contact Nate https://www.instagram.com/ottonate/ Contact Me Connect with me: https://www.instagram.com/nevercallmeagainpodcast/ --- Send in a voice message: https://anchor.fm/robert-reed4/message

Cory Bowman is the first ever career Product Manager in the Air Force. Cory's journey started as an E-4 Urdu linguist, a career trajectory that allowed his engagement with Pivotal Labs and the 480th ISR Wing on team Narwhal. His experience returning to Langley AFB, where he missed the support needed to continue building Narwhal and his software team, to then joining Kessel Run and leading two software teams to adoption in KR's Air C2 KRADOS portfolio, is inspiring. This episode is for anyone in government, junior to senior, and will help listeners understand the culture of great software organizations, the heart that so many like Cory bring to the equation, and how real leadership transcends rank.

Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu's Rohit Kelapure who's been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through. This episode is pretty visual, though audio only works well too. We recorded it in Twitch, which you should subscribe to to start seeing other videos like this. Check out the original recording if you want to see Rohit's most excellent whiteboarded diagrams. https://www.twitch.tv/videos/694237498?t=00h1m00s

Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu’s Rohit Kelapure who’s been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through. This episode is pretty visual, though audio only works well too. We recorded it in Twitch, which you should subscribe to to start seeing other videos like this. Check out the original recording if you want to see Rohit’s most excellent whiteboarded diagrams. https://www.twitch.tv/videos/694237498?t=00h1m00s

Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu’s Rohit Kelapure who’s been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through. This episode is pretty visual, though audio only works well too. We recorded it in Twitch, which you should subscribe to to start seeing other videos like this. Check out the original recording if you want to see Rohit’s most excellent whiteboarded diagrams. https://www.twitch.tv/videos/694237498?t=00h1m00s

Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu's Rohit Kelapure who's been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through. This episode is pretty visual, though audio only works well too. We recorded it in Twitch, which you should subscribe to to start seeing other videos like this. Check out the original recording if you want to see Rohit's most excellent whiteboarded diagrams. https://www.twitch.tv/videos/694237498?t=00h1m00s

Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu's Rohit Kelapure who's been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through. This episode is pretty visual, though audio only works well too. We recorded it in Twitch, which you should subscribe to to start seeing other videos like this. Check out the original recording if you want to see Rohit's most excellent whiteboarded diagrams. https://www.twitch.tv/videos/694237498?t=00h1m00s

Richard Seroter leads technical marketing for VMware's Modern Applications Business Unit, Marketing at Pivotal, a 12-time Microsoft MVP for cloud, an instructor for developer-centric training company Pluralsight, the lead InfoQ.com editor for cloud computing, and author of multiple books on application integration strategies. As VP of Product Marketing at Pivotal, Richard heads up product, partner, customer, and technical marketing and helps customers see how to transform the way they build software. Richard maintains a regularly updated blog (seroter.wordpress.com) on topics of architecture and solution design and can be found on Twitter as @rseroter.

Farhan Thawar (@fnthawar) , VP of Engineering @ Shopify shares the hiring framework he’s built where 15-minute interviews result in both faster placements AND better fits. You’ll hear how to find talent in non-traditional ways, what happens when you leverage creativity, and how speed in hiring is a massive competitive advantage. “The problem with interviews in general are they're very biased to either things you've done before or they're biased to some other signal...like school you went to company, you worked for, GPA in some cases, right? Google used to use that... And it excludes a wide swath of people. That's my number one problem with interviews. Not that good candidates can pass an interview. It's that non-traditional candidates will likely fail your interview” Farhan is currently VP, Engineering at Shopify via the acquisition of Helpful.com where he was co-founder and CTO. Previously he was the CTO, Mobile at Pivotal and VP, Engineering at Pivotal Labs via the acquisition of Xtreme Labs. He is an avid writer and speaker and was named one of Toronto's 25 most powerful people. Prior to Xtreme, Farhan held senior technical positions at Achievers, Microsoft, Celestica, and Trilogy. Farhan completed his MBA in Financial Engineering at Rotman and Computer Science/EE at Waterloo. Farhan is also an advisor at yCombinator and holds a board seat at Optiva (formerly Redknee). SHOWNOTES Farhan’s origin story being recruited to start Helpful.com by Daniel Debow. (1:28) Impact and examples of going above and beyond in recruiting using unusual ways to reach potential candidates. (8:30) Using speed as a competitive advantage, especially when you’re small. (12:44) How to prevent speed from backfiring by thinking about decisions as “one-way” or “two-way doors.” (14:36) Critical structures to best assess candidate fit. (15:17) How Farhan starts from first principles to leverage creativity in recruiting. (20:38) Farhan’s MOST IMPORTANT indicator of performance, and how to uncover it in an interview. (25:49) Results of speed in the hiring process - 15 min interview (31:36) How the 15 min interview works. (33:47) What’s different in hiring an engineering leader. (35:41) How to increase your pool of potential candidates through “backward promotions,” interim titles, and recruiting people who haven’t “done it” before. (42:41) Examples of what happens when bias is removed in the interview process and people are given a shot. (48:03) Farhan’s most terrible leadership mistake & how to turn underperformers into extremely high performers in 30 days with Performance Improvement Plans (PIP’s). (49:36) Farhan’s most impactful leadership action: the power of personalization. (53:56) Join our community of software engineering leaders @ sfelc.com --- Send in a voice message: https://anchor.fm/engineeringleadership/message

It wasn't that long ago when Dell Digital's software product teams were typically bogged down in very silo'ed development cycles. One of the more troubling effects was how long it took to complete projects, often measured in months. In some cases, software releases could even take a year before deployment. And all to often these very long development cycles did not result in something that met Dell Digital's business goals — as in, creating something the customer wanted or needed. Besides the requisite culture for agile development, missing in Dell's digital-transformation strategy was a single underlying platform that Pivotal Labs eventually provided, said Greg Bowen, chief technology officer and senior vice president, Dell Digital (the IT organization that supports Dell). With the help of Pivotal Labs' platform and the adoption of a more agile DevOps culture, Dell Digital's teams are now "extremely hyper-focused on the outcome with the business partner right there in the development process,” Bowen said. “And so, that's allowed us to take the scale of an enterprise company, and become almost startup in nature.” In this latest episode of The New Stack Makers podcast recorded at the SpringOne Platform conference, Bowen discussed how Dell Digital's transformation was dependent as much on culture and processes as it was on selecting the right technologies and tools including, as mentioned above, Pivotal Labs' platform.

We've written some about accessibility in terms of building apps and websites — although there's always more to learn and do — but what about accessibility and inclusion in the developer world? How can you best serve your full customer base when your customers are developers? How is designing for inclusion an essential part of the developer experience? These are the questions Pivotal Labs' Senior Designer Raquel Breternitz is trying to answer in this episode of The New Stack Makers. Why is inclusion so important to Breternitz? "We don't have to just make sure that someone can get there, and can understand it when they do, but we also have to find the ways in which folks are excluded and break those barriers down as well," she told The New Stack in a follow-up conversation.

Michael Coté: @cote | cote.io | Pivotal | Software Defined Talk Show Notes: 00:54 - Pivotal 04:39 - Being a Professional Muller aka Analyst 11:08 - Iterative Development 32:54 - Getting a Job as a Professional Muller aka Analyst Resources: Pivotal Cloud Foundry GemFire Greenplum Pivotal Labs Wardley Maps Software Defined Talk Episode #79: From a vegan, clothing optional co-op to working with banks and oil companies - Coté's professional life, part 1 Software Defined Talk Episode #85: Being an analyst without being an asshole - Coté's professional life, part 2 RedMonk Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #66. I am a developer, Charles Lowell at The Frontside and also host-in-training for 65 episodes. This is my 66th and I'm flying alone this week but we do have on the show with us a very special guest. Actually, the person who taught me how to podcast, I think it was about 10 years ago and he was like, "Charles, we should do this podcasting thing." I started my very first podcast with him and I still haven't figured it out. But his name is Michael Coté and he's a fantastic guy and welcome to the show, Coté. MICHAEL: Thanks for having me, Charles. It's great to be here. CHARLES: Now, what are you up to these days? You're over at Pivotal. MICHAEL: That's right. I work at Pivotal and probably people who are in the developing world know them for Spring. We have most of the Spring people. Then we also have this thing Pivotal Cloud Foundry. We're not supposed to call it a platform as a service but for matters of concision, it's a platform as a service that's the runtime that you run your stuff in. Then we also have a bunch of data products like GemFire and Greenplum and things like that. Then, 'openymously', if that's a word, we have Pivotal Labs. Now -- CHARLES: I think, it's eponymously. MICHAEL: Eponymously, yes. Now, you might remember Pivotal Labs as the people who use Chef Scripts to configure their desktops. Remember that? CHARLES: Yeah, I remember that. I was into that. MICHAEL: Yeah, in coincidental kind of way, the inspiration for the project Sputnik thing, which is coincidentally because now Dell Technologies owns Pivotal so all of that stuff has come for a full circle. I guess also since I'm intro-ing myself, I work on what we call the Advocate Team because we don't call them evangelists. No one likes to be called that I guess. I guess there's 12 of us now. We just hired this person, also in Austin actually McNorma who's big in the Go community and apparently can make images of gophers really well. I'm sure she does many other extraordinary things, not just the illustrator master. Everyone else basically like codes or uses the terminal but I do slides. CHARLES: Well, that's your weapon of choice, right? It's a more elegant weapon for civilized time or something like that. I'm going to look it up on Wikia. MICHAEL: Yeah, basically what we do on our team is we just talk about all the stuff Pivotal does and problems that we solve in the way people in an organizations like would think to care about our stuff. Most of what I do is I guess you call it the management consultant type of stuff. Since I have a background as an analyst and I used to work on corporate strategy and M&A at Dell so I have a vantage point in addition to having programmed a long time ago. If you're changing your organization over to be more agile or trying to devops, we would say cloud-native with a hyphen. How do you change your organization over what works and doesn't work? Most people in large organizations, they sort of pat you on your head. I'm sure you encounter this. That sounds really nice that we would be doing all of the good, correct ways of using computers but we're basically terrible and we could never make that happen here. Thanks for talking with us, we're going to go back and stew in our own juices of awfulness. You've got to pluck them out of that self-imposed cannibal pot there in the jungle and show them that they actually can improve and do things well. CHARLES: Would you say you feel like your job is being that person who shakes them away and can be like, "Good God! Get a grip on yourself!" MICHAEL: Sure. That's a very popular second or third slide in a presentation -- the FUD slide, the Fear of Uncertainty and Doubt slide where you're basically like, "Uber!" and then everyone just like soils their pants because they're afraid that are like Airbnb and Uber and [inaudible] and Google is going to come in and, as they say, disrupt their state industry. I try not to use the slides anymore because they're obnoxious. Also, most people in large organizations nowadays, they know all of that and they've already moved to putting on a new pair of pants stage of their strategizing. CHARLES: You've got the kind of the corporate wakeup call aspect of it but then it's also seems like a huge component of your job which is when you were at RedMonk, when you were at 451 and even to a lesser extent, it was Dell who was paid well to just kind of mull it over, like just kind of sit there and asynchronously process the tech industry, kind of like organizational yeast and let it ferment, kind of trying to see where the connections lie and then once you've made that presented, do you think that's fair? That's what sprung to mind when I heard you say like, "Yeah, we just kind of sit around and think about what is Pivotal and what does it do and what's it going," but like how do you get that job of like, "I'm just kind of a professional muller." MICHAEL: That's right. First of all, I think professional muller is accurate, as long as, I guess mulling is also for -- what's that thing you drink at Christmas that you put the little -- CHARLES: Mulled wine. Like low wine. MICHAEL: I can feel like that sometimes late at night. But having a job as an analyst, I was an industry analyst at two places for a total of about eight years or so. Then as you're saying doing strategy at a company, now what I do here, essentially a lot of what you do is very difficult. I know it sounds to people. You just read a lot of the Internet. You just consume a lot of the commentary and the ideas of things that are going out there and you try to understand it and then synthesize to use that cheesy word. Synthesize it into a new form that explains what it is and then finally, the consultant part comes in where you go and meet with people or you proactively think about what people might be asking and they say something like, "What does this mean for me? And how would I apply it to solve my problems?" I guess as an example of that -- I apologize for being a little commercial but these are just the ideas I have in my head -- Ford is a customer of ours and they also have invested in us which is kind of novel. We have GE and Ford invested in Pivotal and Microsoft and Dell Technologies as an interesting mix but anyways, they have this application called the Ford Pass Application. I drive a Ford Focus -- CHARLES: Like Subaru? But you do drive a Ford. MICHAEL: Yeah, because I don't care about cars. It's a bunch of nonsense. I see this app and basically the app, if you have a more advanced one, it might tell you your mileage and even like remotely start your car. But it doesn't really do that much. You have the app and it will tell you information about your car and where to park and it even has this thing where it links to another site to book a dealership thing, which is annoying. CHARLES: Why would you want to book a dealership? To buy another car? MICHAEL: Well because the Ford Focus I have is notorious for having transmission problems so you're like, "I got to go and take it into the dealer to get all this recall stuff taken care of," so wouldn't it be nice... I don't know if you've ever worked with a car dealer but it's not desirable. CHARLES: Yeah, it would be nice if they didn't charge $6000 for everything. MICHAEL: Right. It's a classic system of having a closed market, therefore that jacks up prices and lowers customer service usually. What's the fancy word if there is a negative correlation, if you were to chart it out? Like price is negatively correlated to your satisfaction with it. Kind of like the airline industry, not to bring up a contemporary topic. You pay a lot of money to fly and you're like, "This is one of the worst experiences I've had in my life," whereas you go to the dentist and get a root canal and you're like $20 co-pay. Loving it. [Laughter] MICHAEL: Anyhow, this Ford Pass application doesn't really do very much so what does that mean for what I was explaining. If you go look up and read about it, starting back in the late-90s, your extreme programming and then your Agile Software Development and your devops nowadays, one of the major principles is what you should do is ship often. Maybe you should even ship every week or every day. Don't worry about this gigantic stack of requirements that you have and whatever you should be shipping all the time and then we've trained ourselves to no longer say failing fast. That was a fun cheeky thing back in the late-2000s. CHARLES: Did we trained ourselves not to say that anymore? MICHAEL: I don't hear it very often. CHARLES: Man, I got to go scrub my brain. MICHAEL: Yeah, well this is why you consult with me every 10 years as I tell you the new things. CHARLES: Okay, here we go. We're going to have you on the podcast again. MICHAEL: That's right. You have this idea of like, "We should be releasing weekly," but then if you go to Ford, you're like, "What does that mean?" To shave the shaggy dog here, essentially the idea that they're shipping this mobile application that doesn't really do very much is an embodiment of the idea that they should be shipping more frequently. This may be a stupid example. It's not that it's not going to do very much like permanently but as I have witnessed, very frequently they add new features so Ford is in this cadence but there's this app that instead of working on an application for two years and having everything in it, they're actually releasing it on, I don't know if it's weekly but they're releasing it on a very frequent basis, which allows them to add features. What that gets you is all the advantages of a fast iteration cycle small batch thing where they can study this actually a good feature. They can do all your Lean Startup nonsense. That's a very like weird, perhaps example of how you explain to someone like a large car manufacturer like Ford, this is what devops means for you. Therefore, why you should spend a lot of money on Pivotal? Now that's the part that lets me pay my mortgage every month, the last bit there. CHARLES: Right so Pivotal builds apps. MICHAEL: Well, the Labs people build apps for you. CHARLES: I'm kidding Coté. MICHAEL: Yeah, they actually do. The Labs people are like a boutique of another boutique like ThoughtWorks is kind of a boutique but they're kind of a boutique-y version of ThoughtWorks. That probably is terrible as someone who markets for Pivotal to do that. Do you ever notice how political candidates never really name their opposition? Like you never really want to name your competition but anyways... CHARLES: Pivotal marketing are going to come crashing through your window. Everybody, if we hear them in the next five seconds -- well, I guess you can't call 911 because this is not live. MICHAEL: Yeah, that's true. The Labs people build stuff for you and then the part that I work, in the Pivotal Cloud Foundry people, they have the actual runtime environment, the cloud platform that you would run all that stuff. Plus all the Spring nonsense for your microservices and your Spring Boot. I understand people like that. CHARLES: So good for Ford, for actually being able to experience, either in the development and the joys and the benefits that come with it. But this is actually something that I actually want to talk about independently was as I kind of advance in my career, I find myself pushing back a little bit against that incredibly tight, iterative schedule. Shipping things is fantastic and it's great but I find so much of my job these days is just trying to think out and chart a course for where those iterations will carry you and there is a huge amount of upfront design and upfront thought that it is speculatory but it's very necessary. You need to speculate about what needs to happen. Then you kind of measure against what's actually happening but I feel that kind of upfront design, upfront thought, we had this moment we're like, "We don't need that anymore. Let's throw it all in the garbage." In favor of doing things in these incredibly tight loops and finding where's the clutch point, that kind of long range thinking and long range planning comes and meets with the iterative development. I have no idea. What's the best way for those to match up those long cycles and those short cycles? Where is the clutch play? MICHAEL: I'll give you two and a half, so to speak trains of thoughts on that. One of them is I think -- CHARLES: Two and half trains of thought, I like that. Can we get straight to the half train of thought? MICHAEL: Yeah, I'm going to start with the half, which is just taking all of your questions and putting periods at the end of them before I round up to answering the question. I think a lot of the lore and the learnings you get from the Agile world is basically from consultants and teams of consultants. Necessarily, they are not domain experts in what they're doing so their notion is that we're going to learn about what it is we're doing and we don't actually know we can't predict ahead of time because we're not domain experts so they almost have this attitude of like, "We'll just figure it out on the job." Let's say The Frontside gets hired to go work on a system that allows the Forest Service to figure out which trees to go chop down or not -- CHARLES: If you're the Forest Service, we are available to do that. MICHAEL: I'm guessing you don't have a lot of arborists who have 10 or 20 years of experience working there. CHARLES: No, we don't. MICHAEL: And so you have no idea about that domain so in doing an iterative thing, you won't be able to sit down and predict like everyone knows that when you send the lumberjacks out, they're going to need these five things so we're going to have to put that that feature on there. They need to be able to call in flapjacks when they run out. That's just what's going to happen so you don't know all of these things they need to do so you just can't sit down and cogitate about it ahead of time. Also this comes in from the Lean Startup where there's a small percentage of software that's actually done globally and the notion of a Lean Startup is that when you're doing a startup, you're never going to be determined what your exit is, how you cash out, whether that's building a successful long term company while you get sold to someone or whether you IPO, you're not going to able to predict what that business model is so you just need to start churning and not think a lot ahead of time. Now, the problem becomes, I think that if you are a domain expert, as you can do the inverse of all the jokes I was just making there, you actually can sit down and start to predict things. You're like, "We know we're going to need a flapjack service," so we can predict that out and start to design around that and you can do some upfront thinking. Now similarly, developers often overlook the huge amount of governance and planning that they do for their own tools, which I know you're more cognizant of being older or more experienced, as they like to say. But basically, there's a bunch of, as we used to call it when I did real work and develop stuff, iteration zero work like we're going to need to build a build system, we're going to need a version control. You actually do know all these things you're going to need so there are all the things you can plan out and that's analogous to whatever domain you're working in. Sometimes, at least for your toolchain, it is worth sitting down and planning out what you want. Now, to hold back the people who are going to crash in my window, one of the things you should consider is using Pivotal Cloud Foundry. That's probably something you should cogitate on ahead of time. CHARLES: I think they're going to crash through your window and give you a Martini, if the marketing ninjas are going to do that and if you mention them in a positive light. MICHAEL: You know, it's 10:52 Central but if we were in London, it would probably be an appropriate time so we'll just think about that. Now, on the other hand, you don't want to go too overboard on this pre-planning. I'll give you an example from a large health insurance company that I was talking with recently. They had this mobile app -- it's always a mobile app -- that had been languishing for 15 months and it really wasn't doing anything very interesting. It was just not working well and they could never release it. This is a classic example of like, "We took a long time to release a mobile app and then we never released it again and then it blows." It's not achieving all of the business goals that we wanted. Mostly, what a health insurance company -- I've talked with a lot of the health insurance companies -- want with their mobile app is at least two things and probably many more but these would be the top of the list. One, they want their customers, their users to look up what their health insurance is, figure out doctors they can go to, the basic functioning that you expect from your health insurance company. And two, they want to encourage their customers to do healthy behaviors because if you think about it as a health insurance company, health insurance in my mind is basically like this weird gamble of like, "I'm gambling on the fact that you are going to be healthy," because then I pay out less to you and you just give me money so the healthier that your users can be, the more profit you're going to make. That's why they're always trying to encourage you to be healthy and stuff like that. The mobile app was not achieving, at least these two, if not other business goals they have. They basically were rebooting the effort. The way they started off is they had -- I don't know how many inches thick it was -- a big, old stack of requirements and the first few iterations, the product team was working on it and talking with the business analyst about this and going over it and what they sort of, as we were calling Pivotal Labs the product owner but the person who runs the team, realize is like -- to cut a long story short -- "This is kind of a waste of time. We shouldn't just prioritize these 300 features and put them in some back road and execute on them because these are the same features that we based the more abundant application on, we should probably just start releasing up the application," kind of like the FordPass app. That said, they did have a bunch of domain experience so they had a notion of basically what this app was going to do and they could start planning it out but they figured out a good balance of not paying attention to, as Martin Fowler used to call it the almighty thud, of all the requirements. What they ended up doing is they basically -- CHARLES: What's the almighty thud? MICHAEL: You know, he's got some bleaky or whatever. It's basically like we started a project and I think it's from 2004 and someone FedExed me about 600 pages of an MRD or whatever and I put it down on my table and it made a loud noise so he calls that the 'almighty thud', when you get this gigantic upfront requirement thing. What happened in this health insurance thing is they stopped listening and talking with those people and they kind of like chaff them out, not like when your rub your legs together but they kind of distracted them to that fact but eventually, they just got them out of the cycle and they started working on the app. Then lo and behold, they shipped it and things are working out better now. CHARLES: Hearing what you're saying and kind of thinking it over, I think if you're going to have an almighty thud, what you really want is you want all that upfront research and all that upfront requirements gathering or whatever, not necessarily to take the form of a set of features or some backlog of 300 things that the app 'needs' to do or 'should' do but just a catalogue of the problems, like a roadmap of the problems. MICHAEL: Exactly. CHARLES: You know, that actually is very valuable. If it's like, "These are things that are true about our users and these are the obstacles that they face. If we do choose that we want to go from Point A to Point B, where we are at Point A, then we actually have a map of what are the things that are sitting in front of that and what are the risks involved." It's like if you got -- you played, you're from my generation, you play the Oregon Trail, right? MICHAEL: Yeah. "You have dysentery." CHARLES: Right. I don't know where I'm going with this analogy but my point is developing that app is like going from Kansas City to Portland. But the thing about software is you don't necessarily have your corn meal. You don't need to say like, "We're going to need six pounds of cornmeal and we're going to need these wagons and we're going to need these mules," because this is software and you can just code a mule if you need it. But you might not need a mule, if the rivers are not in flood... I don't know. Like I said, I don't know where I'm going with this analogy. But do you see what I'm saying? The point I'm trying to make is that having the map of the Rockies and where the passes are is going to help you. MICHAEL: Yeah, this is probably where I'm supposed to expertly rattle off what Wardley maps are and how they help, which is fine. I think that's a great tool. There's this guy Simon Wardley and he's actually a great contemporary philosophizer on IT-led strategy. I think he works for CSC who no longer owns mercenaries but they used to -- Computer Science Corporations. I think they own a little bit of HP Services Division but he works for some think tank associated with CSC and he has got a couple of OSCON talks on it, where it's called a Wardley map and it's a way that you start figuring out what you're saying, which is to say your company's strategy. Using your front metaphor of the era of tall hats, if you remember that other movie, if you're on the Oregon Trail, broadly your strategy is -- and people get all up in your face about the difference between a plan and a strategy and we'll just put mute on them and edit them out of the audio because they're very annoying -- CHARLES: We'll call it an approach. MICHAEL: That's right. Your plan or your strategy -- and pardon me if I use these phrase free and loosely and everything -- is you would like to get to Oregon and you would like to live there and maybe grow apples or start a mustache wax company or some donuts, whatever it is you do out there once you get to Oregon and their strategy is -- what are the assets that I have. I have a family, I have some money and I also know some people who are going there so I'm going to buy a stagecoach and a mule, then I'm going to kind of wangle it out and we're going to go over there. Also, part of our strategy is we're going to go through the northern pass because we're used to winter versus the southern pass, which isn't the Oregon Trail because reasons. Maybe Texas isn't part of The Union yet so I don't want to deal with the transition between whatever that weird Texas thing down there -- CHARLES: The desert, there's the southwest and the desert. MICHAEL: I don't have the capabilities to survive in a desert so I need to go to the north and hopefully I won't be like that movie and have a grizzly bear rip up my backside and everything. You sort of put together this plan. Now going back to what you would do in IT world is to your point, someone does need to define what we would call the business value or the strategy, like what you want to do. Looking at the Ford thing, what Ford wants to do is they do cogitating thing ahead of time and they're like, "We manufacture cars," and you've got electric cars and Uber. That's where the scarce light comes in. In the future, who knows that people will still buy cars? It might be like that I-Robot movie where all the cars are automated and you just go into one. As a company, whose responsibility is to be as immortal as possible, we need to start making plans about how we can survive if individuals no longer buy cars. Let's do that. This is a huge upfront notion that you would have and then that does trickle down into things like my Ford thing -- I'm kind of speaking on their behalf -- if we have a direct connection with people, maybe eventually we introduce an Uber-like service. You can just check-out a Ford car. Then maybe this and maybe that. It's the strategy of how do we set ourselves up to do that. Now, I think the Agile people, what they would go for is it's really good to have that upfront strategy and you'll notice that in a lot of lean manufacturing in Agile talk, no one ever talks about this stuff, much to my extreme annoyance. They don't ever talk about who defines the strategy and who defines that you're working on this project. That's sort of left as an exercise to the reader. The Agile people would say like, "The implementation details of that are best left to the development team in an Agile model." Just like the developers are always arrogantly are like, "Hey, product manager. How about you f-off about how I should implement this? I am the expert here and let me decide how I'm going to implement the feature that you want for me." It's kind of like that rushing dolling down of things. To the development team, you worked on some, what was it? Band frame wire thing, a long time ago? It was basically like, "We don't know it. Maybe this is not the case. Let's pretend like it was." We don't know exactly how you're going to implement this stuff but our goal is that there's bands and they need sides and ways of interacting with their users so let's just figure out what that looks like but they had that upfront idea of ways that they were doing things. CHARLES: Let's start walking. MICHAEL: To add on some more. There's another edge case that you're making me think of, which is a good way of thinking through almighty thuds versus how much planning you have and that's government work. Government work that's done by contractors and especially, military contracting work. What you notice in government work is they have, seemingly way too much paperwork and process. They literally will have project managers for project managers and the project managers have to update how the project is going and they reports. If they don't do the reports correctly, their contract is penalize and you might even get fired for doing it. If anyone stops and says while the software is working, they were like, "No, no, no. don't be naive. It doesn't matter if the software is working or not, if we don't fill up the project report, we're fired." Until someone like yourself or me, it's just like your head explodes and you're like, "But working software, not a concern." In that case, it actually is part of the feature set, part of the deliverable is this nauseating amount of project reporting and upfront requirements, which has this trickle-down effect of annoyance but that's what you're getting paid for so that's what you do and if you want to make yourself feel better about it. I don't know how it is in the rest of the world but in the US, basically we think the only person worse than maybe, Lucifer is the government. I don't know why this comes about. We enjoy the fruits of the government all the time but for some reason, we just think they're awful. Whenever we give money over the government, we want to make sure that they're spending it well and if they're not corrupt and they don't hire their entire family to help them run the government and make sure that they're making extra money globally in their businesses, I wouldn't know anything about that. But essentially, you want to make sure there's no corruption so transparency is almost more important than working software. The way you achieve that transparency is with all this crazy documentation. CHARLES: Here's the thing. I agree the transparency is fantastic but nothing is more transparent than working software. Nothing is more transparent than monitored software. Nothing is more transparent than software whose, by its very nature is radiating information about itself. You can fudge a report but you can't fudge a million happy users. MICHAEL: Don't get me wrong. I'm not saying that the way that things currently operate is the ideal state. I'm saying that that desire for transparency has to be addressed and for example, using your example, let's say you were delivering working software but you were also skimming 20% off the top into some Swiss bank account -- you're basically embezzling -- and then it turns out that you need 500 developers but you only actually had 30 developers. There was corruption. The means even though the ends, even though the outcome was awesome, the means was corrupt so that's the thing in a lot of government work that you want to protect against. I just bring that up as an edge case so a principle to draw from that, when it comes to almighty thudding is like sometimes, that is part of the deliverable. We would aspire in our fail, fast, Agile world to not have a bunch of gratuitous documentation as part of the deliverable because it seems like a waste. It would be like every morning when you battle with your kids to get their shoes on, you had to write a two-page report about how you're getting ready to go to school stuff with your kids was going. As a parent you would be like, "I don't need that." However, maybe if you were like an abusive parent and it was required for you to fill out a daily status report for you to retain the parentship of your kids, maybe it would be worth of your time to fill out your daily status report. That was an awfully depressing example there. CHARLES: Let's go back to the Oregon Trail. What I'm hearing is that -- and we will take it back to the Oregon Trail -- you also need to consider, as were saying, you have some sort of strategy which is we want to go sell apples and moustache wax. But what we're going to do is we're just going to start walking, even though we don't have a map. But obviously, if you send out scouting missions, like you know where you're going, you know the West Coast is out there somewhere, you start walking but the stakes determine how much of your resources you spend on scouting and map drawing -- MICHAEL: Yeah. My way of thinking about strategy and again, people strategy is this overloaded word. But my way of thinking about strategy is you establish a goal: I would like to go to the West Coast. Now, how you figure that out could be a strategy on its own, like how did you figure out you want to go to the West Coast. But somehow, you've got to get to a prime mover. Maybe those tall hat people keep beating me up so I want to go to the West Coast. I want to go the West Coast is the prime mover. There's nothing before that. Then you've got to deal in a series of constraints. What capabilities do I have, which is another way of saying, what do I not have? And what's my current situation and context? On the Oregon Trail thing, you might be like, "I have a family of seven. I can't just get a horse and go buy a pack of cigarettes and never show up again." I guess I could do that. That's probably popular but I, as an individual have to take this family of six other people. Do I have the capabilities to do that? How could I get the cash for it? Because I need to defend against all the madness out there, I'm going to need to find some people to meet with. You're thinking and scenario planning out all of this stuff and this gets to your point of like, "If you're going to Oregon, it probably is a good idea to plan things out." You don't want to just like the next day, just figure it out. [inaudible] tell a joke. It's like, "Why do they sell luggage at the airport? Is anyone is just like, 'Screw it. Pack a clothes and we'll sort it out at the airport.'" It's an odd thing to sell at the airport. But you do some planning and you figure out ahead of time. Now, to continue the sort of pedantry of this metaphor, the other characteristic of going to the Oregon Trail, unless you're the first 10 people to do it is hundreds, if not thousands of people have done it already so you kind of know what it's going to be like. It's the equivalent, in a piece of software, if they were like, "This application is written in COBOL. I want you to now write it in --" I don't know, what are the kids do nowadays? Something.io? I-want-you-to-write-this-in-a-hot-new-language.io and basically just duplicate it. You're going to still have to discover how to do things and solve problems but if the job is just one-to-one duplicate something, then you can do a lot more upfront planning for it. CHARLES: While you're doing it, making the Uber and Airbnb. MICHAEL: Yes. CHARLES: Then you're done. MICHAEL: I think that's the truth and I want to put it another way. We used to be down here in Texas, the way we run government here is just lovely but we used to have this notion of a zero-budget, which is basically like, "Assume I'm going to give you nothing and justify every penny that I'm going to give you." I think that's a good way to think about defaults. I mean, about requirements is default is you don't need any and only get as many requirements as you need. If you're building tanks or going to the Oregon Trail, you might need a lot of requirements upfront that are actually helpful. CHARLES: But like a suit, you're just going to just strike out naked walking with. MICHAEL: That's probably a bad idea unless you -- CHARLES: Yeah, that is a bad idea but that's the bar but what happened if I were to do that? I might make it for 20 miles. MICHAEL: And build up from there and then have all the requirements that you need. I'm sure when Lewis and Clark went they were like, "We're going to need a quill and some paper and maybe a canoe and probably some guns and then let's see what happens." But that was a whole different situation than going to establish Portland. CHARLES: That was an ultimate Agile move. That was a pretty Agile project. They needed boats, they built them but they didn't leave St Louis carrying boats. MICHAEL: Right and they also didn't have a family of six that they needed to support and all this kind of stuff, right? CHARLES: Uhm-mm. MICHAEL: There was a question you asked a long time ago, not to steal the emceeing for you -- CHARLES: I would say, we need to get onto our topic -- MICHAEL: Oh, yeah. Well, maybe this is a good saying, what you're asking is, "How do you get this job?" and I don't think we ever addressed that. CHARLES: Yeah, that's a great question. You said you had to consume a lot of stuff on the internet. MICHAEL: Right. That's definitely how I do the job but I think how I get the job, there's an extended two-part interview with me on my Software Defined Talk Podcast Episode, available at SoftwareDefinedTalk.com, where I talk about my history of becoming an analyst and things like that but the way it happened is I don't have any visible hobbies, as you know Charles except reading the stuff in the Techworld. I would read about what's happening in the Techworld and would blog about it back in 2004, 2005 and I was discovered as it were by the people at RedMonk. I remember for some reason, I wrote some lengthy opinion piece about a release of Lotus Notes. I don't know why but that was a good example. This is back when all of the programming job were going to be off shored and I thought it was imminent that I was going to lose my job. I was looking for a job and I shifted over to being an analyst. That like the way that you get into this kind of business is you establish, there's two ways -- CHARLES: You established expertise, right? MICHAEL: Yeah, which is like always an unhelpful answer because it's sort of like, I was joking about this in another podcast, it's like Seth Godin's advice about doing good marketing, which is the way you do good marketing is you have an excellent product. If you have an excellent product that everyone wants to buy, then your marketing will take care of itself. I think if I'm asking how to market, I'm trying to figure out how to market a bad product. That's really what people want. CHARLES: That's also just not true. That's just like flat ass not true. That's a lie. MICHAEL: I mean, people who want to know how to diet better are not already healthy and dieting successful. You can't start with the base assumption of things are going well. CHARLES: Well, it is true. I like to think that we have an excellent product. We sell an excellent product but the thing is you can just sit on your excellent product all day and you have to tell people about it. If you want them to come sample it and try, maybe eventually buy it like the advice that you just need an excellent product. I'm amazed at anyone who can actually can say that with a straight face. MICHAEL: Well, he only writes like 150-word blogpost. I think his point is that you should aspire to have a unique situation and then marketing is easier. Similar with everyone's favorite example like an Apple or like a Pivotal or a ThoughtWorks. We eat all three of us and yourself as well, once someone gives you the benefit of the doubt of listening, you can explain why what you have is not available anywhere else. CHARLES: What it boils down to is if you want to easily differentiate, allow people to differentiate your products from others, then be different. That's fair. I'll give -- MICHAEL: To summarize it, it begets more of the tactics of how one gets a job like I do. What's the name of the short guy in Game of Thrones? 'Tyrian'? 'Tyran'? 'Tyron'? CHARLES: Tyrion. MICHAEL: At one point, Tyrion is like, "I do two things. I know things and I drink," so that's how you get into this type of business as you establish yourself as an expert and you know things. Now, the third thing which I guess Tyrion was not always required to do is you have to be able to communicate in pretty much all forms. You need to be good at written communication, at verbal communication, at PowerPoint communication, whatever all the mediums are. Just knowing something is not very useful. You also have to tell people these things. CHARLES: I think Tyrion is pretty good at that. MICHAEL: Yeah, that's true but he doesn't ever write anything. There is no Twitter or things like that. CHARLES: I feel like [inaudible] been a pretty big deal in the blogosphere. MICHAEL: Sure, no doubt. The metaphor kind of breaks down because the lattice for the continuing counterarguments do not exist in the Game of Thrones universe but whatever. CHARLES: They've got the ravens. That's like Twitter and it's bird. MICHAEL: That is true. Knowing how to deploy a raven at the right time, with the right message is valuable. CHARLES: We buffer up our ravens so that they fly right at eleven o'clock. MICHAEL: That's true. I could be convinced otherwise. CHARLES: That's why they arrived both at 6PM in the Westeros -- MICHAEL: I guess true to the metaphor of a tweet, most of the communications in Game of Thrones is either, what are they called? Little Birds? That the [inaudible] always has and then the Big Birds. You've got to tweets and the blogs. CHARLES: This is like it's nothing but Twitter. MICHAEL: Exactly. You got to really communicate across mediums. Now that the other thing that's helpful and you don't necessarily have to do this but this is what I think gets you into the larger margin. The more profitable parts of the work that I do is you have to be able to consult with people and give them advice and consulting is largely about, first figuring out the right opportunity to tell them how they can improve, which usually is it's good if they ask you first. I don't know about you but I've found that if you just pro-offer advice, especially with your spouse, you're basically told that you're a jerk. CHARLES: Well, it'd be like a personal trainer and walking around me like, "Hey man. Your muscle tone is kind of flabby. You got to really work on that." MICHAEL: The line between a good consultant and being overly-explain-y is difficult to discern but it's something that you have to master. Now, the other way you consult with people is you study them and understand what their problems are and you're sympathetic to them and I guess you can be like a British nanny and just scold them. That's a certain subset of consulting. CHARLES: Don Rickles of consulting? MICHAEL: That's right. You just help them understand how all of this knowledge that you have applies to them and hope solve their problems like the FordPass thing. When I went from being a developer to an analyst, it was a big risk to take on. I think I probably took like a $30,000 pay cut and I went from a big company health insurance to being on a $10.99 and buying your own health insurance which a whole other conversation. We talked about that every now and then but like it's a risky affair. It's not a promotion or even a lateral move. It's just an entirely different career that you go into. Then you talk with people a lot. As an analyst, you're constantly having to sort out the biases that you have with vendors who want to pay you to save things versus end-users who want to hear the truth. You can't really see a lot of Gartner and Forrester work but the work that you can see publicly from people like RedMonk, it's pretty straightforward. CHARLES: Yeah it is and whatever they did, a piece that was for one of their clients, there was always a big fat disclaimer. MICHAEL: Now, the other thing I would say is what I've noticed -- not to be all navel-gazing -- about myself and other people who are successful at whatever it is I do is there's two things. One, they constantly are putting themselves out there. I remember and this is probably still the case. This is probably all in Medium. There's probably a Medium post every quarter that's like, "If you're a developer, how do you give more talks. What your first conference talk?" Basically, the chief advice in there, other than bring business cards and rehearse is essentially like you just got to get over that idea of self-promotion. You basically have to self-promote yourself incessantly and do all those things that you find nauseous and be like, "Me, me, me," which is true. You've got to get over that thing. If you're like me and you're an introvert who actually doesn't really like that many people, except a handful of people like yourself that I'm friends or family with, you have to put on the mask of an extrovert and go out there and do all this extrovert stuff or you'll fail. I shouldn't say you'll fail, you won't increase your overall comp and margin and everything. You'll basically bottom out at about $120,000 a year or so because that's about as much as anyone will pay for someone who just write stuff but doesn't actually engage in the world and consult. You've got to do that. Then the other consequence of that is you always have to be trying out new types of content and mediums like here we are in a podcast. Long ago, you and I, in 2005 or 2004 -- CHARLES: You got me to sign up for Twitter. MICHAEL: Yeah, like we started off a podcast because I remember hearing the IT conversation stuff and John [inaudible], who is a big inspiration for me, a role model, I remember he was just trying out podcast and I was like, "All right. I'll try that out. That looks like fun," and then here we are. CHARLES: I remember you tried out the podcast and you're like, "Let's go into your backyard or my backyard. Let's talk about software for 15 minutes." I remember that very clearly and that was 12 years ago. Then I remember also like with Twitter, you're like, "Now, you should sign up for this Twitter thing," and I remember I did and that's when it was still coming through SMS on your phone and like "I'm walking around Teatown Lake. I'm going to get tea." And I was like, "Oh, my God. This is so fucking stupid." But little did I know, you were actually signed me up to a service that changed my life. MICHAEL: Yeah, it was the stage direction era of Web 2.0 where you're just supposed to give people your status updates, instead of your searing insights. But yeah, you've tried it all these different mediums because again it goes back to your job is to communicate. You need to tell people things that you know. CHARLES: Coté, what is your strategy on virtual reality? MICHAEL: My strategy in virtual reality. Well, you've caught me, Charles because I'm not into that. You remember when Time Magazine had that Chinese lady who was like a... Not Frontside. What was the name of the big virtual reality thing that was big...? CHARLES: Second Life. MICHAEL: Second Life, who is a Second Life millionaire. CHARLES: Yeah, she had armies of people. She was mining some resource in Second Life and then reselling it and she made a lot of money. MICHAEL: I don't really like visual mediums so as Marshall McLuhan would say 'hot mediums'. I guess I like the cool mediums. That's not my thing. That's where my principle fails. Maybe I'll do that one day. CHARLES: This is pretty hot. This medium is pretty like -- MICHAEL: I think maybe audio broadcast is hot. I'm just pretending like I know. This is another trick that you can deploy that my wife has picked on is most of the time, 78% of the time, I actually have no idea what I'm talking about. I just know words. I don't actually know Marshall McLuhan theory. I read that one book a long time ago and I remember that scene in Annie Hall where he gives a little diatribe to whatever the Woody Allen character is. That's the extent of my Marshall McLuhan knowledge. CHARLES: Was Marshall McLuhan actually in Annie Hall? MICHAEL: He was. CHARLES: Don't sell yourself short, Coté. MICHAEL: Sure. CHARLES: You know things and you drink so let's talk about that second aspect because I know that you like me whole tearing up as a role model. MICHAEL: I should say since we're both happily married, except for the third thing that he does which he -- CHARLES: Oh, right. MICHAEL: Another unmentionable word. He too freely hangs out with the ladies. CHARLES: Right, anyway aside from that, throughout doing all this stuff, you keep a very, very chill perspective on things. I feel like the tech world gets so wound up around itself and it gets so tight and so stressed about its own problems. There's constantly wars in JavaScript and before we were in the JavaScript world, we were warring in Ruby. I remember when Twitter went over to using Scala instead of Ruby. Oh, my goodness, it was terrible times. I feel like there's a lot of stress and yes, you want to take it seriously but I feel like you've always been able to maintain an even-keeled perspective about technology which actually allows you to commentate on it effectively and intelligently because you're able to unwind yourself from the squabbles of the day and see maybe a bigger picture or something like that. MICHAEL: That's nice of you to characterize me to use a -- is that a hanging, dangling participle there, when you're in [inaudible]? CHARLES: Yeah, I don't know. MICHAEL: I think that's also just a function of being old. CHARLES: So are you actually not stressed or is it just part of your persona of being an extrovert or something like that? MICHAEL: About the tech world? No, I'm not stressed about that. As you kind of outlined, especially I was not sent the demographics for the show, which is fine. I'll overlook that but I'm guessing that that was a joke. CHARLES: Who got some designers, developers -- MICHAEL: I'm guessing there's a lot of people who actually are on the frontlines of working on software. I think this happens also in the white collar set. But essentially, it's really easy to slip into over allegiance to something and I don't know what rhetorical fallacy this is but it's the bias of over allegiance to something, you get all wrapped up in defending a tool over something and the virtue of it, whether it's Emacs and vi. I'm sure reactive people, whatever that is, have all sorts of debates. The thing is when you're heads down on this stuff, you don't realize how petty all those discussions are. It's not so much that it's a waste of your time but it's just one battle in an overall war that you have. It's good to have opinions and figure things out but you should just relax about it because the more angry and emotional you get, you're going to make a lot of mistakes and decision and problems. I wish I had an example of this but this is one of those things that intuitively as you ages as developer, it's not like your literal age. It's just the amount of time you've been developing software. You could be a 25-year old who's been developing software for 10 years and you would probably get this notion but you just realize that stuff changes and you just learn the new things. It's kind of not a big deal like one day, you're going on and on about how vi is great and the next day you're using that Atom editor and then whatever and you just use the tool that's appropriate and it's annoying when you're younger and people are applying Hacker News with like, "You should use the tool that is appropriate," which is a stupid reply. That's just kind of how it is. Also the other thing, in the more white collar world, as an analyst, especially doing strategy for a company, you can't be biased by things because then you'll make poor decisions as an analyst. Also when you're doing strategy in M&A that result in bad business outcomes so you actually be very unbiased about things. CHARLES: I think it applies in everything. If you get too emotionally invested in one particular approach in software, literally in anything you do, it does result in bad outcomes. The problem is you may not actually realize the consequences of those bad outcomes far down the road from the poor decision that you made that caused you that outcome so you might not necessarily connect it back. MICHAEL: Yeah, and I keep bringing this up but I think another effect of being calmer in your nerd life is having something that you do outside of your programming life, which is either having a family or having hobbies or something like that but you know -- CHARLES: Or having a wild turkey. MICHAEL: Yeah but you've got to have something, a reason to stop thinking about your tech stuff or it'll consume you. I suspect when you see the older graybeards who go on and on about open source and they're very like... I don't know. What's the word? They're very over the top and fervent about tech stuff. It's probably because like me, that's their only hobby and they haven't figured out how to how to control it. It becomes part of their identity and it defines them and then they're down this twisty, turny path of annoyance to the rest of us. CHARLES: Again, don't sell yourself short, Coté. You've got plenty: you love the cooking and eating and the drinking so close this. Do you have a favorite drink that you've been mixing lately? MICHAEL: No. CHARLES: Or any kind of favorite food because every time I go over to your house, even if we're having pizza, there's always a nice hors d'oeuvre or something to drink, something to tweak that appetite for something special. I kind of wondering if there's anything that you're into. MICHAEL: I have some very basics. One, I don't know if I drink a lot or drink a little. I think the science on this is very confusing, kind of like drinking coffee. I try to drink less. I basically go back to the basics of I want cheap wine that's not terrible. That's what I'm always trying to discover. I think I've also started to rediscover just straight vodka. That's pretty good. I think that fits into the grand scheme. CHARLES: I just can't do it. I can't follow you there. I need some, what do they call them? Gin florals? I can drink gin -- MICHAEL: Oh yeah, that's good too. CHARLES: That's about as close as I can get to straight vodka. MICHAEL: And then food-wise, I just wrapped up finally figuring out how to cook fish and chicken without it tasting terrible. CHARLES: Oh! What's the secret? MICHAEL: No, I want to put a disclaimer out. There's a EULA on this. I'm not responsible for anything bad that happens but what you want to do is cook at about 10 degrees less than you're supposed to. A chicken is supposed to be 165 degrees but you take it out of the pot when it's like 150 or 155 on another part of the pan. Fish is supposed to be 145 degrees but you take it off when it's about 130 or 135. It cooks a little bit more but these guidelines to cook your meat to that thing, it ruins it. Also you can brine a chicken and things like that. Also, what you want to get is an instant meat thermometer. One of those that you can just poke in your meat so you're always checking the temperature. That's what I've been working on. CHARLES: I have a theory about that. I will laid out really quickly, maybe it's just because the juices. It's the juice that so yummy there so you want those to be locked in and boiling but not boiled away. I'm going to give that a try on my -- MICHAEL: And fish is particularly tricky. CHARLES: Because all it takes is five minutes. Sometimes, it's two minutes and 30 seconds too long and you ruin the fish. MICHAEL: Then the next theory I want to try out is that you can actually fry fish in pure butter but you've got to paper towel it off afterwards because too much butter ruins it. But I think if your paper tower it off like you do grease off of bacon, then I think that's how you achieve -- not as good as a restaurant because in a restaurant, they have those butane torches and the crisp it up on the outside or reverse sear or whatever -- CHARLES: Is that what they do? Do they just run their torch right over the fish? MICHAEL: That's all I can figure. They might also be professional cooks who know how to cook things. CHARLES: They might have done it a lot of times. They might have had someone like Gordon Ramsay yelling at them constantly. "I can't believe this fish is so terrible. Waah!" All right. I'm going to give the fish a try. I'm going to give the chicken a try and I'm going to give everything that you just spent the last hour talking about, also a try. MICHAEL: Well, thanks for having me on. It's always fun to have a show with you. I just posted yesterday our second revival of the Drunken Retired Podcast, which is over at Cote.show. It's just '.show'. URLs are crazy nowadays. I guess the only self-promotional thing I have is I'm over in Twitter @Cote. It'd be nice if everyone should just go follow me there because I'm always very sad that I don't have enough followers and they'll never verify me. I don't understand what the problem is. I'm clearly me. Then I mentioned earlier, the main podcast that I do is Software Defined Talk, which is at SoftwareDefinedTalk.com and you should come spend a lot of money on Pivotal stuff. I'm happy to tell you all about that. Just go check out Pivotal at Pivotal.io CHARLES: I guess that is about it. We will talk to everybody later. Thank you for staying tuned and listening to this supersized episode. Come check us out sometime!

Continuing our Circle of Code agenda, we talk with Ronan Dunlop of Pivotal Tracker. Tracker was developed over ten years ago as the in-house project management software used by Pivotal Labs and has since then become a product in its own right used by many teams. We discuss what Tracker's history, what it does, and most importantly the philosophy behind tracker. We also discuss some recent news about the Gartner IaaS Magic Quadrant (see free reprint and Coté's highlights), SQL Server support in the Google Cloud, and the wrap of SpringOne Platform, including just released videos of many of the talks. See https://blog.pivotal.io/pivotal-conversations/ for full show notes.

James Watters (@wattersjames) SVP, Products for Pivotal (@pivotal) joins us this week on The Hot Aisle to talk about SpringBoot, Pivotal Labs, Pair Programming “Starter Dough”, and what Pivotal Cloud Foundry is up to these days.  We learn a bit about how CloudFoundry came to where it is today and what Pivotal's charter is as […]