Explore every episode of the podcast Healthy Developer
| Title | Pub. Date | Duration | |
|---|---|---|---|
| Coaching Session: Am I Really a Product Manager? | 07 May 2025 | 00:48:33 | |
Ever thought about stepping into product management—just to try something totally different from engineering? That's exactly where Monte found himself. After years in dev and even engineering leadership, he made a move he thought would lead to more ownership and product vision. But once he was in the role… something felt off. In this coaching session, we unpack what actually happens when you chase product titles inside companies—and why the version you're offered often isn't what you imagined. Monte thought he was stepping forward. Instead, he realized he was just managing user stories and process artifacts. If you've ever wondered, "Is this really what the role is supposed to be?"—you're not alone. Work with me: https://healthydeveloper.com | |||
| Coaching Session: Fixing Development Team Culture | 23 Apr 2025 | 00:50:34 | |
In this real coaching session, I talk with John, a developer-turned-manager, who's navigating the messy middle of leadership. He's caught between two teams, two continents, and shifting expectations. Sound familiar? We dig into:
This is one of the most honest, practical coaching conversations I've had on team culture, dev leadership, and transitioning into management. If you're a senior dev or manager trying to scale impact without losing your soul, you'll get a ton out of this. Work with me: https://healthydeveloper.com | |||
| If Your Tech Job is Comfortable, You're in Danger | 16 Oct 2024 | 00:21:21 | |
Is your tech job feeling a little too comfortable? You might be unknowingly putting your career at risk. In the fast-paced world of technology, complacency can lead to career stagnation, limiting your earning potential and jeopardizing your job security. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching In this video, we'll uncover The Hidden Dangers of Comfort in Tech Jobs - How staying in your comfort zone can make you obsolete in a rapidly evolving industry. Signs You're Experiencing Career Stagnation - Recognize the red flags that indicate you're not growing professionally. The Importance of Continuous Skill Development - Why updating your skills is crucial for career advancement and remaining competitive. Strategies to Overcome Complacency - Practical steps to reignite your passion and drive in your tech career. Exploring Self-Employment and Tech Consulting - How becoming self-employed or starting a solo venture can enhance your career growth. Don't let the comfort of today become the regret of tomorrow. It's time to take control and ensure you're not left behind in the ever-changing technology industry. You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction Visit me at thrivingtechnologist.com | |||
| Is Your Software Company A Feature Factory Or A Lean Startup? | 13 Mar 2018 | 00:11:11 | |
Why do some software companies build exciting products with the freedom of a lean startup, while others deliver boring products like a feature factory run by control freaks? In this episode I ask this question: "Does Your Company Feel More Like a Factory, or a College"? Whether you're using agile methods like scrum, kanban, or any other process – up front design is still alive and well in many companies. To truly build innovative software products that cause your company to profit so you can get the rewards and recognition you want – people must let go. When features are identified has a big impact on success. Many companies focus mostly on the features for their software that they can think of or hear from customers ahead of time. But it's those features discovered only after you release your product to them using devops and continuous delivery approaches, with an agile budget, that cause you to profit greatly. This is the approach popularized by Eric Ries book "The Lean Startup". Companies run like a factory try to predict value, while companies run like a college discover value. Companies run like a factory control people, while companies run like a college trust people. Companies run like a factory use burn-down charts to measure progress, while companies run like a college use learning milestones. Companies run like a factory use a project budget, while companies run like a college use a monthly budget. Companies run like factory focus on measuring expenses, while companies run like a college focus on measuring profit. Do you work at a company that feels more like a software factory (or feature factory), or a college? Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How To Recover Hope In Programming | 06 Mar 2018 | 00:20:27 | |
In the first decade of my career, I would get angry at everyone around me and turned to the Internet to vent my frustration. It seemed like managers and other people who didn't understand software development had caused me to lose hope in my future. In this episode, I share what caused me to lose hope, and many programmers I run across struggle with these symptoms as well. If you're a programmer who has turned to escapism and joining the chorus of complainers – I implore you to reconsider! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. CHAPTER MARKERS (3:00) We're Forced to Cut Corners Visit me at thrivingtechnologist.com
| |||
| Caffeine Makes It Harder To Be Agile! | 04 Mar 2018 | 00:21:31 | |
If you want to be a calm programmer, you may want to consider cutting down on caffeine. On a project that's truly agile, most people need extra patience. Especially if they have high anxiety from using coffee or other stimulants to get through the day. In this episode, I share some things you may want to know if you want a sustainable career in software development. Though you may not be able to completely cut out caffeine, it can wreak havoc on you and your team's ability to work together well. When work is already difficult, and people are under stress, caffeine only tends to make things worse. I hope these tips for avoiding caffeine withdrawal help you to stay a healthy programmer! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Why Do People Take Credit For Your Ideas? | 03 Mar 2018 | 00:20:09 | |
Have you ever had an idea for something on your software project, but someone else takes the credit? Plagiarism can be extremely frustrating, and it's typically caused by narcissistic personality types. In this episode, I share why this happens, how to prevent it – and how to cope with it. I also share a personal story of when this has happened to me. This sucks, there's no way around it. But if you're creative enough to come up with new software development ideas, you can do it again! I hope this episode helps you avoid this situation in the future, and have a healthy mindset if you unfortunately do get plagiarized. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| 5 Career Myths Keeping Good Developers Stuck | 28 Feb 2018 | 00:12:06 | |
Looking at what decisions others make about their career in software can be a big mistake. Though having a career in software development can be exciting, there is also cause for serious caution. In this episode, I share the 5 biggest lies I have bought myself, and I hope you don't about your career in software development. With healthy decisions and a realistic mindset, you can advance quicker than others and not get stuck in common traps. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. CHAPTER MARKERS (1:40) Technical Skill Determines Your Success Visit me at thrivingtechnologist.com | |||
| An Agile Budget Keeps You From Being A Code Monkey | 26 Feb 2018 | 00:20:25 | |
If you feel like a "code monkey" with pressure to work fast – you need an agile budget. It took me many years, but I finally figured out the reason why. Companies that try to build software like a manufacturing plant budget the wrong way. This creates pressure on workers, and produces boring products that barely keep a software company profitable. At companies that understand this, you'll be more creative and spend less time trying to estimate. If the leaders at your software company don't understand this, they may still have a (barely) profitable business, but they'll be wasting tons of money. In this episode, I share hard learned lessons about the software industry that every company should build their foundation upon. Agile budgeting is a key to healthy software development company culture – and careers! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Is Planning Poker Safe On Your Team? | 25 Feb 2018 | 00:12:19 | |
If you've ever had to estimate software development work, you may have engaged in "planning poker". This method of estimating brings with it some potential benefits. But depending on the culture of your team, it can also cause big problems. In this episode, I hope to avoid you falling into using this common practice if it isn't right for your team. Planning poker might be just what your team needs – but you need to make the smart choice! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Programming Made it Hard to Lose Weight | 20 Feb 2018 | 00:14:45 | |
I gained weight quickly from programming and needed help with weight loss early in my career. I took part in the corporate events that provided unhealthy food because it was "there"… I was accepted easier by my coworkers because I would eat the same fatty and high calorie meals that they chose… And I fell into emotional eating, because the stress of software development was depleting my diet of nutrients. So I started to tell myself "losing weight is vanity – I'm not one of THOSE people". But in this episode, I share my personal story of weight loss after ballooning up to over 210 pounds. I hope my story helps someone else out there who is struggling with the lifestyle of programmers that can make it hard to stay in shape. Corporate culture won't always make it easy – but you're worth it! There is hope for you – losing weight is not impossible, but you've got to stand your ground! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| The Secret of Scrum Nobody Wants To Talk About! | 19 Feb 2018 | 00:07:17 | |
Too many companies and agile coaches keep the secret of scrum from people! When agile methods of software development were first brought on the scene, they led to abuse. Managers "cherry picked" the practices that gave them more control, but software products didn't actually get any better! In fact, when you ask most programmers or other software professionals Scrum seems to add MORE pressure and problems. In this episode, I share the secret of Scrum. If your company doesn't know this secret, you're wasting your time because the word "agile" means NOTHING! If you don't understand why scrum doesn't work, I hope this episode offers some insight. Using a sprint in scrum can cause more problems than it's worth – without the right mindset to learn from failure. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Is Your Software Development Leader a Narcissist? | 18 Feb 2018 | 00:14:26 | |
Are you on a project with a software leader who's a narcissist, and criticizes everything you do? Did they treat you like a "rockstar" developer at first, but now it seems like you can never please them? Working under a narcissist can be one of the most frustrating experiences in your software development career. In this episode, I share some key traits and behaviors to look for in identifying if you're working under one. Though people can exhibit several of these traits and NOT be a narcissist, if you see a pattern of several of these behaviors – BEWARE. I hope this information helps you identify whether you're being abused emotionally – and cope until you're able to get out. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Think Your Corporate Job Is Secure? Think Again | 02 Oct 2024 | 00:24:40 | |
What if the real risk isn't leaving your corporate job, but staying in it? If you're comfortable in your tech job today, layoffs aren't the only risk you face. The myth of job security is a common cause for staying stuck and growing complacent. 7 years ago my life was turned upside down when I realized for the first time - just how trapped I'd become. I developed chronic insomnia and anxiety, and it eventually emptied my bank account. All because I refused to accept that I'd outgrown working for corporations. I wasn't sure if I wanted to be an entrepreneur or just work solo as a consultant - but I knew I was done with having a boss. In this episode, I'd like to help you get a sober view at what staying in corporate jobs can cost you. Unfortunately, job security is a myth. I hope this content about overcoming fear of self-employment helps you find the courage to explore more empowering ways of work - if you've outgrown the corporate tech job grind. Whether you want to become an independent software development consultant or start a SaaS (software as a service) business, tech professionals in IT jobs and at software companies don't have to stay chained to their corporate jobs forever. There is no such thing as a "secure job"! But you'll have to step into the unknown waters of being a solopreneur - if you want to experience self-empowerment. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction Visit me at thrivingtechnologist.com | |||
| How To Find The Best Software Project For Your Personality | 15 Feb 2018 | 00:20:29 | |
Ever get the feeling the software project you're on clashes with your personality? Does the way people work together seem very different than you? Have you had a great experience on one project, only to start enough and feel miserable? If this has ever happened to you, I hope today's episode helps you avoid this. Depending on the stage of a software product's life cycle, you may or may not be the right fit for a team. This has nothing to do with the programming technology stack, operations procedures, or software development process. It has more to do with your goals and preferences at this single moment in your career. I explain how the early, growth, and sunset stages of a typical software product's profit life cycle impact your happiness. Armed with this information, you can make the best decision in your software development career and hopefully find the perfect software project. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Why Are YOU Making Programming Harder? | 15 Feb 2018 | 00:17:10 | |
I hear a common complaint that programming has gotten harder over the years. The more years I spent in software development, I fell into getting frustrated and blaming other people, or the technology. But I realized that I was a big part of the problem – though it was hard to admit. In this episode, I share some things I didn't realize at first that I was doing to make my job harder than it needed to be. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| What Happens When Software Products Reach End Of Life | 14 Feb 2018 | 00:17:47 | |
Do you have a feeling that the software product you're working on is reaching its end of life? Every software product goes through a sunset stage as part of its life cycle. This is a natural progression of your software business, but it needs to be handled carefully. In this episode, I share some considerations your development team can apply to navigate this stage better. If you want to ensure that your software development career keeps moving forward, you need to understand this stage of the life cycle. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How Market Fit Changes Software Companies | 13 Feb 2018 | 00:24:31 | |
Have you seen the signs that your software company is profiting and may have reached market fit? The way teams work together needs to change when a software product reaches this critical point in its life cycle. That doesn't mean innovation stops, but a focus on moving towards partnering and stability of technology becomes increased. In this episode, I share some insights I've had about how software teams can go about navigating this difficult phase in the life cycle of a software product. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Is Your Software Company Managed By FEAR? | 11 Feb 2018 | 00:25:26 | |
Why do software companies try to innovate under a culture of fear? Does the software company you work at frustrate people with a focus on cost savings over GROWTH? In this episode, I share some critical insights to how many companies strangle innovation by managing to fear! Armed with this information, you can stop feeling like a cog in a wheel – and help the culture at your software company improve. If you've had agile coaches, DevOps experts, and other "gurus" try to help your company and it still feels like a pressure cooker – this might be why! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Grow A Software Product The Smart Way | 11 Feb 2018 | 00:13:38 | |
Are you concerned that your software company isn't setup for growth? In working with over 30 companies, I've come across many that don't understand the software business life cycle. This episode offers some essential information you can use to understand how your company is being managed. The foundation I provide here can help you determine where in the life cycle of your software products the team you might be working on is at. This will help you make better decisions about technology and software processes – and I'll expand on it in future episodes. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Programmer Flow State: "In The Zone" Coding | 10 Feb 2018 | 00:17:07 | |
Have you solved programming problems easier when "in the zone" or "flow state"? If you've experienced this, once achieved it's hard to work any other way. In this episode, I want to share some strategies you can use to avoid getting interrupted. These will also help you get into the flow state more often so you can enjoy productive and creative sessions of work regularly. If you follow the tips in this episode, you can help others understand why getting into a flow state is more important than letting others interrupt you at will while programming. It will take setting expectations and creating healthy boundaries for yourself, but can result in breakthroughs in efficiency and your enjoyment of software development. Avoiding interruptions can make one of the biggest differences to your satisfaction over your tech career, whether you're a software developer or a consultant. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How To Earn Respect On A New Software Project | 07 Feb 2018 | 00:19:15 | |
Are you joining a new company, team, or project? Do you want to make sure others respect you so you can use the technologies you want – and get your skills used? Early in my career I thought the best way to do this was to impress others with my technical acumen. But I learned quickly that this only causes frustration and delayed me being accepted. In this episode, I share stories and tips that will help you approach a new team with a positive attitude. You'll overcome walls people can put up and instead have others welcome your suggestions for improving their software project. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Are You A Perfectionist Programmer? | 07 Feb 2018 | 00:20:17 | |
In this episode, I want to ask you a question that might make you defensive: "Are you a perfectionist programmer?". I can tell you, after many years of being a software developer, I've gotten much better at this. But one of the things I want to help you with in this video is to maybe think a little bit about how you work with others – and maybe make better decisions about what kind of expectations you have from software developers, technologists, and other people on your team so that you don't get into a situation where you turn people off and you can't really get their best work and cooperation because you might expect them to work exactly how you do. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| "New Framework Disease" (NFD) in Software Development | 06 Feb 2018 | 00:21:49 | |
Technology addiction hurts your software development career if materialism makes you chase shiny objects. When I was a child, I used to like looking through the magazines my father got with all kinds of gadgets in them. As an adult, I often got caught up in obtaining the latest cars, guitars, or other material possessions. And though you may have a handle on materialism in your personal life - it can become prevalent in a software development career. We suffer from technology addiction when we get bored from repetitiveness - this is pretty obvious. But we also suffer from envy - and this is common because many companies don't keep their software developers growing. We can also put on "rose colored glasses" and deceive ourselves into thinking a new framework, API, or other technology will solve our problems. Failing to master a language or technology puts you at a serious disadvantage in your tech career. It's highly important that you develop the ability to match technology to the business. The only way this will happen, is if you both master your current tech stack - and develop an appreciation for what is unique in the business of your current software project. Ultimately, you need to be able to deliver results. Hiring practices in the industry make this an ongoing problem, but you can avoid some of the snares by thinking about the insights I share in this video. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How To Actually Find Profitable Software Ideas | 25 Sep 2024 | 00:13:55 | |
Thinking of quitting the tech industry grind to start a profitable software business yourself? Before you take the plunge, don't make the same mistakes I did! The secret to finding a profitable software idea, is that it must come from your customers. Unless you know a real pain that people who would use your software are experiencing, you can easily fool yourself into thinking it's good enough to build a software product business on. In this episode, I share what I've learned about finding real software product ideas. I use a combination of IBISWorld, ChatGPT, and a book by Dane Maxwell to help my software development coaching clients discover software startup ideas. IBISWorld Businesses Start from Zero by Dane Maxwell Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction Visit me at thrivingtechnologist.com | |||
| What Is DevOps REALLY About? (Hint: NOT CI/CD) | 05 Feb 2018 | 00:15:29 | |
There's plenty of "fake news" from the software industry, so beware of the DevOps lie. There's a lot of confusion - just follow the money to see why. In this video I help you discover the real answer to "what is DevOps?", and why it may not be working for you. Though automated deployment technologies, cloud infrastructure, and other "fun" tools are exciting to talk about... ...DevOps is really about getting people to work together. I hope this episode helps you understand the core reason why DevOps came to be, and how it's a subset of Continuous Delivery. Though both of these terms ultimately seek to allow your company to release quicker (and more often) - I've seen them fail when gone about the wrong way. You can help your company achieve the promises of DevOps by following the tips in this episode. If you can help others answer the question "what is DevOps?" correctly - you can help your company achieve the cross-functional teamwork necessary. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||
| Pull Your Software Project Out Of A Death Spiral! | 04 Feb 2018 | 00:14:37 | |
Being on a software project death spiral can be extremely stressful. It usually happens when your company is doing FAKE Agile software development. People feel despair, and it looks like there's no end in sight? In this episode, I share some practical tips to help you correct this situation. Though it's never easy to recover from a death spiral, don't give up when there's hope! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Programming Estimation – Estimate Software Tasks With Caution | 01 Feb 2018 | 00:13:07 | |
When someone comes to you for an estimate of a software task, do you feel uneasy? Programming estimation is a dangerous activity that should be approached with caution! But people make estimating software tasks more stressful than needed. In this episode, I share some tips that will help you have better success rates when estimating software. Though you may not be able to get out of estimating altogether (#noestimates), you can minimize the damage. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Say NO On A Software Project - So They Will Listen! | 31 Jan 2018 | 00:12:12 | |
It's bound to happen that at some point you'll be asked to do some work that you know will have a negative outcome. How you say no on a software project can build resentment if you don't establish clear boundaries - and decline the request with grace. In this episode I share some tips I've found work well for diffusing resistance to your desire to do the work some other way. When you understand the person making the request better, you'll do a better job aligning your message with their needs. You will need to help them overcome the pressure they already feel to meet any commitment they already made to their boss. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| What To Do When Your Software Tasks Will Be Late | 29 Jan 2018 | 00:10:49 | |
No matter how experienced you are, sometimes your software tasks will be late. How you handle this often has far reaching implications on your career and your health. In this episode, I share some insights I've had from doing this well - and not so well. Learning to be transparent, reset expectations, and refuse to be strong-armed into releasing low quality work will ensure you have a sustainable software development career. You can also watch this episode on YouTube.
Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards | |||
| Democratic Software Architecture - Sharing Technology Decisions | 29 Jan 2018 | 00:29:34 | |
Do the teams you work on have an "elite few" that are looked to for making technology decisions? Are there times you wish people would work together more to drive software architecture? In today's episode I share both good, and bad experiences I've had with team structures that effect software architecture. It seems logical at first to only allow people with more experience to make these decisions about tools, processes, and frameworks. But only teams that have an inclusive technical culture bring out the best in people by giving them shared ownership over the process. Included are some tips I've found useful over my career to speed up the rate of adopting new technologies as part of your product's stack - and making it everyone's job. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Software Project Burnout: Is It Them Or You? | 28 Jan 2018 | 00:24:15 | |
It's easy to blame your company when a software project seems to require so many hours, that you suffer from software project burnout. And there certainly are companies that haven't figured out how to set deadlines in a way that expectations can be reset if things go wrong. But you can also burn yourself out, if you don't set healthy boundaries. I've actually worked overtime at the BEGINNING of a project! This would happen when I wanted to try and "make sure" we wouldn't be late. Or sometimes when I was just so excited to learn new technologies I DIDN'T WANT TO STOP. In this episode, I encourage you to do whatever you can to prevent working any sort of overtime. Even if you love working with software and technology, you need to consider the precedent you set. If employers know you will sacrifice your well being to meet deadlines, it's too tempting for them to abuse again! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Can Imposter Syndrome Help Software Developers Grow? | 24 Jan 2018 | 00:23:04 | |
Imposter syndrome is something software teams often talk negatively about, but it can actually be a sign of growth. The feeling that you don't know what others think you do can cause a lot of stress and anxiety. We all put up with this feeling when we're new, because others expect that we don't know what we're doing. But after a few years in software development, we can forget that feeling. When asked to do work that requires us to grow, it's critical that we get comfortable with it. There are a few reasons why software professionals tend to be especially susceptible to this. One is that other egotistical, narcissistic developers can make fun of us. But this says more about THEM than us. Another is that we worry that we'll be "found out" by management for needing to learn something. But emotionally intelligent managers and leaders see through the false wall of lies that some developers can put up when they try to appear infallible. In this episode, I encourage you to look at imposter syndrome as a healthy sign that you need to grow. If you can be honest, detach from what others think, and learn to reset expectations with others - you don't need a reason to worry that you're an imposter. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Your Software Project Is Failing - Now What? | 23 Jan 2018 | 00:35:43 | |
We all hate that sinking feeling when we realize we're on a failing software project. What you do then will have a bigger impact on your health than your reputation. Earlier in my career, I would try to avoid blame as my number one priority. As I got more experienced, I saw the folly of this and realized I needed to follow through with my best work. How we deal with tough times says more to others than how we behave when things are going smoothly. In this episode I share the story of two clients I worked with that had failing projects. Sadly - I've been on more failed projects than successful ones, but I felt these two might help you think about how you cope with this situation. Remember just because a project fails - it doesn't mean YOU are a failure. It's OK to accept circumstances, accept your limitations - and do what you can. Your family, relationships, and health will thank you for it! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Can You Be Agile - Even When Your Company Isn't? | 23 Jan 2018 | 00:17:26 | |
Stop getting angry that you're company isn't more AGILE! It's human nature that causes digital transformations to fail. I spent most of my career trying to help companies be agile. But people in positions of power are often driven by greed and the illusion of control, and they won't support efforts that require them to change. I had a nasty bout of insomnia in April of 2017 where I had to resign from my job. I spent the 8 months that followed healing, researching, and trying to understand where I went wrong. I'm no "guru" and I certainly don't know everything about this industry - but after working with 30+ companies I've seen some patterns. This year I want to help you avoid the pain I went through by having a healthier, more sustainable career in software development! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| Real 10x Programmers Are SLOW To Write Code | 18 Sep 2024 | 00:15:04 | |
If you've ever been jealous of programmers who seem to write code faster than you - take heart. The myth of the "10x programmer" is misunderstood in many software teams and tech companies. What's important to companies is NOT that you're actually 10x faster at writing code. It's that you help the company produce features 10 times faster. Wake up call - you're not the only member of the team! Over my career, I've met software developers who come into companies and write code super fast - but end up slowing the project down. They bossed around the other junior developers and thought they were God's gift to programming. It was a real disaster. Instead, use these 6 techniques I learned as a software consultant. They'll speed up the project, make you popular on your team, get results for your company - and actually make your tech job easier! Besides, what's more important: that you can write code fast, or that you can avoid writing more code in the first place? Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction Visit me at thrivingtechnologist.com | |||
| 5 Signs Your Software Business Is Led By Amateurs! | 08 Nov 2017 | 00:15:20 | |
Do you ever get that sinking feeling that the people running your software business don't really know what they're doing? Here's 5 signs your software business is led by amateurs! It can be practically a sport to make fun of leadership for not understanding modern software development and its implications. That's not the purpose of this post. If you're working at a company where several of these signs are present, you have three options. Put up with it, try to change it for the better, or move on. Here's 5 signs your software business leadership needs help:
If the place you're working at has these problems, do you have the courage to move from complaining to having some serious conversations? Even if you consider yourself just a cog in a huge machine, you can help your leaders make better decisions that keep the company profitable! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How To Confront Difficult Software Developers About Their Behavior | 04 Nov 2017 | 00:13:31 | |
Have you ever been on a software project with someone who does great work but is difficult to work with? Here's some strategies for confronting difficult software developers about their behavior. Before you even think about having this conversation, go into the conversation detached from the outcome you want. If you go into it thinking "If I don't get this person's behavior then I'll be upset" – the other person will pick up on it. Here's 6 tips for this conversation:
Don't give the person an ultimatum! They will make the change but resent you for it! Don't attach rewards to the change. They will expect rewards for future good behavior! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources:
Visit me at thrivingtechnologist.com | |||
| Needing To Be Understood Makes Software Professionals Dislike You | 02 Nov 2017 | 00:08:41 | |
Does it seem like others are turned off by you before you're even able to fully explain yourself? Today I'd like to share 4 behaviors that stem out of our fear of being misunderstood. These can cause other software professionals to dislike and not want to work with you! Demanding Re-ExplanationA parent will sometimes ask a child "OK, tell me what I just said" to make sure they understand. If you do this to an adult on your project, it sends the signal that you don't think of them as very intelligent. It also comes across as condescending. Instead, make sure the other person understands the essence of what you're saying. If they know enough to take action, move on. NitpickingIt's tempting when we're insecure in some way about our skills to take apart what others say and demand it to be phrased how you would. This comes across as needy, and though you might think it demonstrates your mastery of the knowledge, it turns people off. As with the above point, when the other person chooses to use different words than you, but they are basically saying the same thing, let it go – they get it. Over-communicatingIn our desire to make sure we're understood, we can sometimes verbally vomit our ideas onto a person and overwhelm them. It takes a lot of energy to have technical conversations, so plan wisely and only communicate the minimum information needed to get the other person to take the actions needed. Abusing ApologiesIn our desire to help other people feel comfortable with us, we can sometimes abuse apologies. Saying "sorry" for a mistake you made, and owing up to it, is a good idea. But if others are upset with you about something you didn't do or had no control over it, never apologize. If you do, it sets the precedent they can use you as a punching bag. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources:
Visit me at thrivingtechnologist.com | |||
| Is Ego Hurting Your Software Career? | 22 Oct 2017 | 00:16:23 | |
Does it frustrate you when you see other software professionals get recognition or opportunities you want? Are you stuck in a software project situation where it feels like you're unable to grow? Let me share some information that will help you advance, but in a healthy way. I'll list 4 tips at the end. Growth and Perks are Abundant Early OnWhen you first start working in software, you'll have rewards that will keep you satisfied for the first 2-5 years:
After time spent on spent on projects that aren't letting you grow, you may hit some barriers:
The reality is that the way to grow is to contribute more. You'll always progress faster in your software development career when you serve others with something for which you have become particularly skilled. Why Software Professionals Struggle to GrowYou may be familiar with Tony Robbins' 6 human needs. He breaks human behavior down into things that drive us and are necessary for our survival.
As software developers, we have particular dynamics to the job that cause us to get into trouble with these human needs: Problem #1: We seek certainty, but then get bored. Problem #2: We try to be significant (get promoted, recognized), and sacrifice connection with others. Problem #3: We focus on growing our skills, and sacrifice contribution (helping others). 4 Tips for Healthy Software Career GrowthHow can you balance these human needs better, specifically in your software career? Tip #1: Set Deadlines for Career ChangesDon't wait until you get frustrated. Plan for when to make career decisions if situations don't improve. Tip #2: Respect Resistance to Change from OthersThere will be times you want to grow and others don't. You want to get support from other people on your projects in a way that's healthy to your relationship. Visit the post about How To Win Trust For Your Software Ideas for some tips. Tip #3: Contribute to Other People's Career GrowthWhen you help others get recognized, they will return the favor. You also get an opportunity to learn from others when you let them lead you in doing new work when you want to grow. Tip #4: Allow Others to Be "The Expert"When you let others teach you, instead of just learning from the internet, you strengthen your relationship. This is because people appreciate when you show that you value their opinion enough to defer to them for their expertise. It also helps you learn faster from their experience than scouring StackOverflow and Google. Being able to become a "newbie" again is an invaluable skill! Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources:
Visit me at thrivingtechnologist.com | |||
| Overcome Attachment: Discover the Mindset for Lean Software Development | 14 Oct 2017 | 00:16:46 | |
Are you trying to get other people to use agile or lean software development methods, but they can't seem to break out of the mindset they're stuck in? Today I'd like to offer some strategies to overcome attachment. Building What Customers Want Takes Failure And LearningTraditional management at many companies focus on predictability. They want to know how long things will take, and how much they will cost. Unfortunately if your software company wants to be innovative, you may already know that you can't measure performance this way. If you want to deliver truly disruptive and valuable ideas to your customers, you need to experiment and make small investments to see how customers receive them. Establishing the Mindset for Failure and LearningI talk often about how important experiments are to the success of your software company, and how you can sell and introduce the changes needed to work this way to leadership and other stakeholders. Assume for a moment you've already convinced people of the benefits of lean software development methods that let your company experiment (DevOps, Continuous Delivery, Lean Startup techniques etc.). Yes, people now understand the mechanics of these approaches. But it can be frustrating at first to help others have the courage to take risks and actually experiment. This is because experimenting and then learning from the results, often requires failure. The Uncertainty of Innovation Can Cause AnxietyOne of the technology capabilities I have said in other articles is crucial to a company sustainably releasing valuable software, is Continuous Delivery. This lets your team release your software to customers as frequently as multiple times per day. If you're going to let the customer take a larger role in deciding what's in your product, and release it multiple times per day — you'll have an increased set of feedback. Also subject matter experts like Product Managers will find out their ideas aren't as valuable as they'd hoped when trying new things. These two changes alone introduce uncertainty that needs to be handled with care. Without addressing this, your team will start blaming each other and going back to what they're comfortable with when their first few experiments don't produce the results they anticipated. Overcoming Attachment to Enable LearningIf you celebrate Christmas or your Birthday, you've probably experienced being attached to a gift or outcome you wanted as a child. You and your team need to overcome these feelings of attachment at your company to use lean and agile methods for developing software. Without detaching from outcomes, people will feel threatened when things change. We Must Be Comfortable With Uncertainty to Take RisksThe more comfortable you can be with trying things and not being able to guarantee that the outcome is something that you want, the more you can take risks. This is exactly the mindset needed to be more innovative with software development. Strategies for Practicing DetachmentSince you know people need to be more comfortable with uncertainty, and they need to be less attached to outcomes — what are some strategies you can use to cope with this? Thinking About the Possibility of Other OutcomesMost people in corporate America don't want to do this. Typical work structures are all about certainty and planning for outcomes we expect. Instead, thinking about the possibility that what you've planned might not work out ahead of time primes you for a healthy mindset for taking risk. When you're working with a team to experiment, remind them at every opportunity that everyone is looking forward to seeing the data to help them steer the product in the right direction. If the data behind a release shows that a change wasn't positive, that is not a failure. It must be clear that there will be no reprimanding for theories the team held about what would be valuable, as testing those theories will inherently prove when our ideas aren't good. This is the nature of the scientific method! Beware of CatastrophizingOnce you begin to allow yourself to entertain the possibility of uncertain outcomes, it's tempting to think of the worst case scenario. This is known as catastrophizing, and creates anxiety by focusing your thoughts on negative situations that haven't even happened yet! When I've caught myself catastrophizing, I often realize I'm tensing up and experiencing the same emotions as I would if the event happened — but it hasn't. Spending significant time thinking about the worst possible outcome will cripple your team with fear, and cause them to lose the courage needed to present their best ideas to your customers. Yes, there is a time for risk management — but innovation is not that time. Overcoming Resentment to Past FailuresIf you hold on to negative feelings about what may have happened in the past, you won't have the open mind necessary to try new things. Examples might be working with a person who made a mistake before, a business partner who didn't hold up their end of the deal, or a software development task that was more complicated than first thought. Resentment is another form of attachment. You should consider practicing forgiveness and using whatever healing tools work for you or your team to let go of any resentment. These could be simple things like giving someone a personal apology if you played a part in the situation. Or something that lets you face the situation and let your feelings with it rest such as meditation. Whatever physical, emotional, or spiritual activity you can find that works to help you or others involved emotionally detach from the experience, use it. Let the past go so your team can try new things with a clean slate! Challenging Limiting BeliefsIf someone told you something about yourself as a child, or perhaps a co-worker made a statement about your skills — you may be walking around carrying an inaccurate picture of yourself. You should challenge thoughts held about what is really true with respect to the limitations you or your team may perceive about their capabilities. I once worked with a Fortune 500 client who only released their product at night when no customers were using it. They were convinced it was impossible to release it during the day even though the technology needed to do so was common. Until I challenged this belief, and did not back down until I heard a logical answer for why it couldn't be done — no one had considered it a possibility. Once everyone moved past this limitation in their thinking, they were easily on board and supportive of working with me to plan for the change. Separating Our Identity From OutcomesIn most companies if someone makes a "bad" decision, they are held accountable. What this can do though is cause you to place your self-worth in your decisions and their outcomes. To have the courage to innovate, you need to separate these two. People on your teams should strive to treat each other kindly especially at the times when they make mistakes. But when they slip up and get upset at you or someone else for a decision that they didn't like, it's important to not take it personally. You can't control how the other person will react — but you can control your reaction to their being upset. Practicing Delayed GratificationYour company may need to build and release five small versions of an idea to your customer before you hit the ideal solution, when delivering a product in a lean fashion. Because of this, the management team may be lacking in the necessary patience at first to see things unfold with the product this way. Delayed gratification is simply waiting longer to get something you want. This might sound like a silly thing to recommend, but you'd be surprised how many people I come across in leadership positions who are still very attached to immediacy. If you have people like this in key positions at your company, this may be the reason why you're having a difficult time getting support for the changes you want made. Practice this yourself, and with your team, to relax your feelings of urgency so you have the patience to try several iterations of an idea before settling. Permitting Others to be Frustrated with UncertaintyIt's natural that when trying something new, such as to not be as attached to outcomes, you and others will make mistakes. It's crucial that everyone be willing to forgive each other when unpredictable negative outcomes occur. Without this safety net, there can be no loyalty, transparency, or ability to take risks. These are the attributes of relationships at your company that can make or break the long term health of the software development culture. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How To Build Consensus For Software Decisions | 06 Oct 2017 | 00:08:00 | |
Do you need to get people to agree and come to consensus so you can grow on your software project, or in your career? Today I'd like to share a few resources, and some simple concepts to consider, when influencing others to make a decision. When I started out in my career, I was a good software developer and could write code and work with many complicated pieces of technology. But I didn't become good at influencing people until I began consulting a decade later. The Circles of InfluenceStephen Covey's famous book The 7 Habits of Highly Effective People, introduces many powerful concepts for better work. I'd like to mention his concept of circles of influence, which is important for thinking about how to build consensus. The first circle is the circle of control, and typically only includes yourself. If you have children, or subordinates, you may consider them within this circle. In most cases however, there is little you can actually control. The second circle is the circle of influence, and is comprised usually of people on your software team who you already have good relationships with. These are people who will take your advice seriously, and expect you to influence them. The last circle is the circle of concern, and includes people that we have no direct control over OR influence with. Influencing these people usually takes indirect influence through another person. Who Can I Influence Already?It makes sense, especially within the context of Stephen Covey's book and recommendations himself, that we focus on those we can influence first. If we already have great relationships, those should be the first people we bring over to our side with a decision. Identifying Stakeholders of Your Circle of InfluenceBecause it often takes getting agreement from people outside our circle of influence, we next need to identify who these people are. We can typically influence them indirectly through the relationships we already have. If not, we can look to someone else we know, that knows this person already, to open a door to a conversation. You May Need to Influence "Up the Ladder"Many software companies can grow into a structure with multiple levels of people. Even when using agile development methods, communication across people continues to be a challenge. In addition to building consensus across our circle of influence at our level, we may need to get agreement UP the "ladder" of people in the company so we can reach consensus. Beware of Team DysfunctionsWhile attempting to influence others, it's common that due to past failures or trust issues, you may run into politics. The book by Patrick Lencioni, The 5 Dysfunctions of a Team, is a great resource to help you win back the support of difficult people and get everyone talking honestly again. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||
| How To Shut Down Your Feature Factory | 30 Sep 2017 | 00:19:21 | |
Are you developing software under pressure like a "feature factory", but there never seems to be any economic benefit to the changes? Today I'd like to share some strategies to begin shutting this unhealthy work approach down. The term "feature factory" was coined by John Cutler, a Senior Product Manager who's worked for several high profile companies. He wrote an article in the Hackernoon publication on Medium that introduced the concept to the masses. When you read his article, you may, like me, find yourself nodding your head "YES!" to all of it. Anyone who has worked to produce software on a team that is a feature factory will immediately recognize many of the symptoms. What is a Feature Factory?I'd encourage you to read all of John's articles for more details, but when you really boil it down a feature factory is a team or company that doesn't know how to measure the business impact of their changes. Set a Measurable Business Impact Goal for EVERY ChangeWhen we're in school many of us learn the scientific method. At a high level – you have a theory, you decide how to measure it, you design an experiment, and you record the results. Often our theories are proven wrong. Unfortunately, when it comes to developing software many of us assume we can't be wrong and do very little to handle that very real possibility. One of the first things that is necessary to shut down a feature factory, is to only make changes that can be measured as being successful or not in reaching an outcome. Move Further Towards Cross-Functional TeamworkWhen the people who work together to produce software are in separate departments, it often leads to people deferring design decisions to a UX, Product Management, or other design person. A cross-functional team actually strengthens the ability to deliver "the right thing" and NOT be a feature factory, because everyone can contribute to design ideas because they are dedicated to the success of ONE product. Celebrate Outcomes Instead of ReleasesWhen we start releasing software several times a day using things like DevOps and Continuous Delivery, we often will not hit a positive business outcome with each release. Because of the chance of failure, we should celebrate as a team when we reach a business outcome – not every time we release. John calls this "success theater". Cultivate a Culture Safe for Failure and LearningWhen we plan a project that takes a long time to deliver, during that period there are assumptions about the value of what's being built. There are no ramifications or learning until the end, and on some teams if the product doesn't deliver on it's expectations people are FIRED! To allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be "wrong". This requires making it safe for Product Managers and others to take risks so they can learn. Focus on Value NOT Efficiency / UtilizationThis one is pretty self explanatory. If a team is constantly pushed to be as efficient as possible, they won't have the relaxed and creative mindset necessary to make changes that contradict our initial assumptions! Release Smaller Changes, More OftenTo enable failures (learning) to have a smaller impact and cause less waste when it comes to budgeting – designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||
| 5 Ways Dishonesty HURTS Your Software Development Career! | 30 Aug 2017 | 00:14:00 | |
Do you find it hard to be honest with others about some aspect of developing software? Or maybe you find others are withholding truths, and you wonder why? Today I'd like to share some ways I have been dishonest earlier in my career, and I now see are common in our industry. Not Admitting Being Unfamiliar With SomethingIn short time, we can gain a lot of knowledge about technology and software development processes. If we're not careful, this leads to a "big head" or inflated ego, and we can feel embarrassed if we haven't heard about "the new hotness". If we're honest with others when we don't know something, they trust us more to be transparent, and they know they can share things they are excited about without us shutting them down in an attempt to be seen as the expert. Saying "Yes" To Work You Don't UnderstandIt is often that on software projects we are asked to estimate work based on the information another has captured for us. If we don't fully take the time to understand it, or have a self-inflated sense of our level of skill, it doesn't take much to agree to work when we shouldn't. I learned to say "No" more strongly and honestly about 5 years ago, and it has helped me on numerous occasions. When I didn't do this, I would often put myself under extra pressure, and have to reset expectations with the other party who is now upset that I can't deliver what they expected. Not Admitting We've Overlooked A Process StepSoftware development is inherently complex and often requires many moving parts to be changed in a very specific sequence to accomplish work. As humans, we will inevitably make mistakes. Under pressure, I have failed to be honest with others that I simply forgot a step in my desire to be seen as the expert. I have become MUCH better about being honest about this now, but it is very common in more junior technologists. When we take responsibility for forgetting something, we build trust with others who know we will hold ourselves accountable for our actions. Making Generalizations About OthersIn our desire to be seen as the expert, we can sometimes have just a few interactions with another person and then paint them as incompetent or lacking in skill to others. This thinly-veiled attempt to make ourselves appear smarter than we are casts doubt in all but the most unsophisticated of people. If the person you made a generalization about meets the person you said this to, they will find out that you are quick to judge and make inaccurate statements on a whim. Just don't do this! Not Being Honest About Your Level Of ContributionWe work hard to produce quality deliverables and value for our team and customers on software projects. And few things feel better than a customer or someone else at the company saying "great job!" But I have not always been as forthcoming about the work others did to support me in successes, and since getting better at this my ability to motivate others and build trust has gone up tremendously. When you check yourself when receiving a complement and remember to include others who were part of the success, you build a positive emotional connection between you and them, and deepen the trust and loyalty necessary to keep a strong team together. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| My Software Development Journey (Part 3) | 25 Aug 2017 | 00:29:46 | |
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I'd like to share part 3 of my software development journey with you. Agile Theater: Alive And WellWhat my consulting experience had shown me so far, was that many companies still struggle to do agile development. They use some of the technologies and processes, but they have a difficult time transforming the minds of leadership and key players to support true agility. First Startup: Social Network / Time Tracking For Home SchoolersI got the idea for and began building a social network for home schoolers about 6 years ago. The product was built in ruby on rails for speed to market, and being a Father of 3 home schooled children myself, my wife and I knew some of what we thought others would want. Unfortunately, I fell into the classic "Subject Matter Expert" trap! I had a "knowing / doing gap" where I could help OTHERS do lean software development, but when it came to MY ideas, I was just as stubborn! In the end I stopped working on the product as I had built too many things that were not useful to my customer, and market analysis had me wanting to pursue a different market. Becoming (Unwillingly) A FirefighterAround this time my day job in consulting began sending me in to help fix issues at projects with our clients that were in trouble. I got good at this, but it began to burn me out as I started seeing the same quality issues from both our consultancy and the client. The root problem was that the way we engaged with our clients did not embrace agility, and so when things changed or we learned we'd failed in some way, it was costly and slow to adapt. Resistance To The Shift Towards LeanI began to put together a set of content and team that would have the skills at my consultancy to start delivering in a more lean fashion, but the leadership did not yet have the courage to support me even after numerous presentations, discussions, and wins. By the time they began to invest, it was too late – our competition had a several year lead on us. Second Startup: Public Health Data AnalysisA friend of mine whom I'd worked with for many years brought an idea to me for a product and was gracious enough to ask me to be involved. There were a number of problems as we began building the company though. First, we both had day jobs and children, and the personal investment was too high to be sustainable for our initial offering. Second, we weren't clear on our lines of responsibility and so our relationship was taxed. Third, the technology landscape around the "big data" tools we were using were too immature, and there was too much rework we needed to do to deliver the minimum viable product (MVP). Lastly, we failed to deliver small enough ideas before getting feedback, and fell again into the "Subject Matter Expert" trap by overbuilding. A Burning Desire To Be LeanI finally read The Lean Startup by Eric Ries and it opened my eyes to some of the things I had been doing wrong. As I began trying to apply these techniques with clients, I came up against confusion created by vendors in the industry who focus on technology that is "lean" or "agile" but don't help companies truly adopt the lean mindset. Battling this became the current focus of my career. Using Small Batches To Improve Product ManagementI wanted to help the people driving the direction of the product to learn whether they failed or not with less investment, and faster, so they wouldn't make the same mistakes I did. To do this however requires creating the psychological safety necessary for failure and learning. And to get support for transforming the culture to support this safety, consulting skills are necessary. Supporting Your Lean TransformationEventually, I started a membership program to help mentor software professionals to get the support for consulting and lean skills necessary to help them transform their company's culture, or use lean techniques for their own startup ideas. I am focused on helping people use the scientific method, as described in the Lean startup; relationship skills and personal development to become a better communicator and persuader; and Continuous Delivery technologies such as the cloud and automation technologies – all in an effort to be more successful. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||
| My Software Development Journey (Part 2) | 24 Aug 2017 | 00:25:19 | |
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I'd like to share part 2 of my software development journey with you. Letting Go Of "My Baby"After my first project that was both a product I designed and an opportunity to lead, I was given the opportunity to start a new one. It was difficult to let go of the success I'd had, and hard work I'd done, of this first project so early in my career. Release Deadline Sabotage!Soon the head of the company mandated that all products across the company release on the same day every 6 months. He had no idea what this took, but at the end of the day my team's project was the only one ready. For political reasons, it was sabotaged by changing the name the last week of the deadline! Following The Leader To New OpportunitiesAfter our project was sabotaged, my boss was unfortunately fired and took the fall, and he moved on to a new company where I followed shortly thereafter. This new company was in the pharmaceutical space and needed the kind of help my old team at the prior company could provide, so many of us switched over. Pioneering AgileWe built a simple web portal that let us track our sprints and other artifacts related to agile. This was before tools like JIRA, Pivotal Tracker, or Team Foundation Server were available. It was crude, but we learned a lot and through our mistakes and successes became very early proponents of Scrum. Family Conflicts Of InterestUnfortunately there was a miscommunication between my boss and his, and my boss took the fall AGAIN due to company politics wrapped up in family ownership. I was extremely frustrated at this point after seeing my boss, who I considered one of the best leaders I'd worked with, continuing to be sideswiped by politics. My First Architecture Consulting ExperienceI followed my boss again to his next company, and got a chance to provide architecture consulting services. We helped them ship a late product, and created a prototype of a new one in ruby on rails over that year. Moving To Austin, TexasEventually my Wife and I wanted a change, so we moved to Austin, Texas. The lifestyle and career options were more in line with what we wanted at the time, and we're still here today as of 2017. Moving Into ConsultingShortly after arriving in Austin I was contacted about a consulting opportunity. Though it was a little less than I wanted compensation wise, I was excited about the chance to learn a different way of providing IT services and took the offer. Getting An Ego Check-UpI frustrated several clients in the first 2 years I was a consultant, and had a reality check. During my performance review I was criticized (rightfully so) for my inability to talk and relate well with clients. Setting The Intention To Improve My Soft SkillsAfter the deflating performance review, I emboldened myself to learn what I needed to "get" this consulting thing. I came across the book Flawless Consulting by Peter Block after my wife purchased it to help her with Nutritional Health Coaching. Learning To Be A Trusted AdvisorThe first time I applied the info in Flawless Consulting was a game changer. I could win the trust and advisor status with a client almost immediately through these strategies! Discovering Continuous DeliveryWhile working for a large international grocer based in Austin, I read the book on Continuous Delivery by Jez Humble. This had a huge impact on me and caused me to focus my career almost solely on mastering it. Teaching Clients About Continuous DeliveryAfter creating a framework in Windows PowerShell that helped me implement Continuous Delivery at clients, I began to be frustrated that though we helped them release multiple times per day, their planning and budgeting process still didn't allow them to BENEFIT from this new capability. Discovering Lean Startup Product ManagementThis led me to learn more about Eric Ries, and eventually read his famous book The Lean Startup. I'll talk in Part 3 about how I discovered how important this information was through 2 startups I failed to find market fit for. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||
| How To ACTUALLY Get Your Boss To Listen | 11 Sep 2024 | 00:18:52 | |
If you've ever been on a software project and you can't get your boss to listen, I've been there. Many of us are technical types, so we often think facts are enough to convince management to support us. In this episode, I share 4 strategies I've used to actually get your boss to listen. These take some patience, but if you want to see real results - they do work. No matter what tech job you work on, you'll eventually run into problems that can only be solved if you can win support from management. If you practice these strategies, they can unlock new opportunities in your career that few other professionals in IT ever get to experience. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction Visit me at thrivingtechnologist.com | |||
| My Software Development Journey (Part 1) | 23 Aug 2017 | 00:28:00 | |
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I'd like to share part 1 of my software development journey with you. Lead-up To My First Development PositionThough I'd learned some BASIC programming on "old school" Apple computers in middle school, when I attended college to become a "Microcomputer Specialist" *cringe*, I didn't know exactly what I wanted to do in technology. One of my first teachers had me do some web development side work in college, and soon my Mother met someone at her church that would give me my first job. I came into the organization with no idea of what to expect but excited to do front end testing of software components using Visual Basic at the time. This was my first professional IT experience. Finding My First MentorsI explicitly sought out older, disgruntled software professionals at my company and asked for them to teach me. It gave them something to be excited about (teaching others), and I learned tons! It's easy to be a skeptic today with all the information previously hidden from the public that's come out in the past decade or so online. Though we've all become more distrustful of the government, corporations, and the news – we should be careful not to let opportunities to learn from other individuals pass us by. One of the biggest mistakes I've made in my career is trying to "shortcut" learning by asking mentors to only describe things I "don't know". Often the most revolutionary insights I learned from others were about what I already considered myself an "expert" on. Envisioning And Prototyping A New ProductA little over a year into my first position, my wife was pregnant with my second son who would go to bed at 7 PM. I was around 21 at the time, so I didn't feel right going out and partying while she was at home. So I would stay home and read books about the latest new technologies. Eventually I created a prototype of a new product that simplified 5 existing products we had acquired from other companies to simplify the user experience. My boss showed it to the CEO and within a short time I was the technical lead (Application Architect) over a team of 12 people. Inventing an XML Message Protocol For ManufacturingAt the time, web applications were written about but hardly anyone was doing them. SOAP and REST were not out yet, but I recognized that the application needed to use a messaging protocol to talk to applications and manufacturing devices. XML was popular at the time, so I invented and patented a messaging protocol allowing this to happen. Getting Executive SponsorshipSomehow my boss showed a prototype of what I was working on in my spare time to the VP (who would eventually become the CEO). He recognized it as "the most strategically important project in our portfolio" and asked us to pick 12 people from anywhere across the company to build a project team. On the surface, it was an amazing opportunity – new technology, a new product, a new team, full sponsorship. What could possibly go wrong? 🙃 Recognizing My Limited Understanding Of Development ProcessAt the time, there was no agile manifesto, and many companies did "waterfall" but didn't call it that. I realized quickly that I was unprepared for all of the process nuances related to successfully leading the team. I was good at producing artifacts, but I was horrible at estimating being both new, and working on new technology. Luckily, the company was aware of the need to relax predictability to innovate and take risks so they could grow. Recognizing My Lack of Relationship Management SkillsI was leading many people who didn't know me very well and were 10-20 years older than me. I didn't understand how to setup our relationship with respect for them so we could work together well. Half of my team was inspired by me and loved my passion and ability with the technologies. The other half couldn't stand me and soon conspired to get rid of me. This was all due to my inexperience with company politics, knowing how to treat people, and relationship management in general. The IT Industry Needs To Focus More On PeopleOur industry is driven by gadgets, tech, and whatever helps engineers be intellectually stimulated. But understanding people, how to get consensus, and how to win trust from others is JUST AS important if not more so to your career. My first job was a great example of how not having these skills led to a lot of friction with my colleagues. I Hope This Channel Helps You Be Less AnxiousI've made a lot of stupid mistakes in my career when I let fear and anxiety get the better of me. As this channel's videos progress, I hope hearing more of the story of my career, and the tools I've used more recently, will help you have less anxiety as your career moves forward. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How Failure Produces BETTER Software Projects | 16 Aug 2017 | 00:35:48 | |
Do your projects move forward with many assumptions that turn out to not be true as things progress? Today I'd like to share how learning of a team failure produces better software when you plan to exploit this ability. The overall assumption that most projects operate under is that the project will be successful. However there are several smaller assumptions upon which this one is built. Often these smaller assumptions need to be verified to make decisions that keep the overall state of progress moving in a sustainable direction for the product. Assumptions About The Skill Of The TeamIf the team isn't as skilled as assumed, projects will take significantly longer and more brittle to change. Assumptions About The Quality Of The ReleaseIf the team hasn't put the appropriate quality checks in place, changes assumed to have a certain level of quality that don't cause rework. Assumptions About Full Understanding Of ScopeIf the team is assuming requirements are complete, they look at scope change as failure. Assumptions About Value Of Features & ChangesIf the team is assuming changes being released are valuable to customers, but there aren't measurable ways to know whether that's true, waste could be being released. Doing Less At One Time Is THE KEY To Learning Through FailureOverall, the key to learning that we've "failed" in some way and need to adjust direction based on what we've learned FASTER is to do less at one time! Doing Less Between Releases Minimizes RiskIf we make a mistake to a small change, the impact of that change should be smaller than releasing a large change. This minimizes the impact of rework or breakages. Doing Less Between Releases Motivates RealignmentIf a team iterates on a backlog that hasn't been significantly changed since the project starts; the business has low motivation to realign. If a team is taking action on the feedback of rapid releases, the business must be more responsive. Doing Less Between Releases Improves ROIFor every day that development continues without a release, there's no return on investment. By releasing more frequently, the team has the opportunity to provide value to the customer with less capital. Doing Less Between Releases Improves SkillIf we do a production release every 6 months, how good are people going to be at it? Doing less between releases forces the entire team to practice release practices more often. This results in a team with higher delivery skill. Fail Faster By Having Artifacts That Provide FeedbackHaving tools and processes that give us the state of a change at any time lets people know a failure to some process has occurred early. This enables people to take action on issues as they emerge and catch them before the change makes it out to customers. Fail Faster By Using Cross Functional TeamsThe lag time that occurs between separate departments for disciplines needing something and sub-contracting "as a service" causes releases to take longer. If we want to fail faster, we need to have all the people needed to release the product dedicated to it and working together so there is no lag time to service outside of the immediate group. Fail Faster By Holding RetrospectivesHave a meeting to talk about what went well and what didn't over the past release (Scrum) or several releases (Kanban). This is an easy way to learn earlier that the team is failing to follow processes that are working for the project. Fail Faster By Releasing To A Limited AudienceRather than learning that there's an issue with a release from a large number of voices from your customer base, have a system in place to release to only a small subset of total customers. This is known as ring releasing or canary releasing. Fail Faster By Having a Measurable Pass/FailMany projects release a large number of features. If some KPI changes positively, it is difficult then to know which of those features or changes caused the positive change. Use A/B testing to verify that investments actually impacted a KPI. Fail Faster By Focusing On Valuable OutcomesMost projects have a large number of features. Rather than keeping everyone busy "burning down" a large list, figure out how much money the business is losing by NOT having each story (cost of delay). Work on the highest cost of delay ideas with FOCUS since those are the most economically viable! Fail Faster With Justin-In-Time ScopingIf a team does detailed requirements on a large quantity of work, it creates psychological attachment and wastes money. Teams should instead only get the details of the top items on the list periodically. Fail Faster With Monthly BudgetingIf we assume that we'll learn we need to change what's built every release, we need to re-budget every release with project % complete accounting. Rather, budget monthly to provide the capital needed to take action on changes to customer needs with less pain. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com | |||
| How UNCERTAINTY Impacts Software Development Processes! | 08 Aug 2017 | 00:45:50 | |
Does it ever seem strange how when talking to other software developers they insist that the processes they use are "the best" but they don't seem to make any sense as to how they could work in your company? Today I'd like to share how uncertainty impacts software development. Whether they realize it or not, many people in companies select processes based on their tolerance for uncertainty. The experience they've had developing software in the past, and existing beliefs they have about how the rest of the business and the customer will use the product influence decisions. Changing Market, Customer Needs, and Technologies Require More Adaptability TodayTechnology changes faster today than it did 20 years ago, so being able to respond to change is more important. We need to be careful of fortune telling, and that we aren't over-confident in our ability to see what's coming. When we use agile processes for software development, one of the big benefits is that they help us adapt to changes in the market and optimize for handling disruption. How Responsive Is Your Company Willing To Be?The big question is – how responsive is your company or team willing to be? The more uncertainty people at the company can tolerate, the more adaptable and responsive you'll be in serving your customer. There are a wide number of decisions that can be made about how you develop software that stem from the tolerance for uncertainty, but in this video I'll talk about some major attributes of the two extremes. Uncertainty Of Scope and BudgetA company or team with a lower tolerance for uncertainty may use % complete budgeting to track progress on the project. A team with a higher tolerance for uncertainty may set a monthly budget to allow the customer to influence what's delivered more. Uncertainty Of Cost and Measuring ProgressA company or team with a lower tolerance for uncertainty may focus on cost and estimation. A team with a higher tolerance for uncertainty may track learning milestones to measure progress. Uncertainty Of State Of The CodeA company or team with a lower tolerance for uncertainty may create source control branches for developer changes. A team with a higher tolerance for uncertainty may use feature hiding instead, with everyone collaborating on one branch to follow continuous integration. Uncertainty Of Customer Needs and User ExperienceA company or team with a lower tolerance for uncertainty may make more investments in the UX up front. A team with a higher tolerance for uncertainty may use lean UX practices that provide a minimum viable experience, and adapt as they go. Uncertainty Of Software ArchitectureA company or team with a lower tolerance for uncertainty may make more up-front architecture decisions. A team with a higher tolerance for uncertainty may simplify the architecture to increase the speed of refactoring, and let the architecture evolve with product growth. Join my Patreon: Learn about one-on-one career coaching with me: TechRolepedia, a wiki about the top 25 roles in tech: The Thriving Technologist career guide: You can also watch this episode on YouTube. Related resources: Visit me at thrivingtechnologist.com | |||