Now that I have started showing the tender and slightly bruised heart that lies underneath the savage darklord exterior that I wear comfortably to daily meetings, people have started reaching out to me for professional advice. Actually some people have been doing that all along, but I want to believe that my writing exercise is somehow responsible for this. You should totally accept this as a truth.
As your organization grows and you start hiring more and more people to make software, eventually you have folks who are responsible for making software to help people make software. This is very meta. For people who like touching the hearts of customers, being sent to the “tools and technology team” is a death sentence. For others it is paradise-on-earth. Some people like identifying with their customers, and making code for other engineers means you can essentially pretend that you are your own customer and know exactly what everyone else needs and/or wants without asking them.
What could possibly go wrong with that, right?
In the course of making software, sometimes you have to go half-Zuckerberg on your various other engineering teams. Full-Zuckerberg means “move fast and break things”. For the sake of today’s open-heart surgery let’s just assume the need to “move fast” is not there; no pager alerts went off at 3 am. So let’s just “break things”. Maybe there are security concerns. Maybe there is a Better Way To Do Things™. In any event, you need to release software to other teams that is going to mess up their day-to-day.
It is important that this coming change is understood by all parties, especially if this is the first time you are doing this to your peers. If you do not think that they understand that this change is coming, then do not fall into the obvious trap: Do not just repeat yourself, but louder. If the reception of the data is not acknowledged you should assume it was lost. It is too easy to show a stream of repeated emails and MOTD files and say “hey I did my job”, even if that is not really true. You should plan on doing things that force people to stop and think about the coming change, even if that means you should use The Powers of Dark Psychology.
I will confess to being very comfortable with elements of The Dark Side. Red lightsaber… Green lightsaber… It does not matter to me what color the blade is, or where I swing it. I just like the cool whooshing noise it makes. “The right tool for the right job!” I say, and I mean it. Sometimes you need to give everyone cocoa and hugs. Sometimes you have to run into the room and chop off all the limbs and play hacky-sack with them while laughing maniacally. Figuring out the right time to use which tool is key to a successful leadership career. Don’t fool yourself and think you will win the game using only hugs and cocoa. Sometimes you will have to make hard choices and do things you will feel for the rest of your life.
Back to Dark Psychology. People have habits. If you are changing framework software, you are likely going to be modifying their habits. They may unconsciously ignore your repeated transmissions of impending change, or they may not fully grok the impact of what you are trying to tell them about, so you are going to have to work a little more harderer here. In order to prepare them for these changes, you are going to have to break their habits forcibly.
There are a lot of ways to do this. Grandpa Szeder is going to tell a quick story here. I am an agile practitioner when the team needs it to succeed. Getting teams to properly do agile is painful. I love getting into the conversations where someone points a finger and screams “that is not properly agile”. Dismantling that argument is like eating ice cream, cool, delicious, and sweet, but that has nothing to do with my story; I am going to teach you how I train people to do standups.
The standup is the core of any good agile process. A short meeting, so short that you should only have it standing up, because if it takes so long that your legs ache, then you are doing it wrongly. It is generally understood that the best agile practitioners do The Three Questions standup:
What did I do yesterday?
What will I do today?
Am I blocked on anything?
This is a great way to do a fast status meeting. The average engineer learning this process generally gets a passing grade at this; they get two out of three. There is some part of the brain that feels bad about being blocked. You do not want to expose the fact that you are blocked on something, or worse, you do not want to expose the fact that you are blocked on someone else. It makes it an easy win to omit this last third of the daily report if that is true, and it is even easier to omit from the status if you are not blocked. It also encourages broken windows because if one person routinely omits it then everyone routinely omits it. It took me a while to realize that, and even longer to come up with a long term fix. I am going to share it here because it will help you understand how to force people to communicate of their own free will. Yes, you heard that right.
People enjoy Flow. The Flow of work, the Flow of meetings, heck, even the Flow of delicious booze. We crave it, it means things are going nicely. When there is a group of people going through their stand ups at a break-neck pace, getting the majority of the questions answered, it certainly feels good. Most of them do not notice that they struggled with counting to three. So I figured out the best way to upset their little apple cart and get the third question answered. When someone has said what they did yesterday, and then said what they do today, I wait until they are finished and the next person has started giving their update before I take any action. As soon as the audience has gotten half way through hearing the next person’s description of what they did yesterday, I loudly stop them and ask the previous person: “ARE YOU BLOCKED?”. The first few responses are often nervous laughter. Sometimes the person who forgot to mention if they are blocked feels guilty. Sometimes the person who started next feels guilty. I will tend to stare at each person in the stand up equally, most of them avert their gaze when they realize they should be asking the very same thing. Everyone here is responsible for this message getting across, and it is important for us all to participate in this to be successful.
After two to three meetings like this, eventually someone gets the hint that John does not like to shout “ARE YOU BLOCKED?” at his teams. Eventually people will self-moderate this activity as a group, especially the person who is about to speak. Their concern at getting interrupted will prompt them to ask the previous person if they are blocked; after all, who wants to be interrupted in the middle of their daily update to go back to the previous person? It sucks for everyone.
This is a deliberate exercise. I hate to do it, but after three weeks, I will tell you that these standups are the best standups. I can still picture everyone’s face who has gone through this process with me. I still would hire each and every one of them today.
So what does this have to do with our tools and tech team? I am very glad you asked.
You are going to have to break their habits, to learn new habits successfully.
There are books on breaking habits and changing habits. They make for good reading. I am going to vaguebook a little here and passive-aggressively suggest that you can reach out to me to get a few of my favorite versions of these books. I am not yet so deep into the SEO and affiliate-code-linking to profit from your curiosity. I am sure that day is coming. I digress.
If you are just blasting emails and Slack alerts to your teams that framework changes are coming, you will not succeed in making them understand what that means. Here are some tools you can employ to help make this process more successful:
Sign-off Documents
When training zero-defect QA teams, there is no better tool than a document requiring a physical signature. When I give people test-plans for mission-critical products, I initially give them physical test-plans to execute, and I require a signature on every page. If something is mission-critical, and you are required to test it, I want you to believe it is so very important that you are willing to sign your name to it on a piece of paper. This may sound painful. It probably is. However, the QA leads who I have trained this way are now captains of industry in many different disciplines and much like some of the best software developers I have worked with, I would love to work with all of them again.
Get together with the teams who are about to receive new tools and technology and give them a physical document. Ask them to sign it. People will be very serious about accepting something that they have had to sign for.
Horrific Painful Meetings
Another tool to use is the Painful Meeting. Make it an hour long. Include an agenda in advance. Mention it will be recorded for all who missed it. Post minutes with attendance. Assign action items to attendees to ensure that people who missed the meeting will be brought up to speed. Throw around big words like “Mandatory” and “Compliance” and “Process”.
The secret trick to making this double-effective is that you should promise everyone involved that you will shorten this meeting and make it less painful in the future if everyone is successful at accepting changes to their habits.
Delightful Social Meetings
In addition to the vicious and painful mandatory meeting above, do not underestimate the power of food and fun. Create an outing where you can get people into a good mood and give them some warm and fuzzy feelings about upcoming changes. Whether you make a 3D cake, or you take the team axe-throwing, it almost does not matter. Just get everyone in a good mood and make sure you take a moment to let everyone know that this change is coming.
There is a secret trick to this meeting too. You should assign each person on your team a list of key stakeholders on other teams and speak with them through the festivities. It is important that they are personally updated on the coming change. If everyone feels like they were taken aside and given super secret special treatment, they are more likely to be open to changes and happy to invest time in understanding them.
Gently Breaking Tools
Much like the status interruption, this is another tool that is a great training tool, even though it comes with a heavy price. If you have scripts that people employ on a daily basis, you should add in some prompts to warn people about changes. Adding in a “Do you know this is going to change yes/no” dialog is one way to get people to pay attention, especially if they are used to not paying attention. Are there other things you can do? Certainly! Be Creative!
Take scripts that are executable, and at the end, dump a warning that you are going to make changes to this script, and then have the script take away its execution permissions so it needs to be explicitly reactivated.
Change filenames in some of your scripts to warn people of pending changes, especially if the new flow can be snuck in this way. Are you using new tools? Can you adjust some names in the interim phase to prepare people for these changes? All of these things will help raise awareness.
Actually Talk To Everyone
The last thing I am going to add here is the one that triggers the most “Will It Scale” angry stares. Because it doesn’t scale. At all. Unfortunately, Rome was not built in a day, and it helps you establish more credibility with partner organizations if you actually make the time to ensure that everyone involved is spoken to. You can delegate some of this, but certainly you should speak to the most senior people and the leaders of partner teams directly. Getting their buy-in and preparing them to be the first line of defense against changes is very important.
So there you have it. This is me dispensing thousands of dollars of management consulting advice for cheap-or-free. I hope you found it useful and/or entertaining.
I am going to finish off with a random anecdote and then go back to chasing kids off of my lawn.
A number of years ago, one of my sons was playing soccer. He had a year with a daddy-ball coach who only invested time in his own kid, who was also very terrible at the whole “coaching others” thing. The end result is that many kids did not improve as players, and they lost just about all their games. I am a big believer in not being a pointless whiner, so the following year I did the only thing that is acceptable: I volunteered to coach.
That year was better. We won more games, and many more kids improved as players. Because I was coaching, I got to see first hand that the referring did not look great to me. Having spent my year in the trenches as a coach, I did the same thing that I did last year: I volunteered, but this time to be a soccer referee.
Refereeing youth sports is not for the faint of heart. It is a blood sport. The field is an arena of fear. Everyone is staring at you and waiting for you to slip up, so they can blame the inevitable loss of the game on you. The pressure to make sure you see everything is severe, and it is suffocating. It is also an impossible expectation.
I decided to improvise in how I approached the game by approaching the other team’s parents at the start of the game. I roughly recited the following speech at the start. “Hi there, my name is John. I appreciate you all bringing your kids here to have fun today. I am going to start off by saying I am nervous because this is my first season as a referee and I am going to make mistakes. I am sorry for them in advance. Anything you think I missed, I want you to let me know, so I can improve. Now let’s go out there and play soccer!”
People looked at me strangely, because usually the referee is a parent from the other team and therefore they are “the enemy”. This was not a normal interaction.
At the halftime point, I would go back to the other coaches, and 1-2 parents and thank them for a great game so far. I would point out one or two places where I think I messed up, and then ask if there was anything else I missed. I would repeat this exercise at the end of the game.
Fast forward to about five years later, I ran into a parent from one of the other teams at the grocery store. They seemed visibly excited to see me and came over to say hello. They also asked what happened to me. My son stopped being interested in soccer, and I stopped being a referee, I told him.
“Oh” he said, clearly disappointed. “That is too bad. A lot of us feel like you were the best referee we ever had!”
I was floored by this. I barely know the rules of soccer. I am not a fan of the sport. I went to ensure everyone had fair time, and over-communicated with the other team to give them opportunities for feedback so everyone felt like they were getting the best refereeing possible for their kids. It turns out that it created a lasting impression on everyone I spoke with.
So there you have it. Hopefully this is helpful and useful, or possibly even just entertaining.
I am happy to answer questions about ways to help improve communications between teams, or to communicate changes coming to your internal technical products.
The only thing I would ask: Please do not ask me to referee a soccer game.
