Healthy Developer

Do you find it hard to be honest with others about some aspect of developing software? Or maybe you find others are withholding truths, and you wonder why? Today I'd like to share some ways I have been dishonest earlier in my career, and I now see are common in our industry.

Not Admitting Being Unfamiliar With Something

In short time, we can gain a lot of knowledge about technology and software development processes. If we're not careful, this leads to a "big head" or inflated ego, and we can feel embarrassed if we haven't heard about "the new hotness". If we're honest with others when we don't know something, they trust us more to be transparent, and they know they can share things they are excited about without us shutting them down in an attempt to be seen as the expert.

Saying "Yes" To Work You Don't Understand

It is often that on software projects we are asked to estimate work based on the information another has captured for us. If we don't fully take the time to understand it, or have a self-inflated sense of our level of skill, it doesn't take much to agree to work when we shouldn't. I learned to say "No" more strongly and honestly about 5 years ago, and it has helped me on numerous occasions. When I didn't do this, I would often put myself under extra pressure, and have to reset expectations with the other party who is now upset that I can't deliver what they expected.

Not Admitting We've Overlooked A Process Step

Software development is inherently complex and often requires many moving parts to be changed in a very specific sequence to accomplish work. As humans, we will inevitably make mistakes. Under pressure, I have failed to be honest with others that I simply forgot a step in my desire to be seen as the expert.

I have become MUCH better about being honest about this now, but it is very common in more junior technologists. When we take responsibility for forgetting something, we build trust with others who know we will hold ourselves accountable for our actions.

Making Generalizations About Others

In our desire to be seen as the expert, we can sometimes have just a few interactions with another person and then paint them as incompetent or lacking in skill to others. This thinly-veiled attempt to make ourselves appear smarter than we are casts doubt in all but the most unsophisticated of people. If the person you made a generalization about meets the person you said this to, they will find out that you are quick to judge and make inaccurate statements on a whim. Just don't do this!

Not Being Honest About Your Level Of Contribution

We work hard to produce quality deliverables and value for our team and customers on software projects. And few things feel better than a customer or someone else at the company saying "great job!" But I have not always been as forthcoming about the work others did to support me in successes, and since getting better at this my ability to motivate others and build trust has gone up tremendously.

When you check yourself when receiving a complement and remember to include others who were part of the success, you build a positive emotional connection between you and them, and deepen the trust and loyalty necessary to keep a strong team together.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

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.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 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 with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Does it ever 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 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:

• Daring Greatly (Amazon)

Visit me at thrivingtechnologist.com

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 encourage you to get permission to be as open as possible with your colleagues from whoever you report to if necessary.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com