Showing Some Gratitude for 2022

The last half of December is when the professional world goes to sleep. The Christian holidays, the Jewish celebration of Hanukkah, and the commemoration of Kwanza take the wind out of the global economy's sails. For a brief period, business people spend time with family and friends. It is a chance to rest, recharge and take stock of the previous year. Today, I want to attempt that same activity.

If you look at measurements, 2022 was a strange year. Since the end of the Second World War, the Russian army has been fighting in Europe for the first time. Inflation rose in response to growing demand after COVID restrictions but is starting to cool. Authoritarians worldwide seem to be on the rise, with the 2022 Olympics in Beijing becoming the high point of the global arrogance of that worldview. The world is still smoldering from the previous year's wildfires, and politics in the United States and the United Kingdom looks like a dysfunctional mess. Finally, any man that had any cultural influence made themselves look like a nitwit. Amid all this background noise, I was working as a technology consultant attempting to coordinate the activities of development teams across three continents. 

Working as a technology consultant is an exhausting career. It is not for the weak and takes a mental and emotional toll on anyone who does it well. You spend your time getting incompatible systems to work together. While dealing with these engineering challenges, you confront the confusing world of office politics and leadership. I stumbled into the vocation because I was good at computers. It also occurred to me that I can lead other developers and business people to get work done. I am a weird kid with nerdy hobbies who grew up to become one of the many anonymous figures who keep the global economy spinning. I cannot imagine doing anything else for a living. Over the years, I have experienced plenty of disappointing situations. Still, I have come out of these experiences more dedicated to making the world of work more sustainable, satisfying, and sane. In a way, it has become my life's devotion. 

First, I want to recognize my colleagues from CAPCO who have been there when I needed them. I could only do my job with a great support network. Michael Guerrero has been the best coach, and I look forward to being under his mentorship for a long time. Casey Schaffer is the woman who took a chance on me and taught me the importance of animal rescue daily. Beth Yiznitsky is a serious professional woman who does not take herself too seriously, and it inspires a loyalty that is difficult to understand. I am also grateful to Owen Priestley and Kyle Chavers for letting me be myself at work and allowing me to help others. Together with my fellow CAPCO employees, we are a "merry band of pirates," which I work with daily. 

I also feel like I need to recognize some people outside my company. Monica Guillory at Surestaff and I go back almost ten years, and even though we work at different organizations, we still keep in touch. We are both committed to diversity and inclusion. We both know that work can be a source of dignity and power instead of alienation and despair. Thanks for helping me keep my chin up. I also need to recognize two people I know through the Chicago Agile Coaching Exchange; Ryan Ripley, the Agile for Human's podcast host, and James Carpenter. Both are fighting to make agile real in organizations and doing it one client at a time: nerdy respect, folks. 

I consider myself fortunate. I have people in my professional life who support me, but where I am most lucky is at home. Carol Zelaya is a great life partner who loves me the way I am. My parents are still alive, so I often enjoy their company and wisdom. Finally, I have a group of friends who allow me to be childish around a board game table a few times a year. 2022 was a strange year, but I am grateful for all the people that made it worth living. I will take a week off to enjoy the holidays with my family. Next time, we will look ahead to 2023.

Happy holidays and until next time. 

Software is NOT transcription!

One of the most challenging things about working in technology is explaining what I do to others outside the business. A chemical engineer at a food company can explain they help create flavors or ensure the potato chips we eat are consistently crispy. A petroleum engineer transforms crude oil into gasoline and other valuable petrochemicals, making modern life worth living. An agile coach, scrum master, or software developer has difficulty explaining what they do. Sometimes it looks like magic, and other times, it resembles tedious bouts of frustration. There are plenty of ways to describe my profession, but today on the blog, I want to explain what it is not. 

Nothing is more frustrating for me professionally than interacting with executives who earn their leadership in their organization by mere survival. These people look like leaders but do not exhibit leadership characteristics because survival in a dysfunctional organization is the only accomplishment they can proclaim. They were mediocre people who were unremarkable employees. Eventually, these people are promoted by someone because they do not threaten the status quo and the leaders above them. These executives are allergic to risk and innovation because it would threaten their position.  

