Leading From the Rear

As a kid on the farm, the definition of hard work was something I looked to my dad and his best friend Bruce for. Listening to the two of them talk after church on Sundays about what they were doing, what they were planning, the upcoming week, the challenges with their animals or crops. I was fascinated by how much they could keep in their heads, at how much they knew they could accomplish just by getting up early and working hour after hour, day after day.

I remember one project where my dad had to replace all the doors on our silo. Our silo was about 60 feet tall, and the doors also serve as a ladder. Each one is made of two pieces of 3/4 inch plywood bolted together, about four square feet in size. Heavy as hell to wrangle and lift, let alone climb 60 feet using one arm, dozens of times. That was a regular Tuesday morning after milking the cows for Charles Varty. He had so many things in his care: his family, hired hands, his animals, the equipment. Watching him as a role model had an obvious effect on me and my siblings.

I learned to judge my value based on how hard I worked. That attitude took hold immediately when I went to work on a neighbour's farm in my university years: hours on the tractor doing field work, wrangling heifers, shoveling manure. I even had to replace the doors on a silo.

Fast forward a few decades, and the lessons of my childhood about the value of hard work still rest heavily in my bones. The problem is that my work is different now. I'm not a lone farmer who needs to be the do-it-all hero my dad taught me to be. I'm a leader of people who have jobs of their own, all of which I might judge based on how well I could do that role. I've made that mistake in the past, especially with developers writing code.

My official title is CTO, but I do (and have done) a lot of other roles in my job. I entered the University of Guelph as an English major, but a computer programming course taken on a whim changed my trajectory entirely. After more than 25 years in the tech industry, I've written so much code, much of which is still in production systems, that I've forgotten more than many developers may ever create. That might sound like hubris, but it's actually the thing that held me back in my understanding of what a leader actually needs to do. It's also a hard standard to hold a new hire to. The things that make each person unique are more a sign of the value they bring to their role than how they compare to whoever came before. This is a lesson I took a long time to learn.

Put simply, I have been leading from the front. If I were to picture myself leading a battle charge, I would be at the head of the column, sword slashing to and fro among my enemies, setting the example for those behind me. Look at the hero!

What an idiot.

At best, I might actually be the best at the job, setting the highest possible standard for every developer. At worst, I only think I'm the best, with bad habits built up over years of working in too much of a hurry, in the vacuum of late-night urgency. Other developers look at the code and wonder what it's meant to do. Some of it was written literally decades ago, like an artifact found in a tomb, still giving off a faint glow of unknown forces. That's an extreme simile, but I've seen the initial reactions of new hires to the architecture that has evolved in my work. It's not wonder and awe. It's what is happening here. Don't get me wrong, Agility's architecture is really good, and I'm proud of it. But that's not readily evident to new eyes, and it's got to be daunting to have to ask hard questions of someone who's been playing the hero the whole time.

The commute looks a little different than the farm.

So how am I working differently?

A few examples: When I'm CC'd on an email thread with a customer or partner and a hard question comes up, instead of responding with the answer that seems obvious to me, I message the most senior staff member on the thread privately to let them know they have my support if they need it, and to ask what their approach is. I've stopped attending every single scrum for product development. The team needs their autonomy. I only need to be involved from an architecture standpoint in the planning phase, and from a reporting standpoint. What are you planning to build, how does that fit into the system as a whole, and later, how did that go? I've also unsubscribed from the Slack channels where support issues come in. Let the team escalate to me if they need help. They might make mistakes, but that's how people learn.

I had a conversation with my CEO, Jon Voigt, in a strategy meeting that was incredibly uncomfortable, but it led me to most of the ideas I've described above. He had assigned me as the "accountability lead" on two major projects this quarter. The role means I categorically cannot work on any of the tasks in these projects, but if the projects are not successful, I'm the one accountable. To any good leader reading this, that probably seems obvious. For me, it required a shift.

Jon asked me, based on the current state of the tasks on each project plan, was I sure each project would be completed. My instinct was to say yes, knowing that in the worst case, we could all just buckle down and work our butts off. But then I stopped myself. I had to take my own capabilities entirely out of the equation. No heroics, no late-night saves, no "I'll just do it myself." Suddenly, I wasn't sure at all. There was a long pause before I spoke. My voice was quite quiet when I said, "I don't know."

It's a strange thing to say out loud to your CEO. Not "I'll figure it out" or "leave it with me." Just: I don't know. It felt like admitting something I'd been avoiding for years.

"Ok," said Jon, probably anticipating that response. "Now what?"

In the conversation that followed, I started asking much different questions. What are the goals we're trying to achieve? Have they changed? What are the challenges and risks we're facing right now? What's the impact of those risks in the worst case scenarios?

I found myself stopping the conversation whenever we immediately jumped to mitigating strategies. I needed everyone to slow down and explain the impact of those risks to me before I could even begin to answer the question of whether we'd get it done.

I was incredibly uncomfortable. I felt, frankly, like an asshole. Jon kept reminding me that I had to get more comfortable with this, because it was the only way we were going to be successful moving forward. I had to get comfortable asking the hard questions. And the only way to do that was to look differently at what leadership and accountability actually mean.

It feels a bit like a betrayal of my dad to step away from "just work harder" in favour of leading from the rear. But I know there's a lot of ego wrapped up in that, too. It feels great to play the hero and independently solve problems, checking things off a list. That's not a growth strategy, though. It doesn't foster teamwork, and it doesn't help grow a collaborative work culture. Leaders need to serve the needs of their team, not undermine them in how to do their jobs.

My dad never talked about leadership. He just got up every day and took care of what was his to take care of: his family, his animals, his land. He knew what was his job and what wasn't. I think, if I'm honest, that's what I'm still trying to figure out. Accountability isn't something you can hold anyone else to without first holding yourself to it. And sometimes holding yourself to it means getting out of the way.