Vraag:
Omgaan met iemand die denkt dat hij 'goddelijk gelijk' heeft
Karlson
2012-04-11 19:44:26 UTC
view on stackexchange narkive permalink

Ik ben onlangs de situatie tegengekomen waarin ik te maken heb met de persoon (softwarearchitect) die lijkt te denken dat de softwareoplossing die hij had bedacht in wezen "goddelijk correct" is en voor elke situatie kan worden toegepast. Zonder al te veel in te gaan op wat de oplossing is, hebben we een snelle analyse gemaakt van het toepassen van de oplossing op het probleem en kwamen we weg met meer vragen en problemen die ik graag in de vraag wil opsommen, maar deze persoon blijft doorgaan met het toepassen van de oplossing.

Enkele van de eerste pogingen om de oplossing te gebruiken die deze persoon bedacht, produceerden Rube Goldbergs machines waarvan was aangetoond dat ze meetbaar langzamer werken dan de vorige oplossingen (ongeacht hoe verouderd en slecht geschreven).

Wat in wezen terugkomt van deze persoon wanneer er vragen worden gesteld, is: "Dit is de manier waarop ik heb besloten het te doen en dit is wat we zullen doen!"

Hoe ga je om met een persoon als deze?

Wat heeft deze vraag met het peter-principe te maken?
OP heeft een kritieke component weggelaten - Hoeveel waardeer je je gezond verstand :) In alle ernst - als ze in de positie zijn, ondersteunt iemand hen waarschijnlijk. Zolang dat zo is, heb je waarschijnlijk geen opties.
@JohnFx Omdat het vanaf hier lijkt dat deze persoon "het niveau van zijn eigen incompetentie" heeft bereikt, maar ik heb het toch verwijderd.
@AffableGeek Als consultant kan het me niet zoveel schelen, aangezien de machines van Rube Goldberg de rekeningen bijna voor onbepaalde tijd kunnen betalen. :)
Gerelateerde meta-discussie: http://meta.workplace.stackexchange.com/questions/35/do-we-have-a-quality-control-issue
Vier antwoorden:
#1
+22
kevin cline
2012-04-11 21:11:47 UTC
view on stackexchange narkive permalink

De enige snelle oplossing die ik in deze situaties heb gevonden, is het vinden van een nieuwe situatie. Je hebt te maken met organisatorische waanzin en je zult het niet snel kunnen oplossen. De verkeerde persoon is gepromoveerd en zijn management lijkt het niet te weten of te schelen. Je hebt niet genoeg invloed om een ​​verandering door te voeren, en technische argumenten zullen niet werken .

Het alternatief is om mee te gaan met het ineffectieve proces en je tijd af te wachten. Uiteindelijk zullen de kostenoverschrijdingen iemand dwingen kennis te nemen. De architect wordt aangemoedigd om iets anders te doen. Als je in de buurt bent gebleven, hebt samengewerkt en vrienden hebt gewonnen, word je misschien de volgende architect.

Trouwens, ik verliet een zeer vergelijkbare situatie vijf jaar geleden. De incompetente technische leiders werden vorig jaar vervangen.

* misschien wordt u de volgende architect * in dit geval niet maar een goede gedachte.
Het kan lang duren voordat mensen als deze worden vervangen. Als dit een chronisch probleem is, moet u serieus overwegen om verder te gaan.
Yea, there's always a little A -> B vector thing going on, where the visible incompetent person B is being supported by some senior person A who vouches for them being A Good Person And Therefore Not the Source Of Our Problems.
+1 voor het vinden van een nieuwe situatie. Ik heb een paar jaar geworsteld met de 'goddelijke juistheid' van een belangrijke besluitvormer. De grote frustratie voor mij is niet persoonlijke meningsverschillen of het niet op mijn manier hebben, maar de zakelijke kosten van een slechte beslissing die het succes van mijn collega's vermindert - als je als team werkt, moet je ernaar streven om als team te winnen.
#2
+4
jefflunt
2012-04-11 20:12:50 UTC
view on stackexchange narkive permalink

Als die persoon de beslissingsbevoegdheid heeft, dan is dat dat. Als het niet voldoet aan de eisen van de klant (dwz de klant is het er niet mee eens dat de oplossing aan zijn eisen voldoet), dan hoeven ze er niet per se voor te betalen (tenzij in een contract anders staat), en kunnen ze zoiets eenvoudigs zeggen als: "Oké , Ik hoor waarom je deze kant op wilt, maar dat lost het probleem niet op dat ik nodig heb om de [software / product / oplossing] op te lossen. "

Ego's lopen hoog op. Dit hoort bij elke werkplek. Als het gaat om typen ingenieurs, kunt u proberen om objectieve, meetbare prestatie- en kwaliteitsstatistieken te presenteren (als dat in uw situatie van toepassing is) - ingenieurs zullen (in ieder geval in het algemeen) reageren op met redenen omklede argumenten. Als dat niet lukt, moet u bedenken wie de beslissingsbevoegdheid heeft, of dit een gevecht is dat de moeite waard is om te vechten, en hoe dit uw klanten en bedrijf zal beïnvloeden. Ik denk niet dat het pijn doet om uw zorgen kenbaar te maken, zolang het maar een met redenen omkleed, objectief standpunt is en geen persoonlijke aanval op de ingenieur.

