Passer d'une petite à une grande entreprise [fermé]

14

Quelqu'un a-t-il des conseils, des réflexions, des avertissements ou une sagesse générale pour un développeur d'application / base de données qui passe spécifiquement d'une start-up à une grande organisation?

Des exemples de pensées incluraient des choses telles que:

  • Comment pourrais-je interagir différemment avec la chaîne de gestion?
  • Voyez-vous des tendances de qualité ou de vitesse de développement qui diffèrent entre les grandes et les petites?
  • Réflexions sur le développement de l'équipe.
  • Aspects sociaux.
  • Rien d'autre.

Addition: Quelqu'un a-t-il des histoires personnelles et des expériences à partager avec un mouvement similaire?

Veuillez me faire savoir si je peux clarifier de quelque façon que ce soit.

J'apprécie toutes les pensées!

ses011
la source
Assurez-vous d'avoir un godet que vous pouvez fermer
1
Je préférais les grandes entreprises aux petites start-ups tous les jours de la semaine. Pourquoi? Peut-être que j'aime être un petit poisson dans un grand étang, avec beaucoup d'autres poissons.
TeaDrinkingGeek
"fermé comme pas constructif"? ? ?
ohho
Que faire si vous migrez vers lieu de travail.stackexchange.com ?
ohho

Réponses:

27

Quelques expériences personnelles à partager avec:

  • Avant le déménagement:

    • Ne faites pas confiance à toutes les grandes promesses. Comme ils recherchent du talent, ils vous montreront tous les bons côtés et cacheront ces mauvais faits. Si le poste est si bon, pourquoi n'est-il pas pourvu devant moi? :-)
    • Une entreprise est une entreprise, le seul objectif est de faire du profit. Pensez, si vous amener à bord ajoute de la valeur à l'objectif. Vous êtes invités car ils pensent que vous apportez une valeur ajoutée. Vas-tu?
    • En supposant que vous soyez programmeur, les grandes entreprises sont généralement confrontées à une complexité autre que des défis techniques, par exemple la politique, les compétences en communication, la réglementation, ... Êtes-vous prêt?
  • Après le déménagement:

    • Essayez d'identifier le KPI de votre groupe fonctionnel (département) le plus tôt possible. Pour le dire simplement, pourquoi cette grande entreprise est-elle prête à payer de l'argent pour ce groupe de personnes qui font ces choses?
    • Positionnez-vous comme un facteur contributif de la réponse ci-dessus (le cas échéant). Ne combattez pas les borgs. Tu ne vas pas gagner. Vous êtes payé pour vous conformer.
    • Faire de bonnes choses et faire du bon travail n'est généralement pas la partie la plus difficile.
  • Quand les choses vont bien:

    • Améliorez les choses petit à petit, ne vous asseyez pas et ne vous plaignez pas.
    • N'ayez pas peur de prendre les tâches difficiles . Vous êtes moins susceptible d'être supprimé si vous êtes dans le rôle clé.
    • Utilisez la ressource comme si c'était la dernière goutte d'eau sur terre.
    • Réfléchissez encore et encore si un rôle de gestion est bon pour vous et votre futur cheminement de carrière. Pas trop d'ingénieurs ne sont de bons gestionnaires.
  • Quand les choses vont mal:

    • N'oubliez pas que vous avez en location un mois (de temps ou d'argent ;-) pas de panique.
    • Encore une fois, ne vous battez pas. S'ils peuvent changer d'avis, ils l'ont déjà fait.
    • Quoi qu'il arrive, des sh_ts arrivent. Ce n'est pas une question de bien ou de mal, c'est une question de match ou non.
    • Le monde est plus grand qu'une entreprise. Les opportunités sont pour ceux qui sont prêts à saisir.

À votre santé!

ohho
la source
3
Si vous vous retrouvez à combattre le borg tout le temps, il est temps pour vous de partir - parce que le borg ne le fera jamais.
quick_now
2 ^ 10 si je pouvais. Quelle réponse flamboyante! Des conseils très détaillés à chaque étape du quart de travail.
Karthik Sreenivasan
13
  • Comment pourrais-je interagir différemment avec la chaîne de gestion?

La grande entreprise sera plus bureaucratique que d'habitude. Vous interagirez avec les couches au-dessus et en dessous de vous; les sauts seront rares.

  • Voyez-vous des tendances de qualité ou de vitesse de développement qui diffèrent entre les grandes et les petites?

Vous aurez plus de couches. Vous n'aurez pas d'accès administrateur aux serveurs de production, il y aura donc plus de transferts. Les canaux de communication, la documentation et les processus ralentiront les choses dans la grande entreprise.

  • Réflexions sur le développement d'équipe contre le codage cowboy.

Hors du sujet; grands et petits peuvent être l'un ou l'autre.

  • Aspects sociaux.

Les grandes entreprises ont tendance à être plus conservatrices, car il y a plus à perdre.

Les grandes entreprises ont un gros avantage: elles savent comment faire la paie. Certaines des petites entreprises avec lesquelles j'ai travaillé ont échoué. Les ventes et le maintien du flux de revenus peuvent être un problème pour une petite entreprise.

  • Rien d'autre.

Vous serez une voix parmi tant d'autres. Votre influence dépendra davantage de votre capacité à vous intégrer aux déménageurs et aux secoueurs.

