15 Tipps für ein leichteres Berufsleben

Das Arbeitsleben in unserer Zukunft ist an sich bereits aufregend und herausfordernd, wir müssen es uns nicht noch schwerer machen, indem wir uns ungeschickt anstellen. Im Folgenden haben wir eine Reihe von Tipps gesammelt, die, unserer Erfahrung nach, das Berufsleben entspannter verlaufen lassen und dich (ggf. sogar darüber hinaus) weiter kommen lassen.

1. Ziele und Zielerreichung

• Was willst du tun und lernen?
• Worin bist du gut?
• Was willst du eigentlich erreichen?

Beantworte dir diese Fragen. Wie das am Besten geht, haben andere besser beschrieben, als ich das könnte.

Was ich hier sagen will ist, dass das, was du beruflich tust, sich in deinen Antworten wiederfinden sollte (und sei es nur als absehbares Ergebnis nach einer Durststrecke mit Tätigkeiten, die halt getan werden müssen).

Wenn du das, was du gerade tust, eigentlich gar nicht tun willst und auch nicht zielführend für dich ist, habe den Mut, etwas zu ändern oder Veränderungen in der absehbaren Zukunft anzusprechen.

2. Das Wichtige tun

Ein Zitat von Peter Drucker (Pionier der modernen Management-Lehre), vorweg:

"Stellen Sie sich immer wieder die Frage: Arbeite ich auch an den wichtigsten Dingen?"

• Was für dich wichtig ist, ist natürlich umstandsabhängig. Im Tagesgeschäft kommen andere Dinge bei heraus, als bei der Karriereplanung. Das ist OK. Auch der zeitliche Rahmen und damit die Häufigkeit, in der man sich obige Frage stellen muss, sind hier verschieden. Selbst nach Feierabend bleibt diese Frage bestehen, nur sind die Ziele hier oft andere.

• Die wichtigsten Dinge können den Umständen geschuldet sein, familiäre Verpflichtungen, Hilfe im Freundeskreis, ehrenamtliches Engagement, aber natürlich auch die eigenen Ziele. Aber was auch immer das Ziel ist, ist das, was ich gerade dafür tue, wirklich so zielführend und der größtmögliche Hebel? Wenn ich mich in (noch) nicht wichtigen Details verliere, mag sich das gut anfühlen (und wenn Lernen und Verstehen mein Ziel ist, dann sind diese Details doch wichtig), aber wenn ich dem eigentlichen Ziel mit anderen Arbeiten schneller näher kommen könnte, sollte ich mich diesen widmen:

• Meine Master-Arbeit sollte ich endlich abzugeben, anstelle zu versuchen, wochenlang noch daran zu feilen, was mir Lebenszeit und -Kraft raubt und doch nicht meine Note nennenswert verbessert.

• Netzwerken (s.u.) kann mich meiner Beförderung sehr viel näher bringen, als noch etwas besseren Code im stillen Kämmerlein zu schreiben.

• Einen Schritt gedanklich zurück zu treten und das Design meiner Software nochmal zu überdenken, kann sie besser machen, als einen weiteren Prozentpunkt Testabdeckung zu erreichen.

• Welche Features helfen/nptzen am meisten und von welchen sollte ich meinen Product Owner eher abbringen?

• Quäle ich mich beim alleine-Üben an meinem Musikinstrument, wo ich mich doch eigentlich darum kümmern sollte, mit anderen auf eine Bühne zu kommen?

• Spare ich durch genaueres Messen meines Stromverbrauches in meinem Smart Home wirklich Energie?

• Zocke ich nur gegen Computergegner und hätte doch mehr Spaß, wenn ich mich traute, gegen andere Menschen anzutreten?

• Reden wir im Meeting nur im Kreis? Sollten wir nicht zusammenfassen, Aufgaben verteilen und Schluss machen?

• Hilft mir diese Vorlesung / dieser Kurs wirklich, ist sie wenigstens unterhaltsam, oder wieso besuche ich sie überhaupt?

