Healthy Developer

Imposter syndrome is something software teams often talk negatively about, but it can actually be a sign of growth.

The feeling that you don't know what others think you do can cause a lot of stress and anxiety. We all put up with this feeling when we're new, because others expect that we don't know what we're doing.

But after a few years in software development, we can forget that feeling. When asked to do work that requires us to grow, it's critical that we get comfortable with it.

There are a few reasons why software professionals tend to be especially susceptible to this.

One is that other egotistical, narcissistic developers can make fun of us. But this says more about THEM than us.

Another is that we worry that we'll be "found out" by management for needing to learn something. But emotionally intelligent managers and leaders see through the false wall of lies that some developers can put up when they try to appear infallible.

In this episode, I encourage you to look at imposter syndrome as a healthy sign that you need to grow. If you can be honest, detach from what others think, and learn to reset expectations with others - you don't need a reason to worry that you're an imposter.

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

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

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

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

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

We all hate that sinking feeling when we realize we're on a failing software project.

What you do then will have a bigger impact on your health than your reputation.

Earlier in my career, I would try to avoid blame as my number one priority. As I got more experienced, I saw the folly of this and realized I needed to follow through with my best work.

How we deal with tough times says more to others than how we behave when things are going smoothly. In this episode I share the story of two clients I worked with that had failing projects.

Sadly - I've been on more failed projects than successful ones, but I felt these two might help you think about how you cope with this situation.

Remember just because a project fails - it doesn't mean YOU are a failure. It's OK to accept circumstances, accept your limitations - and do what you can.

Your family, relationships, and health will thank you for it!

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

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

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

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

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Stop getting angry that you're company isn't more AGILE!

It's human nature that causes digital transformations to fail. I spent most of my career trying to help companies be agile.

But people in positions of power are often driven by greed and the illusion of control, and they won't support efforts that require them to change.

I had a nasty bout of insomnia in April of 2017 where I had to resign from my job. I spent the 8 months that followed healing, researching, and trying to understand where I went wrong.

I'm no "guru" and I certainly don't know everything about this industry - but after working with 30+ companies I've seen some patterns.

This year I want to help you avoid the pain I went through by having a healthier, more sustainable career in software development!

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

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

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

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

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Do you ever get that sinking feeling that the people running your software business don't really know what they're doing? Here's 5 signs your software business is led by amateurs!​​

It can be practically a sport to make fun of leadership for not understanding modern software development and its implications. That's not the purpose of this post.

If you're working at a company where several of these signs are present, you have three options. Put up with it, try to change it for the better, or move on.

Here's 5 signs your software business leadership needs help:

1. Failure To Invest In Better Tools and Services
2. Too Much Power In The Hands Of A Few Customers
3. They Can't Say "No" To Any Customer
4. They Have A High Customer Acquisition Cost
5. They Commit To Deadlines Without Understanding The True Cost

If the place you're working at has these problems, do you have the courage to move from complaining to having some serious conversations?

Even if you consider yourself just a cog in a huge machine, you can help your leaders make better decisions that keep the company profitable!

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

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

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

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

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Have you ever been on a software project with someone who does great work but is difficult to work with? Here's some strategies for confronting difficult software developers about their behavior.​​

Before you even think about having this conversation, go into the conversation detached from the outcome you want. If you go into it thinking "If I don't get this person's behavior then I'll be upset" – the other person will pick up on it.

Here's 6 tips for this conversation:

1. Keep The Conversation Private
2. Ensure They Are Well Rested
3. Reinforce Their Value
4. Listen For Struggles
5. Future-Pace The Benefits
6. Discuss Their Reservations

Don't give the person an ultimatum! They will make the change but resent you for it!

Don't attach rewards to the change. They will expect rewards for future good behavior!

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

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

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

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

You can also watch this episode on YouTube.

Related resources:

• "Sonic Drifting" by Ron Gelinas
• "All The Beauty (original ambient version)" by Jani R
• "Ambient Theme No. 1" – Steven O'Brien

Visit me at thrivingtechnologist.com

Does it seem like others are turned off by you before you're even able to fully explain yourself? Today I'd like to share 4 behaviors that stem out of our fear of being misunderstood. These can cause other software professionals to dislike and not want to work with you!​​

Demanding Re-Explanation

A parent will sometimes ask a child "OK, tell me what I just said" to make sure they understand. If you do this to an adult on your project, it sends the signal that you don't think of them as very intelligent. It also comes across as condescending.

Instead, make sure the other person understands the essence of what you're saying. If they know enough to take action, move on.

Nitpicking

It's tempting when we're insecure in some way about our skills to take apart what others say and demand it to be phrased how you would. This comes across as needy, and though you might think it demonstrates your mastery of the knowledge, it turns people off.

As with the above point, when the other person chooses to use different words than you, but they are basically saying the same thing, let it go – they get it.

