Learnings from 10+ years at a Digital Agency

4mation Technologies is a Sydney-based Digital Agency, where I have been working since 2009. In this article, I talk through some of the lessons I’ve learned over the years.

If you’ve ever worked in tech, you’ll know that 10+ years is a very long time to have worked for the same company. It’s an especially long time to have worked for an agency.

Agency life is not for everyone. Agency is a great place to be if you want to gain exposure to a multitude of industries. It’s also great if you want to learn a lot about how the world works. You are given opportunities to learn about things that you never thought you could or should learn.

It’s not all roses, and I’ve had many challenges over the years. I’ve had to think on my feet and make compromises when I didn’t want to. In the dead of the night, I’ve had to code to all hours to meet deadlines and handle critical emergencies.

I’ve learned to be resilient because when bad things happen, I’ve had to deal with them. And from this resilience, I’ve learnt a lot during my 10+ years working at an agency.

Communication > Technical Skill

Life is very hard when there are miscommunications with clients. Nothing sucks more than when we’ve put in a massive effort to get something across the line, only to hear the client say “this isn’t what I wanted”. Clients think we don’t care when we don’t deliver what they ask for. Developers think clients don’t “get it” when their brilliant solution gets thrown in the bin.

The underlying reason is more akin to a cultural clash. Clients come from and work in cultures that can be vastly different from our own. As can happen with people who work in different countries, people who work in different organisations have different styles, values, expectations and ways of communicating.

The solution is to find common ground via two things:

1. Early and often communication and
2. Establishing the rules of engagement

This can be difficult when there is a cultural clash, but it’s not impossible. If there is a vast cultural divide, it’s worth rethinking the value of the relationship.

The benefit of bridging the gap is that you build personal relationships. “Customer collaboration”, as defined in the Agile Manifesto, becomes a lot easier. When problems happen, you end up being on the same team instead of at each other’s throats.

Caring about the work isn’t the same thing as caring about the client

I’ve seen very poor client outcomes produced from technically excellent work. In one particularly bad project, we ticked all the boxes and had built a technically excellent solution. It completely failed because the client hadn’t been consulted at any point during the build phase. We ended up redoing the entire project at our own cost.

One of the major warning signs was “agilefall”. We conducted all of the “agile” ceremonies internally but demonstrated nothing until right at the end.

The solution is to be relentless about demonstrating your work to the client. If a demo hasn’t happened, you’d better believe that you’re going to fail. Don’t wait until something is “ready”. Demonstrate what you’ve got, get feedback and iterate. Explain to the client that what they’re seeing isn’t the finished product — and rightfully so. They will understand, and even welcome the fact that they get to have input along the way.

We’re in a Rally Car. Clients are the drivers. We are the navigators

In the beginning, I saw myself as the driver, because drivers control the rally car, do all of the fun stuff and are the heroes that win the race.

It took a really long time to realise that I should actually be the navigator, and my job is to help our clients win races.

It’s not about us. It’s about what we can do to help guide our clients along the race track, tell them when to turn, and where the potential hazards are. Then we stand back as the client wins the race and gets all the glory. In an agency, that’s our role.

Agile is a mindset

A lot of people misunderstand agile.

It is not a process. Following agile ceremonies does not make you agile. Estimating t-shirt sizes does not make you agile. Saying you’re a Scrum Master does not make you agile.

The entire thing is about continuously delivering value to clients in the smallest chunks possible. It is this thought process that allows us to mitigate risks of failure at every step.

It is not about reaching perfection. If you need to reduce functionality to deliver something now, there’s absolutely nothing wrong with that.

It’s certainly not about smashing out tickets in a sprint. Completing tickets in and of itself does not make you agile. You can complete a hundred tickets in a sprint and still deliver nothing of value.

Demonstrating work is again one of the key ways to keep people aligned around delivering value. It’s hard to fake a demonstration. If you see a ticket and it doesn’t lead to an objective that you can demonstrate by the end of the sprint — think about why you’re doing it. It doesn’t matter if the thing you’re demonstrating isn’t 100% complete — just showing progress and getting feedback is enough.

Learning & growth doesn’t just come from writing code

Agile processes such as Scrum and Kanban are extremely difficult to manage in an agency environment. It requires much more alignment amongst team members, clients and the broader business than anywhere else. You need to balance competing priorities from different clients, as well as their communication styles, schedules and other requirements that change all the time.

In an agency, people by necessity wear many hats, and that includes developers. Teams with ten clients can’t have all communications funnelled through a single Product Manager. Otherwise, that person will be scheduling and attending a demo every two days. Not only is that unfair, but it’s also unworkable. So everyone in the team, including developers, need to step out of their comfort zones.

