How to engage your development team

One of the things I like the most about Zooma is how we always strive to make everything we do even better by taking in the essential learnings from each project. Of course, that is a never-ending process. Had I written this text some years ago, being in a different context, it would have sounded much different than it does now. But even when things are good, there is always room for refinement. In this article, I will focus on three things that are always important not to underestimate or take for granted when involving a developer (or any human resource) in a project.

I often think about project improvements to deliver the best possible, stable, secure, and user-friendly projects. I also like to be part of the delivery, not just responsible for an isolated part. It is always continuous work to improve and stay on top of things, so a project should never rely too much on the previous way. Instead, we should always take in and use the learnings of each prior project. To evolve, you need to be attentive and constantly question things.

What is an ideal development process? Well, it looks like this.

The ideal development process

1. Briefing about the whole scope of the project
   1. Specific briefing for the development part
2. Brainstorming
   1. Consultation with other developers
   2. Break the project into parts and decide the best approach to solve functionality
3. Estimate the time needed for implementation
4. Make the development time plan
5. Development
   1. Periodical code reviews
6. Testing / Quality assurance
7. Bugs/errors fixes + code refactoring
8. Launch
9. Post-launch fixes

Even if we are already following much of this structure today, some things always tend to get less attention. Especially if something suddenly demands things to happen faster than they were initially planned. Therefore, I would like to highlight three crucial things that need to be part of all projects to have a mutual mindset, goal, and way of working to achieve the expected result.

Communication

The first and most important thing is clear communication throughout a project. You can never stop working on improving your communication channels and skills, not only in projects but in everyday life as well. That is for everyone in a team, but for a developer, it's vital how the project manager keeps the communication and involvement of all team members on top. It's easy that meanings get lost in a chain of conversations, which makes it extra hard to get the complete picture if you are to step into production at a later stage of the timeline, which a developer often does.

Managers and developers naturally approach their projects and challenges based on their roles in a company, so there are often different perspectives on what should come first and what is most important. Hence, mutual understanding is essential. There must be an agreement on the priorities of planning, budget, and objectives, as well as the challenges that occur within the cycle of developing new functionality. For example, writing code is an ever-evolving task, and what was technical best practice in the last project may not be relevant in the next one. That means that developers usually need time to think and invent new solutions that might not have been done before, so there should be room for flexibility in the plan.

A good project management tool is also vital. I think everyone at Zooma would agree with that, and I would only be able to work with it. It doesn't matter what tool it is for me; I'm happy as long as I know where to find my tasks and where all information is stored. I usually work on multiple projects during the week, so I need to know where I can find my priorities. Ideally, it would be great to have "One tool/app to rule them all, " but that's only sometimes possible, so it's essential to define and communicate the way of working on a specific project, what tool is used, and how.

Engagement

A developer wants to be involved from the beginning. We want to know what's happening, the entire scope, and the reasons behind the planning, even if we are not scheduled to do something until later actively. Of course, this helps us when we are supposed to plan our to-do's within the project. But it also contributes to us feeling involved and part of the whole picture, not just writing code. 

For example, I might get a brief that I am expected to build a shop functionality. But maybe that shop is part of a whole new web project. Then the brief should contain information on both the shop part and the rest of the web project (even if I'm still only building the shop part). When developing that shop, you want to have the entire brief since your way of solving different functionalities will impact options you might consider in light of the full scope. To evaluate and find the best solution, you need to know how and where it will be used. When developers are not fully aware of the expectations of the project, they might do things a certain way, which can complicate, for instance, later upgrades of services. It helps a lot when we can think things through in advance – before something comes boomeranging back later.

Support

One thing that many developers (and creatives in general) seem to have in common is the impostor syndrome. Especially when there are many ways how you can solve particular problems, it's not something I made up; it can sometimes be a good thing. This is when you feel that you do your work based on luck and that things function out of coincidence. This is, of course, not true, but many people think this way, and in situations like that, the project manager can help by ensuring that the project runs as a team effort. We do everything together, even if we all have individual responsibilities.

Way of working

Another thing where planning and development often need to compromise is regarding the way of working. If I am a generalist, developers tend to lean more towards the agile method, while project management looks at it more from a waterfall approach. In these cases, it calls for a hybrid process, "agile-waterfall", where both methods are combined if we want to find a smooth setup that works for everyone with the best result for the customer.

Meetings

A developer doesn't mind meetings. Not really. We say we do to make it harder for the management team. Jokes aside, meetings are reasonable and necessary, but it could be better when there are fewer. And especially if they are happening all the time. It breaks the creative flow if we need to pause constantly for different project meetings. So when possible, it's worth a lot for productivity if meetings can be well planned and held on fewer occasions.

Process

The development process would be constantly ongoing, iterative, and innovative in a dream scenario. Only some things have to be defined in detail in advance. To get buy-in, you must have a limited scope, time plan, and budget for any project. However, if we can keep a space for flexibility where you can test out different solutions and weigh them against each other, everyone would benefit from it. Also, in this case, a hybrid approach best meets all demands and expectations of the result.

Organisation

It's not all about a specific project and the planning and execution of it. It's also about the organisation. The organisation's culture and rules set the framework for how everybody acts. So, it is not only about solving practical, project-related tasks. A holistic view that considers more cultural parameters in a project creates an excellent working environment, making it easier to be a cog in the machinery. 

Expectations

What usually stresses a developer the most is when requested to do an estimation. We want to set firm delivery dates and have as precise estimates as possible, just as anybody else. But it can often be that the expectations are pretty stringent. Once estimated, you need to stick to it, and that estimate follows you subconsciously, which adds to the stress levels. Managers, sponsors, and the customer all want a commitment to time and budget, which is natural. But this is always based on assumptions, and assumptions can change. Sometimes the estimation is spot on, and sometimes, it needs to be corrected with consequences to delivery time or quality. The expectations need to be clear and communicated to avoid uncertainty and misunderstandings about why things happen and what measures will be taken if they do occur.

Many creatives would prefer not to give an estimation, even if it's only a request for a rough ballpark figure at first. This calls for the understanding already listed under the communication headline. The required estimate often involves assumptions based on new or untried features and functionalities, and it's not easy to say exactly how something will behave until you have built it. But that would mean you are already a long way into the project, so you find yourself in the classic Catch-22 situation. Expectations on estimates and deliveries need to be understood by all parties, and they need to be reasonable. Once the project is up and running, there must be clear communication to the finishing line. That way, we can avoid pitfalls and unwanted surprises or at least address them in time to find a fitting solution to fix them. Also, the estimates are often good in keeping you focused on the work, so flexibility is essential.

Regarding expectations, some recurring tasks often get a lower priority tag in a project plan. One such thing is code refactoring. It's easy to categorise tasks like that as nice-to-haves instead of must-haves because it is expected that everything is already done optimally. Which it hopefully is. But you always find things to clean out or adapt once you are at the end of a project that you didn't realise or were aware of at the beginning. And then there should be room to take care of those things, not leaving it as is and hoping for the best. 

A good quote by Addy Osmani covers that essence in just three steps:

First do it. Then do it right. Then do it better.

So, whenever possible – implement this three-step process for flexibility and optimisation. It will do much good to refine the result.

For everything listed above, it's about finding the balance in each project and letting everyone get a chance to speak from their perspective. As a result, you get a positive and committed team that creates shining results.

Make sure to subscribe to The Onlinification Hub, and you'll get an email whenever we publish new articles.