Why Developers Quit

Every time a software developer leaves a job, I always ask them why they left.  I do this because I like the software developers who work with me, and I really don't want them to leave.

Every time I have this conversation, I'm surprised at the wide variety of reasons why developers leave.  Most, however, leave for the following two reasons:

1)  They are bored with what they are doing.

2)  They don't like their new manager, or there was a change in leadership and they didn't like it.

I always expect them to say "I left for more money" or "I left because I hated the company."  I hear those reasons after layoffs or firings, but I hardly ever hear those reasons because someone quit.

As software development leaders, it is important that we address those two issues.

The first one is easily solved.  Keep your software project fresh, using new technology, and keep your company competitive by always pushing the envelope.  This will benefit the developers and keep the company profitable and current.

The second one is a lot tougher.  I wish I could answer how to be a good leader in one short blog post.  I am writing a book on the topic, where I will go into more depth and provide more information. 

I think one thing that covers a lot of what software developers like in a manager is as follows:

1)  Shield the developers from the chaos of the business.  Don't tell them stories about how there is so much change in the organization and no one knows what they want.  Don't confide your troubles in them.  Don't blame others when projects get cancelled.  Stay positive.

2)  Give clear direction on what they need to do in order to be successful.  They shouldn't have to guess on what their top three priorities are and what order they are in.

3)  Hold them accountable.  If you remember what you asked them to do, and you check in on them and how they are doing, you are not micromanaging them.  You are actually showing them that what they are working on is important and that you care about them.  You are showing them how to be successful and worth all that money you are paying them.

4)  Tell them what they have to do to earn more money.  Give them a way to earn money from you and not all their side projects.  If they don't have a way to increase their income with you, they will start taking work from other sources and they won't talk to you about it.

This is just the reality in an industry where 100% of the good developers have jobs and never have a problem finding more work.

This post doesn't give all the answers, but if you are struggling on how to keep your top talent, minimally addressing these things will go a long way in helping you with that goal.

Find the Right Metric: The NYPD and Prostitution

Looking at the wrong thing to achieve goals is more dangerous than having no goals.  When picking KPIs for executive dashboards, it's critical that we choose wisely, and that we're prepared to change.

So often, once dashboards are created, they seem to be set in stone.  When an executive says a metric is important, it is sometimes difficult to speak up against them and say that perhaps we're looking at the wrong thing.   If we're somewhat flexible on what we see, and we're willing to change in the future, it provides a safe place where mistakes can be made.  

The New York Police Department will often search suspected hookers to see if they are carrying an abnormal amount of condoms.  If they are, they use that as proof against the suspect that they are a sex worker.  Although this seems to satisfy the metric that prostitutes be arrested and off the street, it ignores the bigger goals of public health and safety.  It incentives women to not carry protection, thus spreading disease and sickness through the population.

The NYPD is looking at the wrong metric.  I suppose this is the risk when you use law enforcement to work on what is probably a primarily public health problem.

If call centers look at average call time, and they want the number as low as possible, because that means they are saving money, they might be looking at the wrong metric.  It might be incentivizing rude customer service, abruptness, and poor call etiquette.  Measuring customer satisfaction or absolute resolution time might be a better number to look at.  Perhaps low calls into the center will emphasis the quality of the product you're selling and how easy it is to use.

But mistakes will always be made when selecting metrics and KPIs.  The trick is to make sure that the technology and the business are both able to quickly and effectively change it when the mistake is realized.

Just Venting A Little

Feel free to ignore this post.  I'm writing for me and to get something off my chest.  I'm absolutely not writing to you.  Nor am I disappointed with anyone in particular.

I am often asked by software developers and other consultants about how to be successful.  Now, I don't consider myself to be successful.  I enjoy my career and like where it's at.  I'm excited about where it's going.  I enjoy the process of learning new technology and making new friends and meeting new people and advising customers on how to be successful and profitable.

With that said, I'm often asked about how to be successful.  When I have these conversations, I find that everyone already knows everything I have to say.  They know how to make more money, how to gain recognition, how to achieve...and they knew it before they even asked me the question.

They don't need answers from me.

Their answers all come from within.  Yet time and time again, they fail to execute.

I am consistently disappointed at the small percentage of people willing to execute the simple daily self-disciplines needed to reach higher levels of success.  They know exactly what they must do to bring about their dreams and yet they fail to execute.  It's not a failure of vision or knowledge...it's a FAILURE OF ACTION AND COMPLETION.

They chart their work by the progress they've made, not with any specific goal.

I know that the person who achieves in this business is the person with passion....the person who wants it the most.  They are the people who wake up at 5am to read Hacker News.  They are the people who are writing blog posts at 11pm.  They are the people who spend their weekends speaking and learning at Code Camps and SQL Saturdays.  They are the people who volunteer and attend user groups.  They accept no excuses.  While others are watching TV show after TV show, they are learning, reading, digesting, blogging, tweeting, and writing.

It seems that there are very few people who are willing to put forth the effort to get from where they are to where they want to be.  Most make excuses and blame others for their own poor choices.  They kill the messenger.

Some of you will discredit me.  Some of you will say things like "Who is Ike to say these things to me?"  or "Ike isn't perfect either.  I know he makes mistakes."  Some of you will find other ways to ignore what I'm saying, belittling me or my success.  That's totally fine. 

But others of you will take this opportunity to look inside yourselves and ask if you are doing everything you can to learn, grow, market, achieve, raise bill rates, provide value, write, and succeed.  Others will humbly ask "If I know what it takes to succeed, what excuses are getting in my way of taking ACTION and actually achieving?"

I know you know what to do.  You have all that you need to be self-sufficient, to earn more money, to achieve respect and recognition, to contribute value to your community.  GO FORTH AND DO IT!

