If you're a programmer tired of the corporate grind, and thinking about starting a software company - watch out. I tried this twice and failed, but the third time went much better. Here are some practical tips to avoid pitfalls as a software engineer if you want to start a software company - and be successful! Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (1:05) 8 Mistakes Programmers Make Starting Companies (1:19) 1. Picking a Product That's Fun To Build (3:54) 2. Choosing a Viral Business Model (6:26) 3. Overengineering (9:00) 4. Having a Fixed Mindset (12:59) 5. Spend Too Much Time Building The Product (15:14) 6. Poor Financial Management (18:27) 7. Failing To Build Networks of Help (21:18) 8. Low Self-Confidence Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

The software industry may be messed up, but I need to be straight with you. You're resisting help! If you really want your job and life to get better, and to achieve better things in your software career - the complaining needs to stop. You need to stop resisting the things you already know you should do - and DO them. You can't solve all these problems alone! In this episode, I'm going to share some harsh truths with you about your responsibility for why your career may suck. I don't share these to criticize you, but to help you confront the seriousness of your situation - and show you how you are truly more empowered to change it than you may realize. Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (4:55) 5 Ways We Stay Miserable  (6:34) 1 Tribalism (10:22) 2 Avoiding Responsibility (13:17) 3 Giving In To Fear (18:08) 4 Escapism (21:21) 5 Pride Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

If you're about to get a new tech job, sometimes the red flags are obvious. But what happens when you want the gig anyway? The temptation to take a job when the pay is high, there's prestige, or it's a promotion are strong. In this episode I share some things I've learned about spotting these red flags, and resisting the temptations that come with the allure of tech company offers. I hope they help you take a more healthy job, and not get sucked into working for a company that drains your soul. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (1:16) A Story of Deceit (6:32) 1. Red Flags of a Toxic Tech Company (6:52) 1.1 Vague Answers About Work/Life Balance (8:18) 1.2 Long Hours Are a Bade of Honor (10:02) 1.3 Suspiciously High Salary of Title  (11:34) 2. Why Do We Ignore Red Flags? (11:40) 2.1 Justifying Stress With Money (13:27) 2.2 "It's a Stepping Stone" (15:54) 2.3 Need to "Prove Our Worth" (18:03) 3. How Can You Overcome The Temptation? (18:12) 3.1 Make a Relational Impact List (20:13) 3.2 Ask Brave Questions (22:51) 3.3 Avoid Companies That Resist Transparency (24:22) 3.4 Listen to Your Gut! (26:20) 3.5 Write a Catastrophic Story (28:31) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

If you're tired to the deadlines, pressure, and unrealistic expectations - it may be time to take programming for money into your own hands. In this episode, I share 3 ways you can escape the corporate grind and make money in tech yourself. Being a solopreneur isn't easy, but it's very rewarding if you're willing to learn things like digital marketing. I weigh 5 aspects of considering being a solo IT consultant, starting a solo software product company, or selling what you know about technology through online courses in this episode. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:34) 1. 3 Ways To Escape The Corporate Grind (0:48) 1.1 Solo Consulting / Freelancing (3:23) 1.2 Build a Software Product (5:49) 1.3 Sell Education Online (10:01) 2. 5 Aspects of Each Method of Escape  (10:12) 2.1 Effort vs. Income (15:20) 2.2 Marketing Effort (21:42) 2.3 Dependence on Others (27:19) 2.4 Transition Cost (34:53) 2.5 Learning Required Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Programming starts out like any other career - then one day you wake up addicted. In this episode, I share big problems with programming's impact on your work/life balance, and offer solutions. As a software developer, it's easy to get caught up in the endless cycle of coding and problem-solving, often at the expense of personal time and well-being. I discuss how this imbalance can affect your life and provide insights on how to manage it effectively. I also share some personal experiences and tips on maintaining a healthy balance between your programming career and your personal life. The video is not just about coding; it's about living a fulfilling life while pursuing your passion for programming. Remember, programming is an exciting and rewarding career, but it's important to balance it with other aspects of your life. Don't forget to like, share, and subscribe for more content on navigating the challenges of a software development career. Your support means a lot!  Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (01:45) 1 Signs Programming Is Taking Over Your Life (02:07) 1.1 Only Digital Free Time (03:42) 1.2 Stimulate and Chill Cycle (06:12) 1.3 No Quality Time with Friends or Family (07:58) 1.4 No Non-Technical Hobbies (10:50) 1.5 Living Paycheck to Paycheck (12:52) 2 Life Changes To Get Time Back from Programming (12:59) 2.1 Divorce Yourself from Software Industry Values (15:52) 2.2 Schedule Social Activity After Work (18:43) 2.3 Get Control Over Your Finances (21:56) 2.4 Explore Other Tech Job Roles (24:50) 2.5 Have a Career Exit Plan (29:10) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Feeling swamped in your tech job? You're not alone! In this episode, I dive into the heart of what makes our programming world so overwhelming and, more importantly, how you can navigate it with ease. In this episode, I'm not just talking at you; I'm talking with you. We'll explore the common pitfalls that lead to feeling overwhelmed in tech jobs and share practical, actionable strategies to help you manage your workload and stress levels. Whether you're a seasoned programmer or just starting out, this video is packed with insights tailored just for you. Programming can be a rollercoaster of challenges and triumphs, and it's totally normal to feel overwhelmed at times. But don't worry, I've got your back! We'll look at how to prioritize tasks, set realistic goals, and create a work environment that supports your well-being and productivity. Remember, being overwhelmed doesn't mean you're failing – it's a sign that you're pushing your boundaries and growing. So, let's turn that overwhelm into empowerment together! Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (01:41) How To Stop Being Overwhelmed By Your Tech Job  (02:31) 1.1 Relentless Pace of Projects (03:17) 1.2 Pressure To Continuously Learn (04:32) 1.3 Glorification of Hustle Culture (05:47) 2 Signs of Being Overwhelmed (06:01) 2.1 Constant Fatigue / Lack of Motivation (08:36) 2.2 Brain Fog (09:41) 2.3 Feeling Inadequate Despite Achievements (10:36) 2.4 Anger at Requests for Help (12:13) 2.5 "Too Busy" for Social Activities (13:08) 3 How To Reduce Overwhelm (13:21) 3.1 Prioritize Your Tasks (15:38) 3.2 Learn To Say No (17:20) 3.3 Practice Mindfulness or Prayer (19:34) 3.4 Exercise and Get More Sleep (21:51) 3.5 Social Media Fast Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Let's get real about AI and how it impacts programming. There's a lot of propaganda and fear being thrown around related to artificial intelligence (especially in software development and engineering) - so let's cut through the noise together. I made this video for all you software developers, engineers, and programmers out there who want to get a real perspective on AI's role in our field. Whether you're deep into your software career or just starting out, I've got some insights that you'll find valuable. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:00) Introduction  (4:01) 1. Who Stands To Gain From AI Hype? (4:10) 1.1 The Media (5:08) 1.2 Employers (6:04) 1.3 Startups (7:27) 1.4 Tech Training Companies (8:24) 2 A Rational AI Approach for Programmers (8:30) 2.1 Become an AI Generalist (10:00) 2.2 Spot The Sensationalism (11:52) 2.3 You Are The Compiler (14:38) 2.4 Use AI To Diversify Your Skills (18:11) 2.5 Build a Non-Technical Industry Product (20:22) 2.6 Teach Non-Technical Companies AI Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

If you've been programming for a while and it doesn't seem as fun as it used to be, maybe it's time to take a step back and look at why. In this episode I'd like to help you figure out what the the root cause of your frustration with coding might be. It's only natural that if you started off writing code and eventually got good at it, you'd come to the conclusion that programming is the best tech job for you. But there could be a better fit, or you may need to double down on persuasion and some other skills than just writing code. When you're on too complicated of a tech stack, you haven't learned important soft skills like persuasion, and you make work your life - it's pretty likely that coding is going to start to suck. The good news is, you don't have to stay that way! By identifying which of these reasons for why you're not having as much fun programming apply to you, it's possible to start taking action today to get your tech career back on track. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:   https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:00) Introduction (0:40) Why Isn't Programming Fun Anymore? (0:56) 1. You're Not Challenged (2:16) 2. Programming Not Biggest Talent (4:23) 3. Your Industry Is Boring  (5:26) 4. Tech Stack Too Complicated (6:28) 5. You're Not Learning To Influence (8:09) 6. Your Job Is Toxic (9:30) 7. Work Is Your Life (11:18) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

How does being a software architect differ from a typical programmer? In this episode, I share the 10 aspects I've approached software architecture from that I learned over 20 years of doing it. I was promoted to be a software architect at just 20 years old, and while I was qualified with some aspects of software engineering - I didn't really know what I was getting myself into. Being a great software architect takes a variety of skills that a typical software developer will also benefit from, but are actually essential to software architecture. Yes, using coding patterns, knowing how to interview as a software architect, and making technology selections are required. But there are also other things that if you don't focus on, can hamper your ability to pursue a software architect role either at your current job, or the next one. I hope this episode helps you understand that while there is some overlap between a software architect and a programmer, the less "fun" aspects of the job are actually essential to being a really great one. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks: (0:00) Introduction (0:51) 10 Aspects of Being a Software Architect (1:03) 1. Zoom In / Zoom Out (2:17) 2. Domain Sensitive (3:07) 3. Understand Tradeoffs (4:02) 4. Selfless Decision Maker (5:02) 5. Embrace Change (5:44) 6. Communicative Mastery (6:26) 7. Infrastructure Aware (7:40) 8. Strategic Coder (8:50) 9. Consider Scale (10:28) 10. Cost Sensitive (11:49) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

One of the biggest challenges for all software developers in 2023 (and leading into 2024) - is simplifying their tech stack so work can get done. The continued explosion of boutique frameworks and libraries is making it harder than ever to manage complexity as the stack of tools and technologies we use on our projects grows. Whether you're a software architect, senior engineer or developer, or any other role that encounters tools and technologies on a software project - the decisions we make about what frameworks, APIs, libraries, and other pieces of technology to use on a software project impact us all. In this episode, I'd like to help you simplify your tech stack by sharing some of the things I've learned as a software architect about making informed and reasoned decisions about tech stack choices. I hope it helps you avoid some of the typical pitfalls we programmers can fall into when we select tools and technologies as soon as we find them - instead of stepping back and finding out if they're really high value enough to the team to adopt using them. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks:  (0:00) Introduction (1:07) 1 THE DANGERS OF TECH STACK COMPLEXITY (1:12) 1.1 Tool Overload (1:40) 1.2 Decision Fatigue (2:03) 1.3 Integration Challenges (2:34) 1.4 Cost Implications (3:26) 1.5 Diluted Focus (3:44) 2 SIMPLIFYING YOUR TECH STACK (3:52) 2.1 Prioritize Value (6:35) 2.2 Embrace Versatile Tools (7:39) 2.3 Standardize and Document (8:50) 2.4 Seek Community Input (10:01) 2.5 Regular Review and Upgrading (11:33) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Instatechcoach is a livestream I'm doing on Instagram where I offer short, free career coaching for software professionals every Saturday at 1PM Central Standard Time.  You'll hear me discussing the career challenges of other developers, and answering questions about my own career, as well as The Healthy Software Developer show.  Follow me on instagram as jayme.c.edwards

Burnout is one of the most common dangers to programmers over their career, and I was no exception. Software development and programming can make it difficult to find a healthy balance between work and life. My burnout was a combination of self-inflicted bad decisions, things done to me, and circumstances in my personal life.  In this episode, I share the story of my own burnout and how I lost nearly everything. Through it all, I found what really matters in life - and work became a smaller part of it. I hope this episode encourages you to share your own struggles to get help. Maybe some of the things I learned after going through burnout can also encourage you to keep going. My wife Angie's podcast, "A past, repainted" is here:  https://apastrepainted.com/content/podcast/ Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/ Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/ Need help with your career? Learn about career coaching:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks:  (0:00) Introduction  (0:59) 1 SELF-INFLICTED BURNOUT CAUSES  (1:05) 1.1 People Pleasing  (1:41) 1.2 Overextending at Work  (2:03) 1.3 Side Gigs  (2:15) 1.4 High Expenses  (2:51) 1.5 Drug Addiction  (3:18) 1.6 Guilt and Shame  (3:59) 2 OTHER-INFLICTED BURNOUT CAUSES  (4:16) 2.1 Political Lies and Manipulation at Work (5:31) 2.2 Recurring Project Firefighting (6:42) 2.3 Betrayed by a Coworker (8:04) 3 CIRCUMSTANTIAL BURNOUT CAUSES (8:34) 3.1 My Child Struggled With Dangerous Addiction  (10:07) 3.2 My Father Died At a Young Age (10:45) 3.3 9/11 Work Culture Changes (12:04) 3.4 My Wife's Abuse  (13:36) 4 BURNOUT TRIGGERS (13:42) 4.1 Startup Partner Exited (14:27) 4.2 Marriage Became Distant (15:13) 4.3 Recurring Relapse of My Child (15:54) 4.4 Company Bought Out  (17:04) 5 MY BURNOUT SYMPTOMS (17:12) 5.1 Chronic Insomnia (19:03) 5.2 Uncontrollable Anger (19:47) 5.3 Forced to Resign (20:25) 5.4 Spent Emergency Savings (21:29) 5.5 Spent Remaining Cash (21:49) 5.6 Sold All My Stocks (22:09) 5.7 Fell Behind on Mortgage (22:54) 6 STRUGGLING THROUGH RECOVERY (23:05) 6.1 Tried Quitting Development (23:33) 6.2 My Wife and I Found God (26:11) 6.3 My Addicted Child Moved Out (27:03) 6.4 I Started on YouTube (28:32) 6.5 I Started Career Coaching (30:43) 6.6 My Sleep Improved (32:01) 7 HOW BURNOUT CHANGED ME (32:11) 7.1 Recovery is Daily (32:31) 7.2 Confronted My Addiction (33:09) 7.3 Became Aware of My Limits (34:01) 7.4 Embraced My Suffering (34:24) 7.5 Motivated By Change (36:50) 7.6 I Began Tithing (39:03) 7.7 Learning To Live Sober (40:13) 7.7 Focus on The Positive (41:09) 7.8 Reject Being Defined By Work (43:56) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Trusting people is getting tougher than ever these days, and nobody seems to have a harder time than programmers and managers. In this episode, I'll teach you how to get some hard evidence to determine whether your manager is trustworthy or not. The goal is for you to find out YES and just have a healthy relationship with your manager. But if there are trust issues, you'll have some tough decisions to make about your software development career. This episode can help anyone who has a boss on a software project (programmer, QA, DevOps, etc.), but since there are some unique ways programmers can have their trust broken by managers - I'll focus on that. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/  Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/  Need help with your career? Book a free career consultation:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks:  (0:00) Introduction (2:36) 1 WHY DON'T PROGRAMMERS TRUST MANAGERS? (2:48) 1.1 Manager Can't Do What Programmers Can (4:17) 1.2 Limited Visibility in Command and Control (6:35) 1.3 Hearsay (8:05) 1.4 Power Dynamics of Reporting to Someone  (9:43) 2 WHY DON'T MANAGERS TRUST PROGRAMMERS? (9:55) 2.1 Can't Comprehend All of Their Work (11:01) 2.2 Past Bad Experiences (12:26) 2.3 Remote Visibility Problems (13:36) 2.4 Assumptions of Immaturity (15:30) 2.5 Anxiety Due to High Cost (17:26) 3 HOW TO LEARN IF YOUR MANAGER IS TRUSTWORTHY (17:41) 3.1 Micro-Commitments (19:49) 3.2 Corroborate With Coworkers (22:14) 3.3 Corroborate With "Skip Level" Boss (24:55) 3.4 Set and Track Measurable Objectives (27:48) Episode Groove Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

