Monday, June 29, 2020

Professionalism and Developers Part 1

Developers see the world differently.

I have spent a long time working in the software business.  I was not very good as a software developer until I did it professionally for ten years.   Today, I still consider myself a mid-level developer in terms of skill.  What set me apart later in my career was the professionalism I brought to the job.  Documentation would get written, time cards would get filled out, and I spent a lot of time over-communicating with management and stakeholders.  As I moved into project management, scrum mastery, and leadership, I noticed that software developers struggle with professional behavior patterns, which other business professionals have internalized.  We should discuss this.

The subject of professionalism is a touchy one in software engineering.  If you look at the history of the profession, it is easy to see why.  Bill Pflegin and Minda Zetlin, in their book, “The Geek Gap,” points out business people and technology people see the world from two different frames of reference.  A business person wants to be likable and profitable.  If you are agreeable, others are more receptive to your product which you are selling.  Thus, business people are very focused on being likable.  Engineers are not concerned with being likable.  The most important thing for an engineer is to make sure things work.  An engineer spends most of their time wrestling with the rules of physics or computer science to get things to work faster, better, and more reliably.  Something works, or it does not, and this binary view of the world and their career is often disorienting to business people.

Next, developers since the 1950s have a deep affinity for counter-cultural movements.  Beatnik, Hippie, Anarchist, Libertarian, and Punk mindsets permeate the culture of programming.  The let it all hang out attitude of developers is similar to the approach of Jazz musicians.  Hair color or politics does not matter; what matters is technical ability and the respect it generates.  It is why we have engineers with “UNIX beards” because they honor other engineers for the work they have done, and they do not care what business people think.  Someone like this does not have to care about being likable because they build things that work and keep the organization going. 

Finally, developers are more creative and intelligent than the average business person.  Creative people are alienating to people who are not.  Creative professionals are deeply suspicious of authority and rules.  Combine these two factors, and it is natural to see how business people and engineers distrust each other.  It is also why engineers chafe at the rules, regulations, and notion of professionalism.  To the engineer, professionalism is the curtain that hides the inability to solve problems and make things work.

There are three key reasons why developers and engineers do not behave as professionally as other business people.  First, they see the world differently and judge their value from a different frame of reference.  Next, developers embrace sub-cultures that do not respect authority.  An engineer or developer appreciates accomplishment or skill.  Finally, developers being more creative and intelligent, often chafe at rules made by others.  These three ingredients combine into a perfect stew of unprofessional behavior.  I will talk about how to work with these realities in my next blog.

Look forward to seeing you then.

Until next time.

 


Monday, June 22, 2020

Motivate Others Instead of Bossing Them

Motivation is Powerful


The biggest challenge for a coach or leader is motivating others.  If anyone could do it, the world would be a different place.  Problems like hunger, climate change, and a properly fitting pair of slacks would quickly happen because people would want to address those problems.  In reality, we struggle with these challenges because it is hard to motivate others, and there is an entire group of people who want to discourage people from thinking there are solutions to these issues.  Motivation is getting people to swim against the current of conventional wisdom. 
 
Motivating others is a full-time job.  It requires the application of soft techniques of persuasion and other times the blunt force of human resources.  People want to feel useful and challenged, but often they settle for security and routine.  A leader needs to work with these messy people and give them a chance to rise to their circumstances.  I struggle with this because I come from a command and control environment.  I would discover later in my career; this approach does not work with technical or creative professionals. 
 
The global economy has shifted from building things to creating experiences, services, and ideas.  It is a complicated process, and it requires more than following orders.  It requires looking at things from different perspectives.  The creative process requires a sense of craft.  Finally, it demands that people look at problems and question established answers.  People who excel at these skills are rarely the type to follow orders.  

Because we rely on information and creativity more than ever, leaders need to convince people why things need to happen instead of what needs to happen.  Give a problem to a bunch of creative people and tell them why it needs solving; you will be surprised by the effort they will put into solving it.  Telling people why something is essential creates a common cause with the team.  Explaining the urgency and necessity gives importance to work.  People with purpose are better than those with a plan.

So as a leader, you need to show others where you want them to be rather than telling them. Act as an example by listening to others and avoid asking someone to do something you would not do yourself.  Support others as they struggle to come up with solutions and listen to what others have to say.   It is surprising what you will learn.  

I do not have a magic recipe for motivating others.  Each day, I do my best to explain why certain things should happen.  The team should be concerned with how it should happen.  Finally, try to be an example for others to emulate.  Motivating others is not an easy process, but if you can do it right, the results are deeply satisfying.  

Until next time. 

Tuesday, June 9, 2020

When Culture Eats Agile for Breakfast.

Bad Culture is like canoeing over a waterfall.

I am very fortunate to have family and friends who are into musical theater.  For an aging high school theater nerd, it is always fun to sing along with a show tune while driving.  The funny thing about musical theater since the Second World War is that it has tried to tackle social issues.  “West Side Story,” addressed gang violence and racism.  I remember “A Chorus Line,” exposing me to gay characters.  Finally, “Hair,” had a rock-and-roll soundtrack and a fiercely anti-war message.  Over the weekend, I was running an errand, and the family was listening to the “Hamilton,” Broadway cast album.  I had an unusual emotional reaction, and then I began to think about my agile journey.  

One of the essential songs in the show, “Hamilton,” is “The Room Where it Happens,” where the characters Alexander Hamilton, George Washington, and Thomas Jefferson make backroom deals and compromises to keep the American republic moving forward after the revolution.  It is an excellent song about power and the practical matters of running a country.  It is also an ironic song because Hamilton’s rival Arron Burr jealously wants to be in the room where those compromises happen.