Just as Important as Control

I've been reading "Making Sense of Behavior", by William T. Powers.  The book is about controlling human behavior, but one section really made me think about the importance of proper business intelligence and SQL reporting for an organization who wants to achieve ambitious goals:

==================
"On a twisty mountain road with cars coming around every blind corner you don't look away for even a second!  Because the general rule is that if you want to control something, you have to perceive it.

When you're filling your bath, you don't just perceive that the water looks hot, you specifically use your temperature sensors in your hand to report on the current temperature of the water because that's what you're controlling: temperature.

Perception tells us the current status of whatever it is we're trying to control.  Without that information, received continuously or at frequent intervals, we can't control anything.  Perception is just as important as action, for controlling."
==================

Reporting is not our only means at perception, but it is a powerful one.  And when organizations ignore effective reporting and business intelligence strategies, they do so at their own peril.   I have always felt that business intelligence was nothing more than delivering the right data to the right person at the right time.

I Love Lucy: A Lesson For Business Analysts

In this episode of I Love Lucy, a conversation is taking place between two people who don't understand each other's languages.  They struggle to find someone who can translate between french and english, which they fail to do.  Instead, they find linking languages between them.  So the translation goes from French to German, to German to Spanish, and finally Spanish to English.

The episode is hilarious, and it highlighted to me how difficult it is for software developers and business stake holders to communicate.  Executives, Directors, and other leaders are often fluent in their line of business.  They are also fluent in general areas of business.  Words like cash flow, just-in-time manufacturing, and copywriting are thrown around frequently, and often are lost on engineers and software developers.

Conversely, software developers speak in terms that business leaders find foreign and awkward.  Words like source control, unit testing, and SCRUM are thrown around frequently, and business leaders find themselves equally lost.

Companies often struggle with these two different languages  and rather than putting in the time, effort, and energy into investing in being somewhat bi-lingual into these two worlds, they hire a translator.  Called a business analyst, these translators specialize in speaking both languages fluently.  This is an acceptable solution to the translation problem, but it is less than ideal.

Business Analysts create the following problems:

1)  In the kindergarten game telephone, a message is whispered around the circle and the original message is compared to the final message, and they are often very, very different.

2)  Business analysts are expensive.

3)  If your job is to bridge the communication gap, then you really don't have a vested interest in bridging the gap, in fact, there is profit to be made in making sure the gap is as wide as possible.  This creates a culture of information hoarding and miscommunication.

4)  When mistakes are made, blame is spread around.  Since the analysts are in the middle, you often hear several different stories on who is at fault and what the problems actually are.

5)  Translation takes time, and therefore delays projects, decreases velocity, and hurts shipping times.

So what is a better solution?  I think business people can spend 20% of their time and get 80% of the value by spending some time learning some basic terms of software development, so they understand the challenges that developers face.  I think developers can spend the same amount of time learning to serve the business they are in.   This investment is just for the initial communication issues.  Within months, these communication problems will go away, and that investment will pay off year after year. 

This small investment has no downside, will increase velocity, and will definitely improve your software ship times, while decreasing bugs and increasing software quality. 

We prefer to have constant access to our customer so we can be in constant communication.  This helps us learn from each other and grow together.  Trust will build, and software will ship.  Everyone is happy and the communication problem is solved.

Trust = Group Execution

It is impossible to grow your business if you are not surrounded by people who you trust.  Particularly, you need to trust people to do what they say they are going to do.

Software developers often erode trust by not meeting deadlines, not delivering what they say they are going to do, and not being where they say they are going to be.  They also lose trust by not answering their phone, not being responsive, and by not communicating clearly when issues are being worked on and resolved.

These problems can be resolved by breaking up very large projects into several smaller ones.  Instead of delivering something major in six months, we should deliver ten to twelve small projects every couple of weeks for six months.  At the end of six months, we'll still have the same amount deployed, but we will gain some benefits:

1)  We will increase trust through constant delivery.

2)  We will be more accurate with deadlines, because small things are easier to predict than very large things.

3)  We will gamble less with company resources, because if we fail, we will fail on a smaller two week project, and not a large six-month project.

4)  Constant delivery creates a culture of constant communication, which also builds trust.

Business people also need to earn trust.  They need to speak clearly, answer questions quickly, respond to emails and voicemails, and generally be equally communicative.  In addition, they need to set clear expectations, and take responsibility when changing requirements delays shipping.  Ideally, they would promise not to change requirements for two weeks, in order to facilitate a frequent shipping cycle.

If trust builds, great things can happen, and the business can grow and be more profitable than ever before.  Everyone can use software as a competitive advantage, but only if these two sets of people have complete trust in each other.

The Importance of Shipping Software

I play piano.  Well, not really, but I like to practice a lot.  Alone, I think I play rather well, but when I try to play in front of someone, it’s like I’m brand new and fumbling over every key.

The more people I’m in front of, the more I fumble.  It’s a funny thing how an audience heightens every mistake.

I also golf.  Well, more like hack.  But I am a better golfer than I am a piano player.  At the range, I can hit flawless shot after flawless shot.  If I immediately go to the course, all that talent I found at the range immediately evaporates.  The fact that I’m not as good as I think I am is a harsh reality.

Golfing on a course and playing piano in front of others does two key things for me.  One, it shows me where I’m struggling, because every mistake is amplified.  Two, it shows me where my actual weaknesses are, instead of my assumed weaknesses.  The more eyes on something, the more reality is impossible to avoid.  

Dealing with reality, instead of fantasy, is the central reason why developers must ship working software as often as possible.  The more they do that, the more they will enjoy it, the better they will get at it, and the more value they will provide to your users, customers, and employees.