• Wenn ich erschöpft bin, ist es besser, mich zu erholen oder zumindest was ganz anderes zu tun, um später frisch und effizienter weiterzumachen.

3. Gehe den Dingen auf den Grund

Blicke unter die Haube. Das ist kein Widerspruch zum vorherigen Punkt. Versuche nicht nur, eine Aufgabe irgendwie schnellstmöglich fertig zu bekommen (zumindest, wenn du weiterhin an solchen Aufgaben arbeiten wirst).

Wenn du Web-Anwendungen programmierst, schau dir zumindest die Grundlagen von CSS wie Selektoren an und verlasse dich nicht nur auf dass, was deine Widget-Bibliothek dir bietet. Wenn du mit einer relationalen DB zu tun hast, lerne SQL (JOINs und Indizes) und verlasse dich nicht nur auf deinen ORM wie Hibernate. Wenn du mit Kafka zu tun hast, lerne dessen grundsätzlichen Aufbau. Was macht dieses Kubernetes eigentlich, in dem deine Anwendung läuft? Was ist eigentlich Docker bzw. ein Container?

Verstehe die Konzepte dahinter, dann kannst du die Details bei Bedarf lernen, ersparst dir aber auf dem Weg viel Frust.

Am Anfang wird man eher mit dem "richtig bauen" zu tun haben und umsetzen, was andere sich ausgedacht haben (solange das eigentliche Programmieren nicht vollständig von einer KI übernommen wird, aber so weit sind wir noch nicht). Lerne dabei, hinterfrage, denke mit. Verstehe, wieso du etwas so und so umsetzt. Hinweis: "Die Klara hat mir das so gesagt" ist nicht die Antwort, mit der du lernst. Wieso wurde eine Entscheidung getroffen?

Wieso diese Datenbank, dieser API-Aufbau? Wenige Lösungen sind für alle Probleme gut, versuche also zu verstehen, was genau diese Lösung hier so passend macht. Nebenbei: Wenn diese Gründe bislang nicht aufgeschrieben waren, hole das nach. Hilft allen. Stichwort "Architecture Decision Record".

Du wirst Ahnung von der fachlichen Materie erlangen und kannst mitreden. Mitreden ist Gestaltungsmacht, gibt dir größere Hebel als nur die Umsetzung in die Hand und das lässt sich auch karrieretechnisch gut verkaufen.

Wer dich beauftragt, will letztlich nicht Code, sondern gelöste Probleme oder neue Chancen. Code ist nur Mittel zum Zweck. Besser, du merkst im vorhinein, dass eine Programmieraufgabe eigentlich unnütz ist oder das Problem anders besser gelöst werden kann. Was uns wieder zum Punkt "Das Wichtige tun" bringt.

4. Blick über den Tellerrand

Versuche, über Blogs, soziale Netzwerke, Newsletter o.ä. zu sehen, was in deiner Berufsparte über deinen konkreten Arbeitsplatz hinaus geschieht. Ordne gehypete Dinge für dich ein, versuche zu verstehen, welche Probleme sie wie lösen und was sie toll macht. Seien es neue Web-Frameworks, Datenbanken, Programmiersprachen, ML-Bibliotheken, Vorgehensweisen, Werkzeuge, KIs.

Beschränke dich dabei, du kannst nicht allem hinterherlaufen oder es gar ausprobieren (zum echten Ausprobieren sollte es mehr als ein "hello world" oder "docker run" sein).

5. Weiterbildung

Ob du für den Arbeitsmarkt relevant bleibst, ist deine ureigene Verantwortung. Nicht die deiner Vorgesetzten oder die der Personalabteilung. Du musst aktiv werden, wenn du das Gefühl hast, du lernst nicht mehr weiter. Rede mit anderen darüber.

Vielleicht lernst du dazu, ohne, dass es dir bewusst ist. Ja, die alte Delphi-Anwendung interessiert niemanden, aber wie du jemandem seine Anforderungen entlocken und sie gut strukturieren kannst, ist auch anderswo Gold wert.

