Healthy Developer

It's common in many companies for there to be animosity between programmers and managers – but it's smarter to consider healing that rift. Earlier in my career I met many other software developers who loved to complain about management. And I've been just as frustrated, especially when it seems like management doesn't know what they're doing. But eventually after having several experiences talking to other programmers I respected, my perspective changed. In this episode, I share some stories about software projects I have been on where I was challenged to be enlightened to continue. I hope these stories help you think about what you can do to take the power of your career back into your own hands. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Does it ever feel like the daily scrum meeting is really just a status meeting in disguise? The daily scrum or "stand-up" meeting was created as part of the scrum methodology for agile development to reduce time wasted in meetings. But some companies use it to gather status. In our modern software development market, there are many tools that can provide managers with real-time access to status, so this is unnecessary. In this episode, I share several tips for getting your daily stand-up meetings under control so you can run a daily scrum that actually benefits developers. Though it's tempting for management at software companies to use the daily scrum meeting to gather status, they actually make the job of software developers harder by doing this – and put their software projects at risk! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It can be confusing when most companies don't make it clear how software developers can get promoted for more senior roles. If you're a junior developer and trying to figure out, what exactly do I need to do? – it may not be cut and dry. Rather in this episode, I share some soft skills I've found in working with over 30 software development teams that I see those who get promoted exhibit. If you want to be considered for a senior software engineer role, or perhaps a higher level role such as a team lead, development manager, director, or even CTO – these skills are incredibly valuable. They will make you stand out from other candidates and naturally be seen as a more mature option for a technical leader. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Software developers are often frustrated when a product manager changes the design at the last minute. But product managers are a programmer's best friend! In this episode, I share how your colleagues in product management are actually your biggest ally. Whether you're in Operations, UX,Ssupport, or any other aspect of developing software – a good relationship with the manager of your product is indispensable. As the "CEO of their product", these individuals have access to resources and the ability to influence the company in ways you may not have thought of. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It's tempting to jump into refactoring code that's hard for you to understand – but make sure you're doing it for the right reasons! But before you take that leap, you should probably consider that there can be some dangers. Whether you're coding in Java, Javascript, C#, Python, or any other language – there are non-technical implications of code refactoring that you should be aware of. In this episode, I share 6 considerations to take into account that will help you avoid getting into a stressful situation when you choose to refactor code. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Have you ever been confronted with accepting circumstances you couldn't change on your software project that were really difficult? Maybe you don't agree with a decision, or you've been forced to work in a way that you're not happy with? Though most of us like to think we're able to control our career, there are times we inevitably have to learn to let go, and accept difficult circumstances. In this episode, I share a set of steps I go through to help me on software projects when I struggle with this. If you can accept difficult circumstances easier, you can get back to enjoying your software development career. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

In working with over 30 companies, I've seen 7 common big FAILS in agile software development processes! These are so common, but so easily avoided, and they have little to do with whether you're doing kanban or scrum. In my experience, agile issues are rarely because of a single step in the software development process, but rather because of not considering the implications on the team. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

There's something about software development that makes it hard to stop thinking about programming after work. Earlier in my career when I'd be obsessing over programming, I would get home and right after coming in from the car jump into a video game or play some music. But it didn't last very long. I quickly became a workaholic programmer. When I wasn't thinking about code, I would sometimes wake up in the middle of the night and start thinking about it them. I even had dreams that I was in a whiteboarding session. Have you found healthy ways to stop thinking about programming when you get home? Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Why does it seem like no matter how strong your argument, some programmers never agree with you? In software development we often focus on practices like agile development, unit testing, or code reviews. But these are actually driven by underlying principles that guide the practices we select. Some good communicators will be able to say what their principles are. But even then, you'll come across someone who just will not agree with you no matter how well you understand their principles. This is because there is usually a core limiting belief that lies beneath their stated principles. The only way to find these beliefs out, is to have an authentic relationship with the person. As a software developer, engineer, or consultant we often spend most of our day in front of the computer. So getting to know someone personally can be socially awkward and feel like it's taking away from our productivity. We can ask "why" questions, as described in the "5 whys" concept popularized by Eric Ries, author of the lean startup, to get to root beliefs. Armed with this information, we can broaden our belief system to understand the other person better, or help them get rid of a limiting belief that may be holding them back! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

