Healthy Developer

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. 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 Lean Startup (Amazon) Visit me at thrivingtechnologist.com

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. 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: Flawless Consulting (Amazon) Continuous Delivery Amazon) The Lean Startup (Amazon) Visit me at thrivingtechnologist.com

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. Join my Patreon: https://thrivingtechnologist

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching wi

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. 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: Principles Of Lean Product Management By Jez Humble Visit me at thrivingtechnologist.com

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one care

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. 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 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. 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: "Flawless Consulting" (Amazon) Visit me at thrivingtechnologist.com

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 encou

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

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

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. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki

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

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". 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 Lean Startup" on Amazon Principles of Lean Product Management by Jez Humble Visit me at thrivingtechnologist.com

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

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

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

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. 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 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. 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: Principles of Product Development Flow (Amazon) Visit me at thrivingtechnologist.com

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). 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) Introduction to Scrum - 7 Minutes Kanban 101 - What is Kanban? Visit me at thrivingtechnologist.com

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! 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: Principles of Product Development Flow (Amazon) Visit me at thrivingtechnologist.com

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. 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 Visit me at thrivingtechnologist.com

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. 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 Visit me at thrivingtechnologist.com

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. 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 Visit me at thrivingtechnologist.com