Just the name Tech Lead has this kind of prestigious ring to it, and if you're like most programmers you might think it's the job to shoot for. But 20 years of my career have been spent leading software teams, and you might be surprised to know that tech lead is actually the worst job for most programmers! Some of the information in this episode applies to IT professionals in any technical leadership role: whether that be leading programmers, UX, DevOps, QA - or any other discipline related to software development. But several of the points are more specific to programming leadership. Get free access to TechRolepedia here:  https://jaymeedwards.com/access-techrolepedia/  Download my free Career Guide here:  https://jaymeedwards.com/developer-career-guide/  Need help with your career? Book a free career consultation:  https://jaymeedwards.com/services/software-development-coaching/ You can also watch this episode on YouTube.  Chapter markers / timelinks:  (0:00) Introduction  (1:20) 1 TECH LEAD MYTHS  (1:29) 1.1 Smartest Team Member  (2:11) 1.2 Writes The Best Code  (2:59) 1.3 Chooses Key Technologies  (3:45) 1.4 Most Highly Compensated  (4:12) 1.5 Motivates Through High Standards  (5:19) 2 WHAT SHOULD A TECH LEAD DO?  (5:22) 2.1 Improve Team Effectiveness  (6:35) 2.2 Defend Team Members  (7:52) 2.3 Congratulate Team Publicly  (9:00) 2.4 Getting Team Consensus  (10:19) 2.5 Help When Things Get Hard  (12:57) 3 HOW BAD TECH LEADS GET PROMOTED  (13:28) 3.1 Strong Individual Contributor  (14:13) 3.2 Company Promotes Out Of Fear  (15:01) 3.3 Management Misunderstands Role  (15:25) 3.4 No Desire To Lead  (16:15) 4 BECOMING A TECH LEAD  (16:34) 4.1 Practice Defending Your Team  (18:19) 4.2 Practice Congratulating Team  (19:30) 4.3 Read Books on Leadership  (20:46) 4.4 Work Closely With Others  (21:52) 4.5 Learn More About the Business  (23:28) Episode Groove  Visit me at JaymeEdwards.com Find me on X as @jaymeedwards Find me on Instagram as jayme.c.edwards

As programmers, we often follow practices because of hidden desires - and "self-documenting code" is chief among them. In this episode I'd like to share some of the tradeoffs and implications of choosing to add comments to your code or not, to help you make the best decision for your software development career. When I first started developing software 25 years ago, the company I worked at mostly used C++ with a little Visual Basic and Java. At that time, all the other software engineers I worked with added comments to their code. And at the next two software product companies I worked for, programmers also chose to add source code comments as a regular practice. But once I moved to Austin, Texas 15 years ago and got my first job as an IT consultant I noticed something interesting. None of the other programmers on my team added ANY comments to their code! When I asked them about this, they would often say "the client is paying for features, not comments". I didn't find this a very acceptable reason for not adding comments to code, but I did my best to play along. Around this time the popular programming practice of "self-documenting code" first showed up on my radar. The idea being if we write our code with a clear enough intent, but using business terms and clean designs for the software we write, comments are unnecessary. But upon closer inspection I found this to be (in my opinion) wishful thinking rooted in laziness, upon a host of other factors. I hope this episode helps you make an informed decision about whether the benefits of code comments are worth writing them, or whether you should continue to practice self-documenting code as a principle. I believe we can have the best of both worlds: well-written code that reflects the business domain and is simpler to read, but with accompanying comments to reduce the time it takes for our software development team to use the APIs, helper classes, and other functionality our code and libraries provide. You can also watch this episode on YouTube.  Chapter markers / timelinks:  02:50 Why Practice "Self-Documenting" Code? 02:56 #1 Laziness 04:43 #2 Reduce Visual Clutter 05:43 #3 Refactoring Burden 06:39 #4 Overconfidence in Simplicity 07:56 6 Benefits to Commenting 08:03 #1 Reduce Comprehension Effort 08:50 #2 Accelerate Business Understanding 09:50 #3 Use Comment Features in Editor 11:03 #4 Surface Code Behavior 12:07 #5 Additional Documentation Opportunities 12:48 #6 Treat Code Like a Product 13:51 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Ever wanted to do something new, or make a change on your software project - but other people on your team won't support you? Maybe you want to move from scrum to kanban, use a newer JavaScript framework like remix, or if you're a UX designer introduce something like customer journey maps.  It would be nice to always have support from other people, but if you've never had pushback for one of your ideas, it's a matter of WHEN - not IF. So at some point, unless you want to quit your job every time you need a change to keep delivering great software, you'll need to persuade other people on your software team, or in management - to support you.  In this episode I'd like to share with you what I learned over 15 years of software development consulting about persuading IT management and other technologists on your software team. Persuasion is a soft skill that is more valuable than many people realize!  You can also watch this episode on YouTube.  Chapter markers / timelinks:  0:00 Introduction 1:13 10 Steps to Persuade Others 1:21 #1 Be Honest About Your Skills 1:57 #2 Have an Authentic Relationship 3:40 #3 Know How To Measure Success 4:43 #4 Identify Benefits To Others 5:44 #5 Incremental Persuasion 7:00 #6 Create Visual Aids and Assets 8:38 #7 Future-Pace The Benefits 9:53 #8 Know How They're Measured 11:08 #9 Timebox The Response for Support 12:29 #10 Practice Persuasion 13:39 #11 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Many software development teams use an agile backlog but have NO business agility - and are actually using scrum with a waterfall mindset! When the product backlog is used on a scrum project and the business doesn't really understand agile, it wastes money and makes most programmers feel miserable!  In this episode, I share what I've learned about using agile methods with software teams that actually produces business agility. Business agility is the ability for a company building a software product to adapt to feedback and data gathered about how customers are using it. Since software development is such an unpredictable engineering activity, a business can choose to put their hopes in estimates, or deliver releases more often and let data be their guide.  I hope this episode helps you understand how programmers, product owners, scrum masters, and everyone else who works together to build and release software can do it in a healthy way - where less stress is placed on everyone trying to predict the future through estimates. Instead, we can use the insights gathered through feedback and recording data in production about how customers are using the software to product the RIGHT features - and at a sustainable pace!  You can also watch this episode on YouTube.  Chapter markers / timelinks:  0:00 Introduction 0:57 The Purpose of a Backlog 1:19 7 Waterfall Backlog Signs 1:28 #1 No Feature Usage Metrics 2:09 #2 No Release After Sprint 2:55 #3 Backlog Never Reordered 3:37 #4 Features Never Removed 4:19 #5 No New Features 4:54 #6 Estimates For All Stories 5:35 #7 Measuring Output Not Outcomes 6:32 7 Ways To Get Backlog Agility 6:53 #1 Measure Feature Impact 7:51 #2 Release Every Sprint 8:51 #3 Don't Build Onto Features 10:08 #4 Use Data To Reprioritize 10:42 #5 Remove Bad Features 11:28 #6 Commit To Outcomes 12:40 #7 Use Cross-Functional Teams 15:25 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer?  In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers.  There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates.  You can also watch this episode on YouTube.  Chapter markers / timelinks:  0:00 Introduction 1:19 Why Programming Is Unreliable 1:26 #1 Not Repeatable 2:06 #2 Too Many Variables 2:50 #3 Surface Understanding 4:06 #4 Unique Integration 4:59 #5 Low Diagnostic Output 6:08 #6 Knowledge Work Mismatch 7:19 #7 Undervalued Teamwork 8:20 Reduce Impact of Bad Estimates 8:42 #1 Reduce Estimated Work 10:06 #2 Keep Estimates With Estimators 11:26 #3 Estimate In Components 12:50 #4 Choose Familiar Technologies 13:56 #5 Find Native Integrations 15:04 #6 Stop Using Estimates 16:10 Episode Groove  Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Every programmer seems to want to vomit the second they hear the word scrum. What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team In this episode, I share 7 reasons why programmers hate scrum, and how it makes our jobs nearly impossible on software projects where the scrum master, product owner (or product manager), and the rest of the software company use it to abuse programmers. These mostly get down to not understanding the scrum guide, and human nature! In this first section of the video, I explain how management on scrum projects usually focus on speed and visible features to the point that it puts the quality of the product at risk. They treat story points like time. They resist investment in things like improved architecture, testing, deployment, and the other things needed to keep developers from quitting unless kept in check. And they fail to accept reality when bad user stories, missing acceptance criteria, and abuse of the burn down chart (and velocity metrics) turns scrum into a numbers game instead of about delivering a quality software product. In the second section of the video, I share 7 practical tips for changes you can make on your software team to start loving scrum again! If programmers on your team hate scrum, drawing clear lines between what software developers and project managers, product managers, product owners, or scrum masters can and can't make decisions about is essential. But as programmers, we also need to be more diligent with how we follow scrum processes. We need to closely inspect the work and only move forward with 100% acceptance criteria. We can't make commitments to vague user stories. And we have to stop estimating just for programming and include time for all the things we know we need - QA, automated testing, automated deployment, infrastructure as code, software architecture - basically all the goodies that keep a project on track as it grows in complexity. This is how modern teams do continuous delivery and devops. I hope this episode gives you some good things to think about. Scrum is a complicated topic, but following everything exactly by the scrum guide is a slippery slope. To love scrum again, programmers need to work with management and the rest of the company to adapt processes to meet the way everyone needs to work together to deliver software. And that's different for every team!  You can also watch this video on YouTube.  Chapter markers / timelinks  0:00 Introduction 0:36 7 Reasons Why Programmers Hate Scrum 0:58 #1 PO in Daily Stand-Up 1:36 #2 Overstepping Scrum Master 2:15 #3 Obsession With Features 3:38 #4 Story Points Treated As Time 4:42 #5 Refusal To Cancel Sprint 5:58 #6 No Acceptance Criteria 7:19 #7 Burn-Down Chart Used To Blame 7:54 7 Ways To Love Scrum Again 8:16 #1 Remove PO From Daily Stand-Up 9:00 #2 Put Scrum Master In Their Place 9:49 #3 Buffer Estimates For Code Quality 11:03 #4 Don't Commit To Multiple Sprints 12:04 #5 Keep The Burn-Down Chart With Developers 13:00 #6 100% Acceptance Criteria 13:52 #7 Deliver Features That Delight 15:16 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Professional habits are what makes the difference between someone who actually writes code like a senior programmer - and wishful thinking. The syntax and patterns you use on software projects don't matter nearly as much as the standards you hold yourself to for professionalism. In this episode, I share the essential habits I've developed while working on nearly software projects over my career. If you want to write code like senior programmers do, I hope these practices help you stand out from the pack. 6 HABITS FOR WRITING CODE LIKE A SENIOR PROGRAMMER The first habit is to finish the code you start! There's immense pressure on some scrum or kanban projects to show progress, but if you aren't done - don't lie about it! This only leads to more personal technical debt that you will be under more stress to finish later. If you don't want to let the code grow out of control - this is completely up to you. The second habit is to enforce coding standards. If other programmers on your team have different preferences for how they like to format curly braces, spacing, or any other aspect of your code - this makes it frustrating to share code across the project. We've got the tools to do this automatically now - use them! The third habit is to be disciplined about documenting the patterns the team has agreed to use. You absolutely must have a wiki topic or markdown file in your project that has links to how to apply every major pattern on your project. If you do this, it reduces wasted time in code reviews, and prevents people from introducing new patterns without a justifiable reason for having a discussion before it permeates throughout the codebase. The fourth habit is to review new coding patterns with your team as soon as you introduce them. Rather than replace an existing pattern all over the code base (ask for forgiveness rather than permission), do your teammates a solid and be inclusive as soon as you have something to show. They'll probably have good advice for how to improve on your use of it, and you can get their buy-in and enlist them to help you with the full refactoring effort. The fifth habit is to NEVER expose refactoring as tasks, user stories, or tickets in jira, github issues, trello, asana, visual studio online - or whatever tool your team may be using for work tracking. Whenever an essential engineering practice is called out as a separate item - it only tempts management to pull it out. And the sixth and final habit is to always assume there will be unexpected change in the project for every task you need to estimate. Whether it's unplanned software design meetings, troubleshooting, or documentation - to write code like senior programmers actually do, you can't be pressured to cut corners. While we can't predict every possible uncertainty on a software project, if you estimate like nothing will go wrong - it's your own fault. You can also watch this video on the YouTube channel. Chapter markers / timelinks 0:00 Introduction 0:25 Why senior code matters 0:30 1. Team comprehension 0:57 2. Reduce interruptions 1:28 3. Extend longevity of code 2:10 6 habits of senior programmers 2:18 1. Prevent unfinished work 3:46 2. Enforce coding standards 5:11 3. Document chosen patterns 8:01 4. Review new patterns early 9:28 5. Never expose refactoring 11:16 6. Assume unexpected change 12:40 Episode groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