Wenn du tatsächlich immer im selben Saft kochst und bei der Arbeit nichts dazu lernst, ruft das, bzw. rufe du nach Veränderung in deinen Aufgaben.

• Übernimm Frontend-Aufgaben, wenn du vorher mehr auf Serverseite unterwegs warst.

• Bring den Build auf Vordermann. Hilf den vernachlässigten Tests auf die Sprünge.

• Schnapp dir einen Profiler und finde heraus, wieso die Anwendung manchmal so träge ist.

• Ist das Anmeldeverfahren für eure Anwendung eigentlich noch sicher? Müsst ihr überhaupt ein eigenes Anmeldeverfahren haben?

• Wie tickt eigentlich die verwendete Datenbank? (s.o.)

• Sitzt ihr eure Meetings nur ab und eigentlich mag sie keiner?

• Kannst du die Fachabteilung öfters zur Klärung anrufen? Selten bleibt es bei einem Thema und du bekommst einen breiteren fachlichen Blick und siehst neue Möglichkeiten.

• Könntest du die Benutzerführung verbessern?

• Gib dein Wissen weiter, halte (interne) Vorträge, werde Mentor:in

Eine Weiterbildung für eine neue Rolle ist super. Technische Weiterbildungen ohne Aussicht auf Anwendung sehe ich kritischer, ich zumindest vergesse den Inhalt dann zu schnell. Eine Zertifizierung als Ziel kann hier schon Fokus schaffen.

6. Denk an dein Zukunfts-Ich auch abseits der Weiterbildung

Wenn du etwas programmierst, sollte dir klar sein, was du tust. Wenn nicht, hör auf zu coden und kläre das. Und dann schreibe deinen Code so, dass du ihn in einem halben Jahr noch verstehen kannst. Auch wenn du "schon irgendwie wieder reinkommen wirst", wird es dich ausbremsen, andere werden es noch schwerer haben. Hinrotzen ist nur OK, wenn klar ist, dass der Code keine 6 Monate leben wird (weil du gerade was ausprobierst oder eine Einmalaktion ansteht).

Über den Code hinaus: Was hast du dir gedacht? Schreib das auf. Und halte dich daran bzw. passe die Beschreibung an, wenn ihr Inhalt doch nicht so gut ist.

7. Feierabend

Schalte ab nach getaner Arbeit oder wenn du das Gefühl, du hast dich verbissen. Schalte, wenn du es vermeiden kannst, nicht gleich was neues an. Zugegeben, ein Fahrtweg zur Arbeit erzwingt das, im Homeoffice fällt bei mir diese Abklingzeit leicht unter den Tisch. Gönne sie dir (wenn möglich).

Bonus: Gute Ideen kommen mir oft erst auf dem Nachhauseweg oder beim Zähneputzen. Weil ich davor eben nicht mehr am Durch-Ackern war sondern geistig losgelassen habe und mein Unterbewusstes am Werk ist.

8. Tue Gutes und rede darüber

Wenn du einfach nur im stillen Kämmerlein gute Arbeit leistest und darauf wartest, dass das endlich bemerkt wird und du befördert wirst, dann kannst du das lange tun. Die anderen um dich herum werden hauptsächlich sich und ihre Aufgaben im Blick haben und nicht dich und du verkümmerst, wenn du nicht wirklich Glück mit deinen Vorgesetzten hast.

Wissen die Leute, die über deine Beförderungen und Gehaltserhöhungen entscheiden, davon, was du tolles geleistet hast? Bist du allen, die über dich entscheiden, überhaupt ein Begriff (Networking!)? Weißt du 6 Monate später noch, was du tolles geleistet hast oder ist das schon unter einem Berg neuer Dinge vergraben?

Schreib auf, worauf du stolz sein kannst oder was du an Aufgaben (nicht Tickets) gelöst hast. In welchen Rollen hast du dazugelernt und was geschafft? Hast du komplizierte Gespräche gut geführt? Wem hast du was beigebracht?

