Impulses for organisations – Part 1

As a social media user, I come across numerous impulses from experts who address different topics within organisations or discuss aspects of the work. Since many of these impulses are “fleeting” on social media and difficult to find after a short time, I would like to “showcase” individual contributions here on the t2informatik blog. Since I want to do this from time to time from now on, this is the beginning of a series with organisational impulses.

Part 1 of the series is about pricing, effort estimation and experiential knowledge. Axel Rammlmair addresses value pricing, Martin Möhle discusses effort estimation that doesn’t work and Michael Küsters debates the need for development knowledge among Agile Coaches. Let’s go!

Value pricing doesn’t work for us because …

… our clients don’t know the value that our service generates for them!

In fact, customers often have no idea how much a service or the solution to a problem would be worth to them. This is not even necessary to do value pricing.

The variant “We get 20 cents of every euro you save or make more” is a very striking variant of value pricing, but it is rather rare in practice. Many services do not save costs or bring in more revenue, but rather

• increase security,
• improve customer and employee satisfaction,
• boost the image,
• increase productivity and avoid errors,
• make processes faster and more robust, etc.

“Creative minds” like to try to put a euro amount around these improvements via two corners and abstract key figures. For example, converting higher employee satisfaction into lower recruiting costs or salary savings. But most clients don’t go along with that and dissect these calculations in the blink of an eye.

Which doesn’t matter to us, because value pricing means that I align my price in such a way that it is a good deal for my client (read: the value is significantly higher than the price). So it’s enough if I know that the value for the customer is certainly above what I’m charging. Whether that is 30% more or 30 times more is secondary and a question of optimisation.

The important point: what plays no role in value pricing are the costs. As long as they are below the sales price, it doesn’t matter whether the costs make up 80 % of the price or 8 % or 0.8 %.

The big step towards value pricing therefore does not take place at the customer’s, but in one’s own head – at the moment when one replaces

“How high does the price have to be so that we still make a reasonable profit after deducting our costs?” with

“What value do we have to generate for whom so that we get the money we would like to have?”.

Sounds easy, but it is not. But those who want to multiply their profits may find it worth taking the bumpy road.

Martin Moehle²:

Software development: Why effort estimates don’t work

Trying to specify and measure the entire software development process in advance degrades developers to machines that are supposed to push predictable results through a pipeline on an assembly line.

But mathematical calculations are only possible to a limited extent here. People are not machines. To believe that one can accurately estimate the complexity of a non-trivial software development task in advance is a fallacy.

Software development is a field in which many things are constantly changing rapidly. Many of the challenges developers face are new and unknown. And even the known challenges are subject to change. In other words, last week’s performance is a poor indicator of next week’s performance.

So how could things be different? In the ideal world, people would agree on a common task, embrace the shared vision and then work as a team to develop quality software – without having to predict how long it will take and how much it will cost. However, such an approach is hardly practicable in a business environment because there are budgets and timetables.

Should Agile Coaches have a development background?

1. It helps.
2. Every experience is valuable.
3. You can ask deeper questions.
4. They uncover further improvements.
5. Agile coaching is about helping people discover better ways: If people don’t know there are better ways, someone has to recognise that.
6. In a Scrum context, the Scrum Master (also a coach) is “responsible for the effectiveness of the team”. This requires an awareness of technical barriers to performance.
7. If you have ever worked as a developer, you will empathise differently.

If you are a coach and have no development experience:

1. If this is not a problem for you or your team/organisation.
2. If it is a problem for you, just grab a cup of coffee, bring some snacks, sit next to a developer and say, “Congratulations, I’m your intern now. Teach me.”
3. If it’s a problem for your team and they feel you can’t give them the support they need, address it openly. If they really need a technical coach, you may be more valuable elsewhere.
4. If it’s a problem for your company because the problems are at a technical level, you should get more training.

What about me? Do I respect non-technical coaches?

I don’t like this dichotomy to begin with. It is not an either-or situation. If the coach shows curiosity, openness and a willingness to learn and develop, even on technical issues, then that is commendable. Nobody knows everything. Not even me. I have other blind spots.

But – when they aggressively talk about how developers are just easily replaceable fools with no special skills, that programming is a trivial task that is beneath them, and that Agile Coaching is so much more important than what developers do, then I have zero respect.

Impulses and questions

Three different topics, three different experts, three individual impulses. Could value pricing be interesting for your business model and if so, what is still preventing you from applying it? Do you calculate efforts in the development of solutions? How can you solve the dilemma of budgets and time schedules on the one hand and insufficient effort estimates on the other? And last but not least: Do you pay attention to technical knowledge when employing Agile Coaches and if not, how do the colleagues involved act in situations where corresponding expertise would be useful?

Questions upon questions. Maybe you have one or two; great! Then “Impulses for organisations” has achieved its goal.

Notes:

If you like the article or want to discuss it, feel free to share it with your network.

[1] Alex Rammlmair is a podcaster and expert on value pricing, as well as the author of Das Ende der Tagessätze – Die besten Preisstrategien für IT-Unternehmen, die skalieren wollen. Information about Alex Rammlmair can be found on his impressiv website, the original impulse can be found on LinkedIn.

[2] Martin Moehle is Sales Director DACH at Billennium, a global provider of IT services and solutions. Information about Martin Moehle can be found in his LinkedIn profile, the impulse, which refers to an arcticle in Computerwoche, can be found here in the original on LinkedIn.
[3] Michael Kuesters sees himself as a thought provoker, works as an executive coach for organisational change for Intelygence and blogs under the motto Fail fast, move on. Information about Michael Kuesters can be found in his LinkedIn profile, the impulse can be found in the orginal on LinkedIn here.

Michael Schenkel has published other articles in the t2informatik blog, including

What does t2informatik actually do? One click and you'll know.