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 whereThe 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 featuresqa writes acceptance test for features
developer receives/estimates/completes featuresAt 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.
© Jay Fields - www.jayfields.com