Countless times I have been in the office of these individuals and their faux leadership. One ordered me not to speak to other departments because he did not want the different departments to learn about our challenges with software releases. Another explained that we were not a technology company, so to expect us to behave like a technology company was foolish. I even had a vice president pat me on the head and call me ‘son’ before explaining how I did not understand modern branding. Naturally, when layoffs came, these paragons of leadership remained, and I was made disposable. 

These leaders are toxic and insulting to the professionals who keep the global economy spinning. By far the worst was a salesperson who said, “Software is easy; you just transcribe our order forms into the inventory system.” At that moment of emasculation, I knew it was a matter of time before I would quit the organization to do something else. Software development is not transcription! It is a complex process of taking business artifacts like forms and turning them into strategies that deliver value for the firm. It is not a transcription but countless creative decisions that developers make that have numerous implications for the business and the software development process.

The dismissive notion that software is just transcription is self-defeating. For example, how does an order form behave once a customer fills it out? Developers will ask about the impact of the order on the inventory and accounts receivable system. Software engineers worry about what happens if an item is missing from the warehouse. Can a data team use the inventory to track trends and determine how to serve customers better? Finally, what else should the ordering system do to deliver value to the business? It is a game with thousands of questions, and developers need to answer them to make the software work.

The technology world overflows with intelligent and talented people. Despite layoffs, the technology world has an over-abundance of work and needs more people to do it. Business leaders want to throw as much work at employees as possible because their labor is expensive. It is this crazy ratio of supply and demand which drives much of the dysfunction in the technology business. Instead of creating a cycle of productivity, there are episodes of burnout and failure to deliver. 

Over the years, I have been profoundly disappointed by business leaders who do not understand technology or how to lead others. I joined the agile reformation because I know that there are better ways to lead others and deliver working software. The business world needs reform, and it is up to people like me and you to speed that process along, so now, when a toxic leader says software development is easy, I know what to say to convince them otherwise.

Until next time. 

Cross Training for the Curious Agile Coach

Software development is a long slog of false starts and frustration. It is different from other forms of construction. Stakeholders generate vague guidelines, and it is up to software engineers to transform them into working software on various platforms. As an agile coach, the complex process of building software must have an environment of psychological safety, mutual respect between team members, and a ruthless commitment to quality. I keep thinking about Alex Stoley's discussion about how we need to have a 'brain transplant' between members of an agile team. 

I first met Alex in 2018 at the Agile 2018 conference. We were both giving presentations, and I looked forward to his unique perspective. During his presentation, he used the metaphor of a mad scientist to describe the process of cross-pollination, which should happen between a scrum master and a product owner. He likened it to something like the Frankestines monster, with brains transferred between the two roles. To Stoley, only by living and working in the other person's role was it possible to improve the entire team's performance. I instantly converted to this message, and when I had a  chance, I decided to work as a product owner to improve my skills. 

Today, I continue to think about Stoley and his message. My experience in the software business has convinced me that teams perform better when members cross-train. Training like this allows team members to help each other during difficult periods and prevents bottlenecks from happening when one team member can only do work. Each team member can have a specialty, but each member is responsible for instructing the others on the team on how to do the basics of that specialty. Someone with object-oriented skills can help a javascript developer better understand types. That javascript developer can teach the object-oriented developer how a domain object model works on the web page. 

The cross-training process on your team will be hard work, and the go-go business world might need help understanding it. Still, the hard work done upfront will make the team more resilient and better able to code with the numerous challenges which crop up during a software release. 

If you attempt to explain this to an executive, use a metaphor from athletics. The next player steps in to fill a role when a football player is injured. The replacement player is good enough to help the team and will act as a sparkplug for the people already on the field. Crosstraining is also valuable because it defines the standards of excellence everyone on the team should follow. For example, everyone on the team should know how to write unit tests because a story is incomplete until someone writes a unit test. Thus, when new people join the team, part of the integration process is showing them how to write unit tests. It creates a common bond that all the team members share.

Brain transplants are the stuff of science fiction, but the benefits of cross-training are genuine. Team members who share a standard skill set are less likely to get stuck and perform better for the organization. That knowledge makes me want to cackle like a mad scientist. 

Until next time.