I thought back to a previous position where my manager would joke that I attempted to drag the company toward agile “kicking and screaming.”  The last two years of my career were so frustrating because I would propose solutions and fixes, but because I was not in the room with the decision-makers, my expertise was ignored or actively discouraged.  I would even complain to my manager that I wanted to be in the place where the decisions occurred.  Naturally, when I had my exit interview, I cited the firm’s lack of agile adoption as the reason for leaving.  Looking back at the experience, I realized my efforts were not going to gain traction because the culture of the firm was not going to value agility.  It valued tenure and experience over actually getting work done.  The stock market has rewarded the organization appropriately.  I was never going to be in the room where it happens because I had not paid the twenty-year commitment of time and adequately ingratiated myself with the other leaders.  Shipping software and delivering value was considered a threat rather than a virtue in that organization.  

The rough learning experience helped me grow and develop as a professional, but it reinforced the notion that culture is more influential than agility.  A dysfunctional culture or organization is going to actively fight against agile because agile quickly exposes the rot in the organization, and that threatens the careers of people who professionally benefit from that inefficiency.  People will quickly ally against any change, which is threatening.  The 14th State of Agile report echoed this state of affairs when they said cultural acceptance of agile is lagging because of leadership, not understanding it, and the organizational culture resisting its improvements. 

It occurred to me that unless you have senior leadership working alongside agile coaches and scrum masters, the rest of the organization will continue to do what it has always done through the force of inertia.  Even if I were in the room for decisions, at the old organization, it would not have made a difference because the leadership would not have understood a word I was saying.  So as a coach or scrum master, pay particular attention to culture because if they do not value the agile manifesto or principles, you are going to paddling against the current.  If the senior leadership does not understand agile, then you might as well go over a waterfall in a barrel.  

Agile works, but if you don’t have the right culture, you are up a dangerous creek.  You do not need to appreciate show tunes to get that message.  

Until next time.  


Monday, June 1, 2020

Call out Trolls Before They Destroy Your Business

Spot trolls before they hurt your business

The biggest challenge in Servant leadership is working with the disinterested, dishonest, and disrespectful.  Each organization harbors these individuals like weeds in a field of grass.  People like this seem to revel in their bad faith efforts to undermine others, avoid work, and act as parasites to everyone around them.  Throughout my career, I have confronted these individuals, and it never gets easier.  We should be brave enough to call out poor behavior.  

I spend plenty of time on LinkedIn. It is an excellent service because I can catch up on colleagues, get the latest news from the business community, and many of my fellow travelers share information about what is new. I was surfing along and read the following post from a coach and scrum trainer. The emphasis is mine.  

“I am a project manager having 15 years of experience and 5 years exclusively in project management. I do hold a PMP certificate too. My company is adopting Scrum-based delivery and it seems there is no role for the project managers. There are 3 roles in Scrum but none of them is for me. 

I can’t be a Product Owner because it will get filled from the business/customer side. I am not hands-on so I can’t be a part of the Development Team.

Scrum Master seems to be a very junior role for me. Many Scrum Masters are just a part-timer or working previously as Team Lead/ Tech Lead etc. There was a point when these people were reporting to me on my projects.

I also have an issue with the Servant Leadership style. It is not that I am a command & control person and you can ask my colleagues. Everyone will say how good I am with empathy, situation leadership, and self-reflection. But servant leadership sounds to me either head of the Servant or becoming Gandhi and Mandela. 

What will you suggest? Should I look at some different roles if yes then which one? I have also heard a lot about Agile Coach though I don’t know much how is this different than Scrum Master.”

I had a lot to unpack in this message.  It is an excellent example of how NOT to do Servant leadership.  I have said in the past, that ego is the enemy of good leadership.  Additionally, Servant leadership is more about leading by example than attempting to behave like a saint.  Scrum mastery requires kindness, and it often requires going beyond the call of duty. 

Being a scrum master is not a junior role.  It is a managerial role with tremendous responsibility and little authority. You are the person in the Taupe blazer who must inspire others to get work done.  At times you are a therapist, and at others, you are doing code reviews.  Often you are a square peg in a round hole.  Scrum masters are not junior; instead, they are essential to the success of your organization. 

The arrogance associated with the post was very telling.  What made it shocking was that it came from an instructor from Scrum.org.  I could expose this individual, but that would make me no better a coach or scrum master.  I am sensitive to harassment and doxing concerns on the internet.  I want the satisfaction of calling out a troll and exposing them to shame and ridicule.  The reality is they do not care.  A troll does what they do for the attention and outrage.  Instead, I would rather point out the attitude of these people so that we can be on the lookout for this behavior.  People like this are going to hurt your organization, so it is best to make you aware of them and not give them a chance.  

I take a great deal of pride in what I do.  As I continue to advance my career, I do not want to forget where I came from and the lessons I gained along the way.  Being a scrum master and product owner is hard work.  Developers and people in the organization are under tremendous pressure to deliver value to their customers and organization.  In the global economy, we are all servants, whether we like it or not.  Insulting other professionals as junior or beneath you is not how you participate in the agile reformation.  It is a form of elitism that has sparked backlash around the developed world.  

Today, I wanted to call attention to an attitude that will hurt your organization.  It is elitist, and it comes from a position of arrogance.  Do yourself a favor, find these people, and make sure you never hire them.  

Until next time.