Hacker News new | comments | show | ask | jobs | submit login
Working the System at a BigCo (expatsoftware.com)
118 points by jasonkester 178 days ago | hide | past | web | favorite | 50 comments



At a prior employer of mine, you accrued 12 sick days per year, up to a maximum of 120 in your bucket at any given time.

If you were ill, you were permitted to use as many of your accrued sick days as necessary. In any given calendar year you could take five sick days without any documentation, but the rest had to come with a note from a doctor indicating you were too ill to work.

There was also a company policy that stupidly tried to incentivize attendance at work: if you used no sick days in a year, you would receive a "bonus" vacation day to use the following year. Setting aside how this incentivizes people to come into work when they're sick, it also set up an perverse incentive after an employee actually had to call in sick.

Suppose you had to actually take a sick day due to illness. That day off cost you the free extra vacation day next year. Now you may as well just "call in sick" later in the year and exercise your remaining un-validated sick days.


Now you may as well just "call in sick" later in the year and exercise your remaining un-validated sick days.

You gotta love policies like these. What a way to shore up morale.


In a past life, I ran a consulting team at a BigCo whose business centered on T&M contracts like OP's. BigCo had 10k employees, mostly associated 1:1 to contracts with the same "bill exactly 40 hrs, but never overhead" constrains.

Our little team had 100 employees, but we matrixed those guys across all our contracts. While the clients disliked the idea of not having "their guy," they really liked having access to the technical depth of 100 guys vs. just the 10 they could afford. Turns out being able to have a Linux kernel guy, OS X kernel guy, Android kernel guy, database expert and hardware hacker on call at all times is incredibly valuable.

Since we matrixed across contracts, we managed to instuitionalize the "overtime hack." The guys were exempt status, so they didn't get time and a half for hours over 40, but they did get paid for every hour they worked. It was a phenomenal hack - guys were routinely making 20-50% more than their base salary. We intentionally understaffed by a bit, to make sure there were always extra hours to burn.

That team is 15 years into existence at a BigCo, and the hack still lives. If you find yourself in a consulting org and think you can make something like this work, don't think for just yourself, but shoot for the moon - set it up so it works for everyone and outlasts you.


I don't get it. What did you actually do? Multiplex their time so they worked for two clients during the same hour, or what?


To extend the other answers: the 'hack' in this case is putting everyone on every project. In a lot of consulting settings, charge numbers are kept within a small pool of people working primarily on that contract. When things are heavy, they work overtime, when things are light, they work undertime.

In this case, a team of ~100 all had access to everyone's projects. So rather than being stuck with the demands of a single client, everyone got to work overtime whenever they wanted, and not when they didn't.


No, we'd never bill two clients for the same hour. Very few (no?) T&M arrangements where that would be legally/ethically/morally acceptable.

We simply let the team bill to multiple contracts. The contract & dev managers were responsible for authorizing the time and ensuring it was necessary/suitable/etc.

A typical T&M contract considers something around 1920 billable hours per year an FTE. 40 hrs a week, 4 weeks of vacation/sick time/etc per year. The typical way to manage those contracts at scale is hire one person per 1920 hours on a contract, then that person works exclusively on that contract.

We didn't allocate one person to a single contract, but fractions of a person - based on how much we estimated any given contract would need a certain set of skills:

"Joe's 20% on Project X and 80% on Y. Valerie's 100% on Y. Bill's 80% on Y and 20% on Z."

Of course, those are just estimates and nothing ever goes to plan - and it's always hard to hire enough good people. As a result, there were always opportunities for folks to do more work - either on their primary contract(s) or supporting another.

It makes the contract management harder, but it provides meaningful benefits to both the team and the clients.


I think each contract was for 10 people working for 40 hours each per week. In effect buying 400 hours of expertise. That did not stop one of those 10 people doing 40 hours on one contract and another 10-20 hours on another. As long as both contracts were satisfied all was good.

By under resourcing the operation, employees were guaranteed to earn 'overtime' if they wanted it. However implication is that you would be happy putting in 50-60 hours.


> However implication is that you would be happy putting in 50-60 hours

You're taking a too narrow a view of it. We never committed anyone to 50-60 hours, that's unsustainable. But by _allowing_ it and building a system to manage it, you let folks work what they want and still meet the client needs.

Without that flexibility, what happens is what OP describes - folks work more than 40 because you need to / want to, but you don't get compensated for it.


