In the previous post, I wrote about how I was almost everything in my first job (still under freelance agreements): from a Google AdWords campaign supervisor to a programmer. Working at an advertising agency was an excellent start to a freelance career because it probably taught me all possible mistakes.

Apart from creating websites, the first thing I started working with was Google AdWords paid advertising, which at the time was quite mysterious. I remember knowing nothing about it other than that Google Analytics was a growing and new tool partially related to the Google AdWords paid advertising service.

Wanting to be honest and do the job right, I downloaded a bunch of Apress books on SEO and Google AdWords via torrents. I read them in English instead of blogs every day to understand what they were all about and how to manage them properly.

I am proud, but those three books I read were an excellent start to a general understanding of SEO and Google. I then continued to build on this understanding by reading blogs and keeping up with the latest developments. Reading those books formed the foundation of my knowledge, which is still helpful today.

The second problem I realized then was that a print designer could not simultaneously be a web designer. Back then, almost every designer considered themselves a universal designer, and terms like UX or UI were not used. And that was a significant issue.

The problem was that designers would create static, beautiful postcards that, in some sense, were supposed to function as websites. A few examples:

  • Menu items would be designed without states and without making it clear that you could click on them.
  • Gradients were used (CSS3 didn’t exist then), and the background became one huge image—imagine what Google PageSpeed Insights would say about that now.
  • The designer used italic fonts or even Comic Sans at times. Yes, it happened.

To help my colleagues, I read the then-popular Smashing Magazine blog, which essentially shaped my understanding of web design: how elements should be arranged and best practices, and generally laid the foundation for the UI/UX standards that would develop in the future.

So, I became the first barrier before presenting designs to clients—the one who would give a few notes to the designer to make the design at least somewhat better. I remember this was a real pain for an experienced print designer—some kid trying to tell her how to draw. There was a lot of tension, but I felt obligated to do things well and with quality. I wanted to share my knowledge.

The third problem was that websites were not advertising agencies’ main business. It’s no secret that advertising agencies are often about connections and relationships, where a “good buddy” comes in and orders services because they know you “do things well.”

Because of this, I noticed that clients often want more functionality or a different kind after the project was delivered. They thought fulfilling all their wishes and expectations for a fixed price was expected. After all, if you’re organizing an event or tweaking a flyer design, you can make as many changes as you like until you’re happy with the final result.

Initially, we didn’t write or define any specifications. And, of course, you couldn’t disappoint a buddy, so all the additional requests had to be fulfilled for free. Naturally, all this would eventually be done at my expense. No one understood that adding a new page type wasn’t just about adding a menu item but required programming a new entity, management system, and integration into the overall system.

I had only vaguely heard about specifications and that they even existed. I introduced the goal of writing descriptions (at best, these could be called requirements) before starting any project and charging extra for additional unspecified costs.

We both benefited from this: I didn’t have to work for free and fulfill ever-changing requirements, while the agency found a reason to charge the client even more. Although in some cases, I was the only one who benefited from the same budget.

From then on, I learned to write technical specifications or requirements descriptions for every project. I constantly improved and learned to write them more accurately and better, and with each new client, I had fewer and fewer disputes about what needed to be done and for how much.

The fourth problem I encountered was project management. Organizing an event or managing a flyer or business card work is not the same as creating a functioning website.

You can’t be mad because it’s challenging to find good IT project managers even today. To be a good IT project manager, you must understand what your designer and programmer colleagues are doing and the process. If you don’t understand this, you will remain just a messenger between the client and the programmer. Being a messenger often means just empty ping-ponging between clients and forwarding their emails, which creates no value.

I noticed this discrepancy as early as the twelfth grade when observing how the project manager worked with me. For example, before assigning a task to a programmer, it must first be properly described, the necessary credentials obtained, and everything prepared so that all that remains is to execute it. But it turned out that, as one might hope doesn’t happen anymore in IT companies, the responses were, “I can’t answer that, I need to check,” or “I’ll get back to you with an answer.” Your answers are simply copy-pasted to the client, and their emails are forwarded. Eventually, you become the project manager, whether or not you want to.

At the time, we addressed this problem by me, in my first year of university and without a car, frequently traveling by train from Kaunas to Vilnius to attend client meetings.

It was charming that, as a freshman, I would take the first train at 6 a.m. to Vilnius, where the project manager would already be waiting for me at the train station by 8, and we’d head to meetings together.

It was genuinely terrifying because the companies seemed quite large and fancy—at least, that’s how they looked to me. I wore my best sweater and ensured no lint pieces were on my coat. I wanted to be seen as professional and not just a scared kid.

I listened and watched as a genuinely good project manager (despite all the IT-related issues) communicated nicely, resolved conflicts, and even sold services. I learned by observing, and observing is no less important than doing it yourself. When you don’t understand the context or how it should be done, learning from an example provides a wealth of context you can apply later. I’m incredibly grateful for that.

For example, I learned a seemingly simple rule: to be punctual, you must arrive exactly on time—not earlier or later. I always used to come too early, afraid of being late.

It’s funny that some of those clients from back then have now become my clients in e-commerce through the agency without even knowing it. It’s an ego boost.

So, my first job under a freelance agreement with an advertising agency laid the foundation for my further freelance journey. I developed my first SEO skills, deepened my programming knowledge by building systems with WordPress, and started forming abilities as an analyst and project manager.

Ultimately, the projects evolved from “doing whatever works” to “doing things properly:” with specifications and requirement descriptions, preliminary evaluations, and hiring professional web designers and front-end developers, while I programmed everything and managed the process. We even prepared instructions for clients on how to use the system, and I conducted those training sessions myself, showing how the system worked.

Leave a comment