Dat gezegd hebbende, wat doen we niet Het is niet duidelijk aan uw vraag het standpunt van de ingenieur te zijn - misschien heeft u het hier mis, misschien niet - het is moeilijk om een ​​beslissing te nemen zonder beide kanten te kennen.

* Als het niet voldoet aan de eisen van de klant *. Helaas is de klant intern in het bedrijf en heeft hij geen manier en geen kennis om de oplossing te evalueren.
* wat we niet zien in uw vraag is het standpunt van de ingenieur. * Ik wou dat hij het verder zou geven dan "hier zijn uw marsorders".
Voor zover de klant geen kennis heeft om de oplossing te evalueren, zie ik niet in hoe dat mogelijk is. Ik kan zien dat een klant niet de technische vaardigheden heeft om voor of tegen een oplossing te pleiten op basis van ** technische verdiensten **, maar de klant ** geeft ** wel ** om zaken als of de software zijn werk voldoende snel doet om de gevraagde bedrijfswaarde leveren, als de software de juiste resultaten oplevert, enz. Als de technische oplossing die de ingenieur voorstelt de klant op geen enkele manier beïnvloedt, waarom maakt het dan uit welke oplossing wordt gekozen? Ze worden ingehuurd om technische experts te zijn.
Je hebt gelijk dat ze geen technische expertise hebben om te evalueren, maar ze krijgen een stukgoed verkocht dat gevolgen voor hen zal hebben. Het probleem is dat de persoon die verkoopt (ingenieur) niet degene is die die oplossing implementeert. De oplossing heeft impact op het bedrijf, maar de verantwoordelijkheid voor de implementatie ligt niet bij de engineer.
Weet niet of ik je daar kan helpen - dit roept veel vragen op in mijn hoofd. Het is niet duidelijk waarom de ingenieur bij de discussie betrokken is als hij niet betrokken zal zijn bij de implementatie of de voortdurende ondersteuning. Is deze persoon een afdeling / teamleider die met deze beslissingen is belast? Brengen ze andere ingenieurs aan die de oplossing zullen implementeren / ondersteunen en die hun standpunt in de beslissing in overweging nemen? Dit klinkt gewoon gek.
Veronderstel een kolossale bank die "Technology Architecture Group", "Trading Group" en "Software Development Group" heeft. De "Technology Architecture Group" bedacht de oplossing en gaf de "Software Development Group" de opdracht om deze te implementeren, terwijl hij aan "Trading Group" verkocht dat dit het beste is sinds gesneden brood. Op een bepaalde hoogte rapporteren Architecture en Dev-groepen aan dezelfde persoon, maar helaas is het zo hoog dat: http://www.fortunecity.com/campus/books/845/shithap.htm
Oké, maar in dat geval raak je op gebieden als politiek, structuur en organisatie. Je bent helemaal losgekomen van de oorspronkelijke vraag, namelijk hoe je met de persoon / het ego moet omgaan. Door al deze voorwaarden en bijzonderheden toe te voegen, wordt dit een fundamenteel andere vraag: dat wil zeggen: hoe te navigeren door de structuren en politiek die betrokken zijn bij het nemen van beslissingen in organisaties. Ik kan daar binnen de scope van ** deze ** vraag geen goed antwoord op geven, omdat het een heel andere vraag is.
#3
+2
Ourjamie
2012-05-15 15:06:46 UTC
view on stackexchange narkive permalink

In vergelijkbare situaties heb ik vertrouwd op het verkrijgen van een lijst met bronnen (boeken, blogs, standaarden en richtlijnen van de belangrijkste leveranciers in uw specifieke ontwikkelingsruimte, zoals IBM, Microsoft, Idesign, Thoughtworks om er maar een paar te noemen) om een ​​back-up van te maken de punten die ik probeer over te brengen en die ik helaas tijdens vergaderingen heb moeten produceren.

Als u dat proces hebt doorlopen en nog steeds wordt verteld dat u niet juist of onjuist bent, of weet beter. Doe dan wat u wordt opgedragen, maar bewaar uw bronmateriaal als er iets misgaat om uzelf en uw eigen professionele integriteit te bedekken. Positief is dat het zal helpen om je vaardigheden te verbeteren, aangezien je leert hoe je het nodige onderzoek moet doen om je uitspraken te ondersteunen en hoe je met moeilijkheden (mensen, situaties en gebrekkige benaderingen) kunt omgaan.

Vraag ten slotte gewoon hoe ze tot de resultaten van hun beslissingen zijn gekomen. Het is de taak van een software-architect om de bedoeling en het doel van een ontwerp te laten zien en hoe het werkende deel allemaal bij elkaar past om een ​​oplossing te bieden.

#4
  0
Lucas Kauffman
2012-04-11 19:55:09 UTC
view on stackexchange narkive permalink

Wat je kunt doen, is er in groep met hem over praten. Als dit een gezamenlijke inspanning is, moet u kijken wat andere mensen van zijn oplossing vinden en of er een beter alternatief is.

Als u vindt dat de kwaliteit van zijn oplossing niet goed genoeg is en uw klant ongelukkig of uw project in gevaar brengen. Bespreek het met je teamleider of baas. Leg hen uit waarom u denkt dat zijn oplossing niet juist is. Laat uw alternatief zien. Maar als jij de enige in je team bent die denkt dat hij ongelijk heeft, dan zul je met de stroom mee moeten gaan, vrees ik.



Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...