In Praise of Duct Tapers and Problem Solvers

The world of business is shifting and complicated. Billions of dollars are sloshing around the global economy, and currents of this activity impact each of us on the planet. It is hard to make sense of all the motion and activity, so the business press attempts to make sense of it with strange trend articles. Fobes magazine had an article about the five tribes of employees you find in the office and their possible leadership potential. I enjoy these articles as social exercises, but they left out a crucial component, and I feel compelled to discuss it. 

Ryan Hogg in Forbes reported that the good folks at Slack have identified five prominent workplace personalities. He then describes their unique characteristics and possible ability to lead business organizations. These subgroups are detectives, networkers, road warriors, problem solvers, and expressionists. I am including a link to the article here if you want the full details. 

What struck me about the article was the perky and upbeat nature of how Hogg describes these tribes of workers. Detectives are data-oriented, organized, and outcome-oriented, while road warriors are 'feisty' and have a different vision of success than typical employees. It is easy to be glum and write about work with a sense of futility and toil, so I am grateful for Hogg to take a different approach. 

Working in a contemporary office has gotten a bad reputation. As corporations have grown, we need to do a better job developing leaders, and profit-seeking is the central focus of our activities to the detriment of everything else. It is a toxic perfume of alienation and exploitation. It explains television shows like The Office and The IT Crowd have become cultural touchpoints in the UK and the United States. Our work lives contain plenty of farce and pathos. 

According to Hogg, people like me are problem-solvers. We adapt to technology quickly and like using new ideas to solve old problems. Slack's head of customer success said, "I expect to set the problem solver to be an integral part of an organization because they're going to be the people that adopt artificial intelligence much faster and find ways to make their jobs easier." 

Hogg ignored the definitive book about office subculture seven years ago, David Greber's "Bulls#it Jobs." In his book, Graeber uses his experience as an anthropologist to explain the five tribes of people who undermine organizations—he labels these groups flunkies, goons, duct tapers, box tickers, and taskmasters. Graeber's book is an unflattering look at corporate life and the "profound psychological violence" that accompanies it. 

Graeber and Hogg's overlap is the description of problem solvers and duct tapers; both live in an ambiguous realm of decisions requiring judgment and creativity. Duct tapers and problem solvers spend lots of effort fighting corporate red tape, fixing problems before they happen, and keeping the promises of others. They are project managers, scrum masters, and middle management types who support the organization. They also make many enemies because they spend most of their time challenging existing power structures and proposing new ways to do things. It requires technical and people skills with uncertain payoffs. 

I am proud to say that I have been a duct taper for the last twenty years of my career. Along the way, I have earned a few emotional scars and developed a reputation for frankness and delivery. Executives only understand the necessity of problem solvers and duct tapers once they need them. When a deadline is in jeopardy or an existential threat crops up in an organization, these people become saviors. Otherwise, they quit and join other organizations because even the best duct tapers and problem solvers know when to run for cover when an organization is about to blow up. 

So, if you want to ensure the survival of your organization, pay attention to this tribe of employees known as duct tapers and problem solvers. These people know your organization better than you do, from its seedy underbelly to the glamorous product launches. They also have a symbolic roll of duct tape to keep the organization from flying apart. It would help if you had more of them in your organization. 

Until next time. 

 

Postulates for Backlog Prioritization

Today, I am continuing my discussion of backlog management. A good backlog follows Roman Pitchler’s DEEP model. Sticking with three simple building blocks inside your backlog will streamline work, and placing all work that drives value in the backlog will make you more successful than half of the other product owners currently working. This week, I want to discuss something that many organizations struggle with – prioritization.  

As a software developer and agile professional, I spend plenty of time around entrepreneurs and business executives. Many of these individuals are insulated from the hard knocks of life by the success in their careers. Because business leaders are accustomed to getting everything they want every time, they need help when asked to set priorities. People unaccustomed to hearing no are notoriously tricky to work with. 

The cold reality in the global economy is limited time, people, and money to get things done. Bosses who create a climate of terror destroy their organizations. Therefore, priority setting is necessary sooner or later. Confronting this reality requires a few postulates for business people to understand. 

The first postulate of prioritization is if you do not set priorities for work, someone else will. When you give a software developer a list of things to do without priorities, they will work on the most straightforward task or the one that interests them personally. It means employees often spend their time on tasks that are optional to the business. It may not be a big problem at first, but it will create situations where a developer will build something, and it will be radically different from what the person paying the bills asked for. 

The following postulate is that when everything is a top priority, nothing is. In business, there are important things and things which are urgent. Rarely do the two overlap, but business leaders want to create a false sense of urgency to get work done. It is a recipe for failure because if items are all urgent and essential, they are just like they should have been prioritized. The easy or enjoyable tasks will go first, generating conflict between the employees and management who commissioned the work. 

