Welcome to episode 234 of the Nerd Journey Podcast [@NerdJourney]! We’re John White (@vJourneyman) and Nick Korte (@NetworkNerd_) – two technology professionals with backgrounds in IT Operations and Sales Engineering on a mission to help others accelerate career progression and increase job satisfaction by bringing listeners the advice we wish we’d been given earlier in our careers. In today’s episode we share part 2 of an interview with Josh Duffney, detailing his transition from technical writing into a role focused on developer relations and his application of relatable experience to get there, an idea for a new book he wanted to write that brought clarity on sunk costs, and some thoughts on pursuing technical leadership as an individual contributor moving forward.

Original Recording Date: 06-19-2023

Josh Duffney is a senior cloud advocate at Microsoft and a previous guest on the show. If you missed part 1 of our discussion with Josh this time, you can find it here here. The show notes from that episode include links to previous discussions with Josh as well.

Topics – A Role in Developer Advocacy, A New Book Idea and Thoughts on Sunk Costs, An Interest in Technical Leadership, Parting Thoughts

3:49 – A Role in Developer Advocacy

• Was the decision to change in Josh’s case the result of actively looking for other opportunities or from a specific opportunity that presented itself?
  • The initial pivot to join Microsoft was merely opportunistic. Josh had wanted to chance to work there for a very long time. It was opportunity based and a leap of faith.
  • As for technical writing, Josh realized he would not be happy doing it long term. Staying in the role longer would have led to more unhappiness. In this case Josh was looking for opportunities.
  • Josh accepted the offer for his current role the day before many of the large tech company hiring freezes went into play.
  • The job market is different now than it was earlier in Josh’s career. Things are tightening up.
  • “It was definitely a deliberate choice to pivot, and I was searching. But I didn’t exactly know what I was searching for….The dev rel was a good close fit, and so that was an opportunity in that sense.” – Josh Duffney, on moving out of technical writing and into his current role
  • Note that when we say dev rel or devrel, that means developer relations.
• How does Josh define what developer relations is in his role at Microsoft?
  • Josh sits between the customer and the product teams and can act as a bridge between them.
  • For example, someone Josh follows on Twitter was having some issues with a Go SDK, and since Josh knows the team of engineers working on that Go SDK, he was able to engage an engineer for some help and a discussion with the customer.
  • The job is to sit between community and product teams, make sure they are talking, and make sure feedback gets through.
  • Josh also sits a little more broadly above multiple products and often times will discuss how to use those together. Josh gave a talk at Microsoft Build 2023, taking multiple open source projects to which Microsoft contributes and put them together in an end-to-end story about securing container supply chain.
    • This presentation showcased a lot of important work product teams at Microsoft are doing as well as highlighted some important tools and why they are important.
    • With his time spent as a technical writer, Josh had not given a presentation in a while (maybe not since the PowerShell Summit in 2018). As an attendee of Microsoft Build in the past, it felt great to be able to present at the conference.
  • Speaking at conferences is something that is appealing about Josh’s current role, and it may be even more appealing to others who enjoy traveling and may be seeking this type of role.
    • With a young family, Josh isn’t looking to do a lot of traveling.
    • Nick points out that travel is not as glamorous as people think and excessive amounts can lead to what happened to Josh Fidel in Episode 78.
    • John says being regional in your focus and doing things like pre-recorded content could help, but it likely depends on the job.
  • Josh tells us part of the job responsibilities are writing code and contributing to open source with the current scope being to improve the developer experience for some of these (command line) tools.
    • “I’ve been a user of command line tools for a long time, so I know what a good experience is like. And so I can now learn what it takes to implement those good experiences in code.” – Josh Duffney
• What would the person who doesn’t come from a software development background do to get into a role like this one?
  • Josh mentioned in this Twitter thread he had to show some programming chops to get into his current role.
  • “You read and you build.” – Josh Duffney, on advice for someone without a software development background
  • In the last year or so, Josh has read around 10 books on the Go programming language. He also authored a Pluralsight course called Building Go Web Services and Applications in which he turned things he learned from reading the books into a project.
  • Josh tells us once you learn the language and the syntax of a specific programming language, the open source community is a great place to start contributing. There are no barriers other than having your work approved by open source project maintainers.
    • Josh has learned a ton by taking this approach combined with reading, focus, and time on task.