duffymo
la source
Je me rends compte maintenant à quel point le développement de mon équipe était stupide par rapport au point de codage cowboy. Réflexions intéressantes sur votre point «couches». Je me suis demandé à quoi cela ressemblerait de ne plus être administrateur système. :)
6

Liberté et limites

La plus grande différence à laquelle je peux penser dans mon expérience est les limites et les différences de flexibilité. Dans les petites entreprises:

  • Vous jouez un rôle plus important en tant que développeur où vous devez en faire plus. Que ce soit la mise en place d' un serveur, la configuration d' un système de contrôle de code source, la gestion de la base de données pour la Société produit X .

  • C'est plus social - vous pouvez avoir des relations avec le propriétaire / directeur de l'entreprise, etc.

  • Vous sentez que vous avez plus d'influence à mesure que vos opinions vont plus loin dans l'entreprise.

Lorsque vous passez aux grandes organisations, les limites sont bien plus définies.

  • Votre rôle est beaucoup plus spécifique.

  • C'est presque que vous venez de devenir le programmeur .

  • Vous relevez d'un chef de projet pour les mises à jour des tâches.

  • Votre infrastructure est gérée par une équipe de support / communication.

  • Il y a parfois une équipe de test qui fait les tests UAT et bat sur les bogues dans un système de suivi des bogues.

  • Cela semble plus compétitif car il y a une hiérarchie plus claire que les gens essaient de grimper et se sentent remarqués dans une mer de gens.

Martin Blore
la source
5

En tant que personne qui a travaillé dans les deux environnements, voici mes pensées:

  • Gestion - Vous constaterez probablement que beaucoup de communications se "perdent dans la hiérarchie". Ce que je veux dire par là, c'est que dans les petites entreprises, à peu près tout le monde sait tout (ou du moins "le sait"). Dans les grandes entreprises, il n'est pas rare que votre cadre intermédiaire n'ait aucune idée de ce sur quoi vous travaillez (c'est le travail du chef d'équipe - il y a donc une perte de granularité des informations de haut en bas de la chaîne).
  • Qualité et rapidité de développement - Cela a tendance à être plus lent dans les grandes entreprises. Les startups ont tendance à être plus agiles (cela tient en partie au fait que le produit de la petite entreprise est probablement plus petit). Cependant, ne tombez pas dans le piège de penser qu'une grande entreprise a nécessairement des processus et des méthodologies mieux établis. Surtout si la compétence principale de l'entreprise n'est pas dans le logiciel - les équipes logicielles ne peuvent pas être mieux gérées que dans n'importe quel petit hackshop. En fait, l'un des meilleurs endroits où j'ai jamais travaillé était un petit hackshop en ce qui concerne cela - principalement parce que c'était un véritable petit magasin de logiciels - lancé et géré par des programmeurs. Solide 12/12 sur les trucs de Joel Test.
  • Développement d'équipe - Comme ci-dessus. Cela dépend vraiment de l'équipe. Les grandes entreprises ne fonctionnent pas nécessairement mieux (contrairement à certaines autres disciplines). Cela dépend surtout de la «compétence en développement logiciel» des responsables des équipes logicielles. Les cadres intermédiaires / supérieurs qui ne comprennent pas suffisamment les logiciels sous-financeront et frustreront les équipes logicielles dans les grandes entreprises en particulier.
  • Aspects sociaux - Dans l'ensemble, les petites entreprises et les startups sont généralement plus informelles et sociales, mais les grandes entreprises ne doivent pas non plus être trop rigides. Beaucoup peut dépendre du domaine de l'industrie, mais aussi de l'âge moyen de l'équipe. Une jeune équipe de logiciels étroitement coopérative dans une grande entreprise peut se sentir à peu près une petite start-up.

Autre chose (juste quelques pensées et avertissements aléatoires auxquels je peux penser):

  • Attention aux conflits inter-équipes. Dans les grandes entreprises, il y a souvent des équipes distinctes responsables de différentes couches d'un système, etc. etc). Vous n'avez pas tendance à voir cela dans les petites startups où tout le monde fait essentiellement partie de la même équipe.
  • Habituez-vous à prendre des commandes de personnes qui n'ont aucune idée du fonctionnement du logiciel. Cela peut être un problème n'importe où, bien sûr, mais la séparation entre les «hommes d'affaires» et l'équipe logicielle a tendance à être plus fortement définie plus l'entreprise grandit. Dans une petite startup, ce sont souvent les mêmes personnes. Dans les grandes sociétés, ils ne le sont presque jamais. Ce ne sera pas si mal si la société est une véritable société de logiciels (par exemple, Microsoft).

  • Vous serez probablement plus protégé de la «ligne de front» du client. Il y aura probablement un service d'assistance et des chefs de produit qui traiteront avec les clients, et vous n'aurez probablement presque jamais à le faire. Cela peut être bon et mauvais à la fois. Bon dans le sens où vous n'avez pas à vous occuper d'un support direct, mauvais dans le sens où il peut y avoir des problèmes de communication et des délais de traitement fastidieux pour résoudre des problèmes relativement simples.

C'est à peu près tout ce à quoi je peux penser pour l'instant.

Tables Bobby
la source