Finally, we should prioritize work based on the needs of customers and stakeholders rather than the highest-paid people in the room. I have spoken at length about egoware and other types of waste in organizations. The top priority for any business is the customers who pay for the solutions and products the business manufactures. So, when confronting a situation where a customer conflicts with an Executive Vice President of Application development, you must side with the customer. Improved revenue and better profit margins have a way of silencing critics. 

So, for a backlog to be successful, follow these three postulates of prioritization. First, set priorities; otherwise, others will set them for you. Next, priorities need variation because if everything is a top priority, nothing is. Finally, prioritize based on customer needs instead of management desires. These postulates are the foundation of a successful backlog. A successful backlog is the beginning of a successful agile implementation. 

Until next time. 

From the Basics to Healthy Ownership

Agile professionals tell tales about our successes and failures regularly. It is how we learn about what works and what doesn’t in our profession. Agile people also enjoy a good tall tale about the foibles of working in the global economy. After some time, these tall tales become apocryphal stories that we share. I am guilty of this behavior, and I am sure other coaches do it. Today, I want to pull back from the mythology surrounding agile and focus on the basics. 

I am reading Dave Todaro’s book “The Epic Guide to Agile.” What I like about this book is that it concentrates on the basics of agile and scrum. Todaro builds out advanced concepts from the basic foundations grounded in years of experience working with software professionals and business people. It is refreshing to see this writing about agile. 

As a coach and scrum master, the most fundamental building block is the product backlog. It is the bedrock where most Agile efforts begin. It is also where we see the origin of many of the dysfunctions in a business. When reviewing the subject, a product backlog is a prioritized list of work, including user stories, bugs, tasks, and spikes. A product owner creates and prioritizes that list while a development team completes that list. In contrast, a development team completes that list, checking off individual stories.  

Backlogs work on the level of individual teams. When coordinating between multiple units, we create what the people in SAFe call a value stream. Value streams then roll up into portfolios of work. Thus, you can roll work up into larger blocks or break it into its most fundamental levels. We aim to have a clear view of what is being worked on and measure how much value is generated for the firm, not to create busy work at the organization.

To avoid getting lost, Agile professionals need to be able to measure progress and draw maps of where we have been to where we are going. It takes organization and a particular discipline, but if done correctly, you can communicate clearly with both business leaders paying the bills and development teams doing the work. The push-pull between the two groups is what I like to call “healthy ownership.” In a perfect world, leadership trusts the organization to get work done and can trust leadership to look after them. It should be a beneficial and mutually symbiotic relationship. 

Over the next few weeks, I will focus on how to help build healthy ownership in organizations, from setting up backlogs of work to ensuring that middle management does not strangle agility efforts for selfish reasons. I look forward to you joining the conversation. 

Until next time.

A Place for the Manager in the Agile Organization

I am always impressed by my fellow Agile advocates. Some are grumpy cynics who see failure around them and feel responsible for helping clean up the substantial debris cluttering global business over the last fifty years. Others are cheerful warriors attempting to show a better way by living example for others to follow. My approach lands somewhere in the squishy middle as I see behavior that violates my values. I understand intellectually that these violations are occurring because people created those systems to normalize those violations. 

As an agile professional, I have spent the last ten years fighting the uphill battle of changing business culture and performance. A common observation we in the Agile community have when we attempt to bring Agile to organizations is that teams quickly adapt to this new reality. Managers, in particular, are a constraint on how successful agile is in an organization. Today, I want to discuss the manager's role in an organization. 

My coach at CAPCO Financial, Michael Guerrero, ruefully observes that middle management is where agility dies. Executives know the importance of being more agile, and teams embrace the ethics of agile frameworks like Scrum and Kanban. Managers are often caught in the middle and do not know how to navigate an organization transitioning to agility. The challenge of finding a place for a manager is becoming a central question in the agile reformation, along with how to scale it to the entire organization. Diana William and Liz Rettig from Project Brilliant gave an excellent presentation at AgileIndy 2023. 

The Scrum Guide and Agile are very good at defining the roles of a scrum master, product owner, and team member. The Agile community is silent about where managers fit into this system. It does not help that we do a poor job selecting and training managers and that those who advance into those roles behave in ways detrimental to the organization. Instead of making middle managers scapegoats for the failure of agile, coaches and scrum masters need to recruit them as partners for success. 

Williams and Rettig suggest four roles for the manager in an agile environment.

Provide Strategic direction –

Managers need to provide clarity and direction to the teams. They explain the 'why' of the decisions made and let the agile teams figure out the 'how' and 'what' of work. In traditional managerial roles, they thrive on ambiguity in an agile environment and must provide clear guardrails for performance and conduct. 

Grow People – 

A manager in an agile environment must grow the people they serve with training and development so that their skills become more 'T' shaped and they can advance within the organization. Even a person content to remain in the same position can learn to be better at their job. Managers of this type are judged by how they grow the people under their care. 

Create an Environment for Success – 