• How does one decide which open source project to contribute to?
  • Nick equates this to trying to decide which interesting book on your reading list you will read next.
  • Josh says we should find something (a specific project) we want to use and seek to contribute there.
  • If Josh had discovered he wanted to move in this direction earlier, Python might have been a great pivot because it’s the language in which Ansible is written (a place where Josh had a lot of experience). Terraform is another possibly missed opportunity for contribution if Josh had known he wanted to “walk the stack” into software development earlier.
    • Contributing to Ansible and Terraform might have led to Go. But the ship has sailed as Josh doesn’t spend as much time using Terraform these days.
    • “My advice is pick a project that you use.” – Josh Duffney, on contributing to open source
    • Nick suggests to pick through the lens of what contributing to a project will get you if you do (i.e. something contributing to the project will allow you to step into by contributing – sort of a doubling of the benefit).

11:39 – A New Book Idea and Thoughts on Sunk Costs

• John mentions we might not get to see a Become Terraform book from Josh now.
• Recently Josh spent about 7 hours on an outline for a Go book called Effortless Go and was working on a Manning book proposal for it.
  • Josh likes to pitch ideas like this to his wife who acts as a great sounding board. Upon pitching it to her, Josh realized only the last couple of chapters he had outlined were something unique he could contribute. Other more experienced authors had done a great job explaining the basics and the syntax of the Go language in their books.
  • Josh’s unique stance can be showing how to build out a project in Go, and as a result he chose to change the emphasis and scope of his outline.
  • “What can I build to have someone that just read a book on Go and learned the syntax and show them how to build something useful with it and give them skills to kind of kickstart and give them confidence that they can pick up project work? That’s the unique area where I can add some value.” – Josh Duffney
  • Though there was an initial sunk cost of 7 hours in that first book idea, it was better than hundreds of hours in the wrong direction.
  • “At least in its current form it’s not different enough for me to make hundreds of hours of investment.” – Josh Duffney, on developing a differentiated idea / value proposition
  • One of the things Josh had on his list to do in the near future was to record a YouTube video sharing what he learned from the 10 books he read on Go and a guide for others to take a shorter path to where he’s made it. Some chapters may be too detailed for the beginner or are lacking application. The idea is teaching someone to read topically across these many resources in the proper order that promotes faster skill acquisition.
  • “If you were to come and ask me, ‘I want to learn Go.’ I would say read these books in this order. That’s the value I can add for the fundamentals.” – Josh Duffney
  • As it relates to spending hundreds of hours on a project, Josh has to crystalize his understanding and has to learn in that process. That process would be to build some kind of project.
  • Josh has an idea for a URL shortener that will use a web service and a command line tool (close to his domains of expertise) and plans to create a GitHub project around these. Josh feels he will eventually refactor this and create a training experience for it once he has gone through building the project on his own.
  • When Josh told his wife (a great sounding board) he was thinking of writing another book it was enough for her to have a reaction. Perhaps it was some of the baggage left over from writing the nontechnical book (Reclaim).
  • But by choosing not to pick up the Go book, he decided to go pick up the manuscript of Reclaim and start editing. Maybe he needed that space to return to the other project, but at present he isn’t sure.
  • John would love to see some published advice from Josh about not writing a specific chapter but encouraging others to read a specific chapter of another book
  • Josh mentioned former guest Joe Houghes made a comment about the things Josh likes to share on Twitter that really stood out in that the struggles that Josh shares helps people.
    • "Hey, I put 7 hours into this. I was going to write it. I decided not to. Here’s what you should do instead.
    • John mentioned people want to learn from others going through struggles as opposed to someone who has already mastered something. It’s a great contextual frame to use when you’re trying to teach someone.
  • With Josh having already put in 7 hours on the outline mentioned here, many would advocate avoiding the sunk cost of initial time spent. But, that isn’t always the best choice. Sometimes we need to cut our losses or be honest with ourselves.
    • “Right now at my current level I can’t top what already exists….I’m choosing not to invest the hundreds of future hours into this because it’s not something that I uniquely can do, and then through that, came the idea of something that I can uniquely do.” – Josh Duffney, on deciding not to write the Go book he had originally outlined
    • There are not many books out there which help you get started applying the knowledge of Go and solving programming problems with it.
