Life as an IT software engineer can seem like shoveling a mountain of dirt into a red wheelbarrow called “Release,” pushing that full wheelbarrow to a chasm called “Production,” and trying to make sure we don’t have to backtrack and re-do any shoveling. Our reward for working some extra hours to make all that happen? The mountain of dirt called “Backlog” keeps growing and gets higher than the local “Mt. Trashmore” at the county landfill.
As a youth, my first real employment was at McDonalds. You know that you have your first real job when someone called FICA starts taking your money in order to share it back with you in 48 years. I did not appreciate McD’s as much as I should have. The job taught me how important quality was, how to work with a mix of teammates, and once my shift was over, I went home thinking that I had personally cooked for one million of the billions and billions served. I did not have this mountain called “Backlog” stirring in my mind during time-off or as echoes of work to do in my dreams. When I went home, I was done with responsibilities.
Back to my chosen field of software engineering. As a leader, I know that we have that backlog in mind, and that it can stand in the way of adopting change. I am fond of telling myself “Do one thing at a time, and do it well.” For a software engineer, that can translate into “I need to handle this backlog.” I applaud that mindset, because it shows an engineer has the ownership and pride to continually improve the application. It builds trust in the entire team and grows sponsorship from the business.
As a leader, why would I want to disrupt the wheelbarrow cycle of progress? If I do not look for the appropriate time to adopt change and promote it within the team, the outside forces of competition will force me to do it when I am not ready. Then I have to go from helping people through change to ordering them to change immediately.
Back to McD’s. For some reason, my store manager gave a 17-year-1-week-old kid a chance to be a night manager with a key and the safe combination. I helped with scheduling people, making sure we were doing things right, and getting my hands dirty when things got really busy. When hiring, we valued those high-schoolers who could multiply and add quickly, because we still used a paper order sheet without a calculator. There was one calculator at the manager’s desk if we had a ridiculous order. On the good side of the ledger, our folks could “math good” and do it quickly. But, change was coming – the first fast food registers showed up when I had just become a shift manager. Comically, it was a train wreck. Although we did get a few moments of training, the strange keypad to do the orders was hard to do quickly until you used it for a few shifts. There was no change management, and as a leader, I had to fumble with it as well and tell folks we had to use the register.
After surviving that poor change management, the need to do fast math moved way down the list of critical skills. I can recall a newbie, a really nice sophomore who always had a smile, suddenly becoming a great success because those service skills were not overshadowed by trying to “carry the one” and memorize the cost of “3 Big Macs.” It was a good change in the end. People’s value increased through taking a detailed task away.
Back to IT. When I was a trainee in programming, Assembler and COBOL were king and IBM was the undisputed IT champ with a dependable mainframe and infrastructure. Even at age 19, I could see that the home computer, just like the one that I purchased with my McDonalds fortune, would have to be a part of the future. Our company required independent insurance agents to calculate annual premiums with formulas that would have looked great on the Dead Sea Scrolls. Alarm bells began to go off in my mind. I had seen McDonalds change hiring due to the ability to do math in automation. These independent agents were saddled with the same challenge. Are we trying to hire amateur Actuaries, or the best sales people? Do we value that math too much?
I loved innovation and was a proponent to working the personal computer into IT strategy. I worked with 2 leaders who were visionaries that listened to me and one other personal computer zealot. We got a shot at creating that insurance calculator for agents. In 6 months, we launched the only independent commercial insurance quoting mechanism of the day. It could run on this new-fangled thing called a hard disk on a PC in the agent’s office. Our agents literally lined up to try it out, and about 40% adopted it on the spot. Because we were so early in desktop automation and had a lead on our competition, we could soft-sell the tech to the rest of the agents. The reason they did not adopt right away? They did not have a personal computer in their office yet. And if you are thinking that I might be ancient, I would only say that I do not remember the boys coming home from Gettysburg. Although I have been around for 3 Pirates World Series wins, so ancient is relative.
Full circle. Software engineers have this mountain of work as a backlog, and have a comfortable set of tools. These tools are beginning to look as old as the pencil and tablet of McDs. What is one of the keys to finding the best engineer of the past? How can that individual understand a business requirement and place it into a language syntax that is not practical for 95% of the people on the planet. Should the IT leader begin to consider the next steps for software engineering based on finding the next best symbolic language? Perhaps I should go back to my McDonalds days or insurance days and agree that removing a skill that limits our team is the next big step.
I had come to this realization for the third time in my career in 2013 when I began to study the tools for Low-Code software development. In Low-Code, the engineer creates logic in a way that reminds me of the old flowcharts we provided in technical designs. It was a way to understand the logic without slipping into one propriety code base. My weapon of choice was Mendix, but there are a number of viable technologies that promote the low-code method in 2021. How could I begin the change management process? After all, I was looking at a skill in senior software engineers that was a source of pride. A senior software engineer, by definition, could create, maintain and understand the most complex of technical routines and languages. Some software engineers react to Low-Code in the same way they might hear the news about losing a kidney. How could I convince them it was similar to losing wisdom teeth or (at worst) an appendix?
Important tactic #1. As a leader, I stand up and tell the engineers who are thinking of trying this new technique: “If this tool does not work out, it is my fault, not yours.” I remember receiving new tech in my young past, and having a leader tell me that other companies use the tech successfully. Therefore if I do not make it work, it is my fault. If we want to break change management on day 1, that is the way to do it.
Leaders, hear this loud and clear. We need to make a safe place for our software engineers to take a leap of faith and know that there are not big rocks at the bottom of the hill.
The results of the journey to low code? The business, seeing the reduced cost and improved delivery timeline is now asking for more work in this area. The mountain named “Backlog” has moved itself to another pile. In the area of hiring, I have begun to look for logical thinkers with open minds to sharing their work with business experts. I value head-down coding a bit less, and collaborative skills as a much higher indicator of success. A strange, viral symptom has been seen on teams using Low-Code. Business Analysts who create requirements are being invited in to look at the Low-Code flowchart being built by the engineer. In the start, the Business Analyst can understand the way the logic flows, and helps to confirm that the logic looks correct. What a great step for quality delivery! The next step? I have been part of teams who are training the Business Analyst to model their requirement inside of the Low-Code tool. This term is being called “Citizen Developer.” The software engineer would still do the heavy technical lifting needed to make the app function in the scope of all technical and non-functional requirements, as well as do the coaching for Citizen Developers to follow standards. Refactoring remains with the software engineer.
I would say that in my first attempt to promote change to Low-Code tools, I was only about 25% successful in having volunteers come forward. With quite a bit of hard work, problem solving and (some) cultural pushback by others, the small team of early adopters made a very good application. As the app matured, it was recognized in the Low-Code community as an award winning innovation when combined with legacy systems.
Important tactic #2: Leadership rewarded those who took the big step to work on the first Low-Code project. Our junior talent took notice that their peers were on a faster track to a senior role, because the innovators were in demand to be a tech lead and mentor others. For my part, my writings and communication consistently called out the people who made the success happen. Other software engineers began to take a closer look at Low-Code.
This is not to say that software engineers who are in those legacy systems that are critical value should be discounted. Those older apps likely make most of the money for the shop. The pure coder is a smart and dedicated individual. I have learned that opening the door to the traditional engineer has worked to bring over those folks gradually. I was not forced to do the “all or nothing” cash register change of 1977.
I am not sure what the next big tech will be in software engineering, but as a leader, I will make two statements when I see that tech and want to try it.
“Team, if this does not work, it is my fault.”
“Team, if this does work, you will be in the spotlight.”