Over-communicating

In our desire to make sure we're understood, we can sometimes verbally vomit our ideas onto a person and overwhelm them. It takes a lot of energy to have technical conversations, so plan wisely and only communicate the minimum information needed to get the other person to take the actions needed.

Abusing Apologies

In our desire to help other people feel comfortable with us, we can sometimes abuse apologies. Saying "sorry" for a mistake you made, and owing up to it, is a good idea. But if others are upset with you about something you didn't do or had no control over it, never apologize. If you do, it sets the precedent they can use you as a punching bag.

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

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

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

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

You can also watch this episode on YouTube.

Related resources:

• "Free Ambient Loop" by Sweet Wave Audio
• "Sonic Drifting" by Ron Gelinas
• "All The Beauty (original ambient version)" by Jani R

Visit me at thrivingtechnologist.com

Does it frustrate you when you see other software professionals get recognition or opportunities you want? Are you stuck in a software project situation where it feels like you're unable to grow?

Let me share some information that will help you advance, but in a healthy way. I'll list 4 tips at the end.

Growth and Perks are Abundant Early On

When you first start working in software, you'll have rewards that will keep you satisfied for the first 2-5 years:

• Lots to Learn (Everything is NEW!)
• Casual Environment
• Good Benefits

After time spent on spent on projects that aren't letting you grow, you may hit some barriers:

• Continued growth may not be important to your employer
• The path to advance may appear to be "blocked" by other ambitious professionals

The reality is that the way to grow is to contribute more. You'll always progress faster in your software development career when you serve others with something for which you have become particularly skilled.

Why Software Professionals Struggle to Grow

You may be familiar with Tony Robbins' 6 human needs. He breaks human behavior down into things that drive us and are necessary for our survival.

1. Certainty
2. Variety (or Uncertainty)
3. Significance
4. Love and Connection (or Team/Community belonging)
5. Growth (Personal skills)
6. Contribution

As software developers, we have particular dynamics to the job that cause us to get into trouble with these human needs:

Problem #1: We seek certainty, but then get bored.

Problem #2: We try to be significant (get promoted, recognized), and sacrifice connection with others.

Problem #3: We focus on growing our skills, and sacrifice contribution (helping others).

4 Tips for Healthy Software Career Growth

How can you balance these human needs better, specifically in your software career?

Tip #1: Set Deadlines for Career Changes

Don't wait until you get frustrated. Plan for when to make career decisions if situations don't improve.

Tip #2: Respect Resistance to Change from Others

There will be times you want to grow and others don't. You want to get support from other people on your projects in a way that's healthy to your relationship. Visit the post about How To Win Trust For Your Software Ideas for some tips.

Tip #3: Contribute to Other People's Career Growth

When you help others get recognized, they will return the favor. You also get an opportunity to learn from others when you let them lead you in doing new work when you want to grow.

Tip #4: Allow Others to Be "The Expert"

When you let others teach you, instead of just learning from the internet, you strengthen your relationship. This is because people appreciate when you show that you value their opinion enough to defer to them for their expertise. It also helps you learn faster from their experience than scouring StackOverflow and Google. Being able to become a "newbie" again is an invaluable skill!

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

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

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

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

You can also watch this episode on YouTube.

Related resources:

• Tony Robbins TED Talk (He Discusses The Human Needs)
• Tony Robbins Website

Visit me at thrivingtechnologist.com

Are you trying to get other people to use agile or lean software development methods, but they can't seem to break out of the mindset they're stuck in? Today I'd like to offer some strategies to overcome attachment.

Building What Customers Want Takes Failure And Learning

Traditional management at many companies focus on predictability. They want to know how long things will take, and how much they will cost. Unfortunately if your software company wants to be innovative, you may already know that you can't measure performance this way.

If you want to deliver truly disruptive and valuable ideas to your customers, you need to experiment and make small investments to see how customers receive them.

Establishing the Mindset for Failure and Learning

I talk often about how important experiments are to the success of your software company, and how you can sell and introduce the changes needed to work this way to leadership and other stakeholders.

Assume for a moment you've already convinced people of the benefits of lean software development methods that let your company experiment (DevOps, Continuous Delivery, Lean Startup techniques etc.).

Yes, people now understand the mechanics of these approaches. But it can be frustrating at first to help others have the courage to take risks and actually experiment.

This is because experimenting and then learning from the results, often requires failure.

The Uncertainty of Innovation Can Cause Anxiety

One of the technology capabilities I have said in other articles is crucial to a company sustainably releasing valuable software, is Continuous Delivery. This lets your team release your software to customers as frequently as multiple times per day.

If you're going to let the customer take a larger role in deciding what's in your product, and release it multiple times per day — you'll have an increased set of feedback.

