Asking the Right Questions

I once worked for a CTO who had a very different leadership style than any other manager I had ever worked for in the past. He pulled from several different management techniques, but was ultimately rooted in the Socratic Method. Yes, he asked questions. Better still, he encouraged questions from those around him.

If you’re not familiar with the Socratic Method, it’s actually rather straight forward. This is the practice of teaching by asking open-ended questions with the intent on the students answering through examining their knowledge and beliefs. It is done to get students to think on the fly and not have to always rely on straight fact memorization. This discussion among students (and the instructor or leader) also adds the benefit of everyone involved buying in to the proposed answer, or at least knowing their their dissent was recognized and discussed and not just dismissed.

This CTO would quietly sit in meetings and listen. When the meeting was about over he would pose one, maybe two questions, and then watch and listen as we debated further. Occasionally he would have a predetermined outcome he wanted us to all reach, but more often than not he was just as interested in our discussion and path as we were.

More than once I would find myself in a one on one discussion with him and the only thing he’d say was a variant of “you make a valid point, but what is the real question you are trying to solve?” He challenged me to think deeper; to try and find the underlying question to the problem I was trying to solve. Some days it drove me crazy, but then I’d have that epiphany when I hit upon the “right question,” and it all became clearer to me.

I have always been inquisitive. It’s just my nature to ask questions. However, watching him in action was enlightening. I could wax poetic about how he had elevated it to an art form.

Those who didn’t like his methodology felt he was ineffectual because he didn’t always have a clearly defined agenda. They couldn’t have been more wrong. He knew what he wanted to achieve from the very beginning, but he asked us questions which in the end made all of us feel as though we had the ideas. In turn, that gave us a deeper ownership in the project as individual contributors as opposed to just receiving marching orders and being told what to do.

Since working under this person I’ve tried hard to “step my game up” with Socratic Management. I’ve tried to not just manage those around me, but lead them by asking questions and getting them to buy in to the ideas I have on their own. I’ve had some strange looks from some people, and have even had a few tell me that they’d rather just have me tell them what to do instead of asking all those questions. That’s fine, and I am happy to adjust for them. Others though really took to the questions, and I’ve watched them grow and become leaders in their own rights.

I still hear that CTO as a little voice in my head, telling me “You still haven’t asked the right question.” It drives me every day.

Questioning the Boss: Challenge to Authority or Collaboration Opportunity?

I recently was declined for a job interview. Not because I wasn’t qualified, but because one of the managers turned out to be a manager that I had worked with in the past, and they felt that I would not be a good fit for their team. They didn’t think I’d be a team player.

You see, back when we worked together, I questioned him.

A lot.

I questioned everything from task prioritization (shouldn’t the ability to login and have user roles be ahead of 90% of the heavy work we need to do which is role based and not three months down the road?), to team selection (why are we putting PHP developers on a Ruby on Rails project when we have enough Ruby developers to spare?), to just about anything else you can think of. Yes, I challenged some of it because I really did think they were poor choices, and I didn’t want to be held accountable to an impossible delivery schedule. However, the majority of it I challenged and questioned because I wanted to learn more, and at the same time I wanted to share my knowledge and experience with him.

The manager saw my questions as challenges to their authority; a lack of respect. Where I thought I was being a collaborative team player, I was being seen as a trouble maker. A subversive employee whose goal was to make the manager look bad, and promote their own self-interest. I tried changing tactics to ask questions in email and in private meetings as opposed to in large meetings in front of their peers and subordinates. Unfortunately, by that time, I was still deemed a threat.

My wife was recently in a situation where a new manager came into her company.  My wife has been there for nearly 20 years, and rather than take the questions she was asking as guidance, the manager took it as a challenge.

A good manager knows that not only should they surround themselves with people smarter than they are, but they need to utilize them. My wife’s situation is a perfect example of that… someone who is new to a company should want to leverage the knowledge of someone who has been there for a long time. You cannot become a truly effective manager without fully leveraging your team and their abilities. Some of these “smart” people will have very specialized knowledge. Others will have a broad knowledge base to draw from, or they always look at the problem from a different angle. A good manager fills out their team with people which will fit the gaps in their own knowledge and experience, as well as people with different viewpoints and problem solving skills. The total of their knowledge and experience will greatly exceed the sum of their parts with a wise manager leading the way.

If an employee comes to their manager with a question, particularly one regarding the current project, processes, or even staffing, the manager should listen and respond accordingly. Sure, sometimes it will just be an off the wall question, or just someone having a grouchy day. More often than not though, the question is an opportunity, not a threat. It could be an opportunity for the manager to help mentor the employee (help them see the bigger picture, not your view of how things “should be.”). It may be an opportunity for the manager to learn something new (especially with new technologies and tools which could speed up development or delivery time).

The CTO for the company where this manager and I worked had a habit of sitting back in meetings and listening, and then just asking one question.  Granted, it was one question that sparked a series of other questions by the team.  He didn’t point out the holes, or the flaws in the plan, or come across as challenging the process – instead he simply would ask “Why? How? When?” I admired his ability to spark discussion and his openness to listen to questions from the team.  He encouraged questions, and I asked him a lot of questions.  He would constantly tell me, “You’re not asking the right question.”

