Follow-up Thoughts on Aligning Business & Programmer Goals

My recent entry on Aligning Business & Programmer Goals led to an email conversation that I thought might be worth sharing.

From A. Nonymous:

I have an issue with tying bonuses to performance due to, basically, performance being out of the programmer's hands. Where I'm working right now developers are treated as code monkeys: We're there to implement features the business people dream up, and nothing more. How could I provide more value when I work in an environment where

• The visual design phase has already happened (no pushback on any design elements taken seriously)
• The business development phase has already happened (i.e. the business decides to create a new service tells it's code monkeys: "we need feature x, y, and z")
• The individual projects we're working on is out of our control.

I can't figure out how to tie what I do to business value in the short term (or even in the year-long-term), because I don't have the autonomy to work on things that I think would benefit the business. I'm forced to do the work that someone else assigns me. Are the new features/bug fixes creating value? Definitely. How much value? Not a clue. How can the value I bring be measured? The only metric I'm seeing is "ease of implementing the next new feature", but the next feature that touches the code I wrote probably won't be developed for months, if not years.

So, it doesn't seem justified to assign me a bonus based on the value that features create, when I have no control over the features.

My response:

Given your context, I wouldn't want a bonus either. I imagine that many people are in the same situation... probably most people.

2 notes-

• The blog entry isn't solely about bonuses, the ending is all about a visible P&L and nothing about a bonus. I hope people don't completely miss that point.
• While your position is status quo, I think we should strive to do better as an industry. I don't think it's healthy that we (programmers in general, not necessarily you or me) work for organizations where we know little about the business, don't trust our business counterparts, and are not trusted by our business counterparts. Programmers are often ruthless about measurement and improvement, and wasting that effort on resume driven development or process tweaks is bad for our businesses and our reputations.

It's easy for me to say that the good programmers should quit companies that don't expose a P&L and don't empower their programmers, but I know that personal situations can limit people's choices. At the same time, I feel good about continuing to write about the path that I take, which includes quitting companies that I don't feel are aligned. Even if my ideas can't help you at this point; hopefully, something will come of them in the future.

A. Nonymous followed up with:

I totally get the visible P&L part and agree with you on it. Having more visibility into the inner workings of the business can only help focus effort where it's important. Not every business leader feels that way, unfortunately. I'm currently fighting with my boss about a similar issue. I alluded to it before, but he wants to follow what many consultancies are now calling "Agile":

• analyst meets with business team
• analyst comes up with features
• qa writes acceptance test for features
• developer receives/estimates/completes features

At no point in this process does the developer have any contact with the business team.

Do you have any idea how I'd go about convincing upper management that sharing the P&L would be a good idea?

And, my final response:

I've never seen studies on the impact of sharing the P&L. Most of the discussion around this stuff is still in it's infancy as far as I can tell. Brian Goetz has been talking about 'language & framework introduction' for awhile, but I've never heard it combined with P&L.

I would attack your situation in one of the two following ways-

• Fully support your boss' plan, but request to be put on a 'research' or 'experimental' team where you interact directly with the business on a new product (assuming that's possible). I've done this successfully. The rest of IT followed the traditional approach that your boss is proposing, but I broke off with 1 PM and we worked directly with the business on technology for new business lines. I never got to see P&L (though, I never asked), but I would get requirements and deliver features on demand and we ended up constantly impressing the business. e.g. "business: How quickly can you deliver this? (I start thinking of my estimate) business: August? me: (shocked, it was March) I was thinking in the next 2 weeks. -- that conversation actually happened, I'll never forget it. If you get this approved, your boss still gets to do what he wants, and you get to try to do better. If you succeed, he can take the credit for approving the experiment - win/win.
• Assuming you cannot find a way to interact with the business, focus all your efforts on reducing the delivery cycle. If he's going to force the team to be basically skilled labor, you need to deliver at a rapid enough pace that you fail quickly and pivot toward profitable business goals. You build, they point you in a better direction, you build, they point you in a better direction, on and on. Your 'interaction' with the business is delivering them software, and you will benefit from doing that as often as possible. So, focus on things like choosing the best tools for the job, getting the build time down, reducing the test running time, etc, etc. Anything that's slowing you down from delivering faster, it's in your best interest to remove that, so you can get the business feedback as fast as possible. Even if your boss forced you to only do a roll-out monthly (or worse), the more you have to roll-out, the more feedback you'll get - so removing any thing that takes your time and isn't contributing to feature delivery. Dan Bodart is doing interesting stuff with build times and you should be able to find plenty of advice on speeding up tests - attack that stuff so you deliver as much to the business as possible.

While A. Nonymous may never get to see the P&L, and may never be in a situation where we would want a bonus - there are steps that can be taken to align the business & the programmers.

Aligning Business & Programmer Goals

A theme emerged, last week at speakerconf, around the idea that programmers and businesses still don't seem to be on the same page. I'm not sure if it came up even earlier, but for me it began after I gave a presentation on Lessons Learned Adopting Clojure. The talk is similar to Lessons Learned while Introducing a New Programming Language, but focuses more on the technical aspects of selecting Clojure. Upon talk completion the first question I got was from Brian Goetz, something along the lines of:

(Brian) So, you wanted to use another language and simply introduced it into production?
(me) More or less.
(Brian) Do you think that's the most effective way for organizations to select languages or frameworks?

The first response to the question was the obvious and appropriate one:

That sounds better than a CTO making a decision while drunk and on a golf-course with a vendor. -- Josh Graham