I thought I knew what developers needed, but then I met over 200 people online to learn what unlocks their career. The results were surprising in some ways, and not in others. The first thing I learned was that having a plan for your career in software development is something programmers aren't getting enough help with. When I would need a new job, I often took the first reasonable offer instead of having more purpose. It seems other developers are treating their career the same way. The second thing I learned was that developers need more help getting a new job. They treat LinkedIn like an online resume when it's not. LinkedIn is a social profile for your career in software! Software engineers, programmers, data scientists, and other types of developers often have too many languages and technologies on their resume over time - and this bleeds into LinkedIn. I like to help them redo their profile to be more focused on their human side - and learn better techniques for networking to find the best job. The third thing I learned was that developers are suffering from burnout in their career in droves. I've actually had a company pay me to help their lead developer recover from burnout! Recovering from burnout is more than a better diet, exercise, or having a therapist - though people who come to me for help with burnout often already have one. You need help with setting healthy boundaries with your employer so you can be a healthy software developer! The fourth thing I learned unlocks the career of IT professionals in software development and engineering jobs is earning respect and getting recognition from their colleagues. Sometimes there's a difficult person they're dealing with who's a narcissist or just has unrealistic expectations. I use some of the techniques I've learned in IT consulting to help them appeal to the desires of the person they're frustrated with. Once they start earning trust and resetting expectations - rewards and promotions should follow! The fifth thing I learned developers really need to unlock their career is becoming more common. Most of the over 200 I met online were at least considering going into freelancing or IT consulting as a way to work for themselves. Showing developers that the paperwork and administrative tasks needed aren't as bad as they think is something I love to do. I would never go back to being an employee unless I had to at this point. I love being able to pick my own IT consulting clients. The sixth and final thing I learned developers really need in their career is to start using a new tech stack, cloud or data science platform, devops technologies, or maybe switching from a business analyst or product management gig into being a scrum master. Don't hit the books, and waste time on algorithm crunching sites like Hackerrank and Leetcode. Build confidence through having a better relationship with people who might interview you, and have great examples of work. Are there things you're struggling with in your software development career that don't fit into these 6? Leave me a comment! My career purpose is to help more people be healthy software developers. You can also watch this episode on YouTube. Episode timelinks: 0:00 Introduction  0:37 Have a Career Plan  2:09 Get a Better Job  5:31 Stop Burning Out  5:55 Earn Respect and Recognition  8:45 Work for Myself  11:17 Use New Skills or Technology Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

It's tempting to compare yourself to other developers or take skill assessments to see how you measure up, but honestly it's impossible to truly know if you're a good programmer! In this video I share what I've learned over my 25 year career as a programmer, software architect, and consultant that I hope reduces any anxiety you may have around your self worth. To start this off: why do we even care if we're good programmer? Well first of all, the people who depend on us to do a good job as a developer need to know we're competent and can get the job done. Basically our coworkers have expectations, and we want to meet them. The second main reason I see people caring how good they are, and is the bigger focus of this episode, is comparing themselves to others! With social media (especially LinkedIn) and other influential people showing off their accomplishments, we often wonder how we measure up. But that's a dangerous game. How do we try to assess how good of programmers we are? The first way is skill assessments like tests, bootcamp outcomes, certifications etc. And while these can help, I don't put much stock in them. They usually have a very focused and narrow view. The second way is looking at what we've accomplished in our career as programmers. Have we produced good output for the company? Have we been able to get features out in a reasonable time? The third way is getting feedback! While performance reviews can help, asking another developer, manager, or another trusted professional for explicit feedback is a great way to find out. There are two reasons why I don't believe we can really know how good we are. The first is that we don't have a standard definition of what makes a good programmer. There are so many skills we need! Coding, testing, DevOps, wiki topics, scrum, kanban, data science - it's crazy. And that's only the technical and process stuff. There are also all of our personality traits like openness, coachability, motivation and such. The second reason why we can't really know how good we are is based on the Dunning-Kruger effect. I left a link below where you can read more about it. But it explains what I experienced in my career. That I went through a progression of growing confidence until I realized my own incompetence, then had to build it all over again. We go through these cycles of high and low confidence uniquely for every skill we use as a programmer! So be kind to yourself. It's practically impossible to know how good you are, because we're all different, and we're all growing different skills at different times! You can also watch this episode on YouTube. Episode timelinks: 0:00 Introduction 0:35 Why Care If We're Good? 0:39 Reason #1: Confidence 0:50 Reason #2: We're Comparing Ourselves 1:17 How Do We Evaluate Skill? 1:23 Eval Approach #1: Assessments 2:15 Eval Approach #2: Accomplishments 2:48 Eval Approach #3: Feedback 3:39 Why Can't I Know??? 3:58 Reason #1: No Standard 6:10 Reason #2: Warped Self-Image 8:00 The Dunning-Kruger Effect 10:15 Having Realistic Expectations 11:20 Every Skill Grows at a Different Pace 12:52 Next Time 13:33 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

The first software project of my career was a masterclass in surviving corporate politics that I'll never forget. Programming was the least of my problems! The perfect storm of addiction, deceit, and surviving a death in the family sent me into a downward spiral on this true story of a software project. In this story, I share the personal details of how my struggles with marijuana addiction and the lies of IT leadership collided. Looking back at this software project in the context of my career, I can see how it shaped me. No programming degree or bootcamp could have prepared me for working in software development would really be like when powerful people were involved. As a result of this experience, I went through a period of not trusting anyone, and learning to be vulnerable again took decades. But it also taught me some important lessons about loyalty, perseverance, and putting work/life balance in perspective. I hope by sharing this story, I can encourage you to take some responsibility for your own actions while coding. While at the same time being alert to the evil tactics people can threaten you with when ego, power, and money are on the line. You can also watch this episode on YouTube. Episode timelinks: 0:00 Introduction  1:10 The Calm Before The Storm  2:07 A Fragmented User Experience  3:00 Boredom Births and Idea  3:50 An Unexpected Demo  5:45 Mutiny In The Ranks  6:19 The Replatform Distraction  6:55 The Mutiny Exposed  7:50 The Confusions of Addiction  8:55 Impending Family Tragedy  9:41 The Burden of Responsibility  10:31 Putting Life Before Work  11:50 Comparmentalizing Grief  13:02 Accusations of Incompetence  13:50 Investigating the Truth  14:34 Relieved - But Not Really...  15:12 Act II: The Downward Spiral  15:47 A Foreshadowing Warning  16:53 A Seemingly Standard Practice...  17:41 Signs of Sabotage  18:34 The Deception Sinks In  19:44 A Coup D`Etat  20:57 A Harsh Lesson in Project Politics  21:17 New Leadership Arrives  21:38 Unrealistic Expectations  22:33 Mission Impossible  23:45 A Last Ditch C@ckblock  24:27 An Unjust Casualty  25:16 Conclusions  27:41 Next Time  28:17 Episode Groove  Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

There are tons of people online telling you how to get a better career in software development. Unfortunately, they usually tell you a fluffy story that glosses over the truth. In this episode, I share the 4 career desires of every software developer. This is a concept I discovered through career coaching other people in tech positions (developers, product managers, DevOps, data science, etc.) over the past 3 years. An important thing to know about these desires is that they change over our lives. What I wanted from my career in my 20s, was very different in my early 30s, and then in my 40s. This isn't specific to your age per se - it's more about being aware of your changing life situation. I got myself into a lot of trouble in my software development career when I was pursuing the wrong career desires. The first desire is impact. This is the feeling that the work you do makes a difference! Not feeling like you're making an impact can be either because you aren't able to use the skills you want, or the mission of the company doesn't inspire you. The second desire is growth. This is acquiring new skills to increase your value in the marketplace and get to do more different things on the job. These don't just need to be technical skills like programming however. There are also the skills of persuasion, communication, leadership, negotiation - or anything else that makes us more effective in our software development career. The third desire is work/life balance. This is the whole reason I made the healthy software developer YouTube channel in the first place! If you're having trouble sleeping, no energy to exercise, no time for your spouse, kids, or friends, and you spend almost no time pursuing your dreams - you're burned out! I suffered from serious career burnout as I've discussed in many other videos. Don't let this happen to you! The fourth and final desire, is rewards (or benefits). While the things we do on software projects can be fun, to have a career we need to be compensated well for our efforts. However rewards like getting to work with someone you look up to, flexible hours, stock options, key opportunities that lead to others in the future area also benefits. The perfect job would be one where you're making a big impact, acquiring lots of new skills, have a healthy work/life balance, and incredible rewards. I tell people this software development job doesn't exist! These 4 career desires oppose each other. To get more work/life balance, you may need to sacrifice pay, or impact at times. To get an opportunity to have a bigger impact on a software project, you may need to grow less and use the skills you're already really great at. The important point is to not expect the same level of growth in all 4 of these career desires. You can also watch this episode on YouTube. Episode timelinks: 00:00 Introduction 00:55 The 4 Developer Career Desires 01:28 The Desires Change Over Time 03:03 Desire 1: Impact 05:22 Desire 2: Growth 07:11 Desire 3: Work/Life Balance 08:56 Desire 4: Rewards 10:41 The Perfect Job That Doesn't Exist 11:22 The 4 Desires Oppose Each Other 12:18 Pursuing A Desire Is A Tradeoff 12:55 A Call To Action! 13:31 Next Time... 13:44 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Are you looking around on your software project and just waiting to see someone fail? Are you quick to condemn a manager or developer and cast them useless after a single mistake? Today we’re going to talk about how canceling developers and other IT professionals for mistakes can hold you back from the career you want in software. When I first began developing software, I wasn't particularly ambitious. I needed to make a living to support my wife and son, but I came from a background of partying and playing in a band. But after a few short years I had several promotions and raises, and it started to go to my head. With each new success, my pride got bigger. Once software projects started getting complicated, I started looking for people to blame. The scrum master didn't understand agile enough. The operations team wasn't making it easy enough to release changes into production. The other developers weren't following my coding patterns. Yeah, I became an elitist jerk. But as I've told you many times on this channel, I fell hard eventually. A victim of career-long burnout, I lost my job, a lot of money, and sunk into depression. But when I came out of it, I made this channel and started giving software developers and engineers career advice. It also led me to learn how to work better myself - and help you be a healthy software developer. A moment though of reflection for yourself: are you on the way there? Starting to get rewards and recognition for developing software? Is it getting easier to see flaws in developers and other people on your software project, making you quick to judge? Are you canceling the people who can help you for simple mistakes? If we're humble and honest, we've all made mistakes. And I'm sure I'm going to make many more, whether on a software project, coaching you on your career, or on this channel. I'm pretty sure if you're willing to take an honest look at yourself, you know you're going to too. But you've made mistakes in the past and been forgiven. So should you be more forgiving too? Can we really be fair canceling anyone? What would it be like if all our teams were more like this? What if we worked together assuming we'll make mistakes, and not being surprised? What if we spent more time forgiving, learning, and teaching - and less blaming? Imagine the courage we could have to try and do risky things that might be breakthroughs with our products, technologies, and careers? You can also watch this episode on YouTube.  Episode timelinks: 0:00 Introduction 2:35 The Dangers of Leading 4:35 Falling Hard 6:14 Is Success Putting You in Danger? 8:15 Motivation for True Forgiveness 9:20 Leading Means Helping! 11:00 For Future Leaders... 12:52 What Could Teamwork Be Like? 13:48 Why Should You Care? 14:30 A Call To Action!!! 17:40 Next Time... 19:25 Episode Groove Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Can you believe it's been 3 years since I made an episode? Yeah you can - you've been asking me to come back. Sorry! I just wasn't ready yet. I got clean from marijuana addiction in 2019 but it's taken me a lot longer than I'd hoped to get better. At least better enough to come back on YouTube. In the meantime, I've met with about 200 people all over the world to learn better how to help you with software development career issues. There were a lot of things I thought I understood. And some of them I did. But it was humbling to realize many problems you're having with your career are forcing me to step up and learn again. You may notice this video looks different! I've collected some gear over Craigslist and whatnot to try and create a more interesting look for our time together. I hope you like it. I'll be tweaking it over time as I make more videos about Healthy Software Development. I should mention, thank you for blowing up my channel over a year ago! The video "Why do so many programmers lose hope?" got recommended by a well known programming channel and within a short period, the channel grew 10x! I'm not someone who believes the number of subscribers determines the value of content, but it sure helps me to know you care. In the next episode, I'll be talking about learning from people who've made mistakes. Chief among them - me! I see a real problem in our culture right now with developers and other people in IT only looking to people with a fake persona of having all the answers or being flawless. You can also watch this episode on YouTube.  Episode timelinks: 00:00 Introduction 01:33 Where I've been 02:44 I'm still having health challenges 03:55 The channel purpose hasn't changed 04:48 I'm career coaching now 07:30 I'll focus on career outcomes that work 09:45 Channel production changes 09:51 The channel blew up 10x! 11:40 Thank you for your support 13:13 The next video is about... Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

I've been working through anger issues after reflecting on the content I've put out there for people in the software industry.  I mostly avoided social media for the past 5-8 years and when I started putting my ideas out there, I bought into the "outrage culture". I also have been on many failed projects. And I've had personal problems with my family and identity. I made this video to apologize for my anger and how I've come across as "knowing everything" sometimes. I don't think it helps anyone to be another voice in this, and so I'm committing from here on out to be more discerning with how I share my opinions and advice. When I was 14, I stopped going to church because I wanted to party with my friends. 5 years later I got my girlfriend pregnant and had a really hard time with being a father. I felt too young in public, frustrated with myself and my bad decisions, and so I began to smoke marijuana pretty regularly after work. After my Dad died from cancer, I didn't understand how to cope with the grief and so I used video games (MMOs at the time), music, and pot to escape from what my life had become. Though from the perspective of people I worked with I was successful, my home life was a mess. Software developers make a lot of money and even though I had most of my financial and material needs met, I was really empty inside. After suffering from a bout of chronic insomnia two years ago, I began going back to church. It was really strange and I felt completely out of place. But after I started going to a men's group offered by the church on Fridays, I met several other men who were open about their failures and willing to counsel me where I'd went wrong. I began praying that God would help me with a lot of things, but 3 in particular kept coming up. First, that I would have the courage to do what's right even when people don't like me. Second, that I would heal from bitterness in my life, and that my heart would soften to let go of anger. And third, that I would have more discernment to make decisions that would be better for my life. My life has been going much better in all areas other than my career. I've decided to go into management after reflecting on where my passions are with helping companies and people be more healthy about how they develop software. What this means for the channel is that I'll continue to make content, but I need to do it in a more sustainable way. I need to focus more on my personal responsibilities, and healing from burnout on projects. I've started writing songs again to try and provide myself with a better creative outlet. It can be really frustrating to work at companies when they put you in a box and don't allow really good work to be done. I was looking for the opportunity for creativity in the wrong place in my life. Thank you for being so supportive over the past 2 years of me doing this. I just wanted to help people avoid the mistakes I've made, and I never thought there were so many other people out there who needed help too! You can also watch this episode on YouTube.  Related resources: Are You A Perfectionist Programmer? The De-Corporatization Of Jayme Software Project Stories (Playlist) Is It Safe To Make Mistakes On Your Software Project? Colin Zera - Sister (Home Acoustic Video) My Software Developer Career Journey (Playlist) Why Do So Many Programmers Lose Hope? Can You Be Agile When Your Company Isn't? What MEN Need To Know About Software Developer BRO CULTURE! Why Do Some Programmers Never Agree?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies.  In this interview, Scott and I discuss the balance between strengthening your reputation through your personal brand as a developer, and the teamwork necessary to be successful in your career.  We also touch on concepts in the interview with Woody Zuill about mob programming and the "noestimates" movement.  Scott also runs a YouTube channel with great interviews and live programming exercises.  You can also watch this episode on YouTube.  Related resources: Woody Zuill on Mob Programming and Influencing Change How Agile Teams Grow Toxic! Ep. 4 Commitments Scott Nimrod on Consulting and Software Craftsmanship How to Disagree With Your Manager Respectfully How Agile Teams Grow Toxic! Ep. 3 Forecasting   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Today I have a special guest, Woody Zuill, who's one of the leading voices in our industry around the concept of Mob Programming.  If this is the first time you've heard of it, Mob Programming is essentially an entire team working together with only one person's hands on the keyboard.  There are some surprising advantages to this approach that you may not have encountered before.  Follow Woody on twitter at https://twitter.com/woodyzuill. Watch the video and access resources related to this episode on my website: https://bit.ly/2RQLOeB

Does it ever feel like you'd get so much more done if it weren't for how much work people have you do to make commitments? Today I'd like to help you understand whether the development team you're on is using commitments in a way that makes sense, or will stress people out and put the software project at risk! Since most teams I have worked with aren't really agile, I'm concentrating on helping you understand the risks with commitments between the wrong people which often happens in "traditional" software development companies. Whether your a programmer, in UX, or maybe operations - commitments that are too strict, or too unrealistic, put your job and the success of the project in danger. First I will teach you some insights I've learned about how commitments can cause agile teams to grow toxic. Afterwards, I'll give you some actionable tips on what you can do to cope with traditional (non-agile) teams that require unrealistic commitments. I hope this information helps you select the best project for your career, or if you're on an unhealthy team - protect yourself so you have the best chance of being successful! You can also watch this episode on YouTube.  Related resources: The Secret of Scrum Nobody Talks About An Agile Budget Keeps You From Being A Code Monkey What REALLY Gets Software Developers Promoted? How Agile Teams Grow Toxic! Ep. 3 Forecasting Why Do So Many Programmers Lose Hope?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Over the weekend I posted a video clip from episode 3 of my series on this channel "How Agile Teams Grow Toxic!" to reddit. The full video is about how teams can become unhealthy due to how % complete forecasting is done on most projects. In the clip I posted, I spoke specifically about the unpredictability of our work as software developers. There were over 100 comments on reddit alone with some other great ones here on the channel. In this video, I respond to several of these comments to provide further clarification on the concepts of healthy software development. I'm going to do a future video called "My Software Development Philosophy" in which I'll go into many of the things I touch on in the response in more detail. But for now, I hope you enjoy the responses. If you don't agree, let me know why! If you do agree, how can we get this information out to more people? You can also watch this episode on YouTube.  Related resources: How Agile Teams Grow Toxic! Ep. 3 Forecasting Is It Safe To Make Mistakes On Your Software Project? Iain Lowe - Healthy Developer Interview #2 Spot A Fake Agile Team In Under 7 Minutes!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards  

With all the challenges in the software industry with languages, frameworks, and processes...  It's easy to forget we're human.  I've been making some really serious level 301 agile nerdgasm content lately, so I made this episode to just have some fun.  Here are three stories of times I was embarrassed in my 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

Deadlines!  "Drop dead" dates!  Changing the schedule to meet "new requirements"!  Do you ever think there's gotta be a better way to do this?  Well there is, and today I want to share with you some information about a topic that often bores software developers...  But in my experience of working with many teams and companies, when developers are frustrated on their project - it is this topic that's often the culprit.  In this video I discuss how people who pay for software development projects forecast.  Before you bail, if you hang with me on this video you'll know more than many agile coaches and product managers about why investing in software projects is unique!  I'll share the dangers of traditional forecasting on software projects - and an alternative way to give investors confidence.  You can also watch this episode on YouTube.  Related resources: An Agile Budget Keeps You From Being A Code Monkey Eric Ries: The Lean Startup | Talks At Google   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Be careful not to mirror the person interviewing you too much for your next software development job!

The core motivating value of the company's founders shouldn't be ignored when you join a software project.

Have you ever had to quit a good software project...because you figured out you weren't going to be successful in your role? I had the opportunity to help two consulting companies try and rescue a troubled software project for a client. Though I was originally brought in to help figure out how much work was left to do, I found myself in the position of being "the expert" once again. Because of politics, deadlines, and challenges with the maturity of the companies understanding agile - I found myself overwhelmed. Though I continually tried to reset expectations and get help, I decided eventually that it was better to move on. Have you ever been on a good project, with good people, only to find when you really think about it you're not effective in your current role? Did you have a hard time getting support from management to make the changes necessary? You can also watch this episode on YouTube.  Related resources: The ModernAgile YouTube channel Spot a Fake Agile Team in Under 7 Minutes! Why Do Some Programmers Never Agree? New Software Project? Earn Respect From Your Team! Are Developers Being Misled About DevOps? Lead Software Developers Better By Letting Go!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Over my career I've seen many software projects fail spectacularly due to political infighting between team members. Blame-shifting and improper application of scrum got people fired on this one! I prefer a simple definition of politics: when people tell each other what they want to hear instead of the truth. I'd like to share the story of a software project I worked on, where the client was a non-profit company with a big budget. They wanted to redesign a major application used to help struggling educational institutions. But the staff were inexperienced with agile. And multiple contractors on the project were fighting. In this episode, I share how inexperience with software development processes can actually get people fired. Especially when there's politics. You can also watch this episode on YouTube.  Related resources: Are User Stories Making Your Project Late?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Ever had to get the team to STOP to fix a problem?

The story of a consulting project where the client's founders reacted surprisingly to our advice. 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

Over the years I've had to lead many software developers, and it's become much easier since letting go of being seen as "the expert". Even if I’m only leading a few people there’s always too much work and I have to choose really carefully what I do. If you’ve watched any of my other videos you know I’m a big fan of teams where there’s less management. But whether someone is officially recognized as a “lead developer” or not, most teams usually have people on them who are more experienced. And people naturally seem to take ownership for areas of the product they’re most interested in and can start being seen as a leader around that idea. Maybe that’s you, or maybe you’re considering stepping into a role where you’ll be leading developers to do something with the software. In my career I’ve found it’s really easy to get overwhelmed when I’m leading other developers. Meeting with the business, supporting developers, and still trying to get work done on the product myself can feel impossible. You’ve probably heard the saying “give someone a fish, feed them for a day. Teach someone to fish feed them for a lifetime”. But even though I know this, it can be hard to let other developers do more to help you if it’s going to take longer than just doing it yourself. In this video, I share how I’ve had more time to support my team when I let other developers have more responsibility, and you can too. You can also watch this episode on YouTube.  Related resources: Is It Safe To Make Mistakes On Your Software Project?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Sometimes I get an opportunity to show a team how to use a technology that not only solves a business problem, but I really like! In this case it was continuous delivery to deploy business intelligence dashboards to production. When a client of mine was burned by a prior vendor that couldn't deliver their software project, they needed to see progress made quickly. The software product was supposed to be a set of complicated visual dashboards that pulled in data from a bunch of different healthcare systems. At the time deploying these types of software systems was a manual, error prone process. So I had built a framework to automate releases. This would help us follow continuous delivery. But the lead on the project was resistant at first, and the client wasn't sure they were ready. In this episode, I share how the continuous delivery framework I used earned trust at first...but was eventually abandoned. I still had many things to learn about how to support my own software frameworks! 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

Stay calm while people around you jockey for money, fame - and other people's dreams...

John Cutler is a brilliant product manager who joins me as a special guest to discuss agile's controversial position in the market, and developer soft skills.

Over my career I’ve seen more projects fail due to misuse of user stories than any other practice commonly used on agile teams. You probably already know that user stories are just a simple format for writing requirements on scrum or kanban agile teams. Today I want to help you avoid some bad advice I see out there about what user stories are and how they can help (or hurt) you. Why User Stories Were Created Before agile methods for development, teams wrote big documents describing the design of a software product before building it. Since the project was designed up front, it was also funded up front. The more detailed the documents, the better the estimate of costs. But companies were finding that by the time software was done, customers wanted something different. Early leaders in the agile community came up with a great idea to only build and release a little bit of a software product at a time. This would let the team change their mind about what to build once the project started. Since it takes a long time to document something you might not build, the industry began using user stories to describe requirements. The thought was to describe just enough about what value a feature offered to the customer that it could be prioritized. The Pressure For Traditional Budgeting But some leaders and business owners still wanted to know exactly what they were getting before approving budget. They forced people to estimate and scope every idea anyway because they were too scared to fund a team without knowing exactly what they were getting. Many agile coaches tell teams that a user story is just a placeholder for a conversation. Once the team starts working on it, they’ll talk with the customer or Product Manager and get the full details. The problem is, once this conversation was held, many additional details emerged. And this caused the estimate to go way up. With Non-Agile Leaders, You Need More Than User Stories If your stakeholders (product managers, customers etc.) are focused on cost, you are much better off creating detailed acceptance criteria that describes a user story in detail before you give out any estimates. Acceptance criteria reads like a test script and describes exactly how someone can use the software, or write an automated test, to verify it’s done and works right. If you don’t have acceptance criteria, the rough estimate you give out for a user story will change. And every time it does, you’ll lose trust with your stakeholders because you’ll look like you estimated wrong. So match the level of detail in your design and requirements on your project with your stakeholder's tolerance for uncertainty. If they are focused on costs, certainty, and predictable deadlines - writing only user stories and committing to estimates without acceptance criteria is foolish. It’s like committing to a waterfall project with 10% of the documentation necessary to really estimate it!! 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

Ever been on a software development project where one team is putting pressure on another because of a hidden agenda? I was once asked to investigate two teams that worked together to build a software product for doing taxes. The first team contacted us and said they needed help with releasing software better. So I planned to use an interview I'd come up with over the years. It had questions I could ask people about how they work together. Things like how they gather requirements, test the software, and approve releases for example. While interviewing the first team, it became clear that they did't like the second team. The second team wasn't following scrum, while the first team was. The first team was convinced the problem was with the second team. However after interviewing many people on both teams, we realized the second team was following kanban. But they were doing it for a good reason - to respond to unpredictable changes in tax code. So eventually we presented our findings, and though many people were pleased - our client was disappointed that we hadn't only found issues with the second team. In this episode, I share the story of how I had to avoid being used as a pawn in corporate politics at my client. I hope it helps you avoid being put into a situation where you're pressured to side with a group of people to force another to change unwillingly! 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

Sure, progress seems like an innocent thing to measure. *rolls eyes*

One of the most frustrating software projects I've been on was when we designed a product that never got built! A couple different things happened on this project that made it difficult... First, the project was being sold to use an agile process, but then was suddenly switched to fixed cost at the last minute. Secondly, there were too many people in management positions. It created confusion where team members were getting conflicting instructions. The client was telling each manager different things! And lastly the client had never designed a software product before. We tried to warn them to design a simpler product than their entire vision, but they wouldn't listen. Because they tried to design the product up front, they designed a product that was too complex for a first release. Though we did what we could to keep the project on track, it ultimately was too expensive for them to build. I hope this episode helps you avoid some of these mistakes on your software projects. 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

When people say "scrum (or agile) is about going faster!" - send them this episode.

Is there a time to just stop learning and write code? Software development draws many of us in with endless opportunities to learn, but is it right for every project? Early in my career I wanted to know everything possible about the software companies I worked for. But a couple of years in software consulting taught me I could actually be a better developer by learning to ignore information sometimes. In this episode, I share a story of a project I was on where the relationship was in trouble between my agency and a client. Fixing the relationship was the most important thing to do - but it could only be done by solving their problems quickly. The relationship was repaired quickly - but only through ignoring learning some things about the software! 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

If people don't feel safe, they won't try.

There's no shame in getting help from a friend on a software project! Let me tell you the story of a project I worked on soon after moving to Austin, Texas. I was new to the consulting side of the software development industry, and didn't know anyone in town. After being put on a project with a more experienced consultant, I ran into a few challenges. But after realizing the other consultant wanted to help, I got myself out of a jam that was starting to make me feel pretty stressed out. I hope this story helps you think about the next time you're struggling to get some work done. There's no shame in asking for help, or even giving your work over to someone else. Businesses pay us to get value delivered to customers - but we don't always have to be the ones to do it! 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

Knowing whether a team is truly agile or not, is actually really simple!

Making changes to a company's culture needs to be done a little at a time...

Iain Lowe, a veteran in the software development industry joins me to discuss estimation, agile dogma, and career growth.

I'm still figuring out how to help more software developers understand how important consulting skills are!

Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies. He was an early subscriber to my channel and has given me a lot of great advice and support since I started out on YouTube in 2017! In this interview, Scott and I discuss some serious topics related to software craftsmanship and consulting. Specifically the dynamics between consultants and managers, working with difficult people, career growth, testing – and the direction of the software industry. Scott also runs a YouTube channel with great interviews and live coding exercises: https://www.youtube.com/user/Bizmonger  Skip to points in the episode:  Rescuing Projects with Quality (9:55)  Short-Term Product Decisions (13:17)  Continuing Developer Education (17:40)  Accepting Unmotivated Employees (20:34)  Getting Blamed for Failures (26:01)  Staying Positive and Fearless (29:11)  Establishing Industry Authority (35:31)  Unpredictability and Estimating (42:53)  Forcing Process Changes on People (48:45)  Focusing Your Passion on People (58:40)  Coping With Corporate Politics (1:00:27)  Watch the video and access resources related to this episode on my website: https://jaymeedwards.com/shows/healthy-software-developer/scott-nimrod-on-consulting-and-software-craftsmanship/

It's like I have a filter - I can't even tell you everything I want to!

What every software developer wishes their leadership knew about software development!

I learned to stop blaming management and take more responsibility - regardless of who's fault it is. Intro music "Dreams" by Joakim Karud: https://soundcloud.com/joakimkarud/dreams-1

There were no daily status meetings before scrum...

Become the person companies are looking for to be recognized in a more senior software development role.

Programmers give a lot of grief to product managers, but they're just misunderstood. I hope this episode helps.

I can be too quick to want to use my own patterns.

What do you do when something's outside of your control AND influence?

If you see these common agile development fails on your team, you can really help make things better by talking about a change.

Something about writing code and software architecture makes it hard to sleep at times.

I'm trying to see my own limiting biases better so I work better with other developers.

It's easier to get a raise if you can quantify your impact.

Help keep your team's eye on the prize (in your market).

A comparison of a factory vs. college mindset in the culture of a software company.

Lean leaders let go of their certainty and discover successful products.

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! Skip to points in the episode:  What causes us to lose hope?  We're Forced to Cut Corners (3:00)  Cognitive Overload (4:33)  Low Perception of Value (5:17)  High Income Forces Deeper Goals (6:50)  Learned Helplessness (8:31)  How can you get your hope back?  Say No With Grace (10:38)  Communicate Uncertainty (12:45)  Ask for Help Earlier (15:28)  Develop Empathy (16:48)  Surround Yourself with Positive Devs (18:24)  Watch the video and access resources related to this episode on my website: https://jaymeedwards.com/shows/healthy-software-developer/why-do-so-many-programmers-lose-hope/

The irony that what we typically use to keep us going - keeps us from changing.

I've struggled a lot with trying to protect - and let go of my ideas.

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. Skip to points in the episode:  Technical Skill Determines Your Success (1:40)  Harder Work Gets More Done (2:40)  Past Success Determines Future Results (4:16)  Bigger Companies Have Better Practices (6:27)  Promotions Are Proportional (8:56)  Watch the video and access resources related to this episode on my website: https://jaymeedwards.com/shows/healthy-software-developer/5-big-lies-the-software-industry-tells-you/

When programmers feel like robots and people are jaded, the software project budget is often the culprit.

Planning poker is great - if people respect each other.

I should have noticed earlier how I just did what everyone else did.

You can't improve without finding out what's wrong.

Be sure they really are nuts before you bail on your potentially narcissistic software leader!

A few questions you can answer that will help you find the right project for where you're at in your career right now.

It's a powerful feeling to write code - but let's not be ridiculous about it.

How software projects change when the project is nearing the end of it's life.

How software projects change after "market fit" has been found.

An introduction to the life cycle of a software company.

How software projects can be managed incorrectly because fear is a result of not understanding where the project is in it's life cycle...

Tips and insights to help you stay in a focused state when you need to.

Impressing people with what you know may be what they ask for - but it isn't what they really want.

I was at my most frustrated when I didn't let people just be themselves.

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. 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

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. You can also watch this episode on YouTube.  Related resources: The Journey To Cross Functional Development Teams Continuous Delivery - Are You Missing The Big Picture? "Continuous Delivery" (Amazon) "The Phoneix Project" (Amazon)   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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! You can also watch this episode on YouTube.  Related resources: Programming Estimation - Estimate Software Tasks With Caution   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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. You can also watch this episode on YouTube.  Related resources: Say NO On A Software Project - So They Will Listen! Agile Project Management - Is It Stopping You From Being Agile?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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. You can also watch this episode on YouTube.  Related resources: How To Win Trust For Your Software Development Ideas   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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. You can also watch this episode on YouTube.  Related resources: My Software Development Journey! (Part 1) Can Imposter Syndrome Help Software Developers Grow?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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

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! You can also watch this episode on YouTube.  Related resources: Can You Be Agile - When Your Company Isn't? Software Developer vs Consultant - What's Better For You?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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. You can also watch this episode on YouTube.  Related resources: My Software Development Journey! (Part 1) Creative Software Development - Explosive Growth By Letting Go!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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! You can also watch this episode on YouTube.  Related resources: How Uncertainty Impacts Software Development Processes Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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! You can also watch this episode on YouTube.  Related resources: Can You Be Agile - When Your Company Isn't? Software Developer vs Consultant - What's Better For You? Continuous Delivery - Are You Missing The Big Picture?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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: Failure To Invest In Better Tools and Services Too Much Power In The Hands Of A Few Customers They Can’t Say “No” To Any Customer They Have A High Customer Acquisition Cost They Commit To Deadlines Without Understanding The True Cost 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! 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

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: Keep The Conversation Private Ensure They Are Well Rested Reinforce Their Value Listen For Struggles Future-Pace The Benefits Discuss Their Reservations 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! You can also watch this episode on YouTube.  Related resources: "Sonic Drifting" by Ron Gelinas “All The Beauty (original ambient version)” by Jani R “Ambient Theme No. 1” – Steven O’Brien   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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-Explanation A 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. Nitpicking It’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-communicating In 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 Apologies In 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. You can also watch this episode on YouTube.  Related resources: How To Win Trust For Your Software Development Ideas "Free Ambient Loop" by Sweet Wave Audio "Sonic Drifting" by Ron Gelinas "All The Beauty (original ambient version)" by Jani R   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 On When you first start working in software, you’ll have rewards that will keep you satisfied for the first 2-5 years: Lots to Learn (Everything is NEW!) Casual Environment Good Benefits After time spent on spent on projects that aren’t letting you grow, you may hit some barriers: Continued growth may not be important to your employer The path to advance may appear to be “blocked” by other ambitious professionals 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 Grow You 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. Certainty Variety (or Uncertainty) Significance Love and Connection (or Team/Community belonging) Growth (Personal skills) Contribution 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 Growth How can you balance these human needs better, specifically in your software career? Tip #1: Set Deadlines for Career Changes Don’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 Others There 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 Growth When 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! You can also watch this episode on YouTube.  Related resources: How To Win Trust For Your Software Development Ideas Tony Robbins TED Talk (He Discusses The Human Needs) Tony Robbins Website   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Learning Traditional 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 Learning I 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 Anxiety One 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  data-href="https://medium.com/jayme-edwards-mentoring/how-uncertainty-impacts-software-development-processes-9d7d7cefe5c6">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 Learning If 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 Risks The 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 Detachment Since 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 Outcomes Most 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 Catastrophizing Once 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 Failures If 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 Beliefs If 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 Outcomes In 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 Gratification Your 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 Uncertainty It’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. You can also watch this episode on YouTube.  Related resources: How Uncertainty Impacts Software Development Processes 5 Ways To Cope With The Anxiety Of Software Development How To A/B Software Development To Find What Customers Value Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Influence Stephen 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 Influence Because 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 Dysfunctions While 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. You can also watch this episode on YouTube.  Related resources: How To Win Trust For Your Software Development Ideas The 7 Habits Of Highly Effective People (Amazon) The 5 Dynsfunctions Of A Team (Amazon)   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Change When 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 Teamwork When 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 Releases When 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 Learning When 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 / Utilization This 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 Often To 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. You can also watch this episode on YouTube.  Related resources: John Cutler on Medium The Journey To Cross Functional Development Teams Continuous Delivery - Are You Missing The Big Picture? Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Something In 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 Understand It 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 Step Software 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 Others In 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 Contribution We 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. 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

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 Well What 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 Schoolers I 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 Firefighter Around 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 Lean I 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 Analysis A 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 Lean I 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 Management I 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 Transformation Eventually, 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. You can also watch this episode on YouTube.  Related resources: The Lean Startup (Amazon) My Software Development Journey! (Part 1) My Software Development Journey! (Part 2) How Failure Produces BETTER Software Products! How To Win Trust For Your Software Development Ideas How To A/B Software Development To Find What Customers Value Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Opportunities After 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 Agile We 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 Interest Unfortunately 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 Experience I 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, Texas Eventually 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 Consulting Shortly 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-Up I 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 Skills After 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 Advisor The 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 Delivery While 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 Delivery After 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 Management This 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. You can also watch this episode on YouTube.  Related resources: My Software Development Journey! (Part 1) My Software Development Journey! (Part 3) Flawless Consulting (Amazon) Continuous Delivery Amazon) The Lean Startup (Amazon)   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Position Though 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 Mentors I 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 Product A 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 Manufacturing At 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 Sponsorship Somehow 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 Process At 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 Skills I 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 People Our 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 Anxious I’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. You can also watch this episode on YouTube.  Related resources: My Software Developer Career Journey! (Part 2) My Software Developer Career Journey! (Part 3)   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Team If the team isn’t as skilled as assumed, projects will take significantly longer and more brittle to change. Assumptions About The Quality Of The Release If 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 Scope If the team is assuming requirements are complete, they look at scope change as failure. Assumptions About Value Of Features & Changes If 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 Failure Overall, 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 Risk If 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 Realignment If 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 ROI For 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 Skill If 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 Feedback Having 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 Teams The 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 Retrospectives Have 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 Audience Rather 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/Fail Many 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 Outcomes Most 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 Scoping If 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 Budgeting If 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. You can also watch this episode on YouTube.  Related resources: How To A/B Software Development To Find What Customers Value   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

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 Today Technology 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 Budget A 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 Progress A 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 Code A 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 Experience A 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 Architecture A 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. You can also watch this episode on YouTube.  Related resources: 5 Ways To Cope With The Anxiety Of Software Development! How To A/B Software Development To Find What Customers Value Minimum Viable Product - Letting Software Customers Help You Profit Lean Software Development - It's About Uncertainty! Principles Of Lean Product Management By Jez Humble   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Are you confused or frustrated by the amount of energy spent discussing sexism in the workplace and how men are to blame? Today I'd like to offer some insights and opinions that might help men make smarter decisions about how we treat people to make sure we're not damaging our careers and making it difficult for people to work with us. Disclaimer: These Are MY Personal Opinions First a disclaimer. I'm a heterosexual man and these are just my opinions after many years working in the industry that I've observed and experienced. I'm not qualified to talk about what makes the workplace safe for women, but I can share how my own shortcomings and observations of other men's behavior makes it hard for everyone. Purpose: Get You To Think More Seriously About This Issue  The purpose of this video is not to tell you what the solution to all of these issues is, but to get you to think about how software developer bro culture affects all of us. My hope is that this will lead to you spending some time researching the issue to reach your own conclusions with intention. What's It Like To Work With "Bros"? First I'd like to share what it's like to work with other "bros". On an all male, or male-dominated team like I've been on several times, unchecked aggression, free exchange of ideas regardless of how they make people feel, and shaming are prevalent. The people who do this don't always intend for this outcome, but as the team grows and these behaviors are left unchecked, it becoming "the norm" is the result. Men Can Feel Threatened By Women's Support Of Each Other  I share a story about how a man approached a group of women discussing their lives in the park while my wife was at Yoga teacher training in Boulder. He made the crude joke "what is this the man hater's group?" which underscores how men feel threatened by women's support of each other. Because we can often feel it is a sign of weakness to support each other, we can lash out and say and do stupid things when we are uncomfortable. Men Fear Losing Relationships If They Show Vulnerability I also read a brief passage from "Daring Greatly", a New York Times Best Seller by Brene Brown, speaker, PHD, and researcher on shame and vulnerability in modern culture. In the passage, I describe the real struggle men feel when they don't have a safe place to express vulnerability. I've included a link to the book at the bottom of the page. The conclusion I draw is that men can become afraid of losing relationships that are important to them if they show vulnerability. Misery Loves Company So why do men continue to behave this way? One reason is the concept of "misery loves company", or the phenomenon where men engage in behaviors and ways of relating that make them feel worse about each other just because it feels good to be part of a social group. Standing up for ourselves to not engage in this behavior and instead hold ourselves to a sustainable, higher standard is the first step in rejecting this attitude. Domination Focus Will Limit Your Career Progress We also behave this way because we're modeled from a very early age to dominate others. However, domination will severely limit career progress as we move from company to company, or team to team, as our "bubble" of acceptable behavior is broken and we're forced to interact with wider, more diverse groups of people. Lacking Empathy Can Cause Others To Abandon You A lack of empathy will ultimately cause others to treat us with low respect. When things inevitably go south in any shape or form on a project, and leadership looks for someone to blame, if you treat others like objects of your will and not people you will be at the top of the list to take the fall. This is another form of short-term thinking and it doesn't take long for your career reputation to catch up with you - making a sustainable plan for growth much more painful than necessary. Compromising Work/Life Balance Makes You Easier To Replace In our quest to advance in our careers, we unfortunately often compromise work/life balance with the expectation that this will help us get ahead. In reality, though it might result in a short term promotion or advantage, we actually make it EASIER to replace us with younger, naive employees that will do the same when we inevitably grow tired. Men can do a better job than this and stand up for a fair balance of work by refusing to contribute to the workaholic mindset. Industry Veterans Owe It To Younger Colleagues To Improve Culture Since we will be working with the next generation as we progress, we owe it to our younger colleagues, regardless of their gender or ethnicity, to improve the tech culture. If we accept software developer bro culture as the default way teams interact, we are simply destining ourselves and others to a short career filled with disappointment as we're not prepared with the social skills and empathy needed to progress. You can also watch this episode on YouTube.  Related resources: Daring Greatly (Amazon)   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Are you feeling worried that you won't get what you want out of your career? Today I'd like to share 5 ways to cope with the anxiety of software development. Overcoming Past Failures The first way software development can cause anxiety is when another party you're working with, or perhaps even you, have experienced failures in the past. If you can learn to be OK with having to prove yourself again, and that others may look at you with scrutiny because of what went wrong before that was totally outside of your control, you'll find greater peace. Battling Forced Commitments The second way software development can cause anxiety is when someone is obligated to a commitment for which they were unable to influence the terms. A common example of this is when a software developer estimates work for another. Do whatever you can to help leaders understand the value in the creative ways individuals solve problems, and commit to less without involvement from the person who will actually do the work. Overcoming Impatience In our quest to achieve our goals, we can often become impatient. When we rush to reach our career goals and dreams, we don't enjoy the journey and often make poor decisions in our haste. If we can calm down and savor the moment when we achieve a goal, we won't jump to start the next one without actually slowing down to enjoy what we just worked so hard for. Permitting Yourself To Heal I've personally had many tragedies in my life and failures on the job, and when I don't take vacation or whatever time is needed to fully heal - I'm never at my best. Permitting yourself to take time off to heal is crucial to doing your best work and enjoying software development. If you want to feel less anxiety, you must take care of yourself and put your needs above whoever at the company has expectations for you. If they don't understand, tough! Your health and well-being are more important than trying to keep yourself "together" if you're experiencing anxiety because you need to take care of anything going on in your personal life. Rejecting The Scarcity Mindset In our society today the perception that we don't have enough money, a high enough social media score, aren't attractive enough, or won't get the opportunities we want can result in crippling levels of anxiety. Rather than let this completely FALSE mindset effect us, we need to be realistic about the abundance of opportunity available in this industry. The sooner we can take a step back and realize just how many options there are outside our current situation, and have the courage to explore these while embracing uncertainty - the sooner we can calm down, try what might be more fulfilling, and steer in a direction that's better for us. 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

Do you want to try something new that requires other people to support you? Today I'd like to help you understand how to earn trust for your software development ideas. Honestly Evaluate Your Current Skill Before you begin to win trust for a new idea, you need to be critically honest with yourself about how skilled you are with implementing the idea. It’s fun to try new things, and we’re never “good” at them when we do them for the first time, but we should be careful not to “over-sell” our abilities. Consider A Time-Boxed Research Spike To Determine Effort You might want to consider using a time-boxed research “spike” to explore the true effort to try an idea, and to learn more details about what you just don’t know enough about yet. A time-box is simply a fixed period of time during which discovery of the idea or problem will take place before re-visited again. Make sure you set the expectation with others that the conclusion of this spike will not be everything needed to move forward, but that it’s a chance to regroup and decide how much additional time to spend. Establish Your Role In Collaborating Critically important to getting your skills used so you can win trust with others is to establish your role when working with them. This isn’t the same as your job title or the skills you contribute to an effort or team, but rather what role you play in serving another. Role 1: The “Expert” The first role is the “Expert”, where you essentially swoop in, do the work, and vanish. Though this can be tempting for the person doing the work as you are essentially “not bothered” but the person you’re working with, you miss the opportunity to get feedback and really deliver excellent work that meets both your needs and draws from both your skills. Role 2: The “Pair Of Hands” The second role is the “Pair Of Hands”, which is somewhat the opposite of the “Expert”. In this role, the other person directs your every move, and it’s common in companies with a command-and-control structure or where micromanagement is the norm. This can provide more control to the other party, but it misses out on their ability to have more feedback from you while doing the work. Role 3: The “Collaborator” The third role is the “Collaborator”, which is what you want to try and shoot for with anyone for which you want to gain trust. In this style, the two of you do the work together and have an opportunity to both contribute ideas, provide feedback, and make progress. It may help to share these definitions with others to get them to understand the value of the collaborative style. Align Motivation For Ideas With Others It’s crucial that you align the purpose for the changes you wish to make to the motivation of the other party when “selling” the change or idea. You won’t know this without really knowing the person and their struggles, and so you should consider following my advice from other videos to get to know people on a more authentic, personal level. This will give you the ammunition you need to make sure the other person “gets” why the change is important – to THEM. Use Incremental Wins Towards A Larger Goal Though the idea you have might be of immense benefit in some way, it’s quite possible that the work involved, and changes to the mindsets of those effected, is too much to take on in one go. To get around this, slice up a large change into small increments and only “sell” the first piece. When you’ve successfully delivered this change, it will get easier to win support for future changes. Eventually you’ll get permission to make a larger change in one go. Plan Your Detachment From Success It can be tempting to be seen as the expert or guru around a particular change you helped make on a team or at a company from your ideas, but if you want to continuously innovate in your career, it’s better not to. Plan how you will detach from the success you make on a project or with a company so you are not a bottleneck that must be the “go to” person for that change from then on. You will want to explicitly bring others into the fold, make sure they are trained and understanding the change as well as you do, and able to step away when the change is complete so you can pursue your next big idea. You can also watch this episode on YouTube.  Related resources: "Flawless Consulting" (Amazon) How To Be A Servant Leader On Software Projects Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Do you want to help the other people that work with you so they are more fulfilled, and get an opportunity to inspire them? Motivations To Consider Let’s start with some of the motivations I think it’s important to consider if you want to go about servant leadership. Improve Quality Of Delivery Ultimately, however you serve people still needs to result in improving the quality of delivery. While we’ll focus on how to be a servant leader on software projects by serving the needs of others, this fact is important to still keep front and center. Support Career Goals Of Colleagues As you go about serving others, you might adopt a motivation to see others’ careers advance. This doesn’t mean you stop caring about what happens to you, but that you share the burden for those around you being recognized. You Don’t Need A “Leadership” Title You don’t need an “official” leadership title to be a servant leader on software projects. You may be the boss of your colleagues already or not, either way, the goal is to inspire and help others – regardless of your job title. Don’t Rely On Skills To Inspire As you attempt to lead others by serving them, you may need to shift from relying on demonstrating how skilled you are as a primary motivator. Instead, utilize some of the other tips in this video to be a servant leader. Avoid “Siding” With Individuals Be wary of siding with individuals. Do whatever you can do to avoid being sucked into political games, or disputes between people on your team. This doesn’t mean to not have empathy – far from it, empathy is crucial. Rather, don’t be an ear to lend when someone wants to criticize someone else and join in on it with them. Detach From Personal Advancement You may find detaching from your personal advancement helpful if you want to be a servant leader on software projects. The moment you start considering whether your efforts are advancing your own career, conflict can arise that makes it harder to take altruistic actions. Tips For Better Servant Leadership So what are some of the things you could start doing immediately to demonstrate your desire to be a servant leader? Show More Than You Tell The first thing I’d recommend is to show more than tell. When you delegate work or information to others, taking the time to show them how its done will go further than just conveying the steps. You won’t always be able to do this, but err on the side of demonstration whenever possible. Get To Know Colleagues Personally Next I’d recommend you get to know your colleagues personally. More than just what technical or other work related skills they prefer, get to know what makes them tick personally. This will make it easier to support them and their needs and desires. Organize Opportunities To Socialize If you can organize opportunities to socialize with your immediate group, you will show your colleagues that you care about them as people and are willing to share of yourself outside of work. Don’t rely on company happy hours and events as the sole way for your immediate colleagues to get together. Recognize Individual Contributions It’s important to recognize individual contributions, and not attribute them always to the entire team. When providing status or communicating “wins” of the team, put a name to each gain and give props freely to those who did the work. Advocate For Solutions To Colleagues’ Pain Listen for pain and advocate for solutions. If you get to know your colleagues personally, they will share their struggles and whatever you can do to ease it or help shift the burden to someone else will help them be more fulfilled and effective. Advocate For Growth Of Your Colleagues As a servant leader, don’t rely on people with explicit management titles to be the only ones to look out for your colleagues careers. To avoid seeing great people you’ve built good relationships leave, do what you can to remove roadblocks and enable them to grow. If they want to leave because they aren’t getting the opportunities they need, support them in that as well. Get Excess Capacity To Support Serving You will need to negotiate excess capacity in your schedule so you have the time needed to be an effective servant leader. This may be difficult depending on the management style of your organization, but if you can do it – it’s well worth it. Struggle With Them It says more about you when others see how you help during times of stress than when things are going according to plan. Share in the struggles with your team. If you really want to demonstrate the attributes of a servant leader, this is an easy one. Be As Transparent And Open As Possible Though this can be controversial, I believe servant leaders should do what they can to be as transparent with their colleagues as possible. If you wish to serve others above the company, part of that is being open and honest with them about information you know. Do not divulge information you’ve been asked to keep private, as this is being dishonest – but I encourage you to get permission to be as open as possible with your colleagues from whoever you report to if necessary. 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

Are you frustrated that other software developers often belittle each other or have a hard time coming to agreement on seemingly trivial issues? Today I’d like to talk with you about why software developers disagree – and what to do about it! The Fear of Being Misunderstood The first reason I often disagree myself, or see others do so – is due to a fear of being misunderstood. We strive to have others respect us and understand where we’re coming from, and sometimes this results in us disagreeing simply to clarify our stance. An Inflated Sense Of Experience Another reason we can disagree is an inflated sense of experience. When we’ve worked on a particularly wide variety of technologies and at many companies, we can think we “know everything”. I personally struggle with this and have to constantly strive to keep myself in check, being realistic about what I do and don’t know. A Byproduct Of Detail Needed To Be Successful We can also disagree simply as a byproduct of the detail needed to be successful. The interview process, and the fragile nature of software development tasks can cause us to become nit picky or too particular with each other. Though we should always strive to have a better understanding of what we mean, I try to leave it alone when I feel someone has “got it” even if their explanation may be different than mine. Projecting Prior Frustrations Onto Others Sometimes we have a bad experience on a project or with a person, and when we feel our self in proximity of a similar situation – we fall prey to projecting prior frustrations to others. This survival instinct can be helpful, but it can also damage our ability to see people for who they truly are and not cast an unfair perspective of them through the lens with which we’ve been hurt before. Focus On Mechanics At Expense Of “The Big Picture” I also experience disagreement if I or others focus on mechanics at the expense of the “big picture”. When we split hairs on the “how” without agreement on the “why”, it’s very easy to get distracted and spend unnecessary time working out the details of detailed tasks without having consensus around purpose. How Can We Handle Disagreements Better? What can we do about these easy ways with which we disagree? Get To Know Others Authentically The first one would be to simply get to know each other more authentically. When we have real relationships with people and not just “fake” work relationships, people will be less likely to feel misunderstood. Assume Good Intent And Reason For Disagreeing We also come to agreement easier if we approach others and assume their good intent and reason for disagreeing with us. Though it’s tempting to rely on our prior experience to control and color our perspective of another’s stance, learning to be more patient and understand their unique situation can quickly get us back to agreement. Try Not To Take Disagreement Personally Putting explicit effort into trying not to take disagreement personally is hard, but opens up the ability for others to feel safe with us and to not feel like they must “walk on eggshells” any time they communicate. This fosters the relationship needed for creativity and consensus to flow naturally. Be Selective With What To Disagree About You’ve heard the expression “pick your battles” and this certainly helps with disagreements. By being more selective about what we must get agreement on, we trust the major outcomes of a project and don’t have to be so anxious about every little detail going our way. Get Consensus On “Why” vs “How” If we can get consensus on “why” vs “how”, disagreements are less common since few will argue a high level business or project goal. This gives everyone the fresh perspective needed to look at their own stance more objectively in light of the overall goals being targeted. Appreciate When Others Learn What You Know Lastly, appreciating when others learn what you already know will diffuse many disagreements. Many of us learn best by sharing, so our ability to be patient and hear someone explain what we know helps them learn, and be committed to the work we know they will need to do to take on the tasks at hand. 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

Are you looking for a way to get people with different disciplines to work together better when developing software? Today I'd like to talk about the journey to cross functional development teams and some of the considerations on your way to integration. What Is Cross-Functional Teamwork? Cross-functional teamwork is simply taking people who used to be in separate teams or departments and putting them on the same team. To get there people go through a series of phases or stages. Phase 1: Ad-Hoc The first phase is what I call “ad-hoc”. Someone at the company has done some work that would typically be thought of as associated with a discipline (Operations, QA, Support, UX as examples), but they don’t think about how all the things associated with that discipline should be handled. Phase 2: As-A-Service The second phase is “as a service”, or what most people in medium to large companies often experience. This is where there is a dedicated department that does Support, Operations, UX, or QA; as examples. When a product team needs help with one of the skills of these separate teams, they use their expertise as a service. But these teams are still independently managed and measured. Phase 3: Embedded The third phase is “embedded”, and what most people think of when they hear terms like DevOps, Embedded QA, or Embedded UX as examples. Folks who were on a separate team are now integrated with the product team itself. They are dedicated to using their skills to achieve a single outcome for the business such as a product or deliverable. Embedding Sometimes Uses An Office / Center Of Excellence During the embedding phase, it’s common to see companies create a center of excellence, or office, who’s purpose it is to help make sure good practices are followed by those embedded in the teams. A “Project Management Office” is a common example of these. An important consideration is, does the person leading this new office have the skill with coaching, documentation, patience, and establishing measurable outcomes necessary? Leading Center Of Excellence Requires Additional Skills Also during the embedding phase, it’s important that all of the people working together on a cross functional team now share in the risks and rewards. If we’re going to expect people to work together towards a shared outcome, and not look out only for themselves and do work in silos, we need to spread the results of everyone’s actions across the team members. Phase 4: Infused / Integrated The final phase of cross-functional development teams is when the skills that used to be primarily sought by a dedicated member of the team around a discipline (again, Operations, QA, UX, Support as examples) are disseminated across team members. This is hugely beneficial since multiple team members can now provide help with more than one discipline, and it avoids bottlenecks due to individuals who are thought of as “the person” for a particular skill being unavailable. You can also watch this episode on YouTube.  Related resources: Continuous Delivery - Are You Missing The Big Picture?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Today I’ll share what I’ve learned over 10 years of first being a developer working directly for software companies, and then 10 years working as a software consultant. I hope this helps anyone evaluating the trade offs of a software developer vs consultant, and figuring out what’s better for your career. Influence The first consideration is influence. As an employee, your influence can sometimes be restricted by the position you hold. As a consultant, it tends to lend itself to you having whatever influence is necessary to solve the problem you were brought in for – at least at first. Business Perception Of Value Another thing to consider is how the business will perceive your value. As an employee, you can be looked at as a cost center, or a profit center depending on the business model of the company. As a consultant, your value to the business is typically a solution provider – you’re there to solve a problem, and ultimately to leave. Perception By Peers How will you be perceived by peers? As an employee, you should be treated as one of the family since you share the same benefits and struggles as the rest of the company’s people. As a consultant, peers will often look at you very skeptically at first – you must learn to be comfortable with this to fit into their culture. Key Traits and Skills What are some of the key traits and skills needed? As an employee the focus is often on your technical skills. Though soft skills and process understanding will help, most hiring managers focus heavily on technology above all else. Additionally, you’ll be considered for “culture fit” – which can be a real thing, or a wild card used to reject candidates in my experience. As a consultant, there are very different skills that will tend to help you be successful in the position. First, likability – people must like you to enable you to get the influence necessary to become a trusted advisor. You also need to be above average at communicating clearly, and tailoring information to different audiences. Lastly, an appreciation for and desire to understand the business in which the software development is done will help tremendously. Rewards Next think about rewards. As an employee, you’re usually going to make some adjusted version of the market rate for your skills, and optionally some options or equity. As a consultant, you’re either billing your clients at an hourly rate, or can charge a percentage of the opportunity you’re enabling. Growth As an employee growth will happen when the company needs it. So you need to grow on the side if things aren’t moving as fast as you’d like. A consultant has the potential to grow with each contract, but it can be stressful and fast paced. An employee can get recognition whenever they work on a successful product effort. A consultant gets less recognition that turns into a reward short term, since they depend on their firm rewarding them and they don’t always directly see the work. Ability To Change Work Processes Employees can change whatever work processes they want within the realm of their responsibility with reasonable ease. Consultants must prove themselves before they are allowed to change processes, but once proven it can be easier than an employee. 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

Are you asking team members or maybe your entire company to change the way some aspect of software development is done? Today I'd like to share why software development change initiatives fail all too often. The first thing people are most familiar with around a change is the communication. This can often happen in a meeting where leadership or a project manager states “what” the change is. Though this is a necessary part of the process, it’s bare minimum. The second thing people are familiar with is “how” the change occurs. What training, documentation, and other materials are needed to equip people with the tools or assets they need to make the process change? Next, you’re probably familiar with how interested most teams and companies are in governance. That is, how do we know how many people are making the change, and how successfully? Though it’s important when doing software development that change initiatives are accompanies by measurable goals or metrics, the biggest piece of the puzzle still needs to be tackled. To have the highest chance of a successful change, we must answer the question “what’s in it for me”? But from the perspective of each INDIVIDUAL we’re asking to make a process change or a tool or technology change. Before we can do that, we need to know people on a personal level. And to do that requires spending TIME with people and getting to know their unique circumstances, history, and life struggles and goals. When asking someone to make a change that in no way benefits them, often the best chance of success is to motivate them with some sort of reward. It’s a companies way of saying “we’re sorry you need to do extra work or work differently, so here’s something we want to share to show how we take into consideration to burden this adds to your workload”. In all other cases, understanding each person’s motivation, and what outcomes they might want to be supportive of a software development change initiative, is most often the key, CRITICAL factor in the success or failure of widespread adoption. People change most successfully when the reason for the change is not just communicated, not just understood, but aligned with their own goals! 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

Are you making decisions about what technologies and patterns are used in your software product? Today I’d like to talk about some considerations you may wish to entertain when you select technology for use on a product being delivered to customers with software. Evolving software architecture to adapt to product growth can help your team deliver faster and accommodate refactoring needs easier as the project progresses. We should determine how mature our product is in the market first. Geoffrey Moore’s famous book “Crossing the Chasm” describes how a product goes through segments of customers along the maturity of a product’s timeline in the market. In this video I talk about how to change the software architecture depending on where you are along that timeline as you chase market fit. Are you selecting technologies that are appropriate for how mature the product is? If you have team members who’s only work experience was on more mature products, they may need help with making technology decisions that are simpler and support the speed of change necessary for a less-established, exploratory product. If we select a comprehensive, full stack set of technologies for our minimum viable product (MVP), we can be susceptible to over-architecting. We can never make perfect decisions, but I recommend considering the maturity of your product in the market, and if choosing simpler architectural patterns and technologies might be better. Once a product has growth needs, the business should be profitable enough, with enough additional revenue, that updating the architecture to meet the new growth needs can be afforded. This takes pressure off the team early on as they are able to product changes for early customers to validate business ideas quicker. We should also consider the skill level of our team members, and whether they’ve mastered the foundational technologies upon which pattern and stack decisions are based. If a team is especially proficient choosing a more comprehensive stack may be appropriate. If not, it may make more sense to select the minimum viable set of components needed to simply produce changes to get that market feedback as you’re still crossing the chasm. It’s worth considering whether to innovate with our own frameworks or libraries when we select technologies for a project and how their patterns might benefit the software architecture. If we go this route, we should consider whether we really have the time and support from the business to train people on it, document it appropriately, and provide support for it. We might consider spending more time fully researching all available options for existing components and frameworks that meet the needs of the product first before innovating ourselves. Whether using nodejs, C#, Java, python, ruby – or any other core language, there are a huge number of available packages on the community to implement most concerns of a modern architecture. The exceptions to this are the “secret sauce” where your product provides its core value – but this is what you should probably spend the bulk of your time building – NOT architectural building blocks. You might consider resisting the temptation to select patterns and technologies that allow for future flexibility until you actually need them if ANY additional complexity is necessary to do so. Though this leaves you up to the chance to need to refactor at a later date, it also eliminates any waste spent supporting possible needs down the road that aren’t capitalized on. Emotionally detaching from having to think the architecture is “right” and will “never change” helps us have the mindset necessary to be more lean in how we develop software. I’d encourage you to educate stakeholders whenever possible on the realities of the architecture’s suitability for the product at any point along it’s market adoption curve. When businesses understand the implications, they are often very supportive, and will feel less frustrated when changes to the architecture are recommended by the team at a future time. Simple Strategies For Identifying When To Evolve So if we know evolving software architecture allows us to gain efficiency by being deliberate about it, how do we know when to actually make changes? The first thing I’d recommend is to bake monitoring of components and infrastructure into the development process. Whenever a change or feature is being designed, think about how to monitor its performance and anything else about it that might indicate a need to change the architecture. The second thing I’d recommend is to monitor the throughput of the team, and watch for any fluctuations. Though a team delivering slower than they had before can be for a variety of reasons (most often technical debt), it can also signal a need to make revisions to the architecture. You can also watch this episode on YouTube.  Related resources: Software Estimation - Trading Perceived Effort for Outcomes Scrum vs Kanban - How Do They Help You Be More Lean in 2017? Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Are you getting ready to redesign a new version of a digital product with software? Avoid the top 5 software redesign mistakes by software companies I see made all too often. #5 – Focusing On Current Customers It’s tempting to focus on what current customers of the product have wanted at the expense of NEW customers. If the goal of a redesign is growth, it makes sense to do market research and look at the product with an open mind. Do new customers have completely different needs than current customers do? #4 – Trying To Include All Features Of Prior Version Many companies spend too much budget and time trying to design a product that does everything the prior product did. A redesign is the perfect point in a product’s life cycle to look at it with a fresh set of eyes before making a reinvestment. Throwing off the shackles of the existing product’s feature set might be exactly what your team needs to envision a dramatically more compelling, simpler, and BETTER product for the market. #3 – Budgeting Too Little For Marketing As a digital software product becomes more established, many teams focus too much on the engineering side of the product. Is it possible that you might be better off budgeting a larger percentage of the investment in the redesign towards marketing? If you’re not doing Facebook advertising, Google Adwords, or Instagram posting to reach today’s audience you could be missing out on an extremely effective way to reach customers that you used to via a different source. #2 – Failing To Consider A Rebrand Though the benefit of an existing brand name and marketing message can be an advantage, depending on the age of your product and the needs of new customers, it may make sense to rebrand. This allows a team psychologically to detach from the prior product more wholly and look at the new version through a completely different lens. Might this be a strategy your company could use to bring life back to a product that’s no longer as compelling and exciting for the market as it once was? #1 – Failure To Establish Measurable Outcomes The biggest and most common of the software redesign mistakes I see made is unfortunately the failure to truly establish easily measurable outcomes for success. As a project gets underway, unless design decisions were made to accomplish easily measurable goals, it’s easy for the team and management to lose sight of the purpose and simply look at the redesign as a “project” to be completed. It’s a huge opportunity to reach some exciting goals for everyone, and it provides cause for celebration to all those who were involved as they discover what the market wants! You can also watch this episode on YouTube.  Related resources: How To A/B Software Development To Find What Customers Value   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Let me share some stories today that will present at least 5 ways pride kills a software project. At the end of the video I'll share three strategies I've used to fight pride. The first way pride can kill a software project is when we become too proud of an opportunity to lead. At the beginning of my career, I had an amazing opportunity to lead a team to build a software product using a new technology. I was inexperienced, and my pride caused me to be resistant to work with more senior people. It didn't take long, but half my team was resistant to my changes and they wanted to see me fail. Ultimately I was given the opportunity to work on a different project but it was really because I was so difficult to work with. The second way pride can kill a software project is when we become too proud of a select group of people. On a project where I was able to work at a new company with many people I'd worked with before, we created a clique and didn't respect and work with the existing teams at the company very well. In short time our project's success was at risk because we didn't get buy-in from the others on the team. We were too proud of those we trusted, and didn't work hard enough to get the others we should collaborate with to understand that we respected their value. The third way pride can kill a software project is when we become too proud of past successes and efforts. I was helping a client at the consultancy I worked for, and there was a person there who was very senior and experienced, but he wouldn't change. Everyone in the company respected him - and they wanted to see him rise to the occasion, but he just wouldn't budge. When we become too proud of the work we've done to gain skills, we can start to get resistant to doing the work it takes to stay relevant and GROW. Eventually this individual did come along to his senses, but it was painful and wasteful for a long time and caused work to be difficult for many others until that happened. The fourth way pride can kill a software project is when we become too attached to our ideas and their potential value. I was helping another client where they had asked our consultancy to build a product. We warned this client that what they wanted to build was too risky, and that the budget they had allocated put too much risk in all of their ideas being good. Though we tried hard to convince the client of the importance of our approach, and how software development is different from manufacturing, ultimately we did the work the way they asked. The end result was that the business folded, because they didn't profit enough off their ideas to pay back the investment in the development. The fifth and final way I've seen pride kill a software project is when people have too much pride in the way a process was done before. At a company I worked with, the process that was used for selling needed a change. Many of us at the company had seen a shift in the industry, but key people in the sales department refused to entertain our ideas. Though it was understandable that as not being in sales outside "technologists" trying to influence their process may have felt off-putting, it was out of our genuine concern for them. We wanted them to see that customers now wanted lean software development, and our company culture had to change to continue to deliver what the market wanted. There are a few ways we can also fight pride. The first thing we can do to help fight pride getting in the way of our career growth and successful software projects is to simply cultivate gratitude. By being more grateful of what we have, we have less attachment in being right, rewarded, or having certain outcomes - and this gives us the courage we need to try new things. The second thing we can do to help fight pride is to see the potential in other people and the value of their ideas. If we always look to others to do things how we do, and we only evaluate others based on how often they are supporting our ideas, we miss out on the ability to benefit from what they might bring to the table. It helps us be more humble when we keep an open mind to the value of others at all times. The last thing we can do to help fight pride is to encourage risk taking at our company and with our people. With risk comes reward, and working at companies that only take small, calculated risks only produces minimal improvements. It also creates a culture where people are unable to be as creative, and produce the innovation and efficiency breakthroughs necessary to really move to the next level. A leader of a team who knows the importance of this will harvest the best ideas from their people. You can also watch this episode on YouTube.  Related resources: Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Companies need to start to A/B software development to find what customers value. Relying on planning up front based on customer feedback and research just isn't competitive anymore! Software development is not like manufacturing. We don't have to make sure it's perfect before we start to build. In fact, that's not a very agile approach - and we'll too often build things that waste money! When we do lean software development, we look at a lean canvas, or a business model canvas, and figure out which aspect of the business we want to impact through a change. We need to design an experiment to test that change, and part of lean product management is setting up these experiments so we can test whether the experiments we run are pointing us towards the impact to the business we want to make. We need to choose a measurable outcome to impact first, and figure out how to measure it. What will constitute success? Next we need to make sure we know how we will serve both the old (pre-change) version of the product, AND the post-change version to an audience of the same size to see which one "wins". This is known as cohort analysis, and will help us avoid vanity metrics (measurements that don't really represent an improvement). When we serve both versions of a product (with and without a change) to a cohort, we need to determine how long the experiment will run. When the experiment ends, we have a learning milestone where we look at what was gathered, and decide whether to pivot or persevere. Traditional project accounting looks at % complete to determine how efficiently a team is using budget to complete an effort. In lean software development, we need a new approach. This new approach is called innovation accounting, and it instead measures the business on how effectively it is learning about where its assumptions about what's valuable are right and wrong. To use innovation accounting will require getting leaders on board. Unless we change budgeting to account for this, and convince anyone who was involved in the prior software project budgeting approach to use innovation accounting - we'll continue to deal with "change requests" or asking for more budget after we learn, and it looking like a failure on our part. Innovation accounting is a concept introduced by Eric Ries, author of "The Lean Startup". You can also watch this episode on YouTube.  Related resources: "The Lean Startup" on Amazon Principles of Lean Product Management by Jez Humble Continuous Delivery - Are You Missing The Big Picture? Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

To release software smoothly, avoiding time wasted troubleshooting infrastructure issues - you might consider automating your infrastructure as code. To achieve continuous delivery requires thinking about how technologies like chef, puppet, ansible, docker and the like might serve this need for your team and organization. The first step is to determine an approach for using images. If on premise, you might create one that can be used when initializing a virtual machine. In the cloud, this image might be used somewhere like docker hub, or in windows azure or amazon web services (an ec2 image). Jez Humble refers to computing resources and environments that have not had their infrastructure controlled as "works of art". I love this term, it accurately describes the confusion around how a node of infrastructure got into a state. To avoid this, we should use infrastructure provisioning tools against the computing nodes we "stand up" from an image. These tools will run a series of steps against a node to put it in a given state. An important thing to consider when embarking on the journey towards infrastructure automation is whether the company has the discipline to not make manual changes. If this is a new concept, a tool like puppet, ansible, chef, or the like can help by checking to see whether a node is in a given state and only applying the necessary changes. These checks come with additional processing power (and hence time) however, so in a company that's more mature in how it uses infrastructure as code and automated deployment, it may make more sense to use something that doesn't perform these checks - instead assuming nodes are already in a state. A common practice is A/B releasing, which can be used to switch between an active and passive set of nodes in production, or any other environment. This makes deployment faster, and also allows rolling back a problematic deployment easier. A/B releasing is different than A/B testing - the former helps with deployment, the latter with validating that changes had the business impact we theorized. I'll talk about A/B testing more in a future video. I recommend in this video to use powershell, bash, or a similar technology as the "trigger" of any automated deployment or infrastructure provisioning process. This avoids vendor lock-in and provides the most future-proof flexibility in combining the many tools modern vendors can use to make changes as the product evolves. Though there are fantastic tools such as terraform that have a wide reach, able to make changes in cloud AND on-premise environments in both amazon web services (AWS) and windows azure - I've yet to find one tool that can do everything. Regardless of the technologies you choose to use, select a language or syntax that will be most comfortable for your team's existing skillset. For example, if those who will automate infrastructure are object-orientated programmers - a tool like C#, ruby, or python may be sufficient. On a team with a more "traditional operations" set of skills - bash or powershell is probably going to be more approachable. You can also watch this episode on YouTube.  Related resources: How To Use Configuration Management For Continuous Delivery Of Software Development Environments - Isolating Customers From Your Changes Continuous Delivery - Are You Missing The Big Picture?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