Returning to my prior blog post about Who Owns the Scene, I want to elaborate on why asking questions should be taken as a compliment, and not a challenge by a manager. When people ask another individual questions, it’s generally because they want to gain something from them – besides the answer. It could be, as I’ve pointed out already, to learn something new, or to understand a process – both physical and mental. Through asking my brother-in-law questions about who owns the scene at an accident, I learned more about the processes and regulations that are behind law enforcement. He not only got to “show off” his knowledge, but he gained a bit about IT processes in the conversation. Amusingly, both of us sat down with my father-in-law to ask questions of him due to his expertise. My brother-in-law needed to understand some accounting rules as he was reconciling the books for the fire department, and I needed to understand some tax law implications as I was working on a project to try and compute tax depreciation differently. Through the conversation, I learned what I needed and more, as did everyone else sitting around with dessert and coffee. While my mother-in-law was a little bored, she made comments, which made us think differently.

If it’s the right question (you’ll know it when you hear it every time), then it gets both the manager and the employee (or the team, or in the prior example, my family) collaborating together. This results in a better understanding of the issue from all sides, and a solution which now has full buy in from all parties. If that collaboration isn’t a win for the company, then I don’t know what is a win.

I guess being shot down for an interview by a former coworker in a new company (at least this ex-colleague in particular) isn’t such a bad thing after all. Once I found out that I would have been working with him I probably would have thought long and hard about whether or not I should accept the position. The question would be, can I work with someone who is not open to questions? Can I accept that by asking questions I could be seen as difficult? Again, my intent is not to make my manager look bad, whether it’s a line manager, the CTO, or even the CEO when I reported to one. The intent has been, and always will be, to learn and ensure the project is successful.

What do you think? What is the right question to ask to make a project, manager, or employee successful?

Who Owns The Scene?

Not too long ago I was visiting my brother-in-law and he was telling us about some of the more unusual incidents he’s had to respond to as a volunteer firefighter. Putting the colorful storytelling aside here, there was a common thread with all of it: ownership.

Photo courtesy of San Leon Volunteer Fire Department, San Leon, Texas

If there is an accident on the road, or a burning building, or pretty much any incident where emergency services are required, the firefighters own the scene until an all-clear is given. Later, if investigators are out recreating the scene, the police own the same scene, with firefighters blocking the road and providing any secondary support. In each situation, there is a clearly defined chain of command to make decisions and protect the first responders. Others can make requests (“Move the fire truck, my officers can’t get their cruisers in close.”), but the ultimate decision rests on the commanding individual (“No. They’ll get in the way of my crew extracting the victim from the wreckage. Now tell your officers to divert traffic and make space for the helicopter to land so we can airlift them out of here.”)

However, in the IT world, in an outage scenario, who owns the outage?

Yes, I know, there are quite a few ways to go about this, and if you’ve got good processes in place, you already know. What if you don’t?

As a Release Manager, part of my role was to own any potential incidents and outages and delegate any task as needed, including the ownership of the outage. Any incident which was discovered went to a key list of individuals for us to determine the best course of action, including no action. This was me, the Release Manager, the QA Lead, the Engineering Managers, the Architect, and the VP of Engineering. Before this was in place, management, and even half the engineers, had no idea something was happening, and thus the outage would just drag on until someone finally did something about it. It was an unfortunate case of “someone else will fix it” more often than not. Adding ownership to this scenario helped ensure that not only was the issue recognized faster, but there was a single point of contact to direct inquiries and information through. Now, instead of management disturbing the individuals actively working to fix the outage, they go the Release Manager (or whomever I handed ownership to). The same thing occurs with the engineering and operations teams, where they would pass information up to me, and I would be responsible for distributing the appropriate information to management. Through ownership of the issue, both management and the individual contributors were able to focus on what needed to be done to resolve the incident.

Another part of my role was after the incident was resolved. At this point, I had ownership of the analysis of the incident. Just as the Police, when recreating an accident at the scene can request the assistance of the firefighters, I had the authority to pull the necessary engineers out of their normal work to be able to perform a root cause analysis (RCA) of the incident. While this RCA often occurred at the end of a Sprint in the discussions over what went wrong/could have gone better, key information could potentially be forgotten if the incident had occurred at the beginning of the Sprint. Getting everyone involved in a room the day after an incident at the latest, ensuring that timelines and steps taken were still fresh in everyone’s mind.

Having an individual dedicated to incident ownership in a smaller organization may not be the most optimal use of resources. In that scenario, I would strongly recommend (if you don’t have one already) that you have an incident response document that outlines the steps to be taken. Then, incident ownership can fall to any member of the team, including junior members, so that there is a single point of communication in and out of the engineering and operations teams (or single multi-function team of course) for the stakeholders. This would also help to define getting the RCA and any associated documentation completed in a timely manner.

I’d be interested to hear how others handle their incident responses within their organizations.