Managers in an agile environment need to learn how to address constraints and impediments. These managers must create solutions to these blockers and create an environment where people want to work. It is more than coffee, pizza, and foosball tables. It includes reducing technical debt outside the team and getting collaborations from other parts of the business. 

Being an Agile Champion – 

Finally, a manager in an agile environment champions the process. They encourage retrospectives, support efforts to build psychological safety, and allow teams to design their work areas. They must be willing to exhibit the same continuous improvement they expect from the development team. Finally, they need to get out of the office and talk with the scrum masters, product owners, and stakeholders to ensure they have what it takes to succeed. 

These are the four roles of a manager in an agile environment, and they will look alien to people accustomed to sitting behind a desk and doing administrative work. It is a much more hands-on role. 

When we portray agile in organizations, we show it like a three-legged stool with the development team, scrum master, and product owner, each playing a supporting role. We intentionally exclude the manager. If we want Agile to succeed, we must change this mindset to include managers. Thus, a manager should envelop the team providing these four services to make each of its legs successful.  

The next five years will be critical for Agile's success, and it is up to us in the profession to ensure managers are not left behind.

Until next time. 

Mental Heath is a Management Responsibility.

Kim Scott, the author of Radical Candor, says in her book that management requires emotional labor. It is just part of the job. When you work as an agile coach, scrum master, or product owner, you spend plenty of time guiding others to accomplish complex goals. It requires listening and helping people navigate emotions and thorny problems. I wish it were easy, but it involves self-knowledge and awareness that I have only developed over the last ten years. Today, we are facing a crisis in the workplace. Mental health issues are becoming more visible in the workplace, and it is up to us as leaders to mitigate the damage. 

Chicago radio station WBBM reported that the newest cohort of workers, Gen Z, is facing problems in the workforce. According to the Mary Cristie Institute, more than half of young professionals require emotional or mental health support. Furthermore, a whopping 53% experience burnout once a week. Beginning your professional career is always stressful, but these survey results are inexcusable. It also reminds me of my struggles in the job market thirty years ago. Entry-level work is not glamorous and often resembles ugly hazing. The low pay and the uncertain career advancement in this portion of the job sector are making matters worse. You grind at a job in the hopes of financial security and satisfaction, and these things are elusive in the entry-level slice of the economy. 

A newly minted college graduate has something that most organization employees lack – enthusiasm. Within a year or two, we crush that enthusiasm out of those people because we partner these employees with poor managers who make a bad situation worse. Forbes magazine and the Harvard Business Review point out that 70% of employees want managers to support staff's mental health better. 

First, employees want to feel like they are part of a team and making a difference in the organization. Next, they want to spend time with their families and friends. Work and business are commercial enterprises, not families, because I have never met a professional laid off from their family. Work allows us to support our families, and we would like to enjoy time with them. So for the staff's mental health, let them take time off to be with the people they love. Please do not make them choose between a client presentation or attending a music recital. Finally, workloads need to be better managed so that people do not feel like the weight of work is crushing them. Los Angeles Dodgers manager Tommy Lasorda said, "Happy cows make more milk." Ensuring the staff is respected and mentally healthy will do wonders for the bottom line. 

I can already see a few of my colleagues cynically criticizing mental health in the office. They might argue that new employees lack the mental toughness of previous generations. That argument is hogwash. If anything, this latest generation of employees is more robust. Generation Z has more pressure on them than previous generations, including wages that cannot pay for basic living expenses, large amounts of student debt, and a business environment that treats them like red solo cubs. Reducing the tensions among these people will create benefits that will be unexpected. 

Mental health feels like a touch-feely issue that does not impact the bottom line. Mental heal has everything to do with the bottom line because if your staff is sick or burnt out, your customers will know it. Do not be the company people leave because you don't care for the people who support customers. As a manager, we need to do emotional labor to help our employees succeed, and paying attention to mental health is just another part of the job. 

Until next time. 

Some Thoughts About the Great Flattening

Returning to work is a powerful emotional experience. My friends and colleagues were glad to see me, and a pile of work awaited me upon my return. The time away gave me a deep feeling of gratitude. Of course, I had to kick some rust off, but it did not take long to gain my bearings and return to the usual flow of work. My body had other plans, and I had to rest as the healing process continued. It was a strange week in business news. The late reports about technology layoffs pointed out that discharges disproportionally targeted managers at companies. News also surfaced that Meta was attempting to “flatten” its organization. I have spoken about management and leadership on this blog, and I need to share more. 

I always disliked the term manager. In my experience, leadership at any level is more significant than official management titles. It implies an act of authority over others which is short of leadership and greater than building customer value. Serving in a management role also includes plenty of responsibility with none of the corresponding authority. It creates awful paradoxes where people are being pushed and pulled in two different directions, first by executives above and then by the people they serve below. It explains why recent surveys of middle managers show that 43% suffer from burnout. 

