So here's the thing. Today, I'm the founder of With Madrid and The Shake Shake Company. I also worked for more or less 7 other tech companies before. All of them of various sizes but never big. And there is something that quite stands out all the time: project managers and devs don't speak the same language.
Specifically, PMs have no chance at understanding developers. I think that the best way to sum this up is the obligatory XKCD. While developers know what is going on, PMs don't have a clue why something might be easy or might be incredibly hard. Especially if they're junior, they have to trust developers blindly. While this isn't much of a problem in my companies, probably due to their sizes, I've seen trust issue rising once the team gets bigger.
Anyways, I'm not listing all communication issues between PMs and devs, you all know them and that's not the point of this question. As manager of my companies, I feel like that my PMs would feel a lot more confident if they had an idea of how development works. Of course, actually teaching them how to be a proficient developer is out of question since it takes about a shitload of time and is by no means interesting to them.
Question one: what to cover? Here's a few things that we do
- Work with Python in the back and JS in the front
- Use git flow, to which our testing and deployment process is quite coupled. By that I meant that PMs have to test/make test feature branches before getting them merged. It'd help they understood how Git works (haha, yeah)
- Unfortunately, we have a few WordPress lying around. Still that might make into a simple and practical exercise. Simpler grasping the current JS stack at the very least. Especially since those PMs perform a lot of webmastering on WordPress
Question two: how long per session and how many sessions?
Attempted syllabus (1h-or-so sessions):
- Basic introduction on what an abstract computer looks like from a C program's perspective.
- Copying a few BASIC games. With the line numbers and no actual text editor. In 2018 that sounds stupid but I started there and ended up all right so I still believe it's a good way to start.
- Introduction to networking. How Ethernet, IP, TCP, TLS and HTTP stack on top of each other.
- Demo setup of a simple (physical) web server. The main challenge here is make a demo that doesn't look like pure witchcraft. There is too much ground to cover to explain everything but I feel they really need to understand what the Internet is made of.
- Introduction to CSS, the box model and a few more CSS-y things
- Practical exercise to alter a WordPress theme
Where this fails:
- So. Many. Things. Can it fit? What to cut? So many things will probably feel like intangible magic
- I don't feel that it gives an accurate spectrum of what is possible or not
- Totally skips Git
- I've been in this game for too long to remember any learning path
This is why I'd totally appreciate feedback on similar attempts, critics on this (bad) syllabus or a plain re-orientation towards something totally different. Basically, anything constructive!
Fellow devs, thanks in advance!
Top comments (8)
As a dev working with non-techie PMs I somewhat agree. I agree there should be a basic knowledge of how software development works but I don't think teaching them to program is the solution.
What if we pair a PM with a dev (even a junior) for an hour or two of "let me teach you what happens from when I type this stuff to when you tell me it's broken :D" ?
What if instead we teach devs to be better at communicating?
This way we strengthen team bonds instead of siloing PMs in a room to learn programming by themselves. Is it really important they learn what a for loop is? I don't think so.
Maybe it's better to "pair" with a dev and see how the software they help make goes from the requirements to the customer and talk about the pain points and what can be done to make that loop more efficient.
Sure, communication is very important and a part of it resides in not slapping walls in the face of project managers.
I just feel that there is a level of literacy that would help project managers reading what happens and understand more faster. Does that make sense?
Yes it does, but maybe we can go to a middle ground. What about publications well written like increment.com/ ? Most articles are not uber technical and there's lot in there that talks about the life of a programmer, such the issue about Development or the one about being on-call.
The article What happens when the pager goes off?: A survey of incident response across the tech industry seems like a really good place to start to have a conversation in a team about what it means to be a developer.
While I find the idea as such quite charming, but if I take the non-developer project managers I know into account, I see some risks. One of them is the illusion of competence. It wouldn't suprise me if the result were an attitute along the lines of "how hard can something I was shown in half a day be?" and reinforce with them their sometimes more, sometimes less openly communicated notion, that they think of us code monkeys basically as slackers whose only goal is to sabotage the genius plans they make up (where it was under their dignity to consult development), sold to higher management and now need to get done.
I apologize for getting into ranting mode. The gist is, if trust is low, a fix is necessary rather for the organizational structures, than with the training of individual people. But certainly, the former is orders of magnitude harder than the latter.
Pretty true, it indeed can't solve the (potential) trust issue. This has to come from somewhere else because as you mention, people thinking they know while they don't have indeed been one of the biggest hurdles I've encountered.
This, I think it's an issue of trust, not of knowledge. Not exactly the same but: I'm not going to do 10 years of medical school if I don't trust my doctor to prove he or she is wrong, I just change doctor :D
As a former PM that ended up being a dev, I can’t help but feel that this is the wrong approach. As you mention, and as I experienced, PMs often have to blindly trust devs. I don’t believe this to be a fault of PMs and only PMs. Certainly, there will be barriers when scoping a project when a PM knows little to nothing about the dev stack, but i don’t think that necessarily warrants multiple hours of a “dev crash course” to correct.
If I could go back to my first months as a PM, I’d have benefited greatly from a crash course on the tech stack that was underlying my product AND hearing from devs what the biggest barriers were therein. Further, I think those devs would greatly benefit from understanding AND participating in my approach to prioritizing and focus on customer requests.
All in all, it’s a team effort (cliche, I know) that requires a shared understanding of goals and obstacles. Compromise is non-negotiable and cannot happen until some semblance of a shared understanding develops.
Let me know if you have questions, I’d be happy to further elaborate on my experience and share whatever I can. It’s great that you’re asking these questions and want to bring the disciplines together. It’s a tough road.
Very interesting feedback, thank you.
You did end up learning development though, right? How so?