To survive and thrive in the U.S. tech corporate workplace
A guide for junior developers in consulting, immigrants, subcontractors, and mentors
I left IBM Consulting two weeks ago to begin my law school education. August is a brief series on what I learned there. The behemoth of a company was an intimate study of governance, management, authority and jurisdiction, statutes and regulations– what law is about.
We’ll get back to what law school is like in September. I’ll recap my first few weeks, explain how I am financing law school, talk to careers in law, and more.
If you’re looking for resources now I have links to my cycle recap, how to write a diversity statement, scholarship essays, and a comparison of NYU and Cornell.
As always, I love to hear from you at allisoninwonderland@substack.com.
In my last post, I cautioned the reader: If you are a software developer, do not work in consulting. But you may not have a choice. You may be stuck in an economically depressed city where the only software job around is contracted through IBM. You may have just landed in the States with your work authorization tied to a certain employer, meaning only contracting jobs for you. If that is you, this is my guide to survive and maybe even thrive.
I ran human resources for hundreds of consultants at one of IBM’s largest banking clients for a year, including vetting resumes, setting up and priming interviews, negotiating raises, firing people, hiring people, setting up new projects, and trying to mitigate wage theft. I know the trajectories of the most desired software engineers in the market: IBM consultants who mastered the game, and friends from Princeton who are at Google, Amazon, Microsoft, mid-sized startups, and more.
There are a lot of little tips in here, like:
Learn to identify what you “don’t know”
You should always ask for more money
You need to vet your contracts or you might be left without a job
There is one big lesson, too: You need to increase your labor value.
Yes, being paid a wage is wonderful. Perhaps you are earning more than you ever would have expected! But I urge you to consider that while you walk away with a paycheck, the employer walks away with your sweat and tears, most of your waking hours, your code and mental effort, and your creative products and ideas. If you are not extracting more than a wage, then you are being taken advantage of. I talk about how to invest in your own labor value throughout this guide; your children, family and community depend on it.1
Table of contents
“Gig”
– Consulting is temporary work, but longevity is better
– Always feel out the length of the project
– TL;DR
Upskilling
– Don’t expect you’ll be positioned to learn
– Don’t be content simply earning a salary
– Ask for work
– Learn to identify what you don’t know
Mentors and allies
Who writes your paycheck
“Gig”
Consulting is temporary work, but longevity is better
Consulting is ‘project-based’ temporary work. When you are asked to work on a project, the client has no obligation to keep you six months later, even if you are a top performer. You can be moved off of an effort regardless of your personal aspirations.
In the best-case scenario, people can expect to stay with the client for years. This is a win-win situation. Clients retain institutional knowledge and IBM receives a steady profit stream. You can deepen your knowledge in one area, find mentors who have been with the client awhile, and see the fruits of your engineering– continuity that is important for learning.
In the worst-case scenario, the project ends suddenly. The client makes cuts. When a project shrinks from sixty to thirty people, the first to go are the least privileged workers: consultants (contractors) like you.
Consulting companies implement a strict limit to the time you can spend off a project (on the “bench”). Anyone can end up on the “bench.” Top performers are no exception. I knew a brilliant developer who, in order to stay off the bench, was forced to take on odd jobs as a business systems analyst (no coding) and a data engineer. It did not match his career goals at all. He has, to my relief, moved on to a well-known financial institution with an in-house engineering org.
If you are a subcontractor, you do not have the luxury of a bench. Your contract with IBM is dissolved. IBM will always try to keep its full-time employees on a project and quarterly seeks to replace subcontractors with full-time employees, even if it is a worse substitution.2
Here is my tip for everyone…
Feel out the length of the project
You should always “interview” your new projects, even if it is your only option. Gather the following information in the interview process or by speaking early with your manager.
How long has my team been together? Is my role new or a backfill? New teams always scramble to ramp up on work. If your team is new, then senior engineers may not be able to devote as much time to mentoring you.
You should also beware if your role is an ‘addition’ to the team– as opposed to filling in someone who left– because this may mean that it requires an addition to the contract. Clients are notorious for taking months to process and approve contract changes. One of my coworkers was put on a Performance Improvement Plan because she accepted a newly added role in January that was not fully approved until April; she was considered on the “bench” during that interim.
What stage is the project in now? Are there stories in the backlog? (If the project is in its beginning stages, has the client contract been signed?) If the work is in its beginning stages, you may sit idle waiting for the client to engage you. Consulting projects can be notoriously slow in ramp-up due to the bureaucratic decision-making process: various groups fight over what the product should be and what should be prioritized, those decisions undergo compliance and legal scrutiny, and you’re twiddling your thumbs. Sitting idle is not ideal for your own growth. Asking if there is already work in the backlog allows you to see whether you can jump in on day one.
If the project is being staffed for the first time, the contract may not yet be signed, which means it still has the potential to fall through. If it falls through, you are back on the bench or, in the case of a subcontractor, out of a job.
Subcontractors, be especially cautious with net new projects. If the project seems new, ask the staffing focal or the team project manager if the client contract has been signed. I once had a manager ask me to staff an entire team of developers – including two subcontractors who left their previous roles – only for the project to fall through after she lost motivation to push it through (she was recruited to another project). Teams tend to be staffed before contracts are fully signed because IBM wants to prove it has the people to start immediately.
Even if the contract between IBM and client is signed, subcontractors should expect a six to eight week period between when they first interview and when their new contract will be ready. Do not give your notice earlier than that. The process that allows you to work for IBM is fractured and distributed across multiple countries. I submitted my request to my counterparts in Costa Rica, who then work with your staffing agency in Canada or the States. This request must also be fed to the finance teams in India to approve bringing you on. Weirdly, approval sometimes hinges on one person and that person might be out of office. A parallel ‘onboarding’ happens on the client side. The client must approve your profile in their own staffing system. The client may require a background check that can take a month or two. If you give your notice too early, you may not be paid for a while.
Is there a definitive point at which the project will be considered done? Are there handoffs (transition of the work back to the client) expected in the near future? Longevity benefits workers. You should seek out projects where an end does not seem in sight. Subcontractors can get a feel for this by asking for a year-long contract.
How large is the account? How long has the account been together? What do *you* (manager/interviewer) know of other projects? I was part of a 300+ person client account with over twenty teams. Working for the same client, you become part of an association. You can hear about other projects and take advantage of internal mobility. Word also travels within the interconnected group: when two teams heard I was leaving my immediate team, they reached out to ask where I was going, potentially to recruit me. Not all big accounts are cohesive. Previously, I had worked on a tiny team and knew nothing of other teams working with that client. If you ask your manager about other projects, you can garner how interconnected teams are.
TL;DR
The questions you should ask when interviewing:
How long has my team been together? Is my role new or a backfill?
A backfill is safer, contractually speaking
What stage is the project in now? Are there stories in the backlog? (If the project is in its beginning stages, has the client contract been signed?)
It is better if there are stories in the backlog, as you will have work on Day 1
Better if the client contract has been signed. Stay away, if possible, from an unsigned contract – especially if you are a subcontractor.
Is there a definitive point at which the project will be considered done? Are there handoffs (transition of the work back to the client) expected in the near future?
If there is no handoff or endpoint in sight, you will not be moved to another project imminently. On the other hand, this may indicate problems within the organization with releasing code in a timely matter.
How large is the account? How long has the account been together? What do you (manager/interviewer) know of other projects?
If the account is large (greater than 100 people) and been together for a while, and there is much cross-team learning, this can be good for your own mobility.
Upskilling
Mastery is always rewarded in the labor market. In consulting, the tolerance for amateurism is even lower. Clients are paying for expertise, after all. Within my account, three times or more senior developer roles popped up than junior developer roles. Handfuls of junior developer resumes slid across my desk that I had to pass up because of a skills and experience gap. Many of these developers shone with potential, but there was no way the resume would pass a resume screen. Staffing agencies and IBM keyword-match for specific words and programming languages that suggest mastery. You may have unbounded potential, but no one cares.3
Specialization increases your value because demand quickly supersedes supply: when I staffed a team with people experienced with contact centers, specifically Genesys Cloud solutions, the same resumes circulated to me again and again. When we gave them an offer, these people were able to bid up their hourly rates to hundreds an hour. I often searched far and wide for front-end developers who had mastered Angular and backend developers who had mastered Kafka.
In consulting, the path from junior to senior is riddled with obstacles. There is no dedication to apprenticing younger developers because there are no incentives to do so. Teams can be broken apart after just a few months, so there is little time to foster camaraderie between yourself and a more senior developer. IBM gives no tangible reward to coaches for taking time out to mentor others– you likely will not even be on the same project with your coach, so the opportunities for direct mentorship are few and far between. The client will never commit to training someone on their project because it is hiring you for expertise. The work itself can be notoriously slow, so you may not be programming anything for the first few months.
Do not expect you’ll be positioned to upskill
You need to be proactive about mastering and upskilling. This will keep you off the bench (or keep you employed), increase your workplace enjoyment, and give you an edge in the labor market if you switch companies. Recent layoffs in 2022 and 2023 make it crystal clear that no one has bulletproof job security. If you are laid off, you need to be able to sell yourself in the labor market. Quality of experience matters. In the interview room, everything you “did” (or didn’t do) will be laid bare. Will you have skills to speak of?
Do not be content simply earning a salary
A salary is like a drug. It makes you feel good, and it makes you complacent. This phenomenon is especially prevalent in consulting, one of the only places you can be paid so much for doing nothing. (You may be on a project, but no work has been handed to you. This often happens.)
Your first instinct may be to bask in what seems like a wonderful situation: You’re making money without working. However, if you are not learning anything, you are being rented out for cash with little personal return.4
I admired a fellow consultant, a developer from IBM Canada, who refused to be complacent. There was no backlog for his team. My team was a support team that helped move other teams toward writing stories and completing development on our technology, so this developer pestered my manager about having nothing to do.
It worked. My manager asked me to focus on helping his team get across the finish line, and they were one of the first to start deploying code. That developer and I became close friends.
Ask for work
Asking for work tends not to be an issue if you’re respectful about it. You may even propose a solution in a way that invites the manager to make the final call: “Do you think it would be helpful if…?” The saying, “Squeaky wheel gets the grease” holds true in the U.S. corporate context. (I understand this may be a departure from what you were taught in your own culture. I am Chinese, after all). You should communicate early and often if you see an issue– like sitting idle.
Learn to identify what you don’t know
My mother, an immigrant from China, tells me that her most blissful career years were as an entry level software engineer at Lucent Technologies. Her manager taught her that it was okay to say “I don’t know.” She succeeded at everything she did in the thirty years following because hanging on the end of her “I don’t know” was always a determined “but I will learn.”
You need to inculcate an impulse to learn. During a meeting, one of my colleagues discovered that she could not explain a key piece of our technology to another team, so she called me into the meeting to explain. She did not, however, schedule time after the meeting to fill in the gaps of her knowledge. This was a pattern. I would explain something to her, and when I paused for questions, she would say she understood everything. But when I pressed for comprehension by asking questions, she admitted she did not even know what I was referring to on the page.
Take yourself seriously– your comprehension is worth pausing for. Ask questions. Admit you don’t understand. Be the squeaky wheel and get the grease. When you show a rigor to understand everything, people take you more seriously.
Using offers to negotiate a salary higher only works if you already count as the most valuable labor in the market. A salary baseline is not labor power.
We would spin a falsehood to the client saying the switcheroo benefited them, when it was not necessarily the case at all. The ones most adversely impacted were client employees and IBM employees whose teams were ripped apart, not the head-counters that implemented these cuts nor the IBM finance teams that forced our partners to perform the substitutions.
IBM talent pipelines were such a mess. IBM hiring decided who to hire via a generic job matrix IBM must have put together years ago. The teams with boots on the ground used this matrix to put in requests. Engineers on the ground — arguably the best positioned to know the latest skills — did not interview many of the candidates IBM hired. I vetted so many Angular developers IBM hired that had no idea what typescript was. Unsurprisingly, our talent pipelines to subcontractors had higher fidelity. Agencies would send our engineers candidates directly, those candidates would complete a coding challenge implemented by our own engineers who then directly interviewed the candidates, and we would set up a contract.
This skills-based way of viewing people is wrong. We all need time to ramp up and learn. Compounded with the hiring issue I mention in the previous footnote, it stymies IBM’s ability to deliver good solutions.
This is the epitome of the statement “The laborer’s power expires at the end of the day,” for all my employment law colleagues.