Wenn dich Selbstzweifel packen, schau dir diese Liste an - und nicht Kollegin Xenia und was sie alles tolles leistet.

Sorge auch dafür, dass gute Leistungen anderer nicht unbemerkt bleiben. Bedanke dich für gute Ideen, Hilfe oder gelöste Probleme (wenn sie dir geholfen haben) oder nenne einfach die Quelle einer guten Idee/Leistung, wenn ihr darüber sprecht (z.B. im Daily Standup). Lobe andere auch vor deinen/deren Vorgesetzten.

9. Hilfsbereitschaft

Bitte um Hilfe, bevor du Tage alleine versenkst.

Biete deine Hilfe an, wenn du andere beim Tage-Versenken ertappst.

Auch wenn du keine Ahnung hast, lass dir deren Problem erklären. Oft wirst du ihnen alleine dadurch helfen, in dem du ihnen ermöglichst, mal einen Schritt zurück zu treten.

Wenn du Ahnung hast, hilf auch! Hilf ihnen, sich selber zu helfen, aber mache nicht deren Arbeit für sie.

Wenn das Helfen überhand nimmt, dann hast du den anderen was voraus. Sorge dafür, dass auch deine Vorgesetzten deine Stärken im Coachen und Befähigen sehen und wertschätzen und dir nicht ankreiden, dass du weniger Tickets umgesetzt hast.

10. “Nein” sagen

Lass dich nicht mit Arbeit überschütten! Wenn du eh nicht alles schaffen kannst, wer hat einen Nutzen davon, dass du nickst und “OK” sagst und dabei mehr vorgaukelst, als du schaffen kannst? Bei einem frühen “nein” kann der/die andere noch umplanen, bei einem späten nicht.

Wenn du selber die Entscheidungsbefugnis hast: Sage nein, wenn du Wichtigeres zu tun hast und du deshalb keine Zeit für den erbetenen Gefallen hast.

Wenn du “plötzlich” Wichtigeres tun sollst, dann musst du auch vorherige Zusagen auflösen. Ist ja nicht deine Entscheidung, dass “von oben” was wichtigeres kam. Niemand will so einen Rückzieher hören, aber was hilft das? Soll dieser jemand halt eskalieren (das könnt ihr auch gemeinsam tun und “oben” um Rücksprache und Prioritätsklärung bitten, du musst ja nicht “ätsch, doch nicht” sagen).

Wenn du abhängig beschäftigt bist, ist deine Arbeitszeit begrenzt und das muss deinen Vorgesetzten klar sein. Wir müssen uns nicht ausbeuten lassen. Wenn Geld, Lernmöglichkeiten, Sinn oder Spaß gegeben sind, können wir natürlich stundenmäßig reinkloppen, aber in der Softwareentwicklung haben wir den Luxus, dazu nicht gezwungen zu sein! Spieleentwicklung ohne "crunch time" vor dem Release ist eher ungewöhnlich, so etwas muss man von vorneherein bewusst in Kauf nehmen, aber sich nicht einfach nachträglich ohne Not aufdrücken lassen.

11. Professionelles Verhalten

"Wie du von anderen behandelt werden willst, so behandle sie!"

Sei freundlich und hilfsbereit. Bleibe sachlich und zielorientiert. Sei verlässlich.

“Sei du selbst” gilt im Arbeitsleben als Angestellte(r) nur eingeschränkt. Du trägst (in Teilen) eine Maske und verhältst dich anders, als privat. Du bist nicht nur Programmierer(in) im Team Y für Firma X, sondern auch ein Mensch mit Feierabend und eigenem Leben. Deshalb musst dich gefühlsmäßig auf der Arbeit nicht voll rein hängen und dich von den Reaktionen deiner Kolleg:innen abhängig machen. Arbeit ist Arbeit, aber nicht dein ganzes Leben. Arbeit ist begrenzt. Und weil Vorkommnisse auf der Arbeit dich nicht im Kern betreffen, kannst du auch freundlich bleiben, selbst wenn du eigentlich voll genervt sein könntest.

