First day on the job: expectations and interactions with a real client

One of the most intimidating moments in an engineer’s professional career is their initial encounter with a real live client and the first days of working on an actual commercial project. Academy students often ask veteran staff members several questions about their experiences, and generally dread that first conference call (in English!) with their future product owner or team lead. The point of this article is to briefly prepare you for that call and beginning phase of working with a real client - and to assure you that it’s not nearly as nerve-wracking as you might think!

Portrait of a client - whom do we work with?

First of all, it’s important to understand what our usual client looks like. Much like our selection process for engineers, we’re actually quite picky about what sort of clients we take on, and it may surprise you that we reject far more potential clients than we accept.

As a company, we focus almost entirely on small and medium sized businesses - that is, companies which range anywhere from a couple employees to a few hundred. Most of our engagements are fairly long term - at a minimum six months, with some clients sticking with us for several years and many iterations/versions of their product. The vast majority come from Western Europe and North America with a few exceptions - and they come in both technical (CTO’s or developers themselves) and non-technical (product owners and CEO’s) varieties.

What this means for you is that you can expect a close, direct relationship with the client, with whom you will speak/communicate with on a daily or at least weekly basis. You may be working with a single person on the client side, or a whole technical team - and all communications will generally be in English, both written and spoken. Finally, we are very careful about selecting clients which we know we’ll get along with - if we get bad vibes or red flags from a client early on, we’ll make it a point to avoid working with them. This is rather unique in the industry, but it allows us to keep motivated and professional engineers in our team, as we insist on working only with other professionals in turn!

Why clients actually want newbloods on their team

As a novice engineer, you might get the feeling that clients only prefer to work with experienced, seasoned developers with years of experience under their belt and lots of technologies they can draw from. While there is certainly some truth behind this, there are actually a number of reasons why a client would prefer to a more junior person on their team:

Team Balance

With any project, there are varying degrees of complexity for every task that needs to be done. Some tasks are pretty routine, while others require a high level of experience and architectural design. While senior engineers can focus on these more complex tasks, a junior can build their experience working on features that still hold many valuable lessons for the novice developer. While it may seem logical that three senior engineers will perform better than a mixed-experience team working in the same conditions - it is important to note that those three senior engineers will not gain very much personal development from doing tasks they’ve already done dozens of times. Therefore, it’s better for the overall health of the team to have junior engineers on hand who can benefit from doing these sorts of tasks.

Fresh eyes

New engineers tend to bring a different viewpoint to the team that is to the overall health of a project. Since you’ve mostly been exposed to newer technologies and approaches, your suggestions may provide a refreshing perspective on how to tackle a particular problem. This is especially true when the other team members have been on the project for a long time and may have developed a bit of “tunnel vision” in their particular approach to the platform.

Eagerness and flexibility

It’s quite natural to have a more eager and “hungry” attitude towards engaging in a project as a new engineer - you want to prove yourself and flex your technical abilities as much as you can, while trying a variety of different approaches and solutions to problems to see which ones suit you best. As you become more experienced, you’ll start to develop your own preferences - which is perfectly natural, but can sometimes create friction with clients who have their own pet technologies that they want to use. Junior engineers, on the other hand, are often more open to different technologies, which clients certainly appreciate.

What a client expects from a junior developer

Most clients don’t simply lay out a list of expectations for their engineers to adhere to over the course of their collaboration - which can make for some nasty surprises as both the client and developer learn that they may have different visions of what the initial cooperation will look like. For the most part, clients tend to have a few basic tenets of professionalism in mind:

Know your role

If you are entering a team as a frontend React JS specialist, then the client will expect you to be well versed in that particular framework and technology, to the point where they may ask your professional opinion on a specific problem using said technology. You may find yourself providing advice to a senior engineer with much more overall experience in the IT sphere than you have, but who hasn’t touched the technology you have specialized in. However, they won’t expect you to know dozens of technologies or frameworks outside of what you’ve been brought on to the team for.

Common professional courtesies

This might be silly to mention, but it’s obvious that clients will expect some universally standard practices from their team - punctuality, responsibility, and ownership of your actions as an engineer. Clients differ greatly from one another and have different priorities in how processes are carried out, but nobody likes being kept waiting for a team call or hearing excuses about why a task wasn’t done on time or completed in a certain way. Be on time, admit to your mistakes, and don’t bullshit - simple rules to live by in life and at work.

Curiosity and a desire to see the project successful

One of the greatest concerns a client has when engaging in outsourcers is whether the developers will care as much about their project as they do. Outsourcing has a bad reputation in the IT world, which consists of a faceless army of “mercenary” developers who care little about the results of their work and simply just want to get paid. This fear, along with Ukrainians’ reserved nature of displaying emotions, can sometimes elicit doubt on the client’s side as to whether the engineers really care about their work. Therefore, it is important to make it abundantly obvious that you are eager to see positive results from the project - this will go along way in building a good rapport with the product owner and show you’re truly on the same team.

There are some things which a client isn’t expecting

Another thing to keep in mind is that clients, for the most part, are reasonable people who have a normal outlook on what you should be able to deliver as a junior engineer. As we mentioned previously - if a client is unreasonable, we are quick to point it out and strive for a fair exchange between them and our engineers - if it means withdrawing from a project.