It also does not help that many executive suites have the characteristics of the VIP room at an exclusive nightclub. Many executives come from similar MBA programs and have yet to spend time working with customers or employees. When this happens, tunnel vision takes over, prioritizing what the executive team wants versus what the customers might be demanding. It is all fun and games when interest rates are low and business is good, but increasing interest rates and venture capitalists looking for the next big thing trigger over-reactions. The recent tech layoff is an example of these over-reactions. 

So with executive leadership looking out for themselves during difficult economic times, middle managers and front-line employees bear the burden. Naturally, those left behind in the aftermath of layoffs must take on the duties of those who are gone. It is a significant problem in the technology industry because work outstrips the number of competent people to complete that work. It explains why Meta is attempting to flatten by forcing its managers to code with their teams. 

To an executive, this seems logical, but it is fraught with peril. First, programming is a creative skill like music or dance. It is rare for a choreographer or conductor to return to the performing company because they often need help to physically perform the skills. Next, asking technology managers to code and perform their typical management duties means they must improve their skills. Requiring a manager to code means less time for meetings, performance appraisals, and transmitting messages from executive leadership. Executives might say those functions are unimportant but will be when raises and vacations are late for line employees. Finally, managers are connective tissue within the organization because much of the work is too specialized for executive leadership. Someone needs to make sure the network engineers keep the network running. A good accountant must keep accounts payable up to date. Human resources people understand the law and can prevent both strikes and lawsuits. Without this specialized knowledge, most modern businesses would collapse like a house of cards. 

I lived through two downturns in my career. It is not pretty. However, the executives who try to flatten organizations often discover that they need the managers and specialists they depend on to run the organization. You should expect sanity to return to corporate offices in twenty-four to thirty-six months. Let's all tough it out in the meantime.

Until next time. 

Reflecting on Time Off

The last week has been a departure for me. Instead of working and concentrating on my numerous pursuits, I spent most of my time sleeping and relearning how to eat again. The rough moments felt mighty low. Fortunately, they did not last long. Many people have difficulty being alone, and I am no exception. I prefer focusing on things I can control. When your body is recovering from major surgery, you must depend on a team of doctors, nurses, hospital staff, and family members to help you get through the days. This vulnerability and dependency are new to me, and I consider it as I return to work. 

As a society, we train professionals and business people to be suspicious and skeptical of others. People are always looking for a better deal and an advantage over others. It hurts trust, which is the central lubricant of the business world. Without trust, the gears of the global economy would grind to a halt. Work is also so extensive and complex that hundreds of skilled professionals must work on systems to make a change or come up with innovations. Combining this reality with office politics, egos, and incompetence and creating things in the global economy feels like a torturous death march. The author Lewis Carol said, “That between light and darkness lies the shadow.” It is clear to me that I have made my living within this shadow realm. 

As an agile coach and leader, it has made me reaccess how I look at this shadowy realm of dysfunction and frustration. First, I cannot change things that are outside my control. I can control my emotions and guide my teams to do the right things, but if the organization does not want to change, I cannot force it. Next, if the recent layoffs in the tech industry prove anything, work is a place to make a living instead of being a surrogate for a family. If I die, it is clear that my family will mourn my death and lower me into the ground. A company will post a job opening the next day. I will bring a sense of craft and professionalism to my job but will never become emotionally reinvested again. Experience has also shown me the people you can trust and depend on are rare. When you find those people, it is your responsibility to cultivate and empower them so you can do your job better.

This kind of understanding comes with experience and plenty of failures, but it guides me forward. Being an agile professional means dealing with the world as it is and aspiring to make it better. Sometimes, I question my dedication and commitment to those goals. In my small way, I have made the world better, so I carry on. It is ambitious to change the world a bit at a time. Hopefully, my legacy will alter the future for the better. 

Until next time. 

Management in the Digital Age

Anyone who tells you that being a business person is easy has not spent much time in an office.  Customers demand more value, and the pressures of profitability squash and stretch the organization like a piece of taffy. You have to navigate market pressures, office politics, industry regulation, and deadlines as an individual.  Often these factors combine to create a toxic stew that undermines your sense of self.  It is why I embraced the agile reformation as strongly as I have.  This week there has been plenty of conversation in business literature about severe problems in the agile movement.  Jurgen Appelo is promoting a new book entitled “Agile 2.0.” As someone who works on the front line of the reformation, I have seen some of these challenges firsthand on the blog this week, I want to discuss them.  

This week, Steve Denning published an article in Forbes magazine proclaiming managers need a new job description.  He points to a 1977 Harvard Business Review article entitled, “Managers and Leaders Are they Different?”  The article is so popular that it has been reprinted twice since its original publication.  In the article, the author points out three characteristics of a manager in a business organization. 

1) The manager focuses attention on the procedure and not substance – it is more important to concentrate on how decisions are made rather than what those decisions are.

2) The manager communicates to subordinates indirectly by “signals.” - The only safe way to use procedures is to send indirect “signals” that obscure personal viewpoints.

