paint-brush
Proaktiewe IT-loopbaangroei: Neem beheer oor jou professionele reisdeur@ekaterinaandreeva
Nuwe geskiedenis

Proaktiewe IT-loopbaangroei: Neem beheer oor jou professionele reis

deur Ekaterina15m2025/02/15
Read on Terminal Reader

Te lank; Om te lees

Daar is baie goeie artikels oor moontlike loopbaanspore wat jy in IT kan volg. Ek het nie baie gesien wat as werklike leiding gebruik kan word om op die loopbaanleer te beweeg nie. In byna enige min of meer volwasse IT-maatskappy is 'n algemene loopbaanbaan vir 'n sagteware-ingenieur lineêr. Die verdere loopbaanbaan sal afhang van jou neigings, wat jy geniet om te doen en of jy gereed is vir die verskuiwing in die manier waarop jy werk.
featured image - Proaktiewe IT-loopbaangroei: Neem beheer oor jou professionele reis
Ekaterina HackerNoon profile picture
0-item

Daar is baie goeie artikels oor moontlike loopbaanspore wat jy in IT kan volg, maar ek het nie baie gesien wat as werklike leiding gebruik kan word om op die loopbaanleer te beweeg nie.


Tans werk ek in 'n maatskappy wat baie duidelike vereistes het vir die ingenieurs se bevordering en wat gebruik kan word as voldoende bewys van voldoening aan daardie vereistes. 'n Kombinasie van hierdie twee faktore het my die idee gegee dat bykomende inligting oor hierdie onderwerp ander ingenieurs wat in diens is van maatskappye wat dit nie het nie, kan help om 'n strategie te bou wat hulle in staat sal stel om na die volgende vlak te kom.


In byna enige min of meer volwasse IT-maatskappy is 'n algemene loopbaanbaan vir 'n sagteware-ingenieur lineêr en lyk amper dieselfde:

Associate Software Engineer is opsioneel en mag of mag nie in die algemene IT-afdelingstruktuur aangebied word vir 'n baie eenvoudige rede: dit is netto negatief vir die eerste 12 maande, aangesien dit baie handvashou verg, so nie alle maatskappye het hulpbronne en tyd om sulke poste in hul struktuur toe te laat nie.


Die verdere loopbaanbaan sal afhang van jou neigings, wat jy geniet om te doen en of jy gereed is vir die verskuiwing in die manier waarop jy werk.


Daar is niks verkeerd daarmee om 'n senior sagteware-ingenieur te bly as jy die meeste van jou tyd aan kodering wil toewys nie. As jy egter die behoefte voel om ander te bemagtig en te lei, is dit die regte oomblik om alle verwagtinge vir elke rol, jou sterkpunte, die dinge wat jou dryf, op te weeg en die geskikste pad vir jouself te kies.


Ten spyte van die visuele eenvoud van die snitte hierbo, is dit nie duidelik hoe om nader aan die regterkant te kom nie. Die volgende insigte sal van toepassing wees op die maatskappye wat:

  • 'n hiërargiese struktuur waar elke werkgewer 'n lynbestuurder het
  • 'n opregte belangstelling in werknemerontwikkeling


Hoekom is bogenoemde belangrik? Die antwoord is redelik eenvoudig: van dag een af het jy 'n bondgenoot - jou lynbestuurder .


Elke lynbestuurder se doeltreffendheid is gebaseer op die uitset van elke persoon wat aan hulle rapporteer: hoe vinniger jy groei - hoe groter jou uitset - hoe beter is die lynbestuurder se doeltreffendheid. Gegewe dit alles, vroeër of later, nadat jy by jou maatskappy aangesluit het, sal jou lynbestuurder jou nader met die vraag: "Waar sien jy jouself na 'n sekere tyd?" As dit nie gebeur nie en jy het gereelde een-tot-een, voeg dit gerus by as 'n onderwerp vir bespreking in die agenda.