This is one of the biggest drivers of learning and growth for developers; learning better communication skills, how to understand project needs from a different point of view and how to ask deep questions. They learn that these things are just as important as good, clean code.

Developers who balk at talking to clients don’t just limit their own potential, they limit their value to the market.

Ask more questions

When I first started at 4mation, I instantly knew exactly how to solve problems as soon as they were presented. I still have to fight the urge to immediately suggest a solution, as it’s a habit that’s been formed over many years.

I’ve learned to slow down and take a moment to think about the bigger picture. Instead of thinking about what to do, I think about the problem that I’m trying to solve, and ask questions.

Why is my solution good? Why should this be done at all? Does the problem even make sense? My solution might solve an immediate problem, but is there a better solution? Is there a way to achieve the objective that doesn’t involve coding?

Similarly, I’ve found that the best coders aren’t just great communicators — they ask a lot of questions, think more deeply about solutions and suggest simple ways to solve complex problems.

Keeping up with technology

The main programming language that I’ve worked with at 4mation is PHP. At 4mation, we went from no frameworks to CakePHP and on to Laravel in 10 years (not to mention WordPress and other PHP-based open source solutions). After all this time, whilst PHP is declining in popularity, it’s still around.

Things do change: there are new libraries, techniques and technologies that swing around every so often, but the underlying technologies (e.g. languages and frameworks) hang around for a really long time.

In agency life, you’re expected to complete work as quickly and efficiently as possible — meaning that in the normal day-to-day, you often have very little time to experiment (unless you make a case to the client for it, which can and does happen).

So there is always a tension between adopting new technologies and mastering existing ones. A good developer can pick up and learn any language, but that doesn’t mean that they should. Nor should they focus exclusively on a single language and be out of a job when that language becomes obsolete.

What I’ve seen work is to master the technologies that you’re familiar with, but set aside your own time to experiment and explore with new technologies. Don’t expect your company to hand absolutely everything to you on a plate, especially in an agency, where time is literally money.

Some of the best developers that I’ve ever worked with were committed to self-study. They listened to podcasts, attended meetups and worked on side projects in their downtime.

People Leave. All the Time. Be grateful to them for staying

As previously mentioned, Agency is hard. Not only is the work very demanding, but it’s also mentally exhausting and can feel thankless at times.

One of the main things that has made agency life really great are the people that I’ve worked with over the years. 4mation has a reputation in the market for being a good incubator for talent — meaning that the people at 4mation end up being very, very good. I can confidently say that this is true. People don’t last long at 4mation if they’re not exceptionally talented.

This means that the people that I work with are constantly being approached by recruiters, so it’s only a matter of time before they are offered something that is too good to ignore. It’s a fact of life.

We’d love to retain everyone, but there’s a difficult balance between learning, work, wage growth, market forces and a bunch of other factors.

What we can do is be grateful to them for supporting us. We help people grow and learn and do our best to offer a great place to work, with other great people to work alongside.

When they leave, as Marie Kondo might say, thank them for their contribution and let them go.

Don’t punish people for experimenting

People learn from experimentation — and punishing people if experiments fail leads to a reduction in risk-taking, and less or no experimentation. Experimentation is a prime way for us to learn and improve what we do.

It’s like yelling at someone because they told you something you didn’t like. Next time they won’t tell you, and you will be blindsided when that bad thing happens. Not only that — you’ll be blaming them for not telling you when it was you yourself that provided that massive disincentive to them for doing so. Nobody wins.

What you should be doing is the exact opposite — punish people for an absence of communication and not being transparent with either yourself or your clients. Be grateful or even reward them for telling you bad news early enough for you to do something about it.

Demand more communication and more questions. It might feel annoying at times to deal with failed experiments, field many questions, or deal with bad news early… but would you rather have the opposite?

It’s problem-solving, not coding, that makes people great

I’ll wrap up this article with a final thought.

There are literally two types of people who write code:

1. Coders who are problem solvers
2. Coders who aren’t

You might think that all coders are solving problems in some way shape or form. While this is true, what I’m talking about is the mentality. I’ve seen over the years that people who really enjoy solving problems are the ones that come up with the most creative solutions. Those that aren’t… really, really struggle.

For problem-solvers, coding isn’t a daytime job. It’s all-encompassing and they can’t just switch off. A solution will come to them when they’re out for a walk, when they’re feeding the cat and when they’re on the toilet.

Problem-solving is a creative process. Coding by itself isn’t. When hiring, look for people who are problem solvers — they are more likely to demonstrate many of the ways of thinking that I have mentioned in this article.

About the Author

Edward Wong started his professional career in the late ’90s.

The majority of his career has been in technology consulting.

He is currently the Head of Strategy at 4mation Technologies.