3) The manager plays for time.  Self–protective routines are done up and down the hierarchy to avoid being on the wrong side of a decision.  

To anyone who has read the agile manifesto and understands agile principles, these three management practices are what we are attempting to overcome in the business world.  Self-managing teams were better than managers dictating work.  Playing for time disappears when you are working with the customer to provide value to the organization.  Finally, “signals” disappear when you are emphasizing individuals and interactions over processes and tools.  Software is eating the world, so the manager class should disappear as companies move from an industrial age mindset to a digital one.  

In reality, the frozen middle of the management class is alive and well in most organizations.  Banks, Insurance companies, manufacturers, and other businesses have existed for years, and managers have used that time to cling to the organization like barnacles.  Playing for time, using signals, and following procedures work for these people if they keep them employed and feed their families.  When faced with a new way of doing things, they react like saboteurs.

Thus we need a new style of manager who can succeed in the digital economy.  The first characteristic of a new manager is to embrace speed.  Instead of playing for time, they follow the cadence of a sprint.   Every two or three weeks, they release products to customers and hold others accountable for those goals.  It means getting out of the way of the teams when they are attempting to meet those customer needs.  It means learning to ask questions instead of giving orders. Finally, teams need to know how to self-manage, so scrum masters and the development team might need help and training.  

Instead of signals, leaders need to be clear with expectations, and those expectations need to be visible and unambiguous.  It is keeping with the principles of empiricism and transparency public for everyone to see.  Budgets should be transparent, deadlines and requirements should be obvious, and when the plan changes, it should be clear to everyone.  I suspect this will be the most challenging behavior to break because this stinginess with information is self-serving for an old school manager. 

Finally, a manager needs to be less concerned with the process and more concerned with output.  Daily Scrum meetings and sprint reviews are a great place to come up with new ideas.  An idea that originates with a customer or team is just as valid as something that comes from leadership.  We should embrace ideas from everywhere.  Ideas should be tested in public and held to rigorous standards of success.  For the sake of the business, reject ego and authority for outcome and value delivered.  

The management class needs retraining to reject old behaviors and embrace new ones.  Notions of process, signaling, and playing for time should be cast away for outcomes, empiricism, and speed to market.  Leaders and managers who embrace these new values will become agile digital companies.  Those who don’t will see their organizations sink to the bottom of the ocean encrusted in barnacles. 

Until next time. 

It is never about you.

Serve others it isn't about you.

The best part of being part of the agile reformation is the community of supportive professionals who inspire each other.  I can rely on the experience and wisdom of thousands of people who are on a similar journey attempting to make work saner, sustainable, and satisfying.  Currently, I am training at Chicago State University to improve my credentials as a certified agile coach.  It is an excellent experience with people from all over the globe.  Someone from the Philippines has the same challenges I do when leading change.  It is always nice to know that we are all facing similar struggles and challenges. This week, I learned a rather important lesson, which often gets lost as we become more experienced in agile. 

 

One of the critical foundations of agile is the notion of servant leadership.  The best leaders often are those who see themselves as servants helping the people; they lead rather than viewing the people under their authority as people who serve them.  As you gain experience and credibility within the profession, it is easy to let the certifications, recognition, and respect go to your head.  We are scrum masters, and people look to us for advice and guidance.  It is intoxicating.  

The reality is that being an agile coach or scrum master is about service to others.  It is not about us and our journey.  We should remember that success in this profession is when others take the lessons we have learned and apply them to their challenges.  If we are doing our jobs properly, our wisdom will help build success for others.  We should celebrate the achievements of others and the growth of people under our charge.  Unlike other areas of business, being a coach or scrum master means taking the focus away from yourself and directing it at the teams you are working.  

It is nice to learn from others.  The most important lesson is discovering that to be a servant leader, you need to remind yourself it is not about you but the people you are leading.  It is a lesson worth repeating.  

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. 

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.

 

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. 

Scrum depends on leadership.

Leadership is hard.

The global economy is filled with challenges.  The economic cycle of boom and bust.  Trade wars and political uncertainty dominate headlines.  Workers are flexing their muscles to retain the wages and benefits which kept them in the middle s class.  The agile reformation is in the middle of this environment.  We are striving to make business saner, sustainable, and satisfying.  It is hard work.  Often we are struggling with status quo thinking and the demands of the market place.  We test scrum masters and coaches daily.  The principle test is the leadership skills we bring to work each day.

The scrum guide has evolved over the years to discuss the changing role of the scrum master.  We describe scrum masters as servant-leaders with the ability to influence others without having real authority.  I have written numerous times about servant-leadership.  I am a big fan of people like Dwight Eisenhower, Harvey Milk, and Creighton Abrams.  I am also impressed by academic thinkers like Gilles Deleuze and Albert Camus.  What all of these people have in common is deep intelligence and the ability to overcome obstacles to accomplish great things.