Om jou voornemens uit te druk en 'n doelwit te stel, is net die eerste stap van jou pad. Die volgende stap is om die lys van vereistes vir die hoër rol bymekaar te maak en 'n lys van prestasies saam te stel wat as bewys van jou kwalifikasies kan dien wat jy kan gebruik as 'n gids wat jy moet volg om van punt A tot punt B te kom. In maatskappye met deursigtige bevorderingsprosesse behoort dit reeds in plek te wees.


As dit nie die geval is nie, kan jy en jou bestuurder een saamstel. Onthou dat hierdie proses voordelig is vir beide kante: jy kry 'n ooreenkoms dat jy ná sekere prestasies geprys sal word met die bevordering en jou lynbestuurder kan verhoogde uitset van die span kry, so dit is 'n wen-wen geval.


Verskillende maatskappye kan verskillende vereistes vir sekere posisies hê, en ek sal nie beweer dat die onderstaande universeel is en almal sal pas nie. Die hoofdoel is om vir jou 'n idee te gee wat dit kan lyk as jy een nodig het wat verder aangepas kan word vir jou behoeftes.


Riglyne vir bewyse kan gebruik word as 'n padkaart wat jou na die verlangde bestemming bring. Die volgende stappe vir die gemeenskaplike spoor kan wees

  • Gaan die span se padkaart na vir geskikte projekte of veranderingsversoeke wat dalk by die doel van die bewyse pas.


  • Spreek jou voornemens aan die lynbestuurder uit sodat hulle kan help met die geskikte projektoewysing en inligting verskaf oor die prioriteit daarvan, besigheidswaarde en wanneer dit vir ontwikkeling opgetel kan word.


  • Sien enige potensiële gebiede vir verbetering in kode, waarneembaarheid, uitbreidbaarheid en sekuriteitsperspektiewe op en verhoog dit as eienaarskapkaartjies.


  • Vergewis uself van die huidige werwingsproses in u onderneming en vra vir skaduwee tydens werwingsessies. Vra om rolle te verander waar iemand meer senior jou sal skadu en vra vir terugvoer.

    Hierdie is 'n kort lys van die rolle wat gedek sal word uit vereistes/riglyne vir bewysperspektiewe:


    Gemeenskaplike spoor

    • Junior Sagteware Ingenieur Vereistes
    • Sagteware-ingenieur Vereistes
    • Senior Sagteware Ingenieur Vereistes


    Ingenieursbaan

    • Hoofingenieurvereistes

    • Senior Ingenieurshoofvereistes


    Bestuursbaan

    • Ingenieursbestuurder
    • Ingenieursdirekteur

Junior Sagteware Ingenieur Vereistes

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Lewer take
· Duidelike vereistes word benodig (besigheid en stelsel)
· Ontwerp/implementeer beperkte-omvang tegniese oplossings
· Beperkte leiding word vereis

1. Lys van take voltooi
o Take moet kompleks genoeg wees om dit te noem
o Spertye word nagekom
o Geen groot kwaliteit probleme nie
o Take is voltooi met geen handhouding nie
2. Insette van die lynbestuurder wat bevestig dat aan al die vereistes voldoen word.

Kwaliteit

Pas beste praktyke toe
· Leer en pas voortdurend beste praktyke toe
· Vaardig met verskeie dev gereedskap
· Ondersoek en maak ingewikkelde probleme/foute reg

Terugvoer van die lynbestuurder en eweknieë wat bevestig dat aan al die vereistes voldoen word.


Sagteware-ingenieur Vereistes

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Lewer veranderingsversoeke (kenmerke)
· Neem besigheidsvereistes as insette
· Verdeel werk in take met 'n voldoende vlak van detail oor die oplossing (wat gedoen moet word en wanneer dit klaar is) en die implementering (hoe dit gedoen moet word)
· Verskaf akkurate skattings op 'n taak-/gebruikerstorievlak
· Koppel met ander ingenieurs om vinniger af te lewer

