Press enter to see results or esc to cancel.

Why you should spend time onboarding developers

“Setting expectations isn’t the same as educating expectations”

When working in the client service industry finding talent for new projects can be tough.  We take on projects and sometimes need to hire new talents as the in-house team is at capacity.  One of the “critical” functions for the projects to be successful before it starts is communication.  In this instance we are talking about working with new developers who has different work habits.

Time for a cautionary tale

Not too long ago our team took on a small project that was simple in scope and requirements, but on a strict timeline of a few days.  Unfortunately things quickly went sideways when constant communication was not being maintained between the developers and the client and as a result the quality of the work started to suffer. At first the client and developers had multiple calls to sort things out, but some important project details were still being missed.

Identify the problem (early!)

No matter what the barrier is you need to identify and address these pain points quickly and sort out why things are out of sync and being missed. Remember both parties are remote so you cannot see the issues easily.

These are some of the questions we ask ourselves during this project.  

– Is there a language barrier?

– Was the scope of work not clearly defined?

– Are both parties understanding what is expected?

– Should you involve a project manager?

– Is the client demanding too much?

– Is the feedback loop broken

It came down to a mix between client expectations and the feedback loop for the developers implementing the work.  I did not do a proper job or informing and educating the developers on how specific the client wanted things design and realized that although the client’s work was simple in scope we overlooked the importance of taking the early feedback (the first time we noticed trouble) and getting ahead of things so the process would stop repeating itself (missing details).

What we learned

In hindsight, we learned that when you onboard new talent whether its freelancers or new employees no matter how little time you have, you must educate them on what is expected.  This is where we made our mistake.   We realized we did not do our job by making the assumption, that although it was a simple project the tacit knowledge was not being transferred properly to the stakeholders and developers of the project team and it suffered because of it.  

Guest post by Jon Eilerman of


Leave a Comment

Show Buttons
Hide Buttons