Auf der Arbeit wirst du auch mit Leuten (oder für sie) arbeiten, um die du privat einen Bogen machen würdest. Hier gilt genauso: freundlich und konstruktiv bleiben. Wenn ein Gespräch in eine unangenehme Richtung entgleitet, bringe es wieder auf das eigentliche Arbeitsthema zurück (deswegen, und aus deiner Sicht nur deswegend) redet ihr miteinander. Aber weil ihr deswegen miteinander redet, gehe solchen Gesprächen nicht aus dem Weg

12. Kritisieren

Sachlich bleiben. Nicht unnötig an die große Glocke hängen, “Paul hat die Anforderung nicht kapiert” laut im Sprint-Review zu verkünden ist schlechter Stil. Wenn dir das vorher schon auffiel, sprich mit Paul direkt, bevor er weiter Zeit braucht. Tust du das nicht, bist du "mitschuldig" und hast mindestens mal kein Recht, dich über ihn zu erheben. Eine Chance, dein Team/Unternehmen voranzubringen, hast du damit vertan. Paul wird sich dann auch nicht vor anderen für deine Hilfe bedanken.

Wenn Pauls Arbeit dich direkt betrifft und aus deiner Sicht in die falsche Richtung geht und ihr keine Einigung untereinander erzielt, sprich diese Abweichung von deinem und seinem Verständnis in einem größeren Kreis (ggf. Projektleitung) an. Außerdem: Vielleicht hast ja auch du was falsch verstanden, also nicht gleich vor anderen anklagen. Wenn seine Arbeit dich nicht betrifft, lass locker. Sein Problem, du hast dich gemeldet, er wollte es nicht hören, sein Pech.

13. Kritisiert werden

Wir Menschen haben das Bedürfnis, uns bei Kritik gleich verteidigen zu wollen. Aber wie können wir uns gegen unverstandene Kritik, gefühlt als Anschuldigungen, ohne Nachdenken sinnvoll verteidigen? Geschweige denn, daraus etwas lernen?

Durchatmen. Bis drei zählen. Anhören und verstehen, was die andere Seite meint. Nicht in Gedanken gleich eine Verteidigungsrede formulieren. Verstehen. Nachfragen. Ja, das fällt auch mir schwer.

Wenn das Gegenüber verallgemeinert, “immer” und “nie” sagt: nach konkreten Begebenheiten fragen. Meistens kommt dann schon nicht mehr viel und dem Gegenüber geht die Puste aus.

Dann im Kopf bewerten, hat die andere Seite Recht (ganz oder in Teilen)? Wo sieht er nur eine Seite vom Ergebnis?

Schätze ein, wie mein Gegenüber zu mir steht? Will er/sie mir helfen? Wenn ja, toll. Gemeinsam aus einer, vielleicht nicht so gut gelaufenden Situation, lernen ist besser, als alleine. Aufforderungen zur Besserung, ausgesprochen aus fremdem Mund, lassen sich weniger leicht beiseite wischen, als gute eigene Vorsätze. Sei dankbar und erörtert gemeinsam, was du daraus lernen und ändern kannst.

Du musst dich nicht vor jedem rechtfertigen, aber du musst immer lernbereit sein. Du kannst oft eine Sache auch mitnehmen und ankündigen, Tags darauf mit konkreten Vorschlägen kommen. Oft hilft auch ein “Danke, dass du mir das gesagt hast, ich denke darüber nach.” ohne enthaltene Verpflichtung, etwas zu tun. Lass den anderen seine Kritik loswerden, oft ist dessen "Zorn" dann verraucht.

Gänzlich falsche Anschuldigungen musst du natürlich nicht stehen lassen.