• The sunk cost fallacy came into play heavily when it came to Josh’s book Reclaim and putting it down for a while. Nick says the choosing to put it down enabled him to do something else that would provide unique value (i.e. the decisions around the Go book). This parallels Josh being able to provide unique value to himself in editing Reclaim now (almost a parallel metalesson).
• There’s something Josh learned from his first digital declutter that applies here.
  • “You have to remove things in order to miss them enough to want to bring them back. And some things you don’t ever want to bring back.” – Josh Duffney, on laying down a project to come back to it later
  • For example, Josh feels writing a Terraform book is what he would now consider an expired opportunity. It’s now passed by.
  • Josh tells us if we put something down (a project) and the desire to do it comes back up once we have done that, it’s a sign we should actually do it.
• Was the outline for the Go book a restructuring of content to match the way Josh wishes it was taught to him? John was curious about the outline building being classified as a sunk cost.
  • Josh says yes and that his only learning modality is teaching.
  • As he read the Go books Josh took notes, and in some ways he feels he was obsessive about those notes. He would encourage us all to be kind to ourselves in our note taking.
  • When looking back at the notes he took, Josh thought about how he would teach what he learned to someone else (the structure for presenting concepts in the right order, depth of explanation, assumptions of the reader’s knowledge of Go, etc.).
  • Josh is using sunk costs as something to deter us away from opportunity costs. Josh chose not to pursue the Go book because of the opportunity cost and not the sunk cost. There was some sunk cost but not so much that it kept him focused on completing the book.
  • Just because something has a sunk cost, it does not mean the act of it wasn’t valuable. Making the outline was very valuable in that it brought a lot of clarity.
    • “The manuscript outline has a sunk cost to it because it’s pulling me to commit to a manuscript. So that’s the sunk cost. But the activity of getting it there and its creation was actually super valuable and generated clarity. It’s not that it was completely worthless. It’s just that I can’t let that 7 hours that I invested dictate where I spend the next few hundred hours.” – Josh Duffney, thoughts on sunk cost of making an outline vs. writing a manuscript
    • Nick says it is likely not a sunk cost if you learn something.
  • Seth Godin shares a story of someone who has a bunch of signs made for a business, but they come out with misspelled words. Because the person invested in having so many signs made (the sunk cost), they decide to put them up even though it will damage the business down the road as a result.
  • John says the process Josh used to decide not to write the book (just making the outline) was an interesting cognitive exercise. Josh was bringing his expertise as an instructor to the material in trying to structure it for someone looking to learn.
    • John wonders how many patterns in the way the outline was structured by Josh are unique to Go and learning it compared to patterns which might apply to the way Josh would learn any language.

22:55 – An Interest in Technical Leadership

• Where did technical leadership as mentioned in the Twitter thread come into our story?
  • This came from a Twitter space interview done with Jeffrey Snover. Snover told a story about an injury he had early in his career, and the doctor he went to see encouraged him to switch disciplines. Snover knew there was no way he was going to leave the tech industry.
  • Snover used the phrase “being technical without a keyboard,” and it really stuck with Josh after that conversation, opening his eyes to the technical track beyond management.
  • Josh says once you get to be senior level it’s sort of assumed you go into a manager track (which he did not want to do, preferring to stay technical).
  • If you’re at a large enough organization there is something called Staff Plus (i.e. Staff and higher levels) as referenced by Will Larson in his book Staff Engineer.
    • This is technical leadership but a completely different skillset than management. You need a technical foundation at this level, but there are a number of leadership skills / principles involved (influencing decisions, lead without authority, etc.).
    • Josh tells us he is still in the beginning of this journey, but it was sparked by the comment from Jeffrey Snover (someone at the highest levels an individual contributor can reach)
    • Using Jeffrey Snover’s career as a north star for technical leadership, Josh started to look at the gap between the level where Snover is and the level where Josh is (differences in daily work, how Snover continues to be technical, how Snover influences the direction of his employer, etc. and the levels between). Starting to ask himself these types of questions are what started him down this path.
