Insight into the role of a manager: asking questions
Long ago, I was a software developer. I was an average developer, but every so often I created something I was proud of.
On numerous occasions, I remember the experience of showing my work to one or more managers only to have them start to ask me a bunch of questions: How does it work? What are you trying to accomplish with it? Why did you implement that feature in this way? How is that going to integrate with this other piece over there?
I suppose all of the questions were innocent, but they often left me feeling confused and with a sense that those managers didn’t necessarily think I could figure out whatever needed to be figured out. In short, I wasn’t sure if they trusted me or if they thought I was capable as an engineer.
Fast forward to today.
Now I find myself sitting on the other side of the table—in the role of a manager—and I am the one asking those same questions. How did I end up here? Isn’t manager a bad word for a developer? Did I not learn anything in my earlier role about how developers want to be treated? I would like to think so, but it has caused me to spend some time thinking about this topic and explore why managers think the way they do—and why manager really isn’t such a bad word.
Clues to the behavior
I found one of my first clues when I thought about the role of a manager. One thing a manager must do to be successful is to build a great team.
Well, how do I know if I have a great team? I could look at all sorts of metrics on performance, code commits, bugs reported, or other hard metrics. All good things, but it really starts by getting to know people and how they think, how they make decisions, how they solve problems, or how they work with others.
For me, that comes from walking around and talking to people, having one-on-one conversations, hanging out with them, and yes—asking a lot of questions.
Ok, good enough, but after getting to know people and seeing the results of their efforts, I know I have a great team, and I trust them to do great work. Shouldn’t the questions stop there? Shouldn’t I just accept that they are going to do great work, solve hard problems, and bring all of it together into truly great products that we’ll all be proud of?
Well, sort of. If everything is working perfectly, things will generally take care of themselves. The problem is that even great teams don’t always work perfectly. Stuff happens. Competing priorities, lack of clarity, difference of opinion—you name it. Scrum masters or delivery managers can help resolve a lot of those situations, but some things still require attention from managers.
My second clue came from looking at another responsibility in the role of a manager: get great products out the door. And one minor point—there’s usually some sort of expectation about a general timeline. Timelines are interesting things. Sometimes they seem arbitrary, but they are generally driven by a business goal. In growing companies, they often result from the need to capture new market share when the opportunity presents itself.
And that really sucks because it means that there are now risks that start to jeopardize our success. Risks to quality if we push too much on timeline, and risks to the timeline if we don’t make the right decisions along the way. Sometimes we can just let teams fail because that’s how they learn. Other times, we need to identify and address the risks.
Uh oh, I sense more questions coming.
It gets worse from here. If a manager is really doing his or her job, he or she is giving credit to the team when things go well and stepping in to accept the responsibility when they don’t. This looks like a quagmire: I am never going to get any credit, but I have to be accountable if things go wrong.
Who would ever want that job? The easy thing to do is to start asking question after question until we are sure that everything is uncovered, and nothing will ever go wrong, right? Well, maybe it’s not quite that easy.
Let’s think about the what not the why
We can start by looking at what kinds of questions we ask and how we ask them. I can remember a particular instance when an engineer showed me something he’d done, and I thought it was really cool, but I had seen someone else recently building something that was almost identical.
I asked the first question that came into my mind, "Why did you build this when someone else had built something almost identical?"
I could immediately see the jaws start to clench, a frown start begin, and I believe there was even a bead of sweat forming on the forehead.
Oops, I probably shouldn’t have asked the question that way.
"Why" questions are generally not very productive. They tend to put people on the spot and into a defensive frame of mind. A better approach might have been to say something like, “Hey, that is pretty cool. I saw something kind of similar from Joe.
What do you think we could do to build the best system between the two of you?”
Yes, it’s another question, but it serves to connect the dots between two developers, and they can figure it out from there. I wish I had used a “what” question.
Seriously, you want to understand?
Ok, this all well and good, but really, why does my manager need to understand any of the technical details about what I am doing? What is he going to do with that information anyway?
Sometimes my manager ends up talking to people in other companies, or journalists, or other managers and needs to be able to accurately represent the work his team are doing and how it fits into the big picture. Sometimes the simple act of discussing problems with a team can lead to greater clarity and understanding—and maybe fewer questions.
It’s possible to be a great people manager and not be technical at all, and that shouldn’t be minimized. It often depends on the culture of a company and the backgrounds of the people involved. In many engineering organizations, understanding the technology is just part of the environment and is probably what attracted us to that type of organization in the first place. I’ve also worked for managers who were never developers, and they just didn’t get it. That was frustrating as well.
So, is there any hope out there for the beleaguered engineers who are getting pummeled with questions from every manager in sight? Fortunately, yes. They can give their managers feedback. Managers love feedback, but they also need to understand that it’s tough for engineers to give negative feedback to managers, so they need to figure out a non-threatening way to do this. Delivery managers can be pretty helpful here.
Managers can also work at getting better at asking questions and even coordinating so that multiple people are not asking the same questions. This is sometimes easier said than done, and it takes practice and iteration, just like everything else.
Believe it or not, asking questions can be a bit like writing code. Sometimes things just flow together and work flawlessly. Other times, they kind of wind themselves into a hairball that goes nowhere, and they need to be backed out or refactored.
The point is that getting the information that managers need is an acquired skill that develops over time. Some managers can artfully ask a couple of simple questions that are non-threatening, reveal a huge amount of valuable information, and leave a team feeling motivated and empowered. I envy those people because they make everything look so easy.
I don’t hate being in the role of a manager. In fact, I really love this job. Sometimes I’m able to ask a question that helps a team figure out a path forward. Sometimes I am able to connect a couple of dots, and teams figure out how to make great things happen. Sometimes I sit in a review meeting without saying anything, thinking to myself, That is so cool. There’s no way I could have done that. Those are special moments.
You may not appreciate the questions your manager is asking, but hopefully you now understand a bit more about why he or she is doing it and even a bit about how the world looks through his or her eyes.
We all need to keep working at our craft, whether it’s writing code or asking questions. Build, test, fix, repeat. Everything is an iteration, and our hope is always that the next iteration will be better than the last, and that our managers will learn to be as proficient as our engineers.