Also subject matter experts like Product Managers will find out their ideas aren't as valuable as they'd hoped when trying new things.

These two changes alone introduce uncertainty that needs to be handled with care. Without addressing this, your team will start blaming each other and going back to what they're comfortable with when their first few experiments don't produce the results they anticipated.

Overcoming Attachment to Enable Learning

If you celebrate Christmas or your Birthday, you've probably experienced being attached to a gift or outcome you wanted as a child.

You and your team need to overcome these feelings of attachment at your company to use lean and agile methods for developing software. Without detaching from outcomes, people will feel threatened when things change.

We Must Be Comfortable With Uncertainty to Take Risks

The more comfortable you can be with trying things and not being able to guarantee that the outcome is something that you want, the more you can take risks. This is exactly the mindset needed to be more innovative with software development.

Strategies for Practicing Detachment

Since you know people need to be more comfortable with uncertainty, and they need to be less attached to outcomes — what are some strategies you can use to cope with this?

Thinking About the Possibility of Other Outcomes

Most people in corporate America don't want to do this. Typical work structures are all about certainty and planning for outcomes we expect.

Instead, thinking about the possibility that what you've planned might not work out ahead of time primes you for a healthy mindset for taking risk.

When you're working with a team to experiment, remind them at every opportunity that everyone is looking forward to seeing the data to help them steer the product in the right direction.

If the data behind a release shows that a change wasn't positive, that is not a failure.

It must be clear that there will be no reprimanding for theories the team held about what would be valuable, as testing those theories will inherently prove when our ideas aren't good.

This is the nature of the scientific method!

Beware of Catastrophizing

Once you begin to allow yourself to entertain the possibility of uncertain outcomes, it's tempting to think of the worst case scenario. This is known as catastrophizing, and creates anxiety by focusing your thoughts on negative situations that haven't even happened yet!

When I've caught myself catastrophizing, I often realize I'm tensing up and experiencing the same emotions as I would if the event happened — but it hasn't.

Spending significant time thinking about the worst possible outcome will cripple your team with fear, and cause them to lose the courage needed to present their best ideas to your customers. Yes, there is a time for risk management — but innovation is not that time.

Overcoming Resentment to Past Failures

If you hold on to negative feelings about what may have happened in the past, you won't have the open mind necessary to try new things. Examples might be working with a person who made a mistake before, a business partner who didn't hold up their end of the deal, or a software development task that was more complicated than first thought.

Resentment is another form of attachment. You should consider practicing forgiveness and using whatever healing tools work for you or your team to let go of any resentment.

These could be simple things like giving someone a personal apology if you played a part in the situation. Or something that lets you face the situation and let your feelings with it rest such as meditation.

Whatever physical, emotional, or spiritual activity you can find that works to help you or others involved emotionally detach from the experience, use it. Let the past go so your team can try new things with a clean slate!

Challenging Limiting Beliefs

If someone told you something about yourself as a child, or perhaps a co-worker made a statement about your skills — you may be walking around carrying an inaccurate picture of yourself. You should challenge thoughts held about what is really true with respect to the limitations you or your team may perceive about their capabilities.

I once worked with a Fortune 500 client who only released their product at night when no customers were using it. They were convinced it was impossible to release it during the day even though the technology needed to do so was common.

Until I challenged this belief, and did not back down until I heard a logical answer for why it couldn't be done — no one had considered it a possibility.

Once everyone moved past this limitation in their thinking, they were easily on board and supportive of working with me to plan for the change.

Separating Our Identity From Outcomes

In most companies if someone makes a "bad" decision, they are held accountable. What this can do though is cause you to place your self-worth in your decisions and their outcomes. To have the courage to innovate, you need to separate these two.

People on your teams should strive to treat each other kindly especially at the times when they make mistakes. But when they slip up and get upset at you or someone else for a decision that they didn't like, it's important to not take it personally. You can't control how the other person will react — but you can control your reaction to their being upset.

Practicing Delayed Gratification

Your company may need to build and release five small versions of an idea to your customer before you hit the ideal solution, when delivering a product in a lean fashion. Because of this, the management team may be lacking in the necessary patience at first to see things unfold with the product this way.

Delayed gratification is simply waiting longer to get something you want. This might sound like a silly thing to recommend, but you'd be surprised how many people I come across in leadership positions who are still very attached to immediacy. If you have people like this in key positions at your company, this may be the reason why you're having a difficult time getting support for the changes you want made.

Practice this yourself, and with your team, to relax your feelings of urgency so you have the patience to try several iterations of an idea before settling.

Permitting Others to be Frustrated with Uncertainty

It's natural that when trying something new, such as to not be as attached to outcomes, you and others will make mistakes. It's crucial that everyone be willing to forgive each other when unpredictable negative outcomes occur. Without this safety net, there can be no loyalty, transparency, or ability to take risks. These are the attributes of relationships at your company that can make or break the long term health of the software development culture.

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 need to get people to agree and come to consensus so you can grow on your software project, or in your career? Today I'd like to share a few resources, and some simple concepts to consider, when influencing others to make a decision.