Leadership is hard.  In the words of General Collin Powel, leadership is pissing people off to get things done.  It is uncomfortable.  Leadership is upsetting comfortable structures to achieve greater success.  It is emotionally taxing and a job that follows you around even when you are outside the office.  It is a skill that must be cultivated and rehearsed regularly. 

The alternative is a catastrophe.  People who are concerned with their advancement at the expense of others are toxic in an organization.  Those people will game measurements to make themselves look more effective than they are.  They will withhold support for others unless they can receive some benefit.  People work with these kinds of leaders not because they want to but because they have to do it.  Organizations succeed or fail based on the leadership skills of their people, and poor leadership will kill and organization.

By now, you realize that I feel strongly about this subject.  I have spent my entire career working with many different people.  Some were inspirational, and others were more interested in their success than others.  I prefer the company of inspirational people.   This week my leadership was challenged twice.  I was helping a professional team release software, and I had to perform agile assessments on other teams.  The common thread through these experiences is that good leadership was obvious to see, and lousy leadership was more deceptive.  Be on the lookout for these corrupt leaders; they will harm your business. 

Until next time.

Fight Bad Agile!

Command and control did not
 work then and it will not work now.  

I have been involved in the agile reformation for the last ten years.  In 2009, the agile manifesto was relatively young, and it was a quirky idea to make software better. Today we have three primary scaling techniques for agile.  The reformation has grown and splintered over the years, but the manifesto remains the pole star which every variation circles.  Now business professionals and executives are paying attention to the reformation.  Agile is eating the world, but instead of confronting opposition, we are dealing with corruption caused by the status quo as it exists in many companies.  The corruption creates bad agile, and it is up to coaches and scrum masters to call it out.

Last week, I pointed out that a common dysfunction in organizations is leadership spends too much time pleasing superiors rather than doing the necessary work to make the business successful.  The behavior hurts collaboration between departments and categorizes people as resources which can be swapped out like machine parts.  It is dehumanizing and alienating.  Agile helps fight this dysfunction with emphasis on cross-functional teams and less organizational friction.  The challenge of agile is it works well in the realm of the team, but as it attempts to scale out to the organization, it butts against status-quo thinking, entrenched political agendas, and the command and control mindset of most executives.

Put yourself in the shoes of a typical executive who has spent ten, fifteen, or twenty years in an organization. The executive has presided over budgets and deadlines.  The contact they have with the people doing the actual work is limited, and their knowledge of project management is slight, so they hire project managers to handle the responsibility.  Most of the time, executives spend time involved with pleasing superiors and political sparring with rivals.  An agile coach comes along who tells them they have the wrong career focus, and they have been leading their people incorrectly.  Agile, with its emphasis on inspection, adaption, and transparency, undermines political infighting within an organization, which means career advancement depends on results instead of deception.  It is going to create anxiety, and the executive is going to push back.

The executive is not evil in this instance; the new way of doing things creates uncertainty and fear.  It is natural they would be resistant when confronted with this upsetting of psychological safety.  As a coach, it is going to be your responsibility to address the resistance.  You are going to walk the executive through the process of shifting from a command and control mindset to an agile mindset.  It will not be easy.

Instead of telling people what to do, the scrum master will have to show them.  Lead by example, give the team what they need to succeed, live the agile manifesto and principles, and point out organizations friction where it exists.  Inspection, adaption, and transparency are designed to hold everyone accountable particularly executives.

Bad agile happens because self-interest and the status quo are more important than getting work done.  We tolerate double standards, and it creates corruption.  It is up to each scrum master or coach to reveal this corruption so we can mitigate its effects.  It is up to each of us to show instead of telling others what to do.  Finally, we need to create psychological safety among leaders if they are to embrace agile.  Otherwise, we remain stuck with bad agile.

Until next time.

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

Information technology is hard work.  I have written about it before on this blog.  I have plenty of empathy for others who work in this profession.  I do not have much understanding of poor service or lazy behavior.  I am even less forgiving when large organizations brag about their success in public and struggle to do the basics in private.

I am at a client, and I have the following interaction with someone from the help desk; they said, “Can we close this ticket? If it ages any longer, it effects out SLA.”  My first reaction was surprise.  My second emotion was anger.  The help desk person was asking permission to close the ticket and open a new one because if they did not fix the ticket at a particular time, it would reflect poorly on him and his consulting company.  He was going to lie to make his response time look better than it was. 

It is human nature to please others.  British economist Charles Goodhart coined the maxim, “When a measure becomes a standard, it ceases to become a good measure.”  When you judge or pay people based on a measure, they will game the system in any fashion to make themselves look better.  You see this in economics.  It happens in video games and depressingly at work.  My help desk technician was living proof of Goodhart’s law.

Martin Fowler wrote a great article on the subject, and it outlines how to avoid this trap in agile practice.  Metrics are abused regularly in business.  In a large organization, the only way leadership can track progress is by reviewing these metrics.  Thus, the people doing the work are more focused on the outputs of hitting the metric numbers instead of the outcomes satisfying the customer.