Lys van veranderingsversoeke wat gelewer is, wat aan die volgende vereistes voldoen:
1. Die veranderingsversoek is volledig afgelewer en die sperdatum is nagekom.
2. Die ontdekkingsdeel is deur die werknemer voltooi (kaartjies, skattings).
3. Die veranderingsversoek is kompleks genoeg vanuit 'n tegniese perspektief (meer as 2 manweke vir 1 ingenieur om dit te implementeer).
4. Die veranderingsversoek verskaf 'n betekenisvolle impak op die besigheid.
5. Die veranderingsversoek word deur die besigheid afgeteken en loop in produksie.
6. Die werknemer het 'n voldoende vlak van outonomie en kwaliteit getoon (gebaseer op die terugvoer van die tegnologieleier en die ingenieursbestuurder).

Stelsel ontwerp

Ontwerp dienste
· Ontwerp en implementeer kleiner dienste met inagneming van al die nie-funksionele aspekte (uitbreidbaarheid, sekuriteit, waarneembaarheid, ens.)
· Skryf hoëgehalte-kode met volle aanvaarding van ingenieurspraktyke en -metodologieë
· Neem deel aan kode-oorsig om beste praktyke af te dwing
· Los die hoofoorsake agter foute en probleme wat ondervind word

Ten minste twee dienste wat ontwerp is om aan die volgende vereistes te voldoen:
1. Dit kan 'n nuwe diens of 'n volledige herontwerp van die bestaande diens wees.
2. Dit kan 'n selfstandige diens, 'n biblioteek of 'n komponent wees wat deur ander dienste verbruik word.
3. Die diens behoort nie onbenullig te wees vanuit 'n ontwerpperspektief nie.
4. Die ingenieur moes die formele ontwerpproses gevolg het:
· Verkry besigheids- en stelselvereistes
· Identifiseer die begrensde konteks
· Identifiseer nie-funksionele vereistes
· Breek konteks af in dienste
· Kry terugvoer oor die oplossing
· Implementeer dit
5. Diens is geïmplementeer en loop in produksie.


Senior sagteware-ingenieur

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Lewer projekfases (epiese)
· Neem vereistes en hoëvlakstelselontwerp as insette
· Skep stelselontwerp vir die diens of die komponent, besluit oor die tegnologieë en ingenieurspraktyke wat gebruik moet word
· Breek werk op in take of gebruikersstories met 'n voldoende vlak van detail oor die oplossing (wat gedoen moet word en wanneer dit klaar is) en die implementering (hoe dit gedoen moet word)
· Verskaf akkurate skattings op taak-/gebruikersverhaalvlak
· Lei 'n klein span om die omvang te lewer
· Ontblokkeer hul span, los probleme op en verwyder hindernisse

Lys van projekfases/epiese gelewer, wat aan die volgende vereistes voldoen:
1. Die epiese/projekfase is volledig afgelewer en die sperdatum is nagekom.
2. Die ontdekkingsdeel is deur die werknemer voltooi (kaartjies, skattings).
3. Die epiese/projekfase is kompleks genoeg vanuit 'n tegniese perspektief (benodig ten minste 2 ingenieurs vir >= 2 weke).
4. Die epiese/projekfase bied 'n betekenisvolle impak op die besigheid.
5. Die funksionaliteit word deur die besigheid afgeteken en loop in produksie.
6. Die werknemer het 'n voldoende vlak van outonomie en kwaliteit getoon (gebaseer op die terugvoer van die tegnologieleier en ingenieursbestuurder).
7. Die ingenieur het as tegniese leiding aan die implementering deelgeneem.

Stelsel ontwerp

Ontwerp substelsels
· Dit is dieselfde as vir 'n sagteware-ingenieur, maar fokus op meer komplekse dienste of substelsels
· Vaardig in die ontwerp en implementering van die wolk en verspreide stelsels

