Does anyone have any tips, thoughts, warnings, or general wisdom for a application/database developer who is moving specifically from a start-up sized company to a large organization?

Examples thoughts would include things such as:

  • How might I interact differently with the management chain?
  • Do you see trends in quality or speed of development that differ between large and small?
  • Thoughts on team developent.
  • Social Aspects.
  • Anything else.

Addition: Does anyone have any personal stories and experiences to share with a similar move?

Please let me know if I can clarify in any way.

I appreciate any thoughts!

  • Make sure you have a dump bucket that you can close
    – random
    Mar 21, 2011 at 1:12
  • 1
    I preferred large companies to small start ups anyday of the week. Why? Maybe I like being a smallish fish in a large pond, with plenty of other fish. Mar 21, 2011 at 11:48
  • "closed as not constructive" ? ? ?
    – ohho
    Mar 8, 2012 at 1:24
  • What if migrate to workplace.stackexchange.com ?
    – ohho
    May 30, 2012 at 4:04

4 Answers 4


A few personal experience to share with:

  • Before the move:

    • Don't trust all the great promises. As they are looking for talent, they will show you all the good sides and hide those bad facts. If the position is that good, why is it not filled before me? :-)
    • A business is a business, the only objective is to make a profit. Think, whether bringing you onboard adds value to the objective. You are invited because they think you bring added value. Will you?
    • Assuming you are a programmer, big companies usually come with complexity other than technical challenges, e.g. politics, communication skills, regulations, ... Are you ready?
  • After the Move:

    • Try to identify the KPI of your functional group (department) as early as possible. To put it simply, why this big company is will to paying money for this group of people doing these stuff?
    • Position yourself as a contributing factor of the above answer (if found). Don't fight the borg. You are not going to win. You are paid to comply.
    • Make good stuff and do a good job is usually not the most difficult part.
  • When things go well:

    • Improve stuff bit by bit, don't sit and complain.
    • Don't afraid to take the hard tasks. You are less likely to be removed if you are in the key role.
    • Use resource as if it is the last drop of water on earth.
    • Think again and again whether a managerial role is good for you and your future career path. Not too many engineers are good managers.
  • When things go wrong:

    • Remember you have at lease a month (of time or money ;-) don't panic.
    • Again, don't fight. If they can change their mind, they already did.
    • No matter what, sh_ts happen. It's not about right or wrong, it's about match or not.
    • The world is bigger than one company. Opportunities are for those who are ready to take.


  • 3
    If you find yourself fighting the borg all the time, its time for you to leave - because the borg never will. Mar 21, 2011 at 6:57
  • 2^10 if I could. What a flamboyant answer! Very detailed advice at every stage of the shift. Mar 7, 2012 at 7:21
  • How might I interact differently with the management chain?

The large company will be more bureaucratic than you're used to. You'll interact with the layers above and below you; skips will be rare.

  • Do you see trends in quality or speed of development that differ between large and small?

You'll have more layers. You won't have admin access to production servers, so there will be more hand-offs. Communication channels and documentation and process will slow things down in the larger firm.

  • Thoughts on team developent vs. cowboy coding.

Irrelevant; both large and small can be either one.

  • Social Aspects.

Larger firms tend to be more conservative, because there's more to lose.

Larger firms have one big advantage: they know how to make payroll. Some of the smaller firms I worked with failed at it. Sales and keeping the revenue stream flowing can be a problem for a smaller firm.

  • Anything else.

You'll be one voice among many. Your influence will depend more on how well you can integrate yourself in with the movers and shakers.

  • I realize now how silly my team developent vs. cowboy coding point was. Interesting thoughts on your 'layers' point. I have wondered what it will be like not being a sysadmin anymore. :)
    – Spacemoses
    Mar 21, 2011 at 1:18

Freedom And Boundaries

The biggest difference I can think of in my experience is the boundaries and flexibility differences. In smaller companies:

  • You play a bigger role as a Developer where you are required to do more. Whether that is setting up a server, configuring a source control system, managing the database for the Company Product X.

  • It's more social - you may have relations with the company owner/directors etc.

  • You feel you have more influence as your opinions reach further around the company.

When you move to the larger organizations, boundaries are way more defined.

  • Your role is much more specific.

  • It's almost that you just become the Programmer.

  • You report to a project manager for task updates.

  • Your infrastructure is managed by a support/comms team.

  • There's sometimes a test team that do the UAT testing and bat over bugs in a bug tracking system.

  • It feels more competitive as there is a clearer hierarchy that people are trying to climb and feel noticed in a sea of people.


As someone who's worked in both environments, here are my thoughts:

  • Management - You'll probably find that a lot of communication gets "lost in the hierarchy". What I mean by this is that in small companies, pretty much everybody knows everything (or at least "knows of it"). In big companies, it's not unusual for your middle manager to have no idea what you're even working on (that's the team lead's job - so there's a loss of granularity of the information up and down the chain).
  • Quality and speed of development - This tends to be more sluggish at larger companies. Startups tend to be more agile (part of this stems from the fact that the product at the small company is likely to be smaller). However, don't fall into the trap of thinking that a large company necessarily has better established processes and methodologies. Especially if the company's main competence isn't in software - the software teams can be run no better than in any small hackshop. In fact, one of the best places I've ever worked at was a small hackshop as far as this goes - mainly because it was a real little software shop - started and run by programmers. Solid 12/12 on the Joel Test stuff.
  • Team development - As above. It really depends on the team. Large companies aren't necessarily run any better (unlike in some other disciplines). It mostly depends on how "software development competent" the people in charge of the software teams are. Middle/upper managers who don't understand software well enough will underfund and frustrate software teams in large companies especially.
  • Social aspects - As a whole, small companies and startups are generally more informal and social, but bigger companies don't have to be too stiff either. A lot can depend on the industry domain, and also on the average age of the team. A young, closely cooperative software team in a big company can pretty much feel little a little startup of its own.

Anything else (just some random thoughts and warnings I can think of):

  • Watch out for inter-team conflict. In large companies, there are often separate teams responsible for different layers of a system, etc. Human nature being, erm, human nature - means that there is often some "us and them" mentality here (backstabbing, bitchiness, passing the buck, etc). You don't tend to see this in small startups where everybody is essentially on the same team.
  • Get used to taking orders from people who have no idea how the software works. This can be a problem anywhere, of course, but the separation between the "business people" and the software team tends to be more strongly defined the bigger the company gets. In a small startup, they're often the same people. In huge corporations, they almost never are. This won't be so bad if the company is an actual software company (eg. Microsoft).

  • You are likely to be more shielded from the client "front line". There will probably be a help desk and product managers who deal with clients, and you'll probably almost never have to. This can be both good and bad. Good in the sense that you don't have to deal with direct support, bad in the sense that there can be communication problems and tedious turnaround times to solve relatively simple problems.

This is about all I can think of for now.

Not the answer you're looking for? Browse other questions tagged or ask your own question.