• How did the intimidation factor play into the way Josh prepared for and had the discussion with Jeffrey Snover (if at all)?
  • Nick makes the point that many of us might be intimidated trying to come up with an intelligent question to ask someone like Jeffrey Snover.
  • Josh had the opportunity to meet Snover in 2018 in person and was too shy to talk to him then. Doing the Twitter space was a way to overcome that shyness. Josh had a number of questions collected over the years that he wanted to ask.
  • Many of Josh’s questions came from Jeffrey’s talk on digital transformations.
  • Snover talks about an elevator job. For him, .NET was one, and PowerShell was another eventually.
  • Josh was thinking through his own career from the lens of an elevator job also. PowerShell is something that got him to being a SRE at StackOverflow.
  • As Josh mentioned, he had many questions for Snover, and Snover’s demeanor put him at ease during their conversation.
• There are trends in the tech industry you can latch onto and skill up in which open the door to what we would call elevator jobs.
  • Josh got into scripting around the time the DevOps movement (a big transformation) hit. He had been developing the skills to do DevOps things on Windows (something he calls niche). Josh was learning the principles in PowerShell, Windows Server, and then it eventually bled into Linux.
    • For Josh this was an elevator job (i.e. had a skillset the industry wanted that Josh was able to capitalize on). He tells us Snover’s elevator job was much more profound and got him to distinguished engineer.
    • The idea of the elevator job is being able to see a transition in the industry, to skill up in a specific technology that is part of the transition, and ride that to your next venture. This takes you higher and faster than walking up the staircase of a particular job and getting promoted every so often.
• What makes technical leadership more interesting than the management track?
  • Many people say when you go into management your output is determined by other people. In smaller companies you could get away with being technical and managing people (i.e. some technical work), and in larger companies your job is the career of other people.
  • Josh enjoys the technology and feels he would be better suited there.
  • Jeffrey Snover mentioned he was a manager at one time but felt he was doing the people he managed a disservice because he was more interested in the technology. And he chose to become an individual contributor.
    • Josh feels like he might end up in the same spot were he to pursue being a manager. Josh says maybe in the future he will try management and come back. Right now he is more interested in the technology, but he does want to learn and apply some leadership like having a broad influence and impact, which gives Josh somewhere to climb from where he is.
    • As a first time manager (less than 120 days in at the time of this recording), it’s more about the people than the technology. He thinks there are opportunities to be strategic and nudge your company in a more strategic direction.
    • When faced with many people working on a strategy and all the opinions that come with it, those who can explain their suggestion / opinion with some backing data get attention and get listened to a little bit more, especially when it is aligned with company goals.
    • John would say roughly 80% of the time it’s about the people who report to you and their careers and helping those people do their jobs better. It’s not so much the technology.
• Josh is also trying an interesting comparison of what it means to be technical.
  • Putting hands on the keyboard is one variant of being technical. You’re building something and learning about a technology and applying it.
  • There is another part of being technical which is required when you’re in a leadership role whether an individual contributor or not. This is the ability to apply your technical experience to influence decisions. You can guide a decision based on your own foundation of knowledge, and that foundation of knowledge doesn’t require as much updating as the hands on keyboard does.
  • If you intend to go into management it likely mean your hands on keyboard time would diminish, but it does not mean your ability to influence technical decisions would.
    • “It will probably increase because you will have a bigger scope, you will be in different rooms, and you will be able to exercise that to have broader impact than you would at the keyboard.” – Josh Duffney, on a manager’s impact
    • John mentions if you’re leading a team you have the ability to influence the team to investigate different directions, which holistically becomes more than any one person can do and acts as a force multiplier.
    • John has been thinking about how a technical person can navigate the transition into being a people manager without giving up technical skills. He tells us there are a lot of technical skills, but it happens to be about managing people.
    • “It’s a different set of technical than hands on keyboard.” – John White, on managing people being technical
• Is technical leadership more like wanting to succeed with others and not necessarily through others (management)?
  • In the case of Jeffrey Snover, he had to convince Microsoft to invest in a scripting language. This leadership bled over into the tech industry to support that it needed a scripting language for Windows, which eventually became cross-platform. This is a great example of what leadership is. Snover had the vision and had many others working with him.
  • In a similar way Josh is looking at how to broaden his own impact through influencing others with his idea and in how he scales and contributes to the ideas of others to see a bigger picture.
  • “It’s about going up a level and looking around.” – Josh Duffney, on widening / broadening your impact
  • If you’re coding something and developing it or more feature focused as an individual contributor, Josh says we should look at the levels above that and determine how far up would be enjoyable for him day to day.
    • A level or two up would be a good place to look to gain a perspective per Josh. He can see what his lead is doing nd what his skip level is doing, for example.
    • This is taken partially from some of the ideas in literature related to Staff Engineering.
