# Leading Devs In Digital Services

This will be part 2 in a small series of relatively unfiltered/poorly structured writing on the topic

# Performance

Dev performance is a really challenging topic. I'm not sure if divisive is the correct word for it, but there are a lot of different opinions out there around what's the correct way to do it, and a lot of those opinions are very much in conflict with one another. One thing that I do see somewhat consistently is that everything should be focused entirely on outcomes. Now, I agree with this in principle because results are what matter in the end. The issue with that is that results are the ultimate of trailing indicator of performance problems, and the general kind of consensus that I see out there in the market chatter is that devs should be held accountable only to their own estimates on a certain task. Before going deeper here, let's take a quick look at the business structures here.

# The Contracts and Value Proposition

When you're doing digital services work, depending on the type of contracts that you're getting, you're looking at one of three major classifications: Time and Materials, Fixed Scope/Fixed Cost, and Scope Controlled/Budget Constrained. I'm not going to go in to these here, but effectively Fixed Scope/Fixed Cost is the most risky for digital services firms because it says "we'll deliver X for Y money" and if you miss delivering X on time, or on budget, that's too bad for you. You're obligated to deliver, and that starts eating in to your margins or your sustaining capital. To de-risk this situaton, you have to do a lot of upfront planning (often billable) followed by detailed work breakdowns and estimates, and finally pull in all of your fixed costs to calculate the expected and worst cases for delivery, put a margin on it, then present it to the customer. Sticker shock on these projects is super real. When you're competing with the low cost places that contract works out of Vietnam, India, or the Phillipines, it's easy to lose a lot of business to these firms. Yea, sure, the bitterness of low quality remains long after the sweetness of low price fades, but as noted in the previous post, they've also got speed. Having to worry about your devs stacking on their own heavy padding, it's a recipe for being out of business.

Time and Materials contracts are inviting a devil to come sit on your shoulder. Devs say that delivering a responsive table is gonna take two weeks? Sure, why not. 2 weeks! Now you're going to stretch this simple CRUD mobile application from something that would be an MVP in 3 weeks from a reasonably competent backend dev + mobile dev + designer, even a single fullstack Flutter/React Native dev + designer, to 5 man-month (or person-months if you prefer) saga. Maybe the client will be okay with it, maybe you'll be fighting a war on two fronts with devs saying "I need more time" on one side and the client saying "You're cheating me on the hours to pad billings!" on the other. Well, you're the one with the devil sitting there on your shoulder whispering "relax, the estimate isn't bad, and besides, we need the cash flow".

Scope Controlled/Budget Constrained contracts are more involved but have you committing to milestones on the iteration cycle with clear demos at the end of each one, then you dive in to how you and your team think you can deliver the most value for the client with the remaining budget. The challenge here is more involvement from the client. The benefit is massive de-risking as your commitments are for the iteration, and you cover that ground at the time if you start lagging. The estimates should get better as you're getting to know the application with each iteration, and the feedback loop is tighter.

# Contracts Aren't Performance...aren't they?

Well, if you're time and materials, not managing to get good performance (speed of implementation, quality of code, for the price) out of people will paint you as a cheat. You charge premium prices for work that is far too slow for what the customer gets for their money. If you're on Fixed Cost/Fixed Budget, you're going to either not get business in the first place because your prices are too high, or you're going to be constantly losing money/margin (and eventually business) because you're not delivering on time and have to make up for it on your dime. Company performance is delivery on the contracts. That's driven by developer performance.

Coming back to the developer game, an estimate is something that is easily gamed in to getting some fractional percent of a person's possible sustainable output, and the rates that you pay out are for the agreement that you're getting that 100%. One roll through Hacker News, the Over Employment subreddit, and some loose lips after a couple of beers, and you can see that while that is not a massive percentage of developers, it's certainly enough to warrant caution. It doesn't even have to be malicious as Tim Cain (opens new window) talks a bit about estimation inflation in his two part series here. 4 weeks for a reasonably levelled agency in a high CoL country is between $20,000 - $28,000 USD. That's a $20,000 feature! That can't possibly be reasonable. Many people will argue that you need to push back on those estimates, but many still will laud the fact that they're giving their estimates and then the lead or EM are taking that "2 days" and then saying "3 days". Even if the feature was really well done, it might not even matter.

So...how do we measure dev performance? Bug rates per hour of development? Regression rates? Commit frequency? PRs per iteration? It's all gameable, and gaming those numbers causes issues that can undermine your firm's ability to deliver. Is dev performance a quantam property? Observing it changes its nature? Spot pair programming can be a good method in my opinion, but it's not without its own pitfalls. It can be seen as micromanagement, you might actually lower performance if you're not close to the level of the person you're pairing with, and too much of it can be seen negatively as micromanagement.

Dev: "There are no metrics by which you can measure my performance"
Lead: "Ok, so you're not performing then."
Dev: "By what metrics?!"

One of the better things that I've seen is that you do actually measure all of the "garbage" metrics, quietly, and then use them as indicators to get in deep with someone and do a more holistic review of their performance at that time. The iteration cycle on these things will likely be necessarily long, but I'm definitely short on a lot of great ideas beyond non-delivery or blown milestones versus trying to do it yourself and use that as a gauge for it.

# Short Note On Process

Beyond that, there is all of the process that comes with supporting projects. There is advice from the Stay SaaSy Blog (opens new window) about not putting too much process in the mix and focus on velocity.

Process in a digital agency needs to ensure that all of the customer's contracted requirements are met to keep you out of legal and immediate financial trouble, facilitate the development of those requirements to a level of quality that the customer is satisfied with, developed within a timeframe that is reasonable and agreed upon, and meets the expectations of the client that need to be managed by either the development team or the project manager. Forgetting things doesn't just roll in to the next sprint or passed off as a "yea, no worries, didn't need that". Depending on the contract, missing something is non-performance.

Consistency here is better than inconsistency because you're not just a single product or project, you're a whole heap of them (if you're lucky). Sometimes you bend to accommodate a client's process if you're in a kind of team augmentation agreement, but if you're doing end-to-end development, you're going to want to have something smooth and consistent so you can move between projects with relatively minimal jank between them. Notions set up like a grocery store, consistent repo set ups (as it makes sense), consistent ticketing (as it makes sense) and estimation process, and consistent reporting expectations (by setting client expectations) will all provide the best foundation to build performant developers on.

In the next part I'll expand on performance...

Authored by: Mal
Written: 2023-11-21