Dream the Big Dreams

Every Leader should have a dream

Like many scrum masters, I spend plenty of time learning new things about my profession.  I am participating in the Chicago State University, Certified Agile Coach program to brush up on my coaching skills.  We have been discussing a wide range of topics, from active listening to servant leadership.  This week, something struck me during class, and it was the observation a servant leader needs to dream big dreams.  You do not usually think about leadership requiring big ideas, but imagination is a necessary component if you are going to lead in a global economy. 

Begin labeled a dreamer is often considered a stigma in academics and business.   It implies a lack of seriousness and an inability to recognize the practical realities of the world around us.  To be a dreamer is to be either a rock star or a hippy.  I beg to differ.  People who are dreamers have a vision about how things should be.  Having the imagination to see things differently and the determination to make it happen is something that makes investors swoon and makes innovation possible. 

Being a dreamer is positive.  It looks forward and asks, “Why not?”  A leader replies, “Not yet,” when they hear something is impossible.  It is not mindless optimism; instead, it is a quiet determination to look ahead and see a better future.   In addition to seeing that better future, a servant leader needs to share that vision to provide meaning and purpose to others and yourself in this absurd world.  The ability to dream helps you gather strength in bad times and excel when the opportunity comes along. 

A dreamer is someone each organization craves because much of the business world contains drudgery and monotony.  People crave purpose and want to feel the effort they put in daily is worth the struggle, so a good vision helps fulfill this role.  As a servant leader, dreaming big dreams is necessary. 

Until next time. 

Failure is the Fertile Soil for Growth

Failure happens

A common theme in business writing is the mythologizing of success.  It is an easy narrative to promote.  People enjoy reading about the success of others, and wealth is always intoxicating.  The struggle, failure, and sacrifices necessary to achieve that wealth have a glossy sheen in popular culture.  For me, the most exciting part of the story is how others deal with failure and crushing disappointment.  It interests me because my career has numerous episodes of frustration.  A setback proceeded with each significant improvement in my career and life. Defeat is a teaching tool for me, and now I incorporate it into my coaching practice.  

I have made numerous references to how failure is an exceptional learning tool.  Instead of failure, I should barrow the mindset of Carol Dweck and her Ted Talk from 2014.  Instead of saying, I failed, I should say that I have not yet succeeded.  It is the classic growth mindset which motivates people to figure things out and improve.  It sounds noble, but it is difficult for people to do because it challenges an individual’s self-worth.  

Thus, I spend lots of time taking the sting out of the everyday failures and mix-ups which happen in an office.  It means being kind in moments where your lesser self would like to snicker.  It means saying, “not yet,” and “what could we have done differently.”  It is holding others accountable without being mean about it.  I struggle just like the next business leader, but I have noticed that people respond to this approach.  Instead of beating a drum, a leader needs to show the way and get a little dirty in the process.  

Failure is real, but how we react to it makes the difference between a fixed mindset and growth and continuous improvement.  I choose a growth mindset any day of the week.  

Until next time. 

Professionalism and Developers Part 2

Software Developers are not hooligans.

Last time, I wrote about the three main factors which contribute to a lack of professional behavior among software developers.  For management which does not come from the ranks of engineers, it can feel like you are attempting to organize a group of soccer hooligans.  The good news is there are some simple techniques you can use to improve the professionalism of these challenging employees.  

Since developers are creative and intelligent, a pivotal approach to leading them is to show them what to do and let them take ownership of the details and deliverables.  For instance, we had a client that need to track bakery ingredients.  I said we are required to monitor the elements in a database and that some restful APIs in C# should be able to do the trick.  The development team asked about how they would enter data in the system. I said that we should be flexible and we should use the technology we already have. With that information, the team constructed an AngularJS application that wowed the client and earned us additional business; because I left the details and deliverable up to the team, they took ownership of the process.  

Next, developers crave autonomy.  The reason they specialize is so they can have mastery over a subject.  The ability also translates into others, trusting them to do the correct thing technically for the project and the business. Ability becomes autonomy to a software developer.  Giving team members freedom is going to be a challenge to business leaders accustomed to micro-management, but it will pay dividends.  Set clear deadlines and then allow developers to meet them.  Reward success with more autonomy.  It will become a positive cycle.  

Another proven technique is to allow engineers to automate everything about their jobs they hate.  If they do not like filling out time cards, ask them to write a macro to do it for them.   Instead of scolding people for not writing release notes, have them use the git repository to generate the notes based on pull requests automatically.  I was amazed when a developer created a build pipeline, which creates an excel spreadsheet with unit test results.  I asked them why they did it, and they said it was because they hated to do it each time a build happened. 

Finally, dole out perks and privileges based on professional conduct.  Let people go home an hour early on Friday if documentation is complete, timesheets submitted, and the build is working.    Perks do not have to cost money, and they can be an excellent way to encourage more professional behavior.  

By rewarding professional behavior with perks, allowing engineers to automate parts of the job they hate, granting increasing levels of autonomy, and giving people the flexibility to solve problems, you are creating an environment where developers want to become more professional.  Software engineers are some of the hardest employees to lead, but if you follow my suggestions, it will be much more comfortable than attempting to control a bunch of soccer hooligans. 

Until next time.