• Josh cites two books influencing his current thinking on progressing past a senior level individual contributor:
  • The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly
    • Josh mentions Tanya Reilly shares some great illustrations and that this has been a joy to read.
    • The definition of a senior engineer according to Tanya Reilly – “the level at which someone can stop advancing and continue their current level of productivity, capability, and output for the rest of their career and still be recreating attribution.”
    • If you stay at the senior level you can get more technical and be the subject matter expert but may not be increasing your impact. The books mentioned above make you confront some of these questions (i.e. stay senior or make a change).
    • “Staff Engineer isn’t a lateral promotion. It’s a different track that you are climbing. It’s the individual contributor leadership track, and it’s parallel with management.” – Josh Duffney, on the Staff Engineer’s Path
  • Staff Engineer by Will Larson
    • Josh says he learned a lot about getting to the staff level from Larson’s book. It discusses thinking about visibility, thinking about your promotion packet, and a number of other things.
    • Reilly’s book is more about how you excel and execute in the role of a staff engineer. It’s almost like a sequel to Larson’s book.

37:27 – Parting Thoughts

• Josh is still using Obsidian with the PARA Method of note taking mostly to organize projects.

• Nick thinks it would be valuable to lay out the books Josh read before / around the times we have spoken with him and the lessons he’s learned for himself as a result along his career timeline.

  • “That’s the greatest gift you can give an author is to have a part of that book be a part of you and to live it out.” – Josh Duffney, on the value of reading books to learn
  • Imagine an Obsidian mind map of the books you’ve read cover to cover and the extractions of the lessons you carry with you from them. That could be quite the interesting tool. Maybe there should be an Obsidian plugin for this! Should John write one?
  • The biggest missed opportunity for some of these learning platforms according to Josh is not stealing the skill tree from video games. Imagine the books you read being mapped out on a skill tree. The books become the skills.

• Mentioned in the outro

  • Discussions of the unique value a person provides reminded Nick of our discussions of knowing the problem you solve from chats with Don Jones in Episode 137.
    • See also Episode 138 with Don Jones if you want to hear part 2 of that discussion.
    • It takes time and reflection to figure this out for yourself (your unique value). It might require journaling and deep reflection of things on a day, week, month, or multiple month basis.
  • The idea of unique value could also apply to open source projects and selecting one to which you will contribute. Users of a project are uniquely positioned to make good contributions to the future of the project because they are users.
  • John would love to look at the curated recommendations from Josh on what chapters to read from which Go book to get the most out of them for a specific topic you want to learn. Nick says it’s a learning plan pulled from multiple sources.
  • Chris Wahl told us in Episode 149 that comparison is the thief / death of joy.
    • Josh compared himself to Jeffrey Snover but through the lens of a role and level that was interesting, that he wanted to progress to, and how to get there (learning from someone Snover’s career journey and steps he took along the way to gain expertise or reach a new level). It is about looking for the skills gaps based on where you are much like John was looking to leverage Josh’s experience for guidance on the right path for learning Go.
    • Even in last week’s discussion from Episode 233 Josh was very open about where he is from a skills perspective (i.e. not to the level of a Don Jones in writing for example).
  • There were some great book recommendations in this episode too! Add them to the mention of Ultralearning from the episode last week that we didn’t call out in our intro / outro specifically (but is captured in our show notes).
  • We’re just following Josh’s progression path in each series of episodes we have done with him. Go back and find other episodes with Josh as guest mentioned below.
    • Episode 123 – Just Add Value with Josh Duffney (1/2)
    • Episode 124 – Focus, Create, and Iterate with Josh Duffney (2/2)
    • Episode 156 – Better Notes, Better You with Josh Duffney (1/2)
    • Episode 157 – Take Note of Your Time with Josh Duffney (2/2)

Contact us if you need help on the journey, and be sure to check out the Nerd Journey Podcast Knowledge Graph.