Wenn du in einer Art Gerichtssituation bist, dann verteidige dich. Gib auch Fehler zu! Wenn dir daraus ein Strick gedreht wird, dann ist das nicht dein Fehler. Eine Kultur, in der Fehler nicht offen eingestanden werden können und wo sie nicht als Lernmöglichkeit begriffen werden, sorgt für Vertuschung anstelle für Verbesserung. Willst du Teil davon sein?

14. Neid und Rivalität im Team

Sollte es einen informellen Wettstreit im Team um eine Rolle geben, denke dir “die Welt (der Softwareentwicklung) ist groß genug für alle”. Du bist nicht darauf angewiesen, besser dazustehen als andere (Fokus auf den Vergleich zu anderen, du selbst solltest dein Bestes geben). Wenn du gut bist und trotzdem nicht zum Zuge kommst: Es gibt auch andere Teams und letztlich auch andere Unternehmen. Sprich mit deinen Vorgesetzten über Entwicklungsmöglichkeiten, ggf. klar abgesteckte Themen/Verantwortlichkeiten (dann ohne gegenseitige “Konkurrenz”) oder einen Teamwechsel.

Wichtig: Mache dich nicht fertig und grummle nicht über den anderen! Sollte das Unternehmen dich dauerhaft ausbremsen, hat es dich nicht verdient. Aber dass da noch jemand anderes aufstiegwillig ist, soll dich nicht stören, du willst es ja auch!

15. Klare, ausdrückliche Erwartungen

Von der Chefin

Was erwartet deine Chefin von dir? Frage sie!

Wenn es um Beförderungen oder Gehaltserhöhungen geht: Frage, was du dafür zeigen/lernen/können musst. Du wirst selten einen formalen Katalog bekommen und selbst wenn, wird der noch viel Auslegungsspielraum enthalten. Aber dennoch weißt du dann hoffentlich, was was du in nächster Zukunft achten musst.

Widerspruch der Erwartungen vom Chef zur alltäglichen Arbeit

Wenn deine alltäglichen (Projekt-)Aufgaben dir nicht helfen, den Erwartungen vom Chef für ein berufliches Weiterkommen gerecht zu werden, schlucke das nicht herunter und warte auf bessere Zeiten, sondern sprich es aktiv an. Beschwere dich in konstruktiven Worten über diesen Zwiespalt und finde eine gemeinsame Lösung. Seien es angepasste Erwartungen oder geänderte Aufgaben (ggf. auch erst in der Zukunft, aber dann bitte mit klar überprüfbarer Eintrittsbedingung (Zeit oder nächster Projektauftrag)).

Vom Kunden

Baue das, was der Kunde will, nicht, was du meinst, dass der Kunde es will. Und was er will, muss er dir sagen. Meiner Erfahrung nach geht sowas schriftlich nicht sonderlich gut, sondern muss in einem Gespräch geklärt werden. Wenn du durch Beratung helfen kannst, dass jemand etwas besseres/passenderes will, super!

Und danach schreibst/zeichnest du es als Gedächtnisstütze auf und fragst nach, ob dein Gegenüber das auch so verstanden hat.

In der Vorbereitung dein Verständnis aufzuzeichnen, wird eine große Hilfe für das Gespräch darstellen. Selbst UML-Squenzdiagramme können Wunder tun, wenn du auf Schritt 16 verweisen kannst und diesen Schritt nicht immer neu (in wahrscheinlich nicht immer gleichen Worten) beschreiben musst.

Von der Kollegin / an die Kollegin

Was in einer Auftragsbeziehung gilt, gilt auch in informellen Absprachen mit Gleichrangigen untereinander im Team. Sprich deine Erwartungen klar aus und hoffe nicht vergeblich, dass deine Kollegin deine Gedanken liest. Lerne aus Missverständnissen und frage lieber einmal zu viel als einmal zu wenig nach.

Schlussworte

Ich hoffe, dass dir obige Tipps weiterhelfen. Wenn du anderer Meinung bist oder dir bestimmte Punkte fehlen, lass es uns wissen.