It is more inclusive to use to "people" or some other gender neutral term.


nobody cares


Some obviously do.


is it still all guys their?


Your comment makes no sense.


I am from a region (rural mid south US) where "guys" as in "all of those guys" is gender neutral, referring to both male and female. I have learned when speaking to not do this.


I was pointing out the repeated use of "guy" by the parent. It implies that only men work at the BigCo. Certainly the use of guy is cultural, but it derives from a male dominated work culture.

(also I used the wrong "there"...)


I would be interested in reading any advice for developers/engineers on how to "handle" management. Based on some limited reading I've done, the goals of management and what engineers intuitively think management wants are often very different. Basically, what behaviors do I need to adopt to make my relationship with technical or non-technical managers as mutually beneficial as possible?


1. Strive to understand how your work fits in with the overall organization. Code by itself is a liability; make sure you know how your code is used to provide value to the organization.

2. When appropriate, ask your manager for more context into areas that aren't readily visible to you. What metrics do they care about? What metrics do their boss, their boss' boss... care about?

3. Provide frequent feedback, both affirmative and critical. When providing criticism, do so constructively, and always have ideas for possible solutions. Also remember that there may be other factors that you're not aware of (see point #2). Explicitly acknowledge that you're not criticizing any individual, and admit that you don't have all of the answers. Adapt your perspective fluidly when new information comes in.

4. Make sure your efforts are in line with the direction of your team, your division, the organization, and the industry.

5. Assume positive intent.

6. Be mindful of how your actions are perceived outside of your immediate team. Optics are important.

7. Make your manager's peers envious of the team that [s]he has assembled.


It almost all boils down to more and better communication. Likely, both you and your manager aren't as good at it as you could be - but you can only change what you do.

* Get to know your manager. What do they value, what do they care about? What's their style - analytical, from the hip, super-organizer, likes to try things...?

* Ask for feedback, ask for the things you want. Managers aren't mind readers. (Make sure you have regular 1:1s!)

* Ask for what their goals and expectations are, what they're looking at on a strategic level. Unless you got a heavy politician, most managers love sharing that, they just don't always know you want to hear it. (If you got "The Politician", learn politics or find a new manager)

* Communicate often. Your manager has likely a few more reports than you, and keeping up with all of them is hard. Worse, if your manager doesn't see how you're doing, you're likely more affected than they are. Make sure they see.

* Communicate clearly. If your manager is a veteran who wrote the system, sure, slay'em with jargon. If they're non-technical, or lack knowledge of the system, explain things so they can understand. Without being patronizing.

* Communicate respectfully. Both with your manager - that's just plain survival ;) - and with your team mates. Because it's your manager's job to fix those issues, and making more work is not a good way to win their heart. No matter how technically brilliant you are.

* Keep context in mind. All that info you're now communicating - do they need it right now? Can it wait? Is it turning out to be noise for them? Or, alternatively, will this lead to a crisis if not addressed urgently? Adjust accordingly. Managers are strange beasts, they both desperately want more information and are drowning in the wrong kind of it.

In other words, treat them like a human being, and treat them like somebody whom you want to help. Congratulations, you're well on your way to be good at "managing up". ;)


I think it is not enough to be good, you also have to look good. What I mean by that is you have to make sure your contributions are visible and comprehensible to your bosses. This should establish some level of credit with them. Once you have that credit you can build on it to have more informative discussions, perhaps during one-on-ones. Dare to ask.

Unfortunately, I have seen managers, technical and non-technical, who are seriously non-transparent. That is, they have and promote their own hidden agenda, without regard to how that affects others. Sorry for the pessimistic tone, but management tends to entail politics in big companies, which itself attracts those with the non-transparent personality trait.


> I think it is not enough to be good, you also have to look good.

[emphasis mine]

This rings true in a lot of large places and in some medium places. If your butt is in a chair in the office, you better be working on something. It doesn't matter if you clear your plate, took a few tasks from someone else, finished those as well, and are looking at the Software Engineering or Code Review SE sites or OWASP to help holistically contribute to your project. Your billable time better be used for tangible results that can be demoed or shown on an agile board. Never mind that you crushed estimated 50 hours in 30 - you don't get to be a warm body.


The real advice in this comment is to not finish your work too early, as the only reward you'll get is more work.


