Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Work for a Company Not Lead by Finance

DZone's Guide to

Work for a Company Not Lead by Finance

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Disclaimer: this post touches bits and pieces of finance, management and sociology for which I’m far from qualified. However, I’ve plenty of experience working in companies where they had big effects and I couldn’t resist drawing my own conclusions. I’ll happily listen to realistic solutions.

I’ve been working for more than a decade in the software industry, always as a consultant. Most of my employers were pure consulting companies, with only my latest employer being a software provider. During all these years, my customers were traditional companies in various sectors: banking, insurance, telco, public administration, retail, …

Though my work always revolved around software, in various positions, I couldn’t help notice that it could have been much easier if the context had been different. I’m not talking about personal disputes between two persons, or such trivial things, but about pervasive ideas that originate from very up above – most of the time outside the company, and permeate all hierarchy layers in a organised fashion: the closer to upper management, the stronger its presence.

On short-term objectives

Like it or not, most companies are on the stock exchange. Such companies have to legally publish their results on a quarterly basis. To simplify, the better the results, the higher the share value. This tends to promote objectives based on each quarter to increase the latter. This leads to short-term decisions to increase share value that have very definite consequences on the long-term.

Interestingly enough, the GAFA seem to have a whole another strategy, as they aim for the long-term. Google invests massively in bio-technology and self-driven cars, Amazon makes no benefits since its inception and Apple has a tradition of not being really interested in giving its money to shareholders. I guess despite those respective strategies, none of them could be viewed as unsuccessful.

On productivity

Part of our core values is about always doing “better”. This is of course felt in the private sector, but is also ingrained in us as individuals. I ran twice the half-marathon and the second time, I just had to run it faster than the first time. I didn’t think about it, it was just… expected. For vacations also, most of us want to spend better vacations than the year before, even though they might have been the best so far.

If it is so in the personal sphere, what is it like in the professional one? Well, I guess anyone having ever worked knows about it. It’s all about defining metrics, measuring them, then finding ways to improve them in order to improve productivity. This is not bad per se, but there are definitely issues. IMHO, the greatest is the term “productivity” itself. I can understand it when applied to simple basic tasks, but I’ve never heard about judge or policeman productivity. People might comment that the productivity of public service cannot be easily evaluated. Perhaps, but what about the productivity of private jobs such as lawyers? Or engineers?

Trying to measure the productivity of developers is based on the the thinking that they have more in common with manual labourers than engineers.

On the nature of development

Though impossible to measure, different developers definitely have different productivity. For example, when one developer commits a compile error, it impacts the work of all other developers working on the same project. Thus, one developer can have a negative productivity, as it is the case with engineers and lawyers.

In order for one to understand that, one must probably have worked as engineers or with them. Thus, one could in the best of case understood the nature of development work, or in the worst, realized the difference in productivity of different people.

For people who never had a chance to get familiar with engineering work, all engineers are the same. The only difference then would be on the cost of each different one.

On quality

Continuous improvement goes through measurement. Measuring some metrics and not others have definite incidence on behaviour of professionals, as qualities not measured exist in neither retrospectives nor in annual reviews. Engineers pride themselves on delivering quality software. But what is quality? Regarding software, there are two facets of quality:

  • On one hand, external quality can be defined as the gap between implementation and specifications. The highest quality possible is when they are both fully aligned i.e. the software just reflects specifications
  • On the other hand, internal quality is defined as the relative cost to add new features. With the highest internal quality, the cost of adding new features is linear. With the lowest internal quality, the cost of adding new features is so high that it’s les expensive to rewrite the software from scratch.

Internal quality is pretty hard to measure (read, I don’t know about any) since it’s defined as a gap – between the current current cost and the “best” cost. To compute such quality, one would have to do 2 softwares… and it’s not something that is likely to happen. The logical conclusion to this inability is that internal quality is at best vaguely talked about – and at worst completely ignored, while measurable metrics such as costs and planning are focused upon. When any of those start to get threatened, then quality becomes the fifth wheel.

On individual objectives

The agreed upon way to improve – in general and specifically profits, is by defining objectives. Those objectives are agreed by C-levels which in turn dispatch more specifics objectives into their respective departments, and this goes down until the lowest levels of the organisational hierarchy. Management does like that because it acts upon an assumption: in this case, the assumption is that optimising every single place in the organisation will likely improve the organisation as a whole. Interesting, but completely wrong as only the simplest of systems work like this. Systems like human organisations are much more complex, so they have plenty of local optimums: optimising one area probably has negative effect in another.

In one of my previous job, managers/sales persons had no individual incentives. Their bonuses was solely based on the performance of the company as a whole. Some of you might wonder how it could possible. They might even be suspicious that they didn’t go that extra mile to get more money flowing in given there was no incentive. I cannot be the judge of that but what I know is that collaboration was very high and they achieved much in that regard. Besides, there was a very good work atmosphere and much less of the political games seen in traditionally-managed companies.

On Return Over Investment

As an engineer, I always expected a company and all its employees would try to to maximize the benefits of their investments. My experience has been completely different.

A colleague told me the following story: imagine a new bank coming on the market. For a limited time, they propose for every $20 bill you bring to exchange it for a $50 bill. As a company, what’s the budget you should allocate to such a project? $100, $1,000, 100k? The answer is quite easy: as many as you afford as the return over investment is very high, and probably higher than any other project running in the company.

Most companies official policy is to at least describe the expected benefits for a planned project and even better approximate a ROI. Most of the times, business want to push a project based on more or less imaginary assumptions, and the benefits/ROI paragraph is just a nicely wrapping of those.

Conclusion

In Software Development, many seemingly strange (i.e. stupid) decisions happening are the direct results of the conjunction of two or more of the previous points.

  • Outsourcing: those who take decisions to outsource have no clues about development, they think all developers have the same productivity and then why hire a local developer when you can have 3 remote ones for the same price? And of course, development is such a simple process that direct communication has no place in it.
  • No attention to quality: as productivity, when a property is hard to measure, it’s better forgotten. If you add to this the fact that project manager have individual objectives on the budget and the planning, it’s no mystery only engineers that pride themselves about their craft care about quality. Besides, lack of quality only shows in the long-term…
  • Death-march projects: no understanding of software development plus individual objectives

And this might goes on ad nauseam.

What I noticed however is that successful recent technology companies have completely different strategies. For sure, they fully understand software development but it’s not only that. They definitely have long-term plans. Proofs of that include amazon still making no benefits and Google investing in biotech. I’ve never heard any of them trying to measure productivity, but surely they know about differences in developers. They also care about quality… a lot, as they realize it’s an asset which maintenance costs are directly related to quality. Finally, they are not ruled by finance.

I don’t think it’s all about company politics as in the introducing cartoons, as I see everyday people who are genuinely interested in teamwork. However, I believe management focusing on short-term financial KPIs is a dead-end and companies blindly following those old ways are doomed to fail. If you happen to find different ones, I suggest you stick to them.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:

Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}