A few years ago I decided I wanted to work in a big tech company. I thought it would be an interesting experience, and I wanted to work in a place with more technically advanced colleagues.

So now I work in a big tech company that makes software for other big organizations. What is this like?

I’ll limit myself to discussing some broad organizational patterns. Obviously it’s very delicate to write about one’s work life, and I’m not going to say anything that’s specific to the org, the tech stack, or the business. I’m just going to discuss some organizational dynamics that, from what I can tell, are similar at many large tech companies.

Life in teams

It’s the first place I’ve worked where everything is organized into “teams.” If there are 10 or 3 software engineers in your whole organization, you don’t need to divide things up into teams; you can just be the “engineering department.” Come to think of it, I used to work in places where I did “programming” instead of “software engineering,” and the phrase “software engineering” itself used to sound weird to me. Somehow, I got used to it.

So: you have a team; you belong to it; you keep it going; you hope to improve it… But you might also change teams, or get reorganized into some new structure at any moment. A team is both necessary and ephemeral. The idea of a team hints at sports, although I guess it’s also short for “scrum teams.” As Atlassian puts it, “A scrum team is a small and nimble team dedicated to delivering committed product increments.”

Some weeks feel more nimble than others.

Life outside teams

We’re all in teams, but we’re constantly working with other teams.

Because it is a big organization, the costs of coordination across teams are relatively high. Information can travel slowly from one place to another. Sometimes you meet other teams and find out that they have very different assumptions about how the world works. Here it’s handy to be trained as an anthropologist — it makes it easier to expect difference instead of expecting cognitive similarity across contexts.

You can sometimes start to feel slightly isolated in a big organization divided into so many silos. Some people get news faster than others, and you aren’t necessarily first to hear if you are an individual contributor. I often think of Zane Bitter’s excellent essay, Senior Engineers are Living in the Future.

In this environment, I’ve tried to get good at listening to the faint incoming signals from other planets in our universe, since they often bring essential information.

Social relationships

In a big and complex organization, human relationships are surprisingly important.

When I first got there, everything was confusing, because there was so much local culture and history to assimilate. What made things easier was gradually learning who to ask.

Now if I have a question,I usually know someone who can help me. I know people in customer support, billing, IT, sales, implementation consulting, security, infrastructure, product management, user research, user design, technical writing, architecture, and so on.

It gets dramatically easier to get things done if you know who to talk to. In that sense, relationships have a certain usefulness. You could even call them an “asset,” although I find that term a bit dehumanizing.

In any case, it’s a much friendlier place to work when you have more people to talk to.

Technical specialization

I’m much more specialized than I used to be. I don’t write front end code anymore. I don’t have server admin accounts or write deployment scripts. I don’t usually get the alerts if the systems are broken. I never get email from our customers. (Well, maybe once, ever.) I work strictly on back end software development, focusing on one particular technical area of a particular enterprise product.

The pervasiveness of specialization enables a certain kind of focus, which is the purpose of it, of course. Do one thing and do it well. And yet specialization has some funny side effects. There’s a constant risk of tunnel vision. People get invested in the minutia of code style, in a way that I never saw in small shops. We have debates about automatic code formatting rules, and then we have meta debates about how to refactor the automatic code formatting rules. People sweat over trying to standardize code interfaces and software design patterns. I see a lot of enterprise style code, by which I mean, code that is carved up into many tiny pieces and wrapped in many layers of abstraction. I always see that as an aesthetic preference as much as anything else.

I used to laugh a lot at FizzBuzz Enterprise Edition. If you never saw it, it takes a very simple assignment and overcomplicates it with sententious ceremonies, too many design patterns, and too many abstractions.

Now it’s not as funny… because it hits closer to home.

While our teams are specialized by topic, our work can also involve a lot of role ambiguity. Some software engineers end up doing project management. Some of us end up knowing a lot about the infrastructure, even though we don’t technically work on infrastructure, because we end up needing to solve problems that don’t follow the org chart. Paradoxically, we’re very specialized, and yet we’re often working outside our specialties.

Architecture

The organization needs “architecture” (and the people who specialize in it, “architects”) as the seemingly natural corollary of having so much specialization. We have such large systems that it’s hard to keep track of all of them and how we fit together. Enter the “architect,” a paradoxical role for a specialist in generalization. Or rather: a specialist in thinking about systems holistically.

The career path for software engineers largely points towards becoming architects. It’s a career direction for successful software people who don’t want to become managers.

In practice, our local architects are fun to talk to and very thoughtful. But sometimes it surprises me that systems thinking isn’t considered a core competency for all software engineers instead of a prestigious specialization.

Scale and surprises

We have more users and larger-scale architecture than I’m used to. I certainly don’t work on anything that’s “internet scale,” but our systems do have lots of active users. These users produce a long stream of interesting feedback, new feature requests, and above all, a stream of new edge cases. You have to solve more edge cases when you have a larger and more demanding user base.

Our attention becomes a scarce resource compared to the scale of the system.

To put things in perspective: At my first full time gig, we had a small number of users, and I used to get an email every single time our code raised an exception in production. Days went by without getting those emails.

Now we have a system that manages production exception reports in large volumes. They have options like “Don’t bother me again about this until it happens another 100 times.”

As always, it’s very hard to write code without making lots of assumptions about the world in which it will be executed. It’s impossible for software engineers to anticipate everything, no matter how we try. Thus, while we have fairly rigorous testing processes, we still get surprised by what users do with our systems.

Sometimes it’s unclear if it’s a bug or a new use case.

Jira

We use Jira a lot. A lot.

I do not love it.

I’ll save my thoughts about it for another time.

The tech community

I used to feel slightly more in touch with the rest of the web technical community. If you work in small places, you are more often allowed to try new things without huge barriers. You can test new libraries, new architectures or new styles without having to convince a large organization to approve it. You can probably contribute to open source projects, if that’s relevant.

In a larger organization, there is a much larger internal technical community, which substitutes to some extent for interaction with the larger ecosystem. It’s like living in a microclimate: it has its own weather patterns; it’s less tightly coupled to the surrounding ecosystem.

I’m not saying we are totally decoupled, of course. We keep a close eye on our dependency chain. We integrate lots of new things. Lots of my colleagues read Hacker News to keep an eye on the zeitgeist.

But there’s a certain turn inward just because the internal environment is, comparatively, so large, and so decisive for people’s careers within the organization.

Here’s a good barometer of that.

I used to go to public tech conferences sometimes, not to present, just to listen and learn some new things. Now I have an internal tech conference to attend instead.

Working environment

It’s a pretty good working environment. We rarely have “drop everything for this emergency” problems. That’s much more common in agency work.

My current management is fairly hands off, which I love. You get handed projects, plan timelines to deliver them, provide (lots of) project documentation, and implement. You explain your sprint plan to your teammates, and announce if your plans get blocked by something, so there is some visibility into your work plans, but it isn’t otherwise micromanaged.

That being said, I do notice two things:

  1. The longer you are there, the more meetings you seem to end up in.
  2. The longer you’re there, the more you get pinged with unexpected questions and requests. (Not that you must address them all, but you could.)

There’s a lot more you could say about working in a big public company, but I’m trying to keep it broad strokes.