That being said, sometimes I find that new developers to Binary are worried that they won’t be able to meet the standards a client puts forth, or that we “oversell” them and their capabilities, leading to disappointment and frustration all around. That certainly isn’t the case, and we do our part to clear up any misconceptions before our engineers even start working on a project:

Senior-level productivity

It is a given that a junior engineer who is still learning the nuances of a particular technology or approach has a lot yet to learn, and will spend some time reading up and familiarizing themselves with tools that they may not have used before. This is often a case of simply knowing where to look, or what to look for in order to solve the problem - senior engineers can quickly refer to sources and previous projects to find a solution to a problem which may take juniors much longer to discover and comprehend. Therefore, it’s understandable that the overall output of a junior will be less than a senior can produce in the same amount of time.

Complete knowledge of a variety of tools

This goes hand in hand with the above point - nobody expects a junior to have experience using all the tools available on the market to build a platform. Oftentimes a new engineer will confide with us that they don’t want to give the impression to clients that they are completely unfamiliar with a technology used in their assigned project - quite the opposite, that’s to be expected as there are dozens (if not hundreds) of different frameworks, 3rd party API’s, and languages which a developer can’t possibly have first-hand experience with - at least not entirely. The key here is to just be up front when running into a new technology, and set yourself to task in familiarizing yourself with it as quickly as possibly - relying on your teammates to point you in the right direction to save time and help focus on the most relevant parts to learn.

So how do you meet expectations?

One of the most important things you can do to prevent any problems during your first few months working with a client is to be proactive - take initiative and identify issues early and address them. It’s natural to see a bad situation developing and simply hope that it will sort itself out in due time - but speaking from experience, taking this passive approach almost never resolves the issue better than addressing it directly, and it opens up developers to a lot of risk in making a bad first impression (which can be very difficult to change).

Communication is key

The first point of taking initiative is being clear about your intentions - use any and every means of communication you have to make it obvious what you are planning to do, and where you’re having trouble. Things like daily reports and standups aren’t there just to waste your time - they provide valuable, two-way feedback between you and your client and help you clear up issues before they spiral out of control. The number one cause of conflict between junior engineers and clients is miscommunication - and spending the extra effort in the beginning to establishing a good rapport with the product owner will undoubtedly save you huge headaches later in development.

Don’t be afraid to ask for help

Along with good communication comes an obvious source of support - your teammates! Asking questions early and often will be enormously useful in getting you up to speed with the project and its associated technologies. A common mistake new developers will make is jump into solving a problem on their own which has been solved many times before - often by the other people in their own team! This ends up being a huge time sink, and your extra effort in coming up with a unique solution will often go unappreciated as a result. So don’t ashamed to ask for a hand whenever you run into an issue - everybody is equally interested to see the project completed quickly and efficiently, and generally appreciate more questions as opposed to fewer.

Have faith in your technical skills

One major benefit that Academy provides is that it gives you a very holistic, full-spectrum experience with a variety of technologies - it is not an exaggeration to say that many of our Academy graduates have a skill set equivalent to what the industry would consider a “middle” developer. Bear in mind that for your client, a “junior” developer can be anyone ranging from a new commercial developer with several years of education/experience under their belt as a hobbyist/student, to a person who took a 2 week HTML course and started looking for a job right after.

This means that clients can be quite skeptical of a junior’s technical skills - but we assure you that you’ll not be lacking in them if you managed to graduate our Academy program. It may be prudent to let the client know that you’re willing (and able) to take on tasks outside of the initial scope of your responsibilities - for example, if you’re assigned as a front end specialist, and see that the backlog for backend tasks is overflowing, letting the client know that you could help on that side of things will do a lot to convince them that you’re truly a team player and don’t suffer from “not my problem/моя хата с краю.”

Become a product owner

On that same note, the final thing you can do to prevent misunderstandings and have a good working relationship with your clients is to put yourself in their shoes and become a product owner. Imagine what the end users are going to experience using your program - what sort of things might they care about (or not care about), and realize what they’re trying to achieve.

Remember - the client may have a considerable fear that you don’t care about the project, and the easiest way to address this is to see things from their perspective and treat the project as they would. This will payoff in a huge way in winning the support and admiration of your client, and will also go a long way in helping you build a stellar product.

Academy - the closest thing to the real deal

One major advantage our junior engineers have when facing their first client is that they’ve essentially experienced all these points before during their own Academy projects. We design the Academy course to reflect the same conditions you’d face in a real commercial development environment, and in fact, the standards for completing the Academy program are often higher than what clients expect from their own junior or middle-level developers!

We use the same technologies and industry best practices in our Academy program as you would find in the real world, and conduct our sprints and retrospectives the same way as our clients do. At the end of the course, each of our graduates can proudly display the project that they’ve built over the proceeding few months, and can attest to experiencing a complete development cycle while working in an elite team of students and veteran engineers.

So it isn’t an exaggeration when we say that using what you learn in our Academy program, you’re bound to make a strong, positive impression on clients who may not expect the level of professionalism and experience you’ll have as a graduate. Just keep in mind the above points and we’re confident that you’ll quickly build a solid base of trust and respect with your team - as it has been for all of our previous Academy engineers!