It’s a 500 coming from their User PUT API when we send a person’s name with whitespaces, and our SPA didn’t have a failure callback at that time. You know what I mean?

If you’re a project manager (PM) in our industry, you’ve probably heard the above or similar statements countless times, whenever the software you’re developing presents a problem that you need to describe in front of the client you’re working with. You asked an engineer in your team and this isn’t quite the answer you were looking for. If you are just starting off as a PM, you probably have no idea what this means, even after learning a list of jargon on the first day of work, but that’s okay. Even for experienced PMs, this is still a puzzling maze coming from someone’s mouth. It’s full of technical terms and you might feel you’re going crazy, because you need to explain this problem back to the client in next 30 minutes.

I wrote a blog post about Problem Domain a long time ago, encouraging the engineers to speak the right language for the client. This post is a different version targeting specific PMs who struggle to communicating with engineers in the industry. We engineers, including myself, don’t intend to respond back to you in this esoteric manner. However, this does not justify that the PMs should just expect the engineers to use plain English. Some of the concepts or behavior just can’t be replaced with plain English terms or an easy analogy, due to lots of background information to cover. Moreover, the technical process of the business logic can often be filled with lots of interaction between different software modules, such as a REST API talking to a SPA with a successful response creating a new User object in the server database. The engineers will try their best to explain in plain English, but that doesn’t guarantee full clarity for everyone. What should we do now? The engineers should use two tips of mine so that the PMs at least still try their best to learn the technical terms we use.

Let’s look at this conversation again.

It’s a 500 coming from their User PUT API when we send a person’s name with whitespaces, and our SPA didn’t have a failure callback at that time. You know what I mean?

What the engineer is saying is the REST API server has a bug when the app tries to update the person’s name with the spaces, and the app does not know how to handle the error response from the server, therefore the app ignores the error, and the screen goes crazy. Still confused? How about this?

It’s a fault for both of the server and our app. Imagine if I went to a DMV operated by robots, and I wanted to update my name on my ID. But, I made a mistake and I put some spaces in my full name which the robot doesn’t know how to handle, and the robot just goes crazy and gets mad at me. Of course, I didn’t expect that the robot would get mad at me, and I also don’t know how to handle this angry robot at the same time, so we both panicked. That’s pretty much what happened.

Notice that this example contains no technical jargon, but described the same behavior with progress. It’s a fictitious story to understand why the software is having a problem. Now, the PMs might lose the focus here by asking questions such as, “Why does the robot not know how to handle the spaces? That’s stupid.” or “Wouldn’t you figure out why it’s freaking out instead of freaking out yourself?” They are restating the behavior here, which is a faulty software in this fiction, and they just want to know why that happens. For engineers, we could still use the same technique to explain the bug, but this is mostly wasteful to do so because we all want to fix this bug at the end of the day. Just simply say, “That’s just how it is and what it does in this bug. All you need to know is that there is a thing to fix and you don’t need to have a headache for us.”

There are times where the engineers need to explain the technologies they use or even introduce them to the PMs. While the engineers admire the beauty and technical awe of Python/Django, iOS, Android, AngularJS, and so forth, the PM just perceives them as the toolset we use to create a product. No more, no less. All they know is that they are great for building the meaningful products that people use daily.

I love Django, man. It’s an MVC, so I can quickly create web pages with transactional DB fallback and separation of concerns. I can inherit the web templates, and I can just grab open source libraries to build the feature we want. It’s Python that I know and love, so I can do lots of magical stuff. Django class-based views make my life easier. And oh, this is the one I was talking about…..

To PMs who don’t know the Django framework, this just may sound like standing in front of a super smart salesman who tries to sell you a thing with the elegant delivery that makes you feel dumb. There are lots of cool sounding words here and there, making this technology seem more like a fancy present. What could be a better way to explain the technology we use? How about this:

To build a quality web app, we need a fine quality tool set to create a web app. There are a lot of things to take care of and spend time on when making a great website. You need to think about how to store information correctly and quickly, how to have less painful ways of debugging when the time comes, how to have a clean code structure, an effective way to apply the web design to the actual page, and many more. All for writing better website and code fast. Luckily, there were a bunch of intelligent people who actually had these concerns and teamed up to create a cool toolset for us. Because of these people, we just grab this toolset and start creating a web site in a faster and nicer way. That’s why we use Django. It enables us to create a website fast and nice.

This is obviously longer than explanations with jargon, but it described Django in the context of its origin and the reasons Django is used by many people. The good parts about Django are implicitly elaborated by the needs of a good framework. The PMs can see why Django is good fit for business perspective in its overall scheme.

Seriously though, why do we need to do this?

In this industry, collaboration is the key to making progress that the client wants to see. There is no good collaboration if the engineers and the PMs are unable to communicate internally. The engineers know how to make good stuff and how to make improvements. The PMs know what to prioritize, how to defend any software crisis to the client, and how to make the business decision in order to carry on the win-win case for all of us as much as possible. Trust me, the more technical PMs become in the context of their language, and the more effort engineers put into explaining situations, the better the project outcome will be for all of the team members.