Which of course leads to trying to flex the deadlines to give yourself as much time as the other party is willing to tolerate. After all, if they were willing to budge to a new time but no further, you've just found their actual time.


Ask your manager what you could have done better. Nobody likes giving unsolicited negative feedback, if you take that stress away from then you will have a much better communication channel, which is where all other things stem from.


Simply try to understand the incentives of everybody involved. Not just the goal of the organization as a whole.


Personally, but it can be because I was very lucky - treat them as fellow humans, help them where possible. If they don't respond the same way (and try to take advantage of you), look for another job.


Your job is to make your boss and team look good. And by look good I mean be reliable, dependable, do good work etc...


I was happiest at a place where I was either paid 70% of the billed hours (client pays $100 per hour, I get $70, company get $30) with the company doing weekly paycheck (withholding the taxes, W-2, and handling the health insurance & 401k payments), or 90/10 split on a 1090 (but paid long before the client paid). I went with the 70% because I was a bit scarred of mucking up.

It is amazing how enthusiastic you can be in hour 50 with that situation. I frankly think its unhealthy but at least there was a pain point for requiring it and that pain ($) also benefited me.


Billable hours are the work of the devil. I remember my boss explaining how "I needed to work back all my vacation hours" was a good thing.


It makes complete sense (I mean from their point of view kind of sense, not the system is logical and the compensations are well structured kind of sense) but I would not have thought of the bosses point of view unless it was spelled out for me like in the OP.

In the author's case the mismatch in understanding worked out for them. I wonder how many times it works out quite badly for one party or even both. Even between two sympathetic people where both desire to understand the other, sometimes you just don't.


Most executives and managers don't know how, or don't want to, solve problems. So they dump those problems onto employees, vendors, even customers. Anyone to avoid having to do their job. Their most valued employee is the one in whom they can see value without having to work at it.


You say that like it's a bad thing. I think the management perspective would be that they're good at hiring and/or outsourcing, which are definitely good management skills to have and arguably what doing the job well is all about.


It is bad, because the managers take the bulk of the credit and reward, rather than those that actually do stuff.


You say that like it's a bad thing. Obviously a manager didn't do everything, and no executive would think they did. What they know though, is the manager hired the team that worked together and delivered the appropriate solution. If you want credit from the executives, you should become a manager and manage expectations and deliverables.


Well, I'd argue that a good manager helps his or her people get credit/visibility/promotions that should come with increased responsibility for doing the work.


"You say that like it's a bad thing."

Because it is a bad thing.


Would you please stop posting unsubstantive comments to HN? You've been doing this a lot, e.g. https://news.ycombinator.com/item?id=14573073 and https://news.ycombinator.com/item?id=14571905.

If you have a substantive point to make, please make it thoughtfully; otherwise please don't comment until you do.


Why did the employee need to fill out any paperwork to be taken off of the performance plan? Shouldn't that happen at the direction of their manager? Feels a little bit like a deus ex machina.


Have you not worked at a big company? This is 100% normal for everything.

For the required training I do because my work touches health care: The company has a record of what training I need. It sends me a list of courses. I then have to register for those courses -- within the same company. They can't register me for it on their own. I take the course, get my passing grade and now the course and my training record know that I have a passing grade for the course. So naturally I have to print that out, upload it to another site and mark it complete. Someone in India (literally) checks this. Not done yet, I fill out a paper copy by hand with course numbers and dates and sign it. Upload that and turn in physical copies to my management. If I want credit on the number of hours training I have for the year, I need to update that manually as well. Expect these forms to be kicked back multiple times on the way because the date is in the wrong format or some other reason. Also expect to take multiple forms of the same training within the same training year because it has been repackaged (not new courses, regrouped same courses).


I currently work for a large corporation. This is not 100% normal for everything. This wasn't a training, this was the fundamental employment status of the employee. I don't need to sign any paperwork to accept a raise or promotion, etc. I've never been put on a PP but I'm guessing my company wouldn't require the employee to handle any paperwork if they came off of it either.

Luckily our training system sounds more streamlined than yours. Different strokes for different companies I guess.


Tell them you don't any training on Lean Six Sigma, then ask to apply it to the training process. Never use it for anything else. Ta da!


I agree, but I have also learned never to underestimate the bureaucracy of a big co's paperwork.


Normally there is some form of acknowledgement which might just be a check box, but it sounds like the HR process was setup so that step could not be skipped.