As described in the video on isolating customers from your changes, there are typically a minimum of three environments into which software can be deployed. There are configuration settings used by your application, service, or product with software that need to change depending on the environment. These are called environment-specific configuration settings, and this video describes an approach for managing their values. You may have configuration settings in several files like the web.config (.NET), database.yml (rails), or .json files (nodejs) as examples. The settings in these files that are specific to an environment need to be set appropriately whenever your product and its components are deployed. Though there are utilities and tools often available that will set these appropriately for each type of file, this makes deployment more complicated since there is still duplication. The same database connection may exist in multiple files that all need to access the same database, but are for a different technology for example. Rather than using these technology-specific approaches, a more efficient method that will help your team be more agile is to centralize all environment specific configuration in one master file or list. Then you need to use some script or technology that can read those settings and overwrite the values in the source code or configuration files once deployed to an environment to the correct setting. The more configuration settings your application has, the more important it is that you create automated tests to verify that they work properly. One of the most costly ways to deliver software is to have an extremely flexible set of configurations and not have an automated way to test all of the combinations. The time spent manually testing this is much less than the investment necessary to build out the automation - and will pay you back time and again in time to market with future changes. You can also watch this episode on YouTube.  Related resources: Development Environments - Isolating Customers From Your Changes Continuous Delivery - Are You Missing The Big Picture?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

To release software to your customers, you'll probably need several development environments. To allow a team to make changes to software without disrupting paying customers, we need a way to isolate them. Software developers and engineers working on an agile software development team need an environment where they can make changes under development. The development environment might be a copy of a website, database, or API on their computer. This is sufficient for a product with a minimal footprint. In a larger and more complex software product, cloud or server resources in a datacenter may be needed to support development environments. In addition to a development environment, most teams need somewhere separate from development and production to do additional testing. This can be known as the "test", "user acceptance" (UAT), or "staging" environment and allows the team to more closely inspect a version of the software slated to release. The final environment that is always required is production itself - or the place where your paying customers use the software. In addition to a development, test, and production environment - there are two other environments that can be fairly common. One of these is a demo environment, who's purpose is to provide a playground or sandbox where a limited audience can "kick the tires" of the software without disrupting the development team. The other common environment is a capacity test environment, who's purpose is to determine whether a potential release of the software will stand up to a real load. Capacity test environments should have the same hardware or cloud processing power as production, to provide testing results that are representative of real traffic on the same computing power. Regardless of which environments your company or team uses to release software, you'll need configuration management to automate releases through these environments. I'll talk about configuration management tomorrow, and how you can use it to make sure releases of the software in a given environment don't accidentally point to the wrong environment's resources. You can also watch this episode on YouTube.  Related resources: Continuous Delivery - Are You Missing The Big Picture?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

You probably know you need to use Continuous Delivery to release software to your customers. There's much confusion in the market around Continuous Delivery. How does it relate to Agile Development? How does it relate to DevOps? In this video, I'll demystify Continuous Delivery by helping you understand the big picture. It's a capability - not a technology. The key innovation is reducing your cycle time. This is the length of time from when the business or customer has an idea, until it's available to users. To reduce cycle time, we often need to use automation technologies so less manual work is done between releases of our products. Operations personnel, in a traditional software company, are the keepers of production and have the keys to that environment. These folks are typically motivated by keeping the system stable, since they are measured on uptime and performance as examples. Developers are often measured on their ability to introduce change, and so their motivations are often at odds with operations. DevOps is about bringing these two disciplines together to overcome this psychological barrier so companies can truly be more agile. In a lean company, that's delivering software frequently to its customer for feedback - automation may not be necessary however. You can achieve continuous delivery for a small product or project through manual deployment - assuming the appropriate quality checks and process are in place. The most important thing about continuous delivery is reducing cycle time, so whatever you need to do to achieve that is getting you closer to that capability. Try not to get caught up too much in whether your team is using the right technologies to achieve continuous delivery. It's about cycle time - period. If you are in software product management, understand that this capability is what will help your team deliver software in a lean fashion. This capability is a necessary practice if you wish to get feedback from your customers in a fast enough time to take action on it. One of the most common aspects of releasing a software product that increases cycle time is automated testing. You don't need to do test driven development (write the tests before the code), but you absolutely must have whatever tests /are/ written be AUTOMATED. You can also watch this episode on YouTube.  Related resources: Scrum vs Kanban - How Do They Help You Be More Lean in 2017? Minimum Viable Product - Letting Software Customers Help You Profit Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Why are some companies able to engage in creative software development, while others treat it like manufacturing? Since the work we do to develop software is “knowledge work”, it benefits from the ideas and experiences individuals bring to each problem. Many companies look at the envisioning phase of an idea that’s developed with software as the primary process that benefits from creativity. Selecting the solution used to develop a feature or idea, equally benefits from creativity. So how can we maximize this? Inspiration is the spark that someone gets when exposed to something created by someone else. A piece of music, a fine painting, a software technology etc. Creativity is the work we do to form and shape that inspiration into something tangible in the real world. Being creative takes energy, so many of the things we can do to maximize energy, will also maximize creativity. People are less creative when constraints are placed on what they can change. Freedom allows for more creativity. We can provide technologists with more freedom by encouraging them to make healthy lifestyle choices. We can also provide technologists with more freedom by not allocating them to high levels of utilization. More free time = more opportunities to explore different solutions. These different solutions can have explosive impacts on efficiency. When teams are free to think outside the box and bring their full intuition to bear, problems once slated to take months can be solved in days or even hours. When making decisions about how we plan work, or what the culture at our companies is like – are we optimizing for creative work? Are we focusing on the illusion of predictability and control, using mathematical equations to feed our ego so we can feel like we’re getting the most out of people? Or are we creating an environment for software development that breeds creative ideas, treating people as sources of creativity and not just productivity units? Management and companies historically do a poor job motivating individuals to make better lifestyle decisions to have more energy so they can cultivate higher levels of creativity. You as an individual on a team must decide how important being innovative in your problem solving in your career is, and possibly make some lifestyle choices if you wish to reach your maximum potential. You can also watch this episode on YouTube.  Related resources: Principles of Product Development Flow (Amazon) Software Estimation - Trading Perceived Effort For Outcomes Minimum Viable Product - Letting Software Customers Help You Profit Lean Software Develpment - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Embarking on the journey to let customers lead YOU to the most profitable solutions? You’ll probably need to decide between the two most popular ways agile teams work, and I’m here to help you make that decision. Scrum is a great process when your team needs a scheduled checkpoint for how well they are doing. It is also great when the customer can only respond to change every couple of weeks. Kanban is superior when trying to use your resources to their fullest capacity. It’s also superior when your team needs to adapt to change without time wasted waiting on each other. My vote: Kanban! BOTH processes can be used in a lean fashion, but I just find Kanban supports adapting to uncertainty more fluidly. ​Kanban also lets team members work at their own pace, and do the work they enjoy most – not forcing people to attempt to work at the same speed and rely heavily on estimates being so accurate. Caveat: If you’re going to use Kanban, schedule a regular checkpoint to continuously improve processes by having a retrospective. REGARDLESS of which process you use, the same rigor you’d use on a waterfall project must be followed before any kind of estimate should be communicated. Requirements (or user stories), ACCEPTANCE CRITERIA, infrastructure changes, user interface assets, technical documentation, support & monitoring needs – figure it all out first! If this seems like a lot to figure out for one story – it is! That’s why stories must be small… A team that is learning to truly “continuously deliver” value to their customer in small batches must reduce the business’ expectation of the RATE of product change. There will be less released at once, but what is released will be HIGH QUALITY and ready to go to production immediately! So how does a team prevent changes that aren’t ready for production from going out with those that are? Feature Branching! *BZZZT* JUST KIDDING! Use /Feature Hiding/… Use configuration settings to hide work underway so it doesn’t block releases to production. When a feature is ready to go, just switch the configuration change on the next release! This forces everyone to continuously integrate changes into the trunk (or “master” branch) which is a key principle of *cough* continuous integration (yes, the name means what it says). You can also watch this episode on YouTube.  Related resources: Continuous Delivery (Amazon) Introduction to Scrum - 7 Minutes Kanban 101 - What is Kanban? Lean Software Development - It's About Uncertainty! Software Estimation - Trading Perceived Effort for Outcomes Minimum Viable Product - Letting Software Customers Help You Profit   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

It’s human nature that businesses have a desire for software estimation. For projects with a fixed scope, typical estimating methods can be off by as much as 70%. And that’s a product that doesn’t adapt to user needs. If you desire the economic growth that comes from building winning products for customers, the numbers will be even worse. The short of it? Don’t bother! Pick a budget for what you can afford each month, and let a qualified development team or consultancy tell you if they can build a minimum viable product (MVP) in 1/6th to 1/12th of that budget. This will produce your core theory of value and two delighting features early, with monthly budget left over to adapt to changes. If you find that the product needs to change spend some budget on those changes. If you find that the product needs to improve in quality, spend some budget on beefing up testing. Software projects don’t fail because the product couldn’t get built in time – they fail because they DON'T DELIVER VALUE high enough to justify the investment. To reach this high level of value means spending less time envisioning, and more time ADAPTING. The only way to do this is with a laser focus on the core theory of value, and a budget that will last through several feedback cycles. Any time a product owner/manager or non-technical person of any sort asks for an estimate, they create anxiety in those doing the work. Experienced technologists know the number of variables in software development is ridiculous, and systems that have been created so far to account for all possible outcomes fall far short of being helpful. Though we may need to estimate whether we can deliver the core theory of value within a time frame short enough to get feedback, ongoing estimation should be unnecessary if budgeting of software is done on a subscription-based, value-focused basis. Software businesses must ensure that insights about how the product is being used are recorded with every release of the product. Minimal change must be introduced each release, to allow for A/B testing to determine whether a change had the desired impact on business outcomes. How business outcomes are measured is specific to each business, but these must be determined and agreed upon BEFORE development of any feature that will impact them starts. The effort of a successful software project focuses on measuring whether each release is getting the business CLOSER TO AN OUTCOME, not closer to completing a FIXED SCOPE OF WORK! This paradox can be hard to wrap your head around, but it must be fully appreciated to operate in a truly lean fashion. Determine what you can spend per month, get started, and adapt… TRUST THE MARKET, not your ego! You can also watch this episode on YouTube.  Related resources: Principles of Product Development Flow (Amazon) Minimum Viable Product - Letting Software Companies Help You Profit Agile Project Management - Is It Stopping You From Being Agile? Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Companies can miss out if they don't have the right mindset for agile project management. If your team is pursuing agile practices but doesn't feel that the benefits to the company are delivering on the promised industry hype, this video will explain some of the reasons why that may be the case. I discuss how traditional project management techniques are often applied to software development projects, and the "agility theater" it can cause for teams. It's important for teams who are new to using agile development that executives, customers, and all other staff that work on the project understand the implications of the new approach. The most common misunderstanding I come across is a lack of appreciation for the trade off of agility (a positive effect) for predictability. If a company wishes to adapt to the changing needs of their customer and the market quickly - they must become comfortable with uncertainty, and LET GO of the illusion of control. Estimation specifically is an activity that can cause a great deal of confusion, wasted time, and unmet expectations when working on products that choose to have some form of Agile Project Management. I'll discuss this in more detail in a later video. Regardless of how far along the agile journey your company is, beginning to have the tough conversations with stakeholders about WHY we choose agility, and how treating projects like a traditional work effort such as constructing a physical building doesn't apply, can be the breakthrough you might need in becoming a lean organization. During this video, I also briefly mention a traditional software project management tool known as Gantt charts - which I believe are practically USELESS on agile teams. The number of times a project goes according to the chart is practically zero. I'm sorry to report that over the past 17 years of my career (since agile development was introduced) - teams that are held to Gantt charts can easily fall prey to "faking" deliverables as being done just to make it look like they hit their schedule! You can also watch this episode on YouTube.  Related resources: Lean Software Development - It's About Uncertainty! Project Management - What Is A Gantt Chart?   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Whether producing a software product for a new market in a startup, or introducing a major change in an enterprise - planning a minimum viable product is a good idea. When building a minimum viable product (MVP), you should select a feature that shows users your core value proposition, as well as two features that "delight". The core value proposition is a part of the Business Model Canvas, a visual tool created by Alex Osterwalder that you can use to determine which aspect of the business is being effected by a change. The "delighting" features provide something sexy for users that attracts potential customers due to it's sleekness, innovation, or ease of use. When planning what goes into an MVP, don't budget for only the MVP. Budget for enough to build software for 6-12 months that will adapt to feedback. Spend a small portion of the total budget to release the MVP, and use the majority of the remaining budget to adapt so you can deliver exactly what customers want - and in the way they want to buy it. These other "ways" than the product's features itself are the other aspects of the business model canvas. If you only budget enough for the MVP, you won't have money left over to adapt. Adaptation is the difference between a product that "meets needs" and one that "exceeds expectations". It is this latter category of products that cause companies to be leaders in their market and cause substantial growth. When selecting technologies for the MVP, don't box yourself into feeling you need to use technologies already familiar to the development resources you might have. Hiring a specialist in a technology that is faster to build prototypes and minimal products in can save substantial money. Should the market lead you to find that what you've built is successful, you can always change the technology used down the road to meet scaling challenges, if the original technology can't handle the volume. This is a GOOD problem to have, and means you've found a large user base - but until this happens, don't spend the time and money planning for it! You need as much budget as possible to simply ADAPT at first, and so your money is better spent with excess funds for adaptation than building out an infrastructure or technology stack that assumes a size of user base you don't yet have. You can also watch this episode on YouTube.  Related resources: Lean Software Development - It's About Uncertainty! Agile Project Management - Is It Stopping You From Being Agile? The Business Model Canvas - 9 Steps To Creating A Successful Business Model - Startup Tips   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

In the first video in my series on Sustainable Software Development, I explain how Lean Software Development avoids a company becoming irrelevant in today’s shifting technology market. If you’re looking for the reason why lean software development can be the difference between software projects being fun and innovative, or grueling and underwhelming – this video will provide you with some guidance. I discuss how the software development industry has focused on agile software development methodologies like Scrum, DevOps, and Continuous Delivery but that these don’t get the results companies are looking for if not used with a lean mindset. I discuss the fact that working in the industry continues to be highly uncertain, and so we need strategies that deal with anxiety and reduce pressure to help us sustain our careers. I mention how the industry’s focus on technologies and process distracts us from value. A business must always be profitable, and without a focus on customer value and a culture of learning – you’re dead in the water. I don’t want to see passionate technologists and successful companies fall into the trap of thinking they only need to add features to a technology product or service to sustain profitability and innovation. ​Lean software development will ensure that the way teams work, and the way changes are rolled out to customers, puts the market in the driver’s seat to direct us where we’re headed. Developing software is more like steering a ship than building a skyscraper. We chart a direction to go, but we ASSUME that the winds will blow us off course. So we need to use tools and techniques that let us steer quickly. As I share strategies for sustainable software development on this channel, we will choose tools and techniques that allow us to adapt and respond gracefully as things change. 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