and how we’re trying to overcome it. My colleague Christian and me held a talk concerning that topic at T3OCE 2020 and received an overwhelming amount of positive feedback. That’s why we deceided to add the topic to our blog as well.

Background: What led us down that road in the first place?

There were a couple of initial problems which led us down the road of thinking about changing things.

First and foremost: Manpower Shortage. Like most digital agencies these days, we don’t have an overwhelming amount of developers and finding new ones can be quite the task. Plus: the developers we already have, shouldn’t be bothered with so called ‚monkey work‘.

Secondly, we want our colleagues to expand their knowledge. Mainly, because it’s a lot easier for project managers to sell and support a project they actually know about on a technical level, instead of only playing ticket ping pong and solely being the communication administrator between developer and customer. Yes, you can be a project manager without having any deeper knowledge about how your projects actually work – but it should always be your goal to know significantly more than your customers. And customers tend to be a lot happier if you can actually help them with their problem instead of just saying „I’ll ask a developer“. Talking about improving customer support...

What is more: Some project managers want to actually contribute to the projects they are managing and not only do all of the „administrative stuff“. I can obviously only speak for myself here – but it makes me really happy and somewhat proud, when I’m contributing even the tiniest tasks.

Point number 3: We want to tear down barriers; between colleagues, as well as between the different departments. Honestly. Stop the „that’s a developer’s job“ or „I can’t do that“ mindset. We want to encourage all of our colleagues to at least try something they cannot do so far.

First steps: How did we start?

We did not plan the engagement of our project managers into the development process beforehand. The idea was born pretty spontaneously during one of Christian and mine carpool rides.

And instead of making things way to complicated and bureaucratic – we just went ahead with it. We sat down one afternoon, installed SourceTree and PhpStorm onto my laptop and Christian gave me an introduction into git flow, workdirs and the basic commands I needed to know about – and then I just started. We looked through all currently open tasks on the board and defined which ones could be handled by project managers. Those included:

• Managing and editing translation files
• Symfony form definitions (error messages, validation constraints)
• Replacing or adding versioned images and other project assets
• HTML templating tasks (depending on the different PMs‘ prior knowledge)
• Creating Gherkin-based acceptance tests

Moreover, all project managers received multiple internal training sessions on various topics such as a first look into the general architecture of a typical Marketing Factory TYPO3 project or an overview about the various different methods of caching.

Setbacks: Which problems did we run into?

1. Taking part in development comes with a steep learning curve. 
   When you’re taking your first steps in actual code, there are a lot of things you will inevitably stumble upon and which will cause frustration. For me, it was missing commas and failing build pipelines because of those… Don’t even ask me how many times I needed to correct my own mistakes.
2. Entry level boundaries are pretty high.
   You’ll need to learn loads of new terms, tools and techniques, which have never been on your radar before. That’s definitely pretty intimidating at first glance.
3. Security aspects and two-man-rule
   Usually every developer at Marketing Factory takes responsibility for his/her own developments and almost everything undergoes a second pair of critical eyes. However, when incorporating project managers in this process, quality assurance processes will need to be changed as well.

Current status: Which tasks are already handled by PMs?

This process – as of now – has been in place for around a year and some of the project managers are now regularly doing code related tasks. A couple of the tasks they are handling:

• Actively working with Git by creating branches and contributing own commits
• Managing, merging and finishing branches and tags in Git
• Depending on the very project, some project managers even have local dev environments at hand
• Deploying finished development iterations by means of GitLab CI pipelines.

In addition, we can say that the quality of issue and bug descriptions has also improved, since the technical understanding has been improved significantly.

Next steps: What are our future goals?

We are still working on enabling project managers to handle even larger parts of the overall project lifecycle. This means, we want to let them gather requirements, realize them and deploy the finished results completely on their own.

Also (and this will quite likely always stay like this since everything is constantly evolving) we want to further deepen the technical understanding among our employees. Because more in depth knowledge leads to better recommendations and thereby to happier customers. This circles back to one of our initial goals: Improving customer support. Customers love project managers who can immediately help them with matters of details when asked on the phone 🙂

If you know how things should work, you most likely won’t just hear “The user registration does not work” but might get something like “The registration form does not work, because it lacks the required CSRF token”. This is because you encourage people to have a look into the browser’s debugger and you enable them to understand what’s going on there. Previously this was mostly delegated to the devs with very few technical analysis before.

And besides customer satisfaction: Better technical understanding and knowing how the different building blocks work together also leads to greatly improved QA iterations.

Lessons learned: What went well and what could we’ve done better?

1. Give it a try!
   It’s far more satisfying to help doing things instead of just selling the final product and even seemingly „small“ tasks can help with the ongoing process of the project. There just isn’t really a reason why you shouldn’t try it 😉 Even if it doesn’t work out in the long run… it will always be an enlightening experience to look back on!
2. A Continous Integration System is definitely a must-have
3. If your project can afford it: use test driven development
   TDD safeguards people in that it helps to avoid the above mentioned starting frustration. Also: Mistakes can be spotted earlier in the process and before they might accidentally go to production.If you use tests right from the beginning you will receive useful feedback. You know exact what was broken by the last commit and do not have to spend endless sessions of tracking down “missing commas” 😉 (sigh).

Last but not least

If that sounds interesting to you – whether you’re a project manager looking for new challenges to tackle or a developer wanting to work in more intertwined teams – come and join us!

---

The slides to our talk are available on speakerdeck. If you’d rather like to listen to us than read our slides – this talk is also available on our new YouTube channel!