If they change your status without you knowing or acknowledging, that opens up all kinds of legal issues.


There's a gray area between "good worker mode" and happily salaried. If they're taking advantage of that, then you need to leave BigCo. There are other SmallToMediumEvenSomeOtherBigCos out there who'll pay what you're worth; even if that coincides with 50 or 60 hour weeks.


If the latter are paying you "what you're worth" in return for 50-60 hours a week, aren't you getting paid 50-75% of what you're worth...? I think you've been fooled.


...no? Salaried jobs break the direct correlation between hours worked and hours paid, but it doesn't mean there's no plan there. There are absolutely salaried jobs which openly expect 50+ hours, it's up to you to decide if the salary matches the expectation.

(There are plenty of jobs which aren't upfront about it, obviously. That's more of a scam.)


I had a guy work for me once, I was trying to transition him from hourly to salaried. He had some longer weeks prior to this, and made the assumption that this would always be the case. He said, "I don't want to do this, because I will make more money this way."

Sounds like the article, right?

Except ... this extra time was a very temporary scenario, and he would be getting benefits, an effective hourly raise, etc. Even more to the point, when we didn't need his services ... and he didn't grasp this part, we wouldn't bring him in and pay him, though, as a salaried person, I would expect he would be doing self-education while we had "down" time, so he'd increase his value and utility to the organization.

Basically, I was trying to provide value to both the company and to him. As we were a very small company, I was able to see the value aspect very clearly, and I made the bet (later proven wrong as it turns out) that he would make a stronger contribution to the company if he had a steady source of income, with less worries about billable hours.

The big reason why he was getting more hours was that he was helping us set up our lab space. That project was almost complete ... maybe 2 more weeks of longer weeks, after which ... we'd need him 25%-50% time at best. I did need someone with expanded skills that he didn't have, and thought (mistakenly) that I could grow this particular individual into that role ... he expressed a strong interest in it.

The incentives aren't usually well aligned in BigCo and employee. We are, effectively, cannon fodder, for their plans, up through and including the senior exec ranks. Your incentive alignment with the corporation varies inversely as some power of the distance from the strategic decision making.

In SmallCo and employee, there are typically better alignments, though still not perfect. For someone like me, an entrepreneur CEO/CTO at the time, I was looking to build a culture, an environment, where we took a long view, beyond the next billable event. Where value took time to grow, where we cultivated it, where we grew people into roles that they wanted but might not have been able to do at the time.

The problem is, when you are sufficiently removed from the decision making process, your alignment is entirely economic. When you can't impact outcomes, and gain professional satisfaction and positive reputation from helping to steer a better course, your focus is, correctly, on other matters that benefit you personally.

To a large extent, this is the way things work. What benefits you personally and professionally, and is the compensation, work, and culture, aligned to mutually maximize the value of all of these things. In the case of the OP, no, the compensation was specifically architected to minimize cost to the BigCo, and maximize the benefit to the big co, even at the expense of the employee. Which would, undoubtedly, negatively impact the culture, and the way the employees interact with BigCo.

I am sorry to say this is to be expected ... but it isn't the first time I've heard this type of story.

For me personally, I remember working for some small silicon valley outfit in the 90s, where they treated some of the specialist developers like crap, but paid the contractors something like triple the hourly rate to use their expertise. So, a fairly sizeable cohort of my colleagues resigned, formed small consulting groups, and were hired back at (then) outrageous rates to do effectively the same work.

This misalignment is manifest in many large Cos.


Hey... that sounds similar to what happened under the Howard Government in Australia. The then new PM John Howard thought that the bureaucracy was lazy and bloated (and in some ways, it was). So he sacked a good proportion of workers, and set about his legislative and national agenda, only to realise (much like Trump is now!) that you actually need people to make this work.

So not able to increase the numbers he employed, it was decided to bring in contractors to do the same work. Many of them were former workers at the same departments. However, there were less of them, but they still cost a lot more. Then the government started to realise they needed some way of overseeing their work, but they didn't have enough staff to do so, so they employed people to check on the contractors' work. As the workload was still high, they kept employing more contractors, and you guessed it - more supervisors.

By the time Howard left office, he was employing three times the number of people than the previous Labor government.


TL;DR It is a case of organizational incentives being poorly aligned with individual incentives.


And managers not understanding what their employees were doing. In this case, they understood the technical side, but were not paying attention to the financial side.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: