Some time ago I sat down with Mark Metze for an episode of his podcast Agile Within and we talked about technical knowledge. More specifically, we discussed that technical knowledge is actually needed if you work with software teams, whether you are a Scrum Master, a Product Owner, or an Agile leader.
I’ve talked about whether a Scrum Master needs to be technical a couple of times on my blog:
- The first one was back in 2018 where the general idea I had was pretty simple: you don’t need a computer science degree to be successful and technical knowledge may actually get in the way of your coaching.
- I made another post in 2022 where I talked about technical knowledge and skills Scrum Masters need.
My view on this topic gradually changed as I worked with more teams, more and less technical ones, and as I’ve grown my own technical knowledge over the years.
This is one of the main reasons Mark and I decided to do a little deep dive into this topic. You can listen to the full episode on the Agile Within podcast. Here I’ll share my takes on the topic as I answer Mark’s questions. You may want to listen to the full recording if you want to have more context and Mark’s take on the subject.
What advice would you give people looking to pivot into an agile leadership role as far as what technical skills they need to have?
You need to be technical enough.
I think an important point here is that my opinion has changed over the years. I believe you need certain skills and knowledge to be an effective agile leader, such as a Scrum Master or Product Owner.
I don’t mean you have to be a developer. Full-time developers and programmers have this experience, but I think you need to be technically proficient to succeed.
Returning to the term “technical enough,” what does it mean? It’s something I didn’t realize initially. When you’ve been doing something for a while, it’s harder to realize that it might be more complex than you think, especially for those who haven’t been exposed to it. That understanding led me to realize how comfortable I am discussing the technical topics.
This is known as the “curse of knowledge,” or “the curse of expertise”. It is a cognitive bias where we incorrectly assume that everyone knows as much as we do on a given topic. When we know something, it can be hard to imagine what it would be like not knowing that piece of information.
In the context of sports, for example, how comfortable are you explaining specific challenges you face when playing sports or working as part of a team? Do you understand common pain points?
Being “technical enough” means having enough understanding of the workflow that developers go through. You may not know exactly how to write a program, but you should have a general idea of what it involves.
Do you understand the general process of getting a program like “Hello World” to run? And just that term “Hello World” – do you know what it means? Because if you say it to a developer, they’ll know. If you lack this knowledge, you might not be “technical enough.” It’s not about insider jokes or specialized knowledge but having a general understanding of the workflow.
Your opinion on this changed over time. What specifically changed your opinion?
I think it comes back to that realization I had. If you look at some of my older content, one of the first videos I did was on this topic: Do Scrum Masters have to be technical?
I was just generally thinking that you don’t have to know anything. You’re focusing on the people, you’re focusing on the processes, you need to know Scrum, and very minimum technical knowledge is needed. But what I realized throughout the years is that I was always interested in technical things.
After speaking with Scrum Masters who didn’t have any experience or understanding of tech, and who also believed they didn’t need to know any of that, and seeing people wanting to enter the tech industry without any prior experience, I realized something. It’s fine to switch industries, that’s normal. But trying to enter immediately into a Scrum Master role without understanding the technical side is challenging.
I’ve always been close enough to tech and thought, “Well, I’m not really technical, so why is it harder for others who are not technical to do this job?” I realized I’m technical enough. Going back to my previous explanation, yes, I’m not a developer, but I know some of the code.
I did some website programming for my website and was interested in game development at some point, learning how to write code in C Sharp for my mini-games. I also took an introduction to computer science course that included some coding. Through my work with developers, I learned more specifically about their workflow and new terminology that I’m much more familiar with and comfortable with now.
You have developers, people doing coding, QA, all of that work, and then you have management or leadership team or business, and they live in two completely different spaces.
If you’re more of a humanitarian, less technical person, you will naturally be drawn towards that business side. And it will be much easier for you to understand the business side, but you need to understand both.
We already have business people who don’t understand developers and say things like “why is it taking so long? It seems pretty easy to me!” Well, yes, because you don’t understand the complexity of the work.
And as a Scrum Master, you need to be a mediator, a connector between the two, you need to understand the two sides and create that connection.
What advice would you give to people who want to change industries and don’t have a technical background? What do they need to do before they step in and pivot to a new career?
The common answer would be training: educate yourself.
There are so many ways that you can learn now. You don’t have to go to university to earn a computer science degree. There are lots of courses that you can go to online and that can really help you understand.
You just need to be curious, you need to be interested in learning. Any Agile-related role, you have to be interested in continuous learning.
For example, me personally, I’m always fascinated. I’m finding new models and I get excited about how I can use new things I learn in my work.
It just excites me knowing something. Recently I was going through a course on DevOps, and they were covering so many different models. I would often stop the video to learn more about each one.
If you’re excited about new things and trying out and if it doesn’t work out, you’re still excited and you take it as a learning opportunity.
Then you should be good. And if you hate it, then you probably are going to hate Agile leadership roles.
Say developers are having a technical discussion and you’re not understanding a word of what these engineers are saying. What do you do then?
I think it depends on how the conversation is going. If it is a deep discussion that is going on, you don’t really want to interrupt it. But if you want to take some notes, probably some notes on what you’ve heard and what you did not understand.
I generally found it really helpful to just take notes on whatever I’m hearing. I started doing it when I was facilitating retrospectives or discussions, I would usually try to take as many notes as possible during that time and then reach out to the team and ask them the questions.
And I think this is where the value of courage comes in where you need to be courageous to tell your team: “Hey, I have no idea what this means. Can you please help me? Can you explain it?” Try to paraphrase what they are saying and verify if your understanding is correct.
Just reaching out to the team and asking them, to explain how they work. Because that’s how you can then learn. And what you learn during this time builds your transferable skills, the learning skill.
Ask better questions
If you are coming in and asking developers “can you explain to me how you work and what your workflow is?” That is a very broad question.
Like, if you come to me and ask me just “What is your workflow?” Well, what do you mean? What exactly are you talking about? Can you be more specific? And it’s the same way if you want to learn how the developers are working, you need to come in with more pointed and specific questions.
For example, I’m working with a new team, I’m going to ask more specifically: “Do you have Dev environment, QA environment, UAT environment? How does it work? Is it automated or do you have to push the changes manually? Is there a validation step?”
If I talk about CICD, I will also ask questions: “Is it a separate department that has to create your pipelines” or those questions. If you ask me, do I actually understand how to create a pipeline, I’ll say “No, I have no idea”. But I know that there are different steps in these processes. I know that there might be manual testing, or automated testing. I know what unit tests are.
So small things like this where I can ask specific questions. Say, we’re talking about unit tests: “What’s your coverage?”
And if you’re listening to this thinking “I just heard 10 million words and I have no idea what it means”, well, you need to do some research to be able to understand, because those things aren’t hard.
Once again, I’ve never written a unit test in my life. I don’t know exactly what it looks like, but I understand the concept of what it is and how it’s supposed to help you test.
So these would be some ways in how you need to adapt your questions to make them more effective. Be more specific, think about why you are asking the question, what exactly you are trying to get at.
For example, when I’m asking questions like “do you have a Dev, QA, UAT environments?” what I’m really asking is “How much time does it actually take you to get from an idea to production? How difficult is it for developers to go through the steps? Is there a lot of manual work involved? Are there other teams involved?” These are the real questions that I’m asking. I’m just asking them in a more technical way to create better rapport with the developers.
Have you noticed a difference with how the team interacts with you as you built technical knowledge?
I think it helps them. Developers have trust in me faster as I can build that rapport with them around this. I usually come in and say “Hey, I’m not a developer, I cannot do your job. I am an expert on Scrum, Agile, Facilitation, Teaching, all of that, but I have enough tech understanding to be able to understand you”.
And so often what happens is when I’m doing the initial interviews trying to understand what’s going on in the company and the team, they kind of dance around a topic, trying to make it very user-friendly or nontechnical. And that often misses the point of that conversation that I’m trying to have because I need to understand the real pain points.
And so once I switch to those more technical questions, they can see that there is an understanding. And they are able to use some of those technical terms with me. They know that I will be able to understand. And that kind of breaks the barrier for them as well. It is hard for someone technical to speak in the business language the same way as it is hard for a business person to speak in the tech lab.
An example of us from someone with no prior tech knowledge who built it up to earn developers’ trust
It’s the story of a Product Owner. So a new person was coming into the team as a Product Owner, fairly new to the role, but also not technical at all.
In just 6 months, this person got to a point where their technical knowledge of the product was so good that the developers were impressed. When this person left, developers would still remember him six months after that. They would say things like “if only our PO was here because he would understand”.
I think that had an impact on them because they really trusted this Product Owner with the decisions he was making because they knew that he understood. And the way he got to that point of understanding is by coming to the developers and asking questions: “Can you show me? Let me figure out how our product works.”
He was going into the details and trying to figure it out, and then asking questions to the developers. That really helped build that trust environment between the business side, the product owner, and the developers.
I think that the same approach is necessary for anyone working with the Agile teams, software development teams. You don’t have to know how to do it, but you need to understand the theoretical level at a minimum.