When I started out in my career, I was a good software developer and could write code and work with many complicated pieces of technology. But I didn't become good at influencing people until I began consulting a decade later.

The Circles of Influence

Stephen Covey's famous book The 7 Habits of Highly Effective People, introduces many powerful concepts for better work. I'd like to mention his concept of circles of influence, which is important for thinking about how to build consensus.

The first circle is the circle of control, and typically only includes yourself. If you have children, or subordinates, you may consider them within this circle. In most cases however, there is little you can actually control.

The second circle is the circle of influence, and is comprised usually of people on your software team who you already have good relationships with. These are people who will take your advice seriously, and expect you to influence them.

The last circle is the circle of concern, and includes people that we have no direct control over OR influence with. Influencing these people usually takes indirect influence through another person.

Who Can I Influence Already?

It makes sense, especially within the context of Stephen Covey's book and recommendations himself, that we focus on those we can influence first. If we already have great relationships, those should be the first people we bring over to our side with a decision.

Identifying Stakeholders of Your Circle of Influence

Because it often takes getting agreement from people outside our circle of influence, we next need to identify who these people are. We can typically influence them indirectly through the relationships we already have. If not, we can look to someone else we know, that knows this person already, to open a door to a conversation.

You May Need to Influence "Up the Ladder"

Many software companies can grow into a structure with multiple levels of people. Even when using agile development methods, communication across people continues to be a challenge. In addition to building consensus across our circle of influence at our level, we may need to get agreement UP the "ladder" of people in the company so we can reach consensus.

Beware of Team Dysfunctions

While attempting to influence others, it's common that due to past failures or trust issues, you may run into politics. The book by Patrick Lencioni, The 5 Dysfunctions of a Team, is a great resource to help you win back the support of difficult people and get everyone talking honestly again.

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

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

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

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

You can also watch this episode on YouTube.

Related resources:

• The 7 Habits Of Highly Effective People (Amazon)
• The 5 Dynsfunctions Of A Team (Amazon)

Visit me at thrivingtechnologist.com

Are you developing software under pressure like a "feature factory", but there never seems to be any economic benefit to the changes? Today I'd like to share some strategies to begin shutting this unhealthy work approach down.

The term "feature factory" was coined by John Cutler, a Senior Product Manager who's worked for several high profile companies. He wrote an article in the Hackernoon publication on Medium that introduced the concept to the masses.

When you read his article, you may, like me, find yourself nodding your head "YES!" to all of it. Anyone who has worked to produce software on a team that is a feature factory will immediately recognize many of the symptoms.

What is a Feature Factory?

I'd encourage you to read all of John's articles for more details, but when you really boil it down a feature factory is a team or company that doesn't know how to measure the business impact of their changes.

Set a Measurable Business Impact Goal for EVERY Change

When we're in school many of us learn the scientific method. At a high level – you have a theory, you decide how to measure it, you design an experiment, and you record the results. Often our theories are proven wrong.

Unfortunately, when it comes to developing software many of us assume we can't be wrong and do very little to handle that very real possibility. One of the first things that is necessary to shut down a feature factory, is to only make changes that can be measured as being successful or not in reaching an outcome.

Move Further Towards Cross-Functional Teamwork

When the people who work together to produce software are in separate departments, it often leads to people deferring design decisions to a UX, Product Management, or other design person. A cross-functional team actually strengthens the ability to deliver "the right thing" and NOT be a feature factory, because everyone can contribute to design ideas because they are dedicated to the success of ONE product.

Celebrate Outcomes Instead of Releases

When we start releasing software several times a day using things like DevOps and Continuous Delivery, we often will not hit a positive business outcome with each release. Because of the chance of failure, we should celebrate as a team when we reach a business outcome – not every time we release. John calls this "success theater".

Cultivate a Culture Safe for Failure and Learning

When we plan a project that takes a long time to deliver, during that period there are assumptions about the value of what's being built. There are no ramifications or learning until the end, and on some teams if the product doesn't deliver on it's expectations people are FIRED!

​To allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be "wrong". This requires making it safe for Product Managers and others to take risks so they can learn.

Focus on Value NOT Efficiency / Utilization

This one is pretty self explanatory. If a team is constantly pushed to be as efficient as possible, they won't have the relaxed and creative mindset necessary to make changes that contradict our initial assumptions!

Release Smaller Changes, More Often

To enable failures (learning) to have a smaller impact and cause less waste when it comes to budgeting – designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial.

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

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

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

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

You can also watch this episode on YouTube.

Related resources:

• John Cutler on Medium

Visit me at thrivingtechnologist.com