I see service level agreements or SLAs as a necessary evil in business.  You have to hold vendors and third-party partners accountable.  Such a contract controls my current situation.  In a perfect world, my help ticket would age, and someone who could help me would respond to my issue.  The technician was afraid that if the ticket aged, they would receive a poor performance review or get fired.  It is an ugly situation, and if a company is going to succeed, they with have to address it. 

Large organizations need to focus on execution.  To focus on this goal, metrics and SLA’s need to be used judiciously; outcomes are superior to outputs.  It is a message which did not reach the help desk or his boss. 

Until next time.

A Little Empathy Goes a Long Way

Empathy is a big deal.

As a scrum master, one of the most important qualities you can have is empathy.  It is a special quality where you can put yourself in someone else’s situation and understand the world from their perspective.  It means operating outside your comfort zone.  Today, I would like to discuss the importance of empathy for a scrum master.

Working for a large organization is hard.  Employees often feel alienated from their work and coworkers. I think a significant reason for this situation is many people in leadership roles do not understand what it takes to provide the goods and services their organization offers.  These leaders are good at managing budgets and capacity but little else. It is where empathy matters.  As a leader, you need to walk a mile in another person’s shoes.  If a leader cannot do that in reality, then they must attempt the thought experiment to see the world from the perspective of the employee.

When a leader sees the organization from the perspective of the people interacting with customers several changes take place.  First, they see the people doing the work as people instead of resources who are disposable.  Next, they understand the systems and equipment the employees are using might not be meeting the needs of the customers.  Another by-product of this exercise is leadership understands how long it takes actually to build something.  It gives leadership insight into which deadlines are real and which are fiction.  Finally, leaders discover which activities generate value and which ones do not.

Early in my career, a mentor I respect said I should never order a person to do something I would not do myself.  I still follow those directions today.  It is why I go to meetings, so my coders get a chance to write software.  It is why I fill out expense forms and project requests; so the people doing the work do not have to do it.  It is part of the servant leadership I try to practice each day. So have some empathy for the people who work for you.  You will be surprised by what you might discover.

Until next time.

The Strength of Technology Pros

No rest for technology

Technology is not for the meek.  A software developer is relearning their craft every 18 months.  Technology companies come and go with regularity.  Businesses rely on software to remain profitable and when the software does not work it costs lives.  The men and women who work in this business have to be tough.  Part of that toughness is the realization you have to deal with failure and frustration.  This week on the blog, I will discuss these central conditions of technology.

Many people have romantic notions about scientists, engineers, and software professionals.  The stereotype is that we are super smart and socially awkward individuals who spend their days making inventions and applications which change the world.  The reality of technology is less glamorous; it is hours, weeks, and months of frustration.  It is executives and financers demanding the work to be finished immediately.  It is cold coffee and stale pizza.  It is loneliness and frustration.  In the end, you might have a brief moment which feels like the creator is touching your shoulder but those moments are rare.  Often you will see a solution to a problem which has dominated your life and now you will have to make it work for others.

It means traditional methods cannot measure these workers.  Science is notoriously fickle when it comes to new advancements.  Computer software is a handmade and messy process prone to error and cost overruns.  Software is eating the world, but it depends on a small segment of the world population to build it.  Innovation and invention do not fit neatly into a project plan.  The realities and pressures of technology create unhealthy levels of stress.

The heavy intellectual lifting combined with the anxiety caused by deadline pressure creates a toxic stew of emotions which can lead to physical problems.  Obesity and heart disease are common among software professionals.  Self-medication with cannabis and alcohol are also common within the trade.  All of my contemporaries have recounted stores of insomnia and anxiousness caused by grappling with a severe challenge.  For those outside the profession, the levels of stress and frustration are extreme.  To a developer, it is just another day at the office.

Creativity and innovation are difficult.  The pressure we place on people leading innovation efforts is unhealthy.  The repercussions are professional burn out, defective products, and the risk of cascading failure within complex systems which maintain the global economy.  In many respects, we live in a magical age.  Today’s smartphones are more powerful than the computers which put people on the moon.  With a few swipes, we can order food and find a possible romantic partner to share it with us.  Information can swirl around the globe in seconds and we have millions of people using the internet to solve problems only a century ago would have had the attention of a small group of specialists.  It is a fantastic period to be alive, but the cost is that many people take for granted these advances and forget they are the product of the human mind rather than magic.

It is why I say technology is not for the meek. It requires intelligence, training, and the ability to tolerate frustration and failure.  The strength has helped build the global economy, and I have enjoyed a peripheral role in this process.  Technology people are different, but they have to be; otherwise, the magical world we live in would not exist.

Until next time.

A Scrum Master Demands Interpersonal Skills.

A scrum master must have a
moral compass and great interpersonal skills.

