Transitioning from client services to products

I amicably departed from a developer lead position at WebDev Studios, and joined the product team behind products like EDD, and AffiliateWP this past May.

I’m new to some of the organizational and interpersonal components of product teams, but more to the point, I was consistently surprised by the differences in how I work.

Although I’m just a few months in doing this full-time, I want to note some of the observations in transitioning into full-time product development from full-time client services, because wow. Different.

Here are some of those observations in no particular order.

Commit behavior

Commit good stuff, not an arbitrary timestamp of progress. With client services, common project management expectations mean that a supervisor/lead needs to code-review regularly. It was something I did multiple times per day, every day.

It may also mean that frequent updates need to be sent to the client. If you’re leading a team with several active projects, you can’t look through everything in detail, or have a call with every person on your team. So, you make it easy. At the end of every day, everyone pushes what they have – even if it’s not working (just don’t take down the dev site). Occasionally, a short scrum is adequate instead. For any very particular or abstracted things, you need some code perusin’.

This is a dynamic I’ve found my co-workers, today, don’t care about in a daily context. What they do care about is the stability of the software, and not having to potentially bisect a heap of commits beause of some janky commit.

Regular communication and progress notes are certainly just as important, I just (try to) do it without committing until the thing works1.


If you’re in the business of creating websites or apps for clients, consider this:

How do you sell unit testing?

Unless your client is another engineer/developer/ etc, it’s tough to communicate why a considerable portion of the budget should be set aside for testing.

What gets tested on sites? The appearance, and the apparent functionality. We’re all familiar with this round of issues on a project:

– This doesn’t work if the .csv file is larger than 2mb.
– “The numbers are wrong” -> Replicate issue -> Yay, a floating-point corruption is modifying integer values.
– A memory leak in your sort method gradually coaxes the operating system into a kernel panic.
– This looks weird || broken || bad in IE.
– Unicode.
– “We changed our minds, so”.
– Unicode.

Many agencies try to work in actual unit testing when possible, but the budget and time constraints frequently make this impossible.

If you’re thinking: “Just don’t tell the client! Bill them whatever it’ll cost with unit testing. Make it your requirement!”

Then you’re either one of the few people that are in such high demand that you can make these demands, turning a project with a budget of $x into one with a budget of $x + $x, or you’ve likely not spent much time doing client work. Either way, you’re a fan of writing tests, so good for you.

Prior to this position, my only experience with unit testing was with Mocha, qUnit, and Jasmine – and for concerns testing bare logic chains – essentially basic mathematical proofs. Those I could do, as the necessary deconstruction is all there for you.

The abstractions used in software development so far are very different, and requires similarly different thinking about the reduction of components when creating tests.

I suck at unit tests. But their value is abundantly clear. Thankfully, I have some coworkers that hate me have been willing to share their experience and help me when needed.

Too much ghost mode == bad

In short, don’t arbitrarily isolate yourself when building something, madly toiling away in a corner, only to emerge weeks later with whatever machination you’ve created.

At agencies, especially in supervisory positions, it’s sometimes a requirement to completely unplug and be unavailable (unless a server is on fire). I say requirement because it can be the only way you’re able to get something done that isn’t tied directly to project management or code reviews. It’s a necessary evil, and something you learn to balance.

In contrast, software development thus far is very hands-off. You’re given the flexibility to create, at your own pace, during the time you know you’re most productive. This is a freedom I wish every coder could know.

But it also introduces a risk of working on something without feedback for way too long. This is bad for any team, of course. For remote teams especially, communication is crucial.

Do you feel you’re way too experienced for this to happen to you?

I’ve talked about this at meetings with teammates, notified developers one-on-one that they need to communicate more, and even was forced to let someone go because of zero regular communication for weeks at a time. So you can imagine my surprise when I realized that was the very first thing I did when building my first product feature. It can slip in quite easily.

If you don’t check yourself, you may or may not find that you’ve wrecked one or more things, including, but not limited to, yourself.

I end with something that has been identical in both career directions: support.

Support is the same: super, super important.

No team gets my praise as much as one that has extreme dedication to their customer/client support efforts.

Both the prior and present companies are the embodiment of this. Documentation, response times, and overall commitment and quality make an unbelievably significant difference with how customers/clients view you, share your stuff with others, and stay with you.

As long as I’m still writing code, I’ll always want to have some connection with the people making use of it.

  1. Or, at least until I think it works.

Author: Rami