Of course, I agree with that response, but that doesn't mean that my choice was the best answer either. The question is actually something I've been struggling with for awhile. At speakerconf Aruba 2011, Lyle (DRW CTO) gave a presentation on how we do things at DRW. One of Lyle's slides listed each language that we use in production at DRW. There were a lot of languages, probably around 25, and Dave Thomas questioned whether it was a positive or a maintenance nightmare. The answer today is the same as it was then, so far the ROI is positive - but, I couldn't help feeling uneasy about the situation.

I answered somewhat noncommittally, along the lines of: While selecting a language, I chose one that I felt anyone in DRW could easily learn and use. Additionally, I selected a language that aligned with our business goals of developing software quickly and delivering applications that performed at the speeds required by the traders. And, if not the man on the ground, who is better suited for selecting languages to introduce into production?

Brian followed up with:

The point I was trying to get at was: how does this scale? If every developer chooses what is best for them, is that necessarily best for the organization? How do we balance between the business value of increasing individual productivity and the business value of reducing maintenance costs or development risk? If we have to make compromises to achieve better scale, who should make these decisions, and how?

The usual developer argument -- "this is more productive for me, and increasing my productivity is good for the company" is good as far as it goes, but most developers incorrectly assume these interests are 100% aligned when they are in reality probably only merely overlapping.

These are truly great questions, and no one had a great response. The discussion basically died off as we pondered the tough answers to these questions.

At lunch the next day I asked Brian how he thought companies should go about selecting languages, and I think his response was spot-on (again, going from memory, so likely misquoting): I'm not sure, but I sure do see a lot of developers introducing whatever language or framework they want, leaving within a year, and sticking their employer with a big maintenance problem. The same can be said for consultants. They often show up advocating a sexy new language, mostly deliver a new application and then leave the company with an application that can't be maintained by the existing full-time staff.

Someone quickly spoke up, stating that Resume Driven Development has been going on for years. I can't argue with that, but I did have a different perspective.

A few years ago I joined DRW, and a substantial portion of my salary became bonus money. I had previously worked in places where getting bonus money was about as likely as meeting your future wife at a JavaOne, so I was obviously skeptical. Luckily, I had a friend who already worked for DRW; he reassured me that, in finance, having a bonus as part of your compensation was common, and so was it actually getting paid. I took the job, and instantly my performance at work was more directly tied to my income. I'm sure this reality influenced my decision making, and I witnessed the difference in the decisions my colleagues were making. When people spoke about using/upgrading frameworks/libraries, we didn't talk about what was cool, we discussed the risks of breaking things, the outstanding bugs with the framework/lib, and the immediate value that the inclusion would provide.

Given this experience, I advocated to the other speakerconf presenters that bonuses are a potential solution to combatting Resume Driven Development. The other speakerconf presenters gave me the same response I generally get when advocating bonuses for programmers: That works for you and your trading firm, but most people can't directly tie what they do to how the business makes money. I'm always skeptical of this response for 2 reasons: The business must be able to track whether or not their new idea is making them money, or, if the new software isn't targeted to an external customer, then it should be able to be rated by internal customers. Also, shouldn't the CTO or the Director of Software be able to make an informed bonus decision by either directly interacting with the teams, or trusting the feedback of the managers of those teams?

I guess, if you can't tie what you are doing to the value it's providing the company, and you don't trust your managers to give an accurate assessment, building your resume is probably the best use of your time... and the results aren't very surprising... but, I digress.

I gave the same response I've given a few dozen times: I just don't buy it. You should be able to see how many new customers your new website generated, or less cancellations, new reservations, policy efficiency, auction traffic, add-on sales purchased, etc. Each of the projects I've worked on for the past 8 years could generate metrics that I would have been happy to tie to a bonus. In our back-office, it's harder to tie the value of a back office system to an individual trade; however, we can capture metrics on uptime, latency, and any other attribute that we deem important to the internal systems that are customers of the back office systems.

If you want to measure your value and you trust your management, receiving part of your salary as a bonus is completely viable.

Aligning the goals of the business and the programmers came up again when the afternoon presentations began. Joshua Kerievsky is looking to tackle this same issue at Industrial Logic. Joshua's presentation discussed bridging the gap between managers and programmers, which is a more general version of the same conversation we'd been having about language adoption. Bridging this gap is something he's begun focusing on at Industrial Logic. The benefits are obvious for customers, they should receive higher quality and more relevant software. However, it's not just about customers, the programmers will be more effective and should also have higher job satisfaction rates. No one likes being stuck on yet another, doomed to fail, misguided project using outdated technology. Both parties should benefit by unifying the goals of the programmer and the business.

Josh knew my opinion on using bonuses to help align both parties; however, he and I both incorrectly assumed that the developers at Forward also received business performance based bonuses. I believe that they have some things in the works and situations can vary, but Fred George made it clear that in general a bonus is not tied to business focus. That's fairly standard, but what makes Forward unique is that the business works very, very closely with the programmers. I think Fred nicely summed up the situation: Our programmers are gamers, and we show them the P&L. They want to see that number grow, even if it doesn't directly deposit in their account.

Fred's statement rang very true to me. I've had jobs in the past where I didn't even have a bonus, but the ones that I felt most dedicated to were the ones where I was given visibility into the business. If I can't see the outcome of my programming choices to the business, I'll have a much harder time iterating towards success - worse, I won't even know at what level we are failing and I'll lack the motivation that the failure would provide me.

At the end of the day, programmers like to measure and improve. If you give them a P&L and let them know that it's the most important thing, they'll do whatever they can to help. If you don't give them a P&L they'll focus on making other metrics more efficient. This may include using new technologies to inspire more blog entires, spending hours unnecessarily tweaking the development process, or any other way of measuring their "success." The answer is obvious, let the programmers measure success the same way the business does, using the bottom line. What's not always obvious is how to properly share that information; however, all the discussion at speakerconf definitely convinced me that it's worth solving this issue even if it requires a bit of extra effort.