The role of a scrum master is a challenging one.  Any given day you are confronted with new challenges, and you always face the pressure to deliver software.  You are pulled from the top by the demands of business leadership.  From below, you are leading your team and helping them improve.  I have been reviewing plenty of career postings on the internet lately, and I have noticed an interesting trend.  Postings have mentioned in passing the need for interpersonal skills.  I want to argue interpersonal skills are the essential part of being a scrum master.

When you look at a job posting for a scrum master you often see references to project management systems, years of experience and relevant industry experience, usually there is a request for certifications from the various accrediting agencies involved with agile.  The final bullet point is the requirement is a request for excellent interpersonal skills.

Being a good scrum master demands interpersonal skills.  You spend time coaching and educating others about agile and scrum.  A scrum master must be able to say no to others without sounding dismissive.  It requires solid interpersonal skills to have empathy for others.  A scrum master also must speak truth to power and have the integrity to back up those words.  All of this requires interpersonal skills, and a scrum master who does not have them is in trouble.  Earning a scrum master certification is straight forward, being able to do the job requires hard work and a growth mindset.  

You cannot check off boxes and have a scrum master arrive to make your team better.  It is a process of trial and error.  A team will take two steps forward and then fail in an embarrassing fashion.  It is not a traditional career path, but it is infinitely satisfying.  The foundation is excellent interpersonal skills.

Until next time.

The Development Team Must Be a Shark

The development team is like a shark.

As a boy, I thought sharks were the coolest creatures alive.  They were ultimate predators who created panic at beaches across the nation.  Steven Spielberg made one of the biggest movies of all time featuring a shark.  Sharks were a staple on public television, and today we can enjoy an entire week of shark programming on Discovery.  The more I have learned about sharks the more I respected and admired them.  As a scrum master, I have used sharks as a metaphor for the operation of a good scrum team.

A shark is a living fossil.  It has not evolved substantially in 200 million years.  When you are the top predator in the ocean natural selection is not a powerful influence.  It does give a shark several disadvantages.  The brain of a shark is smaller than the brain of a dog.  Sharks do not breed quickly, and the creatures plunge into irrational frenzies with the presence of blood and prey.

The biggest disadvantage sharks possess they have primitive gills.  Unless a shark is swimming with its mouth open, it cannot breathe.  It is a significant disadvantage because most fish today have gills which can filter oxygen out of the water without swimming.  Thus, a shark is doomed to swim from the moment of its birth.  A shark must swim, or it dies.

Software development teams should use the shark as a metaphor for how they should operate. Organizations need to keep swimming and moving forward.  A team needs to gain new knowledge and techniques continually.  A team has to deliver software regularly.  A team has to respond to a changing environment.  A team must keep swimming forward.

As a scrum master, it is up to you to keep the team swimming.  You need to ask compelling questions.  You must insist on delivering software into production at regular intervals.  Finally, a scrum master should encourage the team to pursue “Healthy Ownership,” with collective responsibility of outcomes.

If you cannot inspire the team in this fashion, you will have a drowning shark, and you will be dead in the water.

Until next time.

It is just like starting over

Listen, Listen, Listen.

The New Year is always busy.  The sloth of the holidays gives way to new resolutions and a means to wipe the slate clean.  I am no different.  I began a new role as a coach and scrum master at a new firm.  Today on the blog, I would like to talk about starting over and beginning a new agile practice.

A scrum master or agile coach lives an intenerate lifestyle moving from client to client.  More than many professionals they are starting over in new environments.  It means a coach needs to embrace responding to change over following a plan. It requires a certain humility and empathy for others.  Some organizations use Azure DevOps to manage the software development lifecycle, and others use tools like Jira.  Any good scrum master should be able to adapt to these different systems.  It might also be helpful to ditch a system entirely to learn the basics of agile. 

I find listening to others is helpful.  To drown out office noise, I often wore noise-canceling headphones and enjoyed a playlist of “New Wave” and “Post-Punk” music.  It made the day go faster, but it created a barrier between myself and others.  I did not understand how big a barrier until I decided to try something different and leave the headphones at home.  I began to hear QA people gossiping about bugs.  I learned about the favorite T.V shows of developers.  It was informative which people took calls via speaker phone and which ones were more discrete.  The office completed work in a particular way, and I gained insight into that process.  The insight is going to help me better coach others. 

Last year, I wrote a despairing article about my failure as a coach.  What came out of that experience was the realization before anyone can coach or guide others you need to empathize with them.  You cannot bully people into improvement.  People need to be shown the way and encourage to make better choices.  Experience and success will create a positive feedback loop of continuous improvement.  Leave the rough justice to managers who can discipline those who will not buy into the agile mindset. 

When starting over, shut-up and listen to others.  Cultivate empathic relations before learning.  Find out how your customers do things before proposing changes.  Finally, have some humility and respond to change.  Ever since Lee Iaccoa took over Chrysler in the early 1980s, professionals have worshiped the cult of leadership.  It is time to take a step back and realize that before you can lead: listen. 

Until next time.