Why is my software development agency letting me down? | 4mation
Over the past ten years, I’ve seen how we, as a software development agency (and the industry as a whole), have developed our engagement with clients.
As much as we would like to think otherwise, clients and agencies are not, in essence, a single cohesive team. There is a challenge to recognise the dynamics of hierarchy & power relationships, which can lead to misunderstandings if not navigated with care and respect.
We’ve learnt to interact with clients differently as we’ve adapted to the Agile way of working. I’ve seen how we’ve evolved to deliver on our promises.
In my previous article, I discussed some of the learnings from working for over a decade at 4mation. Now, I will explain how relationships and expectations have also changed over the years. Plus, I’ll identify when and why your agency is letting you down and how you can get the best out of your development agency.
Direct -> Developer Relationship
When I started my life as a developer (well before 4mation), this was the usual process:
1. I’d be working directly with clients, understanding and (rarely) documenting requirements,
2. Then planning the technical solution (including data structures and processes),
3. Plus creating the actual functionality,
4. And finally demonstrating the work to clients.
Rinse and repeat.
My boss would be involved tangentially in the client relationship, but in essence, I was a one-man-army.
Implications of a direct developer relationship
Some agencies work like this (usually small agencies). While work can get done very, very quickly, there are a few severe longer-term implications to consider:
Key Man Risk: When your developer burns out, there’s no one else who knows how things work and can take over. Your developer can’t take holidays or even be sick without exposing you to this risk.
Narrow Knowledge Pool: No matter how great or experienced your developer is, they’re still only one person. They won’t know how to do everything and will have a strong tendency to either reinvent the wheel or copy & paste from Stack Overflow.
No Time for Learning: Following on from the last point, a sole developer, especially if they’re multi-talented, is so focused on getting that next piece of work done that they won’t have much time to learn about new methods and emerging technologies outside of their direct tasks.
No Documentation: The last thing developers want to do is write functional documentation. So unless your developer is exceptionally disciplined, there will be no documentation that describes how things should work. The common excuse is “my documentation is in the code”. This means that the only way to figure out how things should have worked is by reading the code — right at the moment when something catastrophic has happened.
For developers, being in this situation is more or less sink or swim. They either become incredibly resourceful, or they drown under the load.
On the other hand, clients really value this relationship, right up to the point where the developer drops the ball on a critical feature. Also, since the personal relationship is usually strong, they tend to forgive a lack of progress.
Until the backlog of work grows to an unmanageable level.
Client -> Project Manager -> Developer Relationship
This structure is relatively common amongst software development agencies. Project managers are in client-facing roles to take the project brief, document requirements and act as the client’s interface with the development team. They take on the task of translating functional requirements into technical specifications that the developers can then work on. Finally, they do what the job title says — ensure the individual tasks are on track to deliver the project.
The advantages of this structure are many — it takes the responsibility of managing a team of developers away from the client, and the role is better able to oversee large projects with complex requirements.
Project managers in this structure can project timeframes and resourcing requirements and can also implement agile ways of working. They are responsible for delivering projects on time and on budget.
This structure worked quite well for us for many years but required extremely competent people who were happy to wear many hats. Even so, PM’s in this role often don’t have the time to explore anything beyond surface-level requirements with clients fully. As a result, they also tend not to create value beyond getting the work done.
Clients who work with agencies that utilise this configuration are often disappointed when they expect their agency to recommend better ways of doing things. The harsh reality is that the PM simply doesn’t have the time.
The next addition to the mix addresses this. It is the Product Manager.
Client -> Product Manager -> Project Manager -> Developer
On the software development agency side, the Product Manager acts as the client liaison and is responsible for understanding the client, their immediate to mid-term needs, and deep knowledge of their business. A Product Manager will often ask “have you thought of?” questions to ensure that the client has thought through their decisions.
In this configuration, the Product Manager works closely with the developers to scope out new features and document the technical solutions (instead of the Project Manager in the configuration above).
They also work closely with the Project Manager to ensure appropriate resourcing to deliver the solution. The Project Manager has the primary responsibility of managing resources and keeping the team on task and on budget.
Teams with separate Project and Product Managers are much better able to predict and respond to change, provide feedback and ideas to help clients grow their business.
The Client-Product Manager-Project Manager-Developer structure is what we use at 4mation, and we have found that it’s enormously beneficial to both our clients and our team. However, Product Managers often don’t have the mental bandwidth whilst working on short to medium-term priorities to also switch gears to generate creative ideas for longer-term priorities and overall business challenges.
And this is where Strategy comes in.
Supporting longer-term solutions as a software development agency
Strategy sits adjacent to this entire structure.
It is not involved with the day-to-day workings between the client and the team but has a helicopter view of clients.
Strategy generates creative ideas and validates that the ship is being steered in the right direction. They do not work on short-term priorities but rather look at the bigger picture. They take the time to research innovation in many different industries and draw on ideas from left-field.
The result of this is that the client has the best possible mix of talent in their agency:
- Short term priorities successfully met with the help of Product and Project Management, who work with the Developers
- Medium-term priorities understood by the Product Manager
- Long term challenges and goals addressed by Strategy
- Innovation, ideas and creative solutions also addressed by Strategy
If your agency isn’t offering the above, please contact us to find out about our strategic reviews. Free strategic reviews are available to our clients on retainer.
Originally published at https://www.4mation.com.au on December 5, 2021.
