What’s it like to work at Big Tech? This is a question I had myself before actually joining Apple in April of 2018. As it turns out, it’s nothing like I had expected.
To begin, I had a perception of Apple before working there. While I wasn’t the type of person to blindly think that everything Apple does is perfect, I did think that Apple’s products were largely the best devices for my purposes. I tinker a lot with things at work and with my hobbies, so when I just want to do something like relax and read the news, check the weather, or mindlessly scroll Twitter for hours, I don’t want those things to take any more effort than a few taps. That is, I want things to “just work”. While that phrase is often overused when it comes to Apple’s products – and yes, there are records of bugs and flaws in Apple products – for the most part it’s true relative to other offerings.
Because Apple’s products “just work”, I had a perception that the company must have extremely strict requirements and standards when it comes to doing work there. I imagined they had a strict list of best practices that must be followed or your pull requests would get denied regardless of functionality. I imagined they had strict testing requirements or your code wouldn’t get merged. I imagined every project would require extremely detailed specification of what needed to be done and exactly how it would be done. I imagined that this documentation would be just as important as the code itself.
After my first few days at Apple, I discovered all my assumptions were wrong.
It took me a really long time to reconcile with this fact. For one, I had a severe case of imposter syndrome when I first started. Before Apple, I worked at a small lesser known company. I was extremely shocked that I had received a job offer at Apple, and I felt that there was no way I was going to be up to par to effectively contribute to the company. I was extremely nervous until I started digging in and learning how Apple actually works.
For my first few months at Apple I was assigned to a project in dire need of resources. It was a new product for Apple, and it was using new technology that Apple had never released before. Furthermore, the product launch was coming up fast. There was still a lot of work to be done. The only thing that was really well defined for this product was the user interaction with it. This is one thing that Apple probably does right: the user interaction and the way the device is used is extremely important. On top of that, the quality engineering team won’t let anything be shipped unless those requirements are met. But other than that, it’s up to every individual to make sure that their contribution to the project falls in line with that goal. And, for the most part, every individual is trying to meet deadlines put in place by their management team.
When you’re a new employee at Apple you’re pretty much thrown into the deep end. There’s no orientation for projects on how to contribute to them or requirements to work within a certain set of guidelines. For the most part I was expected to learn things along the way. On top of that, generally there wasn’t any strict rules on things like code review or pull request requirements. I was given some tasks to complete, but from there it was up to me to learn how to integrate my changes into a massive project I had never seen before. I had to find the right people to talk to and learn a lot by trial and error. I had to do all of this while other teams were expecting my work to be done at a certain time, and even though a valid excuse of mine was “I have no idea what I’m doing,” you can imagine that wasn’t always acceptable to someone dependent on me completing my tasks.
The biggest issue in this type of relationship of individual responsibility to meet a deadline is that you will often end up being co-dependent with someone else from a different org with different management and different deadlines. That is, your management and their management may not always agree on something and it ends up being a huge roadblock for you and the other person. It was a constant problem at Apple where I’d either have a request to someone else that was responded with something along the lines of “my management doesn’t want me working on that,” or a request to me that I’d have to respond to in the exact same way. You can imagine the type of impact this can have on your personal relationship with the people that are just trying to do what their management is requesting of them. Even if you’re just the messenger and doing what you’re told, you are the face that they interact with daily. It makes it difficult to form a decent bond when these issues arise.
Furthermore, when issues really started to occur where someone was unable to do any work until you completed a task, it was often threatened that things would need to be escalated to upper management. It was never put this way directly, but to me when people would say this it could be interpreted as “we are going to tell your director about your poor performance.” Because of that, individual contributors (i.e. non-management) would often do everything possible just to get the job done and avoid that escalation. This meant late nights, weekends, skipping lunch, or whatever it takes. Pulling in upper management was bad and should be avoided at all cost. While that wasn’t a written rule, I certainly observed it a lot during my time there.
While constantly dealing with this balance of pissing off my coworkers and the threat of upper management being told I’m a poor performer, I tried thinking of a solution. To me, the core of the issue was upper management not being aligned with another team’s upper management. Perhaps escalations shouldn’t be avoided so that the core issue of conflicting deadlines could be resolved. That made the most sense to me because my priorities were never perfectly aligned with someone from another team. I tried to have a chat with upper management about this at one point but was basically ignored. I wanted to have a one-on-one with my director, but it took a couple months to fit into the director’s schedule. When I finally did, the conversation didn’t result in any actionable things that were followed up on. There was one meeting I was part of where upper management did discuss this problem, but the suggested solution was “sounds like you need to go out drinking with them.” From that point on, it was clear upper management really wasn’t interested in resolving this issue or for whatever reason wasn’t able to. They must have had their own conflicting priorities.
My direct management was doing all they could to help the situation, but it never fully resolved the priority differences among teams. It was just beyond their control. We learned to set up our own boundaries and be okay with saying “no” and the threat of escalation – as it turns out, escalation never really went that far or occurred as often as it was threatened. The sad thing is, this never did us any favors just in terms of keeping a good relationship among our peers. Meetings were constantly contentious when a difference arose, and ultimately one side or the other would just need to bite the bullet.
I had a hard time reconciling this process until I had a candid conversation with another manager. I asked him why things operate this way and why there’s no clear effort to fix it. He gave me the context that Apple works on cutting edge technology, and ultimately people don’t really know the exact solution to a problem. We can do our best at predicting what issues may arise or how to avoid them, but since everything is new and no one has ever done it before, you can’t possibly anticipate everything that will happen during development. Because of that, teams do the best they can to anticipate and prioritize to avoid worst case scenarios. Sometimes things can get resolved by a trade off where we could do the bare minimum to enable another team to continue working to a point, but sometimes things would come to a screeching halt leading to threats of escalation.
That manager’s willingness to give me some more context changed my perspective. How can you improve a process when you don’t know what the right process is? Perhaps we are already doing things the best way possible, and these issues are just a natural result that should be expected. For anyone joining a Big Tech company in the future, this would be my advice to them: it won’t always be smooth sailing, and you should expect to encounter tough problems beyond the technical challenges of your role. While it would be desirable to see upper management work a bit more on this issue other than the feedback of “go drinking together,” I think there’s a lot more in our control than we realize. Most of that starts with setting boundaries and expectations early, and then compromising when a problem does occur to make sure people aren’t entirely blocked by whatever the issue may be.
While my experience in Big Tech is solely from my org at Apple, I would be surprised if it were significantly different at other Big Tech companies or other orgs within Apple itself. My parting advice to anyone reading this that may be joining Big Tech soon or thinking of doing so is this: don’t be afraid to say no. Don’t sacrifice your mental well-being just because another team is hounding you. Set boundaries, turn your work notifications off in the evening, and find something that will help you recuperate from the day to day stress. On top of everything else, make sure your priorities are clear with your management, and bring up any conflicts that occur as fast as possible. The weight of this stress doesn’t need to sit completely on your shoulders.
There’s other aspects of working at Big Tech as well, such as all the media attention they get. Apple is currently undergoing criticism for its decision to scan user’s photos to detect child abuse as well as shutting down employee run surveys for the sake of pay equity. It can be hard to ignore these things while working at the company being criticized, even if you have nothing to do with the specific feature or product being criticized. My advice? Keep an open conversation with your manager. My direct managers during my time at Apple were extremely supportive and open to these discussions, and I truly believe they listened to my concerns and were able to help when they could. I’ve heard other stories about management not being so supportive, so I got lucky there. However, all of this has an impact on your mental health and your ability to focus on the work, so keep that in mind before deciding Big Tech is right for you. Your job and the things you need to do are also often dictated by people you never have the ability to meet with. Upper management all the way up to the CEO could make a decision one day that can entirely change the trajectory of what it is you are working on, and you most likely won’t be able to give them your feedback on the effects of their decision at your level within the company.
These are just my experiences. Others may have different stories. Some people may thrive in this sort of environment, while others deal with this plus things I was lucky enough to avoid such as inherent racism or sexism. I encourage you to share your story with others, whatever the case.
I will be writing more about mental health specifically in future posts.
-Jake
from Hacker News https://ift.tt/3gGf5Vx
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.