Die fünf Fragen, die jeder Aufsichtsrat seinem CTO stellen sollte
Wer Technologie beurteilen will, braucht kein zweites Studium. Er braucht fünf Fragen — und die Geduld, auf der Antwort zu bestehen.
Die häufigste Ausrede dafür, Technologie im Gremium nicht zu hinterfragen, lautet: „Davon verstehe ich zu wenig.“ Das ist verständlich und in der Sache falsch. Die nützlichsten Fragen an einen CTO sind keine technischen Fragen.
Sie sind unternehmerische Fragen, deren Antwort technisches Wissen voraussetzt. Der Unterschied ist entscheidend: Sie müssen die Antwort nicht selbst herleiten können, Sie müssen nur erkennen, ob eine gegeben wurde. Fünf Fragen genügen dafür — und sie eint, dass man sie nicht mit einer Folie beantworten kann.
Die fünf Fragen
-
Was in unserem System würde uns am meisten weh tun, wenn es morgen ausfällt — und wie lange dauert die Wiederherstellung?
Die Frage zwingt zur Priorisierung und prüft zugleich, ob jemand den Ernstfall je durchgespielt hat. Eine gute Antwort nennt ein konkretes Teilsystem und eine Zeitspanne, die aus einer Wiederherstellung stammt, nicht aus einer Schätzung.
-
Welche technische Entscheidung von vor drei Jahren würden Sie heute anders treffen?
Sie fragen nach Urteilsvermögen, nicht nach Fehlern. Wer keine einzige Entscheidung revidieren würde, hat entweder nichts entschieden oder reflektiert nicht öffentlich. Beides ist eine Information.
-
Wer außer Ihnen kann das erklären?
Die direkteste Messung des größten Risikos in technisch getriebenen Unternehmen. Antworten Sie nicht auf die Zahl, sondern auf das Zögern davor. Wenn dieselbe Person mehrfach genannt wird, kennen Sie Ihr Klumpenrisiko.
-
Was davon läuft heute bei einem zahlenden Kunden in Produktion?
Die Frage trennt Fertiges von Geplantem — die Grenze, die in Präsentationen am zuverlässigsten verschwimmt. Zulässig ist jede Antwort, unzulässig ist eine, die die Grenze nicht zieht.
-
Was würde es kosten, das nicht zu tun?
Jeder Antrag begründet, was eine Investition bringt. Interessanter ist der Preis des Unterlassens, denn er zeigt, ob es sich um eine Notwendigkeit oder um einen Wunsch handelt. Wenn er nicht beziffert werden kann, ist es meistens ein Wunsch.
Wie man die Antworten liest
Auf die Fragen kommt es weniger an als auf das, was Sie mit den Antworten machen. Drei Muster helfen:
Eine Zahl schlägt ein Adjektiv. „Sehr robust“ ist keine Antwort auf Frage 1. „Vier Stunden, zuletzt im März getürmt“ ist eine, auch wenn die Zahl unangenehm ist.
Ein Beispiel schlägt ein Prinzip. Wer auf Frage 2 mit einer Haltung antwortet („wir setzen konsequent auf offene Standards“), hat ausgewichen. Wer eine konkrete Entscheidung nennt und sagt, was sie gekostet hat, hat geantwortet.
Nachfragen ist kein Misstrauen. Die zweite Nachfrage — „und was heißt das für uns?“ — ist die eigentlich wirksame. Ein guter CTO wird sie begrüßen, weil sie ihm Raum gibt, ein Problem zu benennen, das er ohnehin schon kennt.
Was die Fragen nicht leisten
Sie ersetzen keine Prüfung. Vor einer Investition, einer Übernahme oder einer Nachfolge braucht es eine Technologie-Due-Diligence, und die übersteigt das, was in einer Sitzung erfragt werden kann. Was die fünf Fragen leisten, ist etwas anderes und im Alltag Wichtigeres: Sie verhindern, dass ein Gremium ein Jahr lang zustimmend nickt, ohne je erfahren zu haben, wie es um das System steht, von dem das Unternehmen lebt.
Und sie kosten nichts außer der Bereitschaft, eine Antwort nicht gelten zu lassen, die keine ist.
The most common excuse for not questioning technology at board level is: “I don't understand enough about it.” That is understandable, and it is wrong. The most useful questions to put to a CTO are not technical questions.
They are business questions whose answers require technical knowledge. The distinction matters: you do not need to be able to derive the answer yourself, you only need to recognise whether one was given. Five questions are enough — and what they have in common is that none of them can be answered with a slide.
The five questions
-
What part of our system would hurt us most if it failed tomorrow — and how long would recovery take?
The question forces a priority and at the same time tests whether anyone has ever rehearsed the emergency. A good answer names a specific subsystem and a timeframe that comes from an actual recovery, not from an estimate.
-
Which technical decision from three years ago would you make differently today?
You are asking about judgement, not about mistakes. Someone who would revise no decision at all has either decided nothing or does not reflect out loud. Either is information.
-
Who besides you can explain this?
The most direct measure of the largest risk in technically driven companies. Listen less to the number than to the hesitation before it. If the same person is named repeatedly, you have found your concentration risk.
-
Which of this runs in production today at a paying customer?
The question separates the finished from the planned — the line that blurs most reliably in presentations. Any answer is acceptable; one that fails to draw the line is not.
-
What would it cost not to do this?
Every proposal explains what an investment will bring. The more revealing figure is the price of leaving it undone, because it shows whether this is a necessity or a wish. If it cannot be quantified, it is usually a wish.
How to read the answers
The questions matter less than what you do with the answers. Three patterns help:
A number beats an adjective. “Very robust” is not an answer to question 1. “Four hours, most recently in March” is one, even when the number is uncomfortable.
An example beats a principle. Anyone answering question 2 with a stance (“we are consistently committed to open standards”) has evaded it. Anyone who names a specific decision and says what it cost has answered.
Following up is not distrust. The second question — “and what does that mean for us?” — is the one that actually works. A good CTO will welcome it, because it gives him room to name a problem he is already aware of.
What the questions do not do
They do not replace an assessment. Ahead of an investment, an acquisition or a succession you need a technology due diligence, and that goes beyond what can be asked in a meeting. What the five questions do is something else, and in day-to-day terms more important: they stop a board from nodding along for a year without ever learning the state of the system the company lives on.
And they cost nothing beyond the willingness to refuse an answer that isn't one.