If you've ever been on a software project and wondered: "what's the impact of the work I'm doing?", impact mapping will help you immensely. Knowing what your code is worth, or any other assets we create on software projects across any discipline (UX, QA, Infrastructure, Operations etc.) is crucial to both getting the rewards you want, and steering the company in the right direction. In this episode I share how impact mapping can be used to identify a goal from a business model canvas (described in detail in my prior episode, link below) and map it to work team members do. With a better understanding of the impact of your work, you can communicate things like "why are we doing this?", "what is this work going to enable?" and "how do we know when we're successful?". Impact mapping can be used not just with software development activities like programming and testing, but also with any activities, features, or tasks a team might consider to impact the business. Advertising, partnerships, cost reduction, and other aspects of a business also benefit from having a map of impacts. If your company hasn't shared this information with you, have a conversation with your product manager or CEO to see if they can provide some insight to your work's impact. An important point I highlight at the end of the episode, is to not budget only for a single experiment identified through an impact map. Most software development investments fail to fully realize their goals, so budgeting for multiple experiments will help. This way you won't have to go back to the business for more money after a "failure", and instead get multiple attempts to reach the goal through trying several things that have an impact. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

If you've ever thought "who came up with these ideas?", you probably need a business model canvas on your agile development team. Even if you don't consider yourself able to steer the direction of a software product (you're a programmer, in UX, operations, QA etc.) it's critical that sound decisions are made about the business. Without a comprehensive plan forward, ego can easily take over your agile backlog. In this episode I share what a business model canvas is, examples of common software products and how the canvas (also known as a lean canvas) can help you as a software developer or any other discipline on your team. The business model canvas, business canvas, or "lean canvas" has been popularized by Eric Ries, Alex Osterwalder, and Ash Maurya. It divides up the aspects of a business into 9 sections that a software company should experiment with to increase profit. When your team is deciding "what features should we build in our software?" the business model canvas should be the first lens through which decisions are looked at. Any user stories your team adds to their backlog should tie back to these sections of the business model canvas, otherwise they can easily be "gut decisions" with no sound business backing. The canvas can provide your software development team with an array of potential opportunities to explore, other than just "cranking out features". Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It takes special software leadership skills to learn what customers want through lean software development. In this episode, I share 7 key traits that will help you, or someone else you know who's leading, to build the most profitable software ideas for customers. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Why do some software companies build exciting products with the freedom of a lean startup, while others deliver boring products like a feature factory run by control freaks? In this episode I ask this question: "Does Your Company Feel More Like a Factory, or a College"? Whether you're using agile methods like scrum, kanban, or any other process – up front design is still alive and well in many companies. To truly build innovative software products that cause your company to profit so you can get the rewards and recognition you want – people must let go. When features are identified has a big impact on success. Many companies focus mostly on the features for their software that they can think of or hear from customers ahead of time. But it's those features discovered only after you release your product to them using devops and continuous delivery approaches, with an agile budget, that cause you to profit greatly. This is the approach popularized by Eric Ries book "The Lean Startup". Companies run like a factory try to predict value, while companies run like a college discover value. Companies run like a factory control people, while companies run like a college trust people. Companies run like a factory use burn-down charts to measure progress, while companies run like a college use learning milestones. Companies run like a factory use a project budget, while companies run like a college use a monthly budget. Companies run like factory focus on measuring expenses, while companies run like a college focus on measuring profit. Do you work at a company that feels more like a software factory (or feature factory), or a college? Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

In the first decade of my career, I would get angry at everyone around me and turned to the Internet to vent my frustration. It seemed like managers and other people who didn't understand software development had caused me to lose hope in my future. In this episode, I share what caused me to lose hope, and many programmers I run across struggle with these symptoms as well. If you're a programmer who has turned to escapism and joining the chorus of complainers – I implore you to reconsider! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. CHAPTER MARKERS (3:00) We're Forced to Cut Corners (4:33) Cognitive Overload (5:17) Low Perception of Value (6:50) High Income Forces Deeper Goals (8:31) Learned Helplessness (10:38) Say No With Grace (12:45) Communicate Uncertainty (15:28) Ask for Help Earlier (16:48) Develop Empathy (18:24) Surround Yourself with Positive Devs Visit me at thrivingtechnologist.com

If you want to be a calm programmer, you may want to consider cutting down on caffeine. On a project that's truly agile, most people need extra patience. Especially if they have high anxiety from using coffee or other stimulants to get through the day. In this episode, I share some things you may want to know if you want a sustainable career in software development. Though you may not be able to completely cut out caffeine, it can wreak havoc on you and your team's ability to work together well. When work is already difficult, and people are under stress, caffeine only tends to make things worse. I hope these tips for avoiding caffeine withdrawal help you to stay a healthy programmer! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Have you ever had an idea for something on your software project, but someone else takes the credit? Plagiarism can be extremely frustrating, and it's typically caused by narcissistic personality types. In this episode, I share why this happens, how to prevent it – and how to cope with it. I also share a personal story of when this has happened to me. This sucks, there's no way around it. But if you're creative enough to come up with new software development ideas, you can do it again! I hope this episode helps you avoid this situation in the future, and have a healthy mindset if you unfortunately do get plagiarized. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Looking at what decisions others make about their career in software can be a big mistake. Though having a career in software development can be exciting, there is also cause for serious caution. In this episode, I share the 5 biggest lies I have bought myself, and I hope you don't about your career in software development. With healthy decisions and a realistic mindset, you can advance quicker than others and not get stuck in common traps. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. CHAPTER MARKERS (1:40) Technical Skill Determines Your Success (2:40) Harder Work Gets More Done (4:16) Past Success Determines Future Results (6:27) Bigger Companies Have Better Practices (8:56) Promotions Are Proportional Visit me at thrivingtechnologist.com

If you feel like a "code monkey" with pressure to work fast – you need an agile budget. It took me many years, but I finally figured out the reason why. Companies that try to build software like a manufacturing plant budget the wrong way. This creates pressure on workers, and produces boring products that barely keep a software company profitable. At companies that understand this, you'll be more creative and spend less time trying to estimate. If the leaders at your software company don't understand this, they may still have a (barely) profitable business, but they'll be wasting tons of money. In this episode, I share hard learned lessons about the software industry that every company should build their foundation upon. Agile budgeting is a key to healthy software development company culture – and careers! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

If you've ever had to estimate software development work, you may have engaged in "planning poker". This method of estimating brings with it some potential benefits. But depending on the culture of your team, it can also cause big problems. In this episode, I hope to avoid you falling into using this common practice if it isn't right for your team. Planning poker might be just what your team needs – but you need to make the smart choice! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

I gained weight quickly from programming and needed help with weight loss early in my career. I took part in the corporate events that provided unhealthy food because it was "there"… I was accepted easier by my coworkers because I would eat the same fatty and high calorie meals that they chose… And I fell into emotional eating, because the stress of software development was depleting my diet of nutrients. So I started to tell myself "losing weight is vanity – I'm not one of THOSE people". But in this episode, I share my personal story of weight loss after ballooning up to over 210 pounds. I hope my story helps someone else out there who is struggling with the lifestyle of programmers that can make it hard to stay in shape. Corporate culture won't always make it easy – but you're worth it! There is hope for you – losing weight is not impossible, but you've got to stand your ground! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Too many companies and agile coaches keep the secret of scrum from people! When agile methods of software development were first brought on the scene, they led to abuse. Managers "cherry picked" the practices that gave them more control, but software products didn't actually get any better! In fact, when you ask most programmers or other software professionals Scrum seems to add MORE pressure and problems. In this episode, I share the secret of Scrum. If your company doesn't know this secret, you're wasting your time because the word "agile" means NOTHING! If you don't understand why scrum doesn't work, I hope this episode offers some insight. Using a sprint in scrum can cause more problems than it's worth – without the right mindset to learn from failure. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Are you on a project with a software leader who's a narcissist, and criticizes everything you do? Did they treat you like a "rockstar" developer at first, but now it seems like you can never please them? Working under a narcissist can be one of the most frustrating experiences in your software development career. In this episode, I share some key traits and behaviors to look for in identifying if you're working under one. Though people can exhibit several of these traits and NOT be a narcissist, if you see a pattern of several of these behaviors – BEWARE. I hope this information helps you identify whether you're being abused emotionally – and cope until you're able to get out. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

I hear a common complaint that programming has gotten harder over the years. The more years I spent in software development, I fell into getting frustrated and blaming other people, or the technology. But I realized that I was a big part of the problem – though it was hard to admit. In this episode, I share some things I didn't realize at first that I was doing to make my job harder than it needed to be. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Ever get the feeling the software project you're on clashes with your personality? Does the way people work together seem very different than you? Have you had a great experience on one project, only to start enough and feel miserable? If this has ever happened to you, I hope today's episode helps you avoid this. Depending on the stage of a software product's life cycle, you may or may not be the right fit for a team. This has nothing to do with the programming technology stack, operations procedures, or software development process. It has more to do with your goals and preferences at this single moment in your career. I explain how the early, growth, and sunset stages of a typical software product's profit life cycle impact your happiness. Armed with this information, you can make the best decision in your software development career and hopefully find the perfect software project. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Do you have a feeling that the software product you're working on is reaching its end of life? Every software product goes through a sunset stage as part of its life cycle. This is a natural progression of your software business, but it needs to be handled carefully. In this episode, I share some considerations your development team can apply to navigate this stage better. If you want to ensure that your software development career keeps moving forward, you need to understand this stage of the life cycle. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Have you seen the signs that your software company is profiting and may have reached market fit? The way teams work together needs to change when a software product reaches this critical point in its life cycle. That doesn't mean innovation stops, but a focus on moving towards partnering and stability of technology becomes increased. In this episode, I share some insights I've had about how software teams can go about navigating this difficult phase in the life cycle of a software product. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Are you concerned that your software company isn't setup for growth? In working with over 30 companies, I've come across many that don't understand the software business life cycle. This episode offers some essential information you can use to understand how your company is being managed. The foundation I provide here can help you determine where in the life cycle of your software products the team you might be working on is at. This will help you make better decisions about technology and software processes – and I'll expand on it in future episodes. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Why do software companies try to innovate under a culture of fear? Does the software company you work at frustrate people with a focus on cost savings over GROWTH? In this episode, I share some critical insights to how many companies strangle innovation by managing to fear! Armed with this information, you can stop feeling like a cog in a wheel – and help the culture at your software company improve. If you've had agile coaches, DevOps experts, and other "gurus" try to help your company and it still feels like a pressure cooker – this might be why! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Have you solved programming problems easier when "in the zone" or "flow state"? If you've experienced this, once achieved it's hard to work any other way. In this episode, I want to share some strategies you can use to avoid getting interrupted. These will also help you get into the flow state more often so you can enjoy productive and creative sessions of work regularly. If you follow the tips in this episode, you can help others understand why getting into a flow state is more important than letting others interrupt you at will while programming. It will take setting expectations and creating healthy boundaries for yourself, but can result in breakthroughs in efficiency and your enjoyment of software development. Avoiding interruptions can make one of the biggest differences to your satisfaction over your tech career, whether you're a software developer or a consultant. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

In this episode, I want to ask you a question that might make you defensive: "Are you a perfectionist programmer?". I can tell you, after many years of being a software developer, I've gotten much better at this. But one of the things I want to help you with in this video is to maybe think a little bit about how you work with others – and maybe make better decisions about what kind of expectations you have from software developers, technologists, and other people on your team so that you don't get into a situation where you turn people off and you can't really get their best work and cooperation because you might expect them to work exactly how you do. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Are you joining a new company, team, or project? Do you want to make sure others respect you so you can use the technologies you want – and get your skills used? Early in my career I thought the best way to do this was to impress others with my technical acumen. But I learned quickly that this only causes frustration and delayed me being accepted. In this episode, I share stories and tips that will help you approach a new team with a positive attitude. You'll overcome walls people can put up and instead have others welcome your suggestions for improving their software project. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Technology addiction hurts your software development career if materialism makes you chase shiny objects. When I was a child, I used to like looking through the magazines my father got with all kinds of gadgets in them. As an adult, I often got caught up in obtaining the latest cars, guitars, or other material possessions. And though you may have a handle on materialism in your personal life - it can become prevalent in a software development career. We suffer from technology addiction when we get bored from repetitiveness - this is pretty obvious. But we also suffer from envy - and this is common because many companies don't keep their software developers growing. We can also put on "rose colored glasses" and deceive ourselves into thinking a new framework, API, or other technology will solve our problems. Failing to master a language or technology puts you at a serious disadvantage in your tech career. It's highly important that you develop the ability to match technology to the business. The only way this will happen, is if you both master your current tech stack - and develop an appreciation for what is unique in the business of your current software project. Ultimately, you need to be able to deliver results. Hiring practices in the industry make this an ongoing problem, but you can avoid some of the snares by thinking about the insights I share in this video. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

There's plenty of "fake news" from the software industry, so beware of the DevOps lie. There's a lot of confusion - just follow the money to see why. In this video I help you discover the real answer to "what is DevOps?", and why it may not be working for you. Though automated deployment technologies, cloud infrastructure, and other "fun" tools are exciting to talk about... ...DevOps is really about getting people to work together. I hope this episode helps you understand the core reason why DevOps came to be, and how it's a subset of Continuous Delivery. Though both of these terms ultimately seek to allow your company to release quicker (and more often) - I've seen them fail when gone about the wrong way. You can help your company achieve the promises of DevOps by following the tips in this episode. If you can help others answer the question "what is DevOps?" correctly - you can help your company achieve the cross-functional teamwork necessary. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: "Continuous Delivery" (Amazon) "The Phoneix Project" (Amazon) Visit me at thrivingtechnologist.com

Being on a software project death spiral can be extremely stressful. It usually happens when your company is doing FAKE Agile software development. People feel despair, and it looks like there's no end in sight? In this episode, I share some practical tips to help you correct this situation. Though it's never easy to recover from a death spiral, don't give up when there's hope! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

When someone comes to you for an estimate of a software task, do you feel uneasy? Programming estimation is a dangerous activity that should be approached with caution! But people make estimating software tasks more stressful than needed. In this episode, I share some tips that will help you have better success rates when estimating software. Though you may not be able to get out of estimating altogether (#noestimates), you can minimize the damage. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It's bound to happen that at some point you'll be asked to do some work that you know will have a negative outcome. How you say no on a software project can build resentment if you don't establish clear boundaries - and decline the request with grace. In this episode I share some tips I've found work well for diffusing resistance to your desire to do the work some other way. When you understand the person making the request better, you'll do a better job aligning your message with their needs. You will need to help them overcome the pressure they already feel to meet any commitment they already made to their boss. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

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

Do the teams you work on have an "elite few" that are looked to for making technology decisions? Are there times you wish people would work together more to drive software architecture? In today's episode I share both good, and bad experiences I've had with team structures that effect software architecture. It seems logical at first to only allow people with more experience to make these decisions about tools, processes, and frameworks. But only teams that have an inclusive technical culture bring out the best in people by giving them shared ownership over the process. Included are some tips I've found useful over my career to speed up the rate of adopting new technologies as part of your product's stack - and making it everyone's job. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It's easy to blame your company when a software project seems to require so many hours, that you suffer from software project burnout. And there certainly are companies that haven't figured out how to set deadlines in a way that expectations can be reset if things go wrong. But you can also burn yourself out, if you don't set healthy boundaries. I've actually worked overtime at the BEGINNING of a project! This would happen when I wanted to try and "make sure" we wouldn't be late. Or sometimes when I was just so excited to learn new technologies I DIDN'T WANT TO STOP. In this episode, I encourage you to do whatever you can to prevent working any sort of overtime. Even if you love working with software and technology, you need to consider the precedent you set. If employers know you will sacrifice your well being to meet deadlines, it's too tempting for them to abuse again! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Imposter syndrome is something software teams often talk negatively about, but it can actually be a sign of growth. The feeling that you don't know what others think you do can cause a lot of stress and anxiety. We all put up with this feeling when we're new, because others expect that we don't know what we're doing. But after a few years in software development, we can forget that feeling. When asked to do work that requires us to grow, it's critical that we get comfortable with it. There are a few reasons why software professionals tend to be especially susceptible to this. One is that other egotistical, narcissistic developers can make fun of us. But this says more about THEM than us. Another is that we worry that we'll be "found out" by management for needing to learn something. But emotionally intelligent managers and leaders see through the false wall of lies that some developers can put up when they try to appear infallible. In this episode, I encourage you to look at imposter syndrome as a healthy sign that you need to grow. If you can be honest, detach from what others think, and learn to reset expectations with others - you don't need a reason to worry that you're an imposter. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Stop getting angry that you're company isn't more AGILE! It's human nature that causes digital transformations to fail. I spent most of my career trying to help companies be agile. But people in positions of power are often driven by greed and the illusion of control, and they won't support efforts that require them to change. I had a nasty bout of insomnia in April of 2017 where I had to resign from my job. I spent the 8 months that followed healing, researching, and trying to understand where I went wrong. I'm no "guru" and I certainly don't know everything about this industry - but after working with 30+ companies I've seen some patterns. This year I want to help you avoid the pain I went through by having a healthier, more sustainable career in software development! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

We all hate that sinking feeling when we realize we're on a failing software project. What you do then will have a bigger impact on your health than your reputation. Earlier in my career, I would try to avoid blame as my number one priority. As I got more experienced, I saw the folly of this and realized I needed to follow through with my best work. How we deal with tough times says more to others than how we behave when things are going smoothly. In this episode I share the story of two clients I worked with that had failing projects. Sadly - I've been on more failed projects than successful ones, but I felt these two might help you think about how you cope with this situation. Remember just because a project fails - it doesn't mean YOU are a failure. It's OK to accept circumstances, accept your limitations - and do what you can. Your family, relationships, and health will thank you for it! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

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! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

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! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide 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 thrivingtechnologist.com

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: "Free Ambient Loop" by Sweet Wave Audio "Sonic Drifting" by Ron Gelinas "All The Beauty (original ambient version)" by Jani R Visit me at thrivingtechnologist.com

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! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: Tony Robbins TED Talk (He Discusses The Human Needs) Tony Robbins Website Visit me at thrivingtechnologist.com

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

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: The 7 Habits Of Highly Effective People (Amazon) The 5 Dynsfunctions Of A Team (Amazon) Visit me at thrivingtechnologist.com

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: John Cutler on Medium Visit me at thrivingtechnologist.com

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com