Ten minste 3 dienste wat ontwerp is om aan die volgende vereistes te voldoen:
1. Dit kan 'n nuwe diens of 'n volledige herontwerp van die bestaande diens wees.
2. Dit kan 'n selfstandige diens, 'n biblioteek of 'n komponent wees wat deur ander dienste verbruik word.
3. Die diens behoort nie onbenullig te wees vanuit 'n ontwerpperspektief nie.
4. Die ingenieur moes die formele ontwerpproses gevolg het:
a. Verkry besigheids- en stelselvereistes
b. Identifiseer begrensde konteks
c. Identifiseer nie-funksionele vereistes
d. Breek konteks af in dienste
e. Kry terugvoer oor die oplossing
f. Implementeer dit
5. Diens is geïmplementeer en loop in produksie.

Ry veranderinge

Stel veranderinge voor
· Bevraagteken die status quo en die aannames wat gemaak word
· Soek maniere om die platform, prosesse, werksomgewing en die tegnologiespan in die algemeen te verbeter

Ten minste drie beduidende veranderinge is voorgestel, wat enige van die volgende kan wees:
1. Funksionaliteit: 'n veranderingsversoek voorgestel wat geprioritiseer en geïmplementeer is (veranderingsversoek moet wesenlik genoeg wees om as 'n verandering beskou te word, nie 'n kosmetiese verandering nie).
2. Mense: 'n onderhoud met 'n ingenieur gevoer wat aangestel is en proeftydperk geslaag het (junior sagteware-ingenieur of hoër, beskou as 'n verandering aan die span).
3. Eienaarskap: 'n eienaarskapprojek voorgestel (ingesluit in die eienaarskappadkaart, goedgekeur deur CTO).



Hoofingenieurvereistes

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Tegniese leier vir projekte (projekvoorstelle)
· Neem besigheidsvereistes as insette
· Vind die mees effektiewe oplossing vir die besigheidsprobleem (navors alternatiewe, valideer oplossings deur gebruik te maak van geen-kode/lae-kode benaderings)
· Skep stelselontwerp vir die nuwe diens of substelsel, besluit oor die tegnologieë en ingenieurspraktyke wat gebruik moet word
· Breek werk op in eposse met 'n voldoende vlak van detail oor die oplossing (wat gedoen moet word en wanneer dit klaar is) en die implementering (hoe dit gedoen moet word)
· Verskaf akkurate skattings op projekvlak, verbind tot datums
· Tree op as 'n tegniese leier vir die hele projek
· Ontblokkeer hul span, los probleme op en verwyder hindernisse
· Bestuur tegnologie, implementering en operasionele risiko's

Lys van projekte wat gelewer is, wat aan die volgende vereistes voldoen:
1. Die oplossing vir die probleem is deur die werknemer voorgestel en dit word as doeltreffend beskou. Dws veelvuldige alternatiewe is geëvalueer, en die beste alternatief is gekies op grond van die lae-kode/geen-kode validering.
2. Die ontdekkingsdeel is deur die werknemer voltooi (kaartjies, skattings).
3. Die oplossing is deur die werknemer gebou.
4. Die projek moet 'n "kenmerk"-projek wees wat deur 'n projekvoorstel geïnisieer word.
5. Die ingenieur het as 'n tegniese leiding aan die implementering deelgeneem (sien vereisteskolom vir meer besonderhede).

Ry veranderinge

Ry tegniese veranderinge (span)
· Stel inisiatiewe voor en implementeer om stelselkwaliteit te verbeter en tegniese skuld te verminder
· Stel veranderinge voor en implementeer om ontwikkelaarervaring en produktiwiteit te verbeter
· Bepleit en dwing skoon kode en skoon argitektuur af

Lys van groot veranderinge wat ingestel is (gewoonlik ten minste vier), wat aan die volgende vereistes voldoen:
1. Die verandering bied betekenisvolle verbetering aan stelselkwaliteit (bv. platformverbeterings), ontwikkelaarervaring of ontwikkelaarproduktiwiteit. Die verandering raak die hele span.
2. Die ingenieur hoef nie die een te wees wat die verandering voorgestel het nie. Die ingenieur moet die primêre dryfveer agter die verandering wees (bv. ontwerp, as 'n tegniese leier opgetree, aan die implementering deelgeneem). Die verandering kan deur 'n ingenieur of as 'n spanpoging gelewer word.
3. Die verandering moet ten volle geïmplementeer en gebruik word deur die span/platform (die verandering moet "taai" wees en genoeg waarde bied om dit te behou).
4. Die verandering moet betekenisvol genoeg wees om op te noem.

Mense

Mentor
· Mentors en ondersteun minder ervare ingenieurs
· Voer tegniese onderhoude effektief
· Dien as 'n "magneet" vir groot ingenieurs tydens aanstelling (wees 'n deurslaggewende faktor waar ons in kompetisie is vir goeie talent teenoor 'n ander maatskappy)

Moontlike bewyse:
1. Ingenieurs ondervra, wat aangestel is en het proeftydperk geslaag.
2. Terugvoer van opgeleide ingenieurs.
3. Opleidingsessies word georganiseer/gelewer vir die hele tegnologiespan (bv. Tech Sync, Engineering Dojo).
4. Wanneer 'n werkgroep gelei word, kan 'n lys van veranderings voorgestel/geïmplementeer in die bestek van die werkgroep as bewys gebruik word.


Senior Ingenieurshoof

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Tegniese leier vir komplekse projekte (projekvoorstelle)
Dieselfde as hoofingenieur, maar fokus op probleme wat kompleks is vanuit tegniese, organisatoriese of besigheidsperspektiewe
· Die projek vereis koördinering oor verskeie groepe
· Die projek behels derdeparty-tegnologieverskaffer of belanghebbende (bv. vennootskap)
· 'n nuwe produk bou terwyl die produk in die ontdekkingsmodus is
· hoë prioriteit/dringende projek met vaste spertye en baie onbekend

Lys van projekte wat gelewer is, wat aan die volgende vereistes voldoen:
1. Die projek word as kompleks beskou (sien voorbeelde aan die linkerkant).
2. Die projek is ten volle gelewer (alle aflewerbares + DoD) en die sperdatum is nagekom.
3. Die oplossing vir die probleem is deur die werknemer voorgestel en dit word as doeltreffend beskou (dws veelvuldige alternatiewe is geëvalueer, en die beste alternatief is gekies op grond van die lae-kode/geen-kode validering).
4. Die ontdekkingsdeel is deur die werknemer voltooi (stelselvereistes, kaartjies, skattings).
5. Die oplossing is deur die werknemer gebou. Die projek het 'n hoë kompleksiteit vanuit 'n stelselontwerpperspektief.
6. 'n Ingenieur het as tegniese leier aan die implementering deelgeneem.

Ry veranderinge

Bestuur tegniese veranderinge (tegnologie)
· Dieselfde as E5 maar op tegnologiese vlak
· Stelseleienaar vir ten minste een nie-funksionele aspek (bv. sekuriteit, waarneembaarheid, ens.).

Lys van groot veranderinge wat ingestel is (gewoonlik ten minste 4), wat aan die volgende vereistes voldoen:
1. Die verandering bied betekenisvolle verbetering aan stelselkwaliteit (bv. platformverbeterings), ontwikkelaarervaring of ontwikkelaarproduktiwiteit. Die verandering raak verskeie groepe (bv. tegnologie-aanneming).
2. Die ingenieur hoef nie die een te wees wat die verandering voorgestel het nie. Die ingenieur moet die primêre dryfveer agter die verandering wees (bv. ontwerp, as 'n tegniese leier opgetree, aan die implementering deelgeneem). Die verandering self kan deur 'n ingenieur of as 'n spanpoging gelewer word.
3. Die verandering moet ten volle geïmplementeer en deur veelvuldige groepe gebruik word (veranderinge moet "taai" wees en genoeg waarde bied om dit te behou).
4. Die verandering moet betekenisvol genoeg wees om op te noem. Dit moet op die "komende projekte"-bladsy nagespoor word as 'n eienaarskapprojek (eienaarskap in hierdie konteks beteken veranderinge aan die platform, gereedskap, prosesse, ens, nie net platformverwante veranderinge nie).
5. Ten minste 2 veranderinge moet verband hou met die nie-funksionele aspek wat deur die individu besit word.

Mense

Erkende kenner
· Erkende kundige binne 'n gegewe gebied van kundigheid op maatskappyvlak, tree op as 'n tegniese kontakpunt in tegnologie binne hul gebied van kundigheid
· Monitor tendense/tegnologieë binne die gebied van kundigheid en kommunikeer opdaterings en bevindinge
· Deel kundigheid aktief en gereeld met ander ingenieurs (werkswinkels, tegnologiepraatjies, opleiding)
· Fasiliteer samewerking om oplossings vir komplekse probleme te vind (werkgroepe, ens.)
· Voer tegniese onderhoude effektief
· Mentors en ondersteun minder ervare ingenieurs, lei hul loopbaan vanuit 'n professionele ontwikkelingsperspektief
· Dien as 'n "magneet" vir groot ingenieurs tydens aanstelling (wees 'n deurslaggewende faktor waar ons in kompetisie is vir goeie talent teenoor 'n ander maatskappy)

Moontlike bewyse:
1. Onderhoude gevoer met ingenieurs, wat aangestel is en proeftydperk geslaag het.
2. Terugvoer van opgeleide ingenieurs.
3. Opleidingsessies word georganiseer/gelewer vir die hele tegnologiespan (bv. Tech Sync, Engineering Dojo).
4. Onder leiding van 'n werkgroep, kan 'n lys van veranderings voorgestel/geïmplementeer in die bestek van die werkgroep as bewys gebruik word.


Ingenieursbestuurder

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Lewer span padkaart
· Lei 'n groep van 3-6 ingenieurs
· Tree op as 'n projekbestuurder vir verskeie gelyktydige inisiatiewe
· In staat om resultate te lewer met slegs besigheidsvereistes as insette (in staat om stelselvereistes te skep en af te teken)
· Fokus op besigheidsimpak, gedryf deur besigheidswaarde
· Kommunikeer verbintenisse, status en risiko's aan sakebelanghebbendes
· Verseker dat alle spanlede al die inligting het wat hulle benodig
· Kommunikeer met 3de partye binne die bestek van inisiatiewe/eienaarskap
· Vind die regte balans tussen kenmerklewering en stelselkwaliteit
· Alle vereistes vir Senior Sagteware-ingenieur

Nuwe projekte gelewer deur die span wat aan die volgende vereistes voldoen:
1. Projek geïnisieer deur 'n projekvoorstel.
2. Die projek het aan sy impakmaatstawwe voldoen, en die openbare verbintenis is nagekom.
3. Projekte wat in die vorige bevorderingsiklus aangemeld is, kan nie by die lys ingesluit word nie.

Produktiwiteit

Dryf aan bestuursveranderinge (span)
· Meet en verbeter voortdurend spanprestasie
· Identifiseer en vestig beste praktyke binne die span met 'n fokus op produktiwiteit
· Handhaaf hoë kwaliteit van aflewering
· Verseker deursigtigheid oor vordering, risiko's, resultate

1. Groep produktiwiteit (prestasie) metrieke waardes.
2. Groot veranderinge (minstens 4) ingestel, wat aan die volgende vereistes voldoen:
a. Dit los 'n probleem op wat verband hou met die groep of stam wat besit word, die probleem moet by die TOP 5 probleme ingesluit word en met die lynbestuurder ooreengekom word.
b. Die verandering moet ten volle geïmplementeer en deur die span gebruik word (verandering moet "taai" wees en genoeg waarde bied om dit te behou).
c. Die verandering moet betekenisvolle verbetering aan produktiwiteit, betrokkenheid of kwaliteit van aflewering verskaf.
d. Die bestuurder hoef nie die een te wees wat die verandering voorgestel het nie. Die EM moet die primêre dryfkrag agter die verandering wees. Die verandering kan deur 'n ingenieur of as 'n spanpoging gelewer word.

Mense

Lynbestuurder (>=3 direkte verslae)
· Bestuur 3-6 direkte verslae
· Lei ingenieurs af en ondersteun hulle
· Ondersteun en lei loopbaanvorderings
· Versoen meningsverskille en help om konflikte te bestuur en op te los
· Moedig 'n positiewe spankultuur en samewerking aan

1. Squad betrokkenheid metrieke waardes.
2. Lys van ingenieurs wat aangestel is en proeftydperk geslaag het (kan oorgeslaan word as ons nie aanstel nie, EM moet 'n huurbestuurder wees).


Ingenieursdirekteur

Gebied

Vereistes

Riglyne vir bewyse

Aflewering

Lewer padkaart vir verskeie spanne
· Verseker aflewering oor 2-3 spanne
· Vervul die rol van Ingenieursbestuurder in een van die spanne
· Besit vennootskappe met derde partye
· Alle vereistes van die Ingenieursbestuurder

Nuwe projekte gelewer deur die spanne wat aan die volgende vereistes voldoen:
1. Projek geïnisieer deur 'n projekvoorstel (nie 'n BAU-aktiwiteit nie).
2. Die projek het aan sy impakmaatstawwe voldoen en die openbare verbintenis is nagekom.
3. Projekresultate is as 'n Tech Feature-sessie aangebied.
4. Projekte wat in die vorige bevorderingsiklus aangemeld is, kan nie by die lys ingesluit word nie.
5. Minstens 2 projekte moet as sleutelprojekte op 'n maatskappyvlak erken word (bv. 'n nuwe produk, ens, kan met CTO bevestig word).

Ry verandering

Dryf aan bestuursveranderinge (veelvuldige spanne/tegnologie)
· Alle vereistes van Ingenieurswese maar oor verskeie spanne
· Stelseleienaar vir ten minste een proses (bv. ondersteuning, ens.)

1. Groepe se produktiwiteit (prestasie) metrieke waardes oor verskeie groepe.
2. Groot veranderinge (ten minste 6) ingestel, wat aan die volgende vereistes voldoen:
a. Dit los 'n probleem op wat verband hou met die spanne of stam, 'n probleem moet by die TOP 5 probleme ingesluit word en met die lynbestuurder ooreengekom word.
b. Die verandering moet ten volle geïmplementeer en deur die groepe gebruik word (verandering moet "taai" wees en genoeg waarde bied om dit te behou).
c. Die verandering moet betekenisvolle verbetering aan produktiwiteit, betrokkenheid of kwaliteit van aflewering verskaf.
d. Die bestuurder hoef nie die een te wees wat die verandering voorgestel het nie. Die Ingenieursdirekteur moet die primêre dryfkrag agter die verandering wees. Die verandering kan deur 'n ingenieur of as 'n spanpoging gelewer word.
e. Ten minste 2 veranderinge moet verband hou met die proses wat deur die direkteur besit word.

Mense

Lynbestuurder (>=10 verslae, insluitend indirekte verslae)
· Alle vereistes vir Ingenieursbestuurder
· Lei ingenieurs af en ondersteun hulle
· Ondersteun en lei loopbaanvorderings
· Bestuur churn, verminder "betreurenswaardige churn"

1. Squads se betrokkenheid metrieke waardes oor veelvuldige squads.
2. Lys van ingenieurs wat aangestel is en proeftydperk geslaag het (kan oorgeslaan word as ons nie aanstel nie).
3. Lys van ingenieurs wat bevorder is (kan oorgeslaan word as daar geen besigheidsbehoefte vir bevorderings is nie).