Software Developers and Project Managers. Do they play for the same team? They work in the same companies, work on common projects, but do they really always share the work, or do they sometimes fight each other for no good? Well, it depends. Mainly depends on the side that you're looking from.
As it comes to launching the project. There are no places for misunderstanding, the goal is usually simple. You have a product or a feature that is either absent or not working in the way that you like and you want to change this situation. As simple as that. Or isn't it? Well, if the software development process was that simple, we'd probably be soon out of a job, because Artificial Intelligence would handle it for us. Fortunately for humankind, there are many aspects, where interpersonal communication is required and we cannot just focus on writing working code. So that's where we are, we are just an actor in a software creation process. And conflicts often come by with the people.
Developer's tale (Stanisław Zawadzki)
Why developers love their jobs? Apart from financial benefits --- mainly because it gives them freedom. The source code doesn't mind and doesn't care if you're writing 40h a week or 10h a day if you write at 9 am or 11 pm. It doesn't care if you use Vim, Atom, Sublime or notepad (but seriously, don't). It doesn't mind you taking a day off, doesn't object your experiments, won't get offended at you if you make a mistake. You can write code while sitting in a cafeteria or sitting at home with the cat on your lap. You can take a break whenever you feel like it, for how long you wish As long as the code is finished and working with the proper amount of tests and documentation, nobody should object, right? Well, this is true, but only if you're both a single project developer and a client. Otherwise, that freedom has to be constrained.
What developers hate? They hate meetings. Especially those kinds of meetings when you sit absentmindedly while your coworkers talk about a part of the system that doesn't engage you at all. Those are the meetings where you drift off and start thinking about dinner, funny dogs videos or whether you have turned your gas off at home. The frustration is getting even bigger when you're overloaded with work and tasks that need to be done, but you can't start them because it's an hour-long discussion whether an image is in the right position and the description might be a little offensive to members of some Papua New Guinea tribes. The meeting stops them from doing what they feel best at --- writing code.
Programmers hate estimations. As either a task is plain simple and will be done quickly --- however it's not easy to estimate if it will take one hour or two (and the second value is two times bigger!), or the task is complex and estimating it is both highly risky and speculative. But the main problem is that developers don't really care about estimations. They prioritize task on the basis of severity and product requirement, not the time needed for the task. They don't use the information in any case and may be confused when they reach some unexpected error.
Developers hate constant changes in the project. Situations where the client changes their approach every second day, where instead of working to meet the deadline they have to once again focus on a task that has already been finalized. Changing the flow sometimes is harder than writing it from the scratch, constant changes may turn the codebase into an unreadable and unmaintainable mess. When the task is done it should remain like that and only bugs should be fixed then.
Developers hate writing documentation. Even if they are aware of its benefits in the future, they still hate it. The code is working, they know the purpose of this code, for now, this code will not change. And they hate filling in development documentation even more. Writing down tasks, dividing it into chunks and describing those chunks in details, estimating them and then logging down how much time it actually took. Blah. I don't believe that there is a single developer who enjoys this. We, developers, love what we do as it's an act of creation. There was nothing, and now after you click or fill something, then we have some response. We craft the world of our software, fight with the upcoming problems and then at the end deliver a beautiful, fast and elegant product. The product that we're proud of, with complex algorithms and great test coverage, with a code that you wouldn't mind to show to any other developer, a design that you crafted and where everything is easy to you to obtain.
And then the client hates it.
Life is not that hard for software developers. There are plenty of opportunities for them, they don't need a diploma, and they can switch between different tools, frameworks as they please, they can earn really good money while they are still young. This makes the developer less focused on details, less willing to plan the future, less willing to meeting the needs of the client and more focusing on purely programming issues. And this is the reason why many programmers need help from more business-oriented managers that will both organize their work and be the one that discusses the details directly with the client regarding the project development plan.
Manager's tale (Mateusz)
Why PMs love their jobs? Apart from financial benefits --- there are many reasons. As someone who transformed from UX designer into PM, I love in PM's job a sense of achievement, a possibility to have an impact on a product during an entire development lifecycle. But there is more to it. Dispel uncertainty and start shaping the product. There's no place for boredom, because of a wide variety of tasks to be performed and dynamic changes occurring within the process. There's also a unique opportunity to work with extraordinary people. All those things drive PMs, makes their job both interesting and challenging.
Challenging because projects are a tough nut to crack. How do you know what should be done in the project in a given situation? Which features you should choose or recommend to your client? Which ones you should avoid at all costs? Imagine a situation, probably is not very hypothetical, where you have to choose one of the two paths: A and B. You have to choose one path, because of limited resources. On what basis you should decide? How to reach a point where such a choice is rational? How to know what criteria to choose so you'll know that a given decision, in a given context, is good and another is bad? How to make the decisions you make optimal, not dictated by those who speak louder?
In general, it's all about the context. In order to resolve a problem, you need to recognize what type of problem it is. Is it something from a chaotic domain? Or maybe a complex one? Or complicated? Or obvious? For each of them, you should apply a different approach. Luckily there's a cool framework depicting that.
Anyway, even if you know Cynefin, you certainly need some help. You have to contact with all stakeholders in order to clarify your next steps. You do need meetings and estimations. Not always of course, but often enough. And developers are a key piece of the puzzle in here. It's a very special social group (not a euphemism in this case), distinguished, inter alia, by the language they use.
Focusing on the language, developers use a technical one, stuffed with non-obvious or misleading words, at least from the point of view of a non-developer (eg. commit, pull request, branch, inherit, master, background job,etc.); PM's job to be done pretty often boils down to recognizing the content in the developer's message, which should be translated into the other language and addressed to the correct recipient (client, designer, tester, user, etc.).
In these circumstances, it's not that easy to be some kind of proxy.
So how can you translate something if you don't understand it fully? Well, sometimes I do feel like the part of the Chinese Room experiment.
It's an argument that supposedly puts the lie to Turing tests. You put some guy in a closed room. Sheets with strange squiggles come in through a slot in the wall. He's got access to this huge database of squiggles just like it, and a bunch of rules to tell him how to put those squiggles together. Grammar, syntax. The point is, though, he doesn't have any idea what the squiggles are, or what information they might contain. He only knows that when he encounters squiggle delta, say, he's supposed to extract the fifth and sixth squiggles from file theta and put them together with another squiggle from gamma. So he builds this response string, puts it on the sheet, slides it back out the slot and takes a nap until the next iteration. (Peter Watts, Blindsight)
Repeat until you got an elephant carpaccio.
In PM's case, it's not that extreme. Firstly, developers speak not only Chinese. Secondly, you can learn their language. As a Project Manager, you should be able to use basic heuristics (you can think of it as pattern-matching or clarification-wise algorithms) to participate in a conversation, even though you're not an expert in a given topic. Depending on how good your rules are, you can get the job done and communicate what is needed to communicate without any drops. Maybe you won't be a wit and raconteur in a language you don't speak, but still --- you can make it. Of course, pattern-matching doesn't equal comprehension, so in case you're totally not sure, you should delegate. Actually, this is another big topic: empower the people and give them responsibility, a purpose, praise them and give them a sense of achievement. And before any of the above can be done you must simply trust them.
To recap: it might be really exciting to be a Project Manager, as long as you have an experience that allows you to anticipate some events early enough, process ongoing communication and assess what you received appropriately.
Troubleshooting
What happens, if things get ugly? When the differences between developers and managers get too intense, or when there is a crisis and both sides are blaming each other? Well, like in each relationship --- these things will happen, sooner or later. The question is what do we do when they appear.
First of all, here in Visuality, we have full freedom of speech. Things get much easier when you discuss openly. We all respect each other and treat equally, no matter who your interlocutor is --- junior developer or CEO. Secondly, we use retrospective meetings after each Sprint ("bullshit Scrum", they say) in order to make sure that we can work the difficult stuff out before it would get too toxic. The final thing, and --- most likely the most important one --- here, in Visuality, we tend to spend a lot of time together after work. Usually, it is happening naturally and we just go for a few beers, have a BBQ in the garden or play board games. So we know each other and we have no position-related artificial boundaries among us. Thanks to that speaking about troublesome matters is much easier.
Are we together, or are we fighting?
However, having said that, fighting isn't necessarily a bad thing. From the fires of discussion, the better world can emerge provided that we can draw proper conclusions. It's better to have a disagreement than to just let go even if you have a different opinion. Co-existing may be hard, but usually, it's worth it, especially when common ground can be reached. Even though the product is created by the hands of programmers, without proper management the problems are inevitable. And there's also one more aspect --- internal corporate management. Life doesn't finish on one project. There will be another, and another and another. Management has to take into consideration how do the software developers perform when they're planning future moves. Whether we like it or not, we're evaluated all the time and data gathered during the development process can put an impact on future work. As long as those data is reliable and properly gathered. Keeping the balance is important --- if the amount of necessary paperwork is on a moderate level it may be a valuable input. Otherwise, it may be only some filling the void with dummy data, because "ain't nobody has time for this". The second important factor is the awareness of the reasons why such things have to be done. People are always resisting more if they don't know or understand the purpose of things. If they do --- there is a much bigger chance that they will comply, even if they still don't like doing it.
We're together and we're fighting at the same time. We fight for project priorities, we disagree on specific tasks, we also sometimes get bored at the meeting --- but this is a part of the whole picture. Without the parts, the whole thing is never working correctly.
