Why Good People Leave Large Tech Companies
thinkgrowth.org
thinkgrowth.org
The saddest realization I've had working at companies is how power-hungry people are, how little respect the people in power often have for those "below" them, and how important politics is even in a field like engineering that you'd expect to be meritocratic. Sweeping decisions are often made in a small room of a few "higher-ups" without any input or regard for those "below" them. Providing counter-arguments that question the decisions of the executive caste is often seen as a threat (how dare you question your leader?). The shy and humble rockstar coder who kicks ass gets little recognition while the smooth-talking sycophant gets accolades and climbs the ladder.
Corporations are authoritarian tyrannies with strict hierarchies. America was founded on the principles of democracy, but we tolerate tyranny in our workplace. The only way to change this is to remove the asymmetric dependency of the employee on the employer (eg. UBI).
I personally love it when higher-ups make a decision without consulting me. Because then I have zero skin in the game. I don't work ridiculous hours. When I am involved in decision making, then I make sure project succeeds. Sometimes that means working late hours, taking pro-active steps to remove blockers etc.
But if I am told what to do without consulting me, then I don't care. There is a lot less stress on me. If it appears decision was stupid and project will not meet deadline, I make sure everyone knows and rarely ever put in more than 40 hours on such projects.
I envy people who can change into "I just do what I have to do"-mode when they don't have 'skin in the game' ... I always feel as if I have skin in the game and get stressed even on the most ridiculous projects where I knew (and stated) from day 1 that this just won't work the way it has been envisioned by higher ups.
You need to remember, whether you put 40, 60 or 80 hours p/w into a death march project, won't be recognised. Everyone will be too busy to tally who's working more. By sacrificing more of your free time, you are just working for free for the people driving the project, who may be doing this purely for political reasons. You will also make it more likely for similar projects in the future.
I maintain it's better to not overstretch yourself and let the project fail. Better for your health, and better for the company, so they manage the next project better and have workers who aren't burnt out.
Yes, there needs to be a captain of the ship, and when she tells you to do something, you fucking do it because that's what captain means and you can kvetch about it when you're back on land.
But if the captain is making all of the important decisions, something has gone terribly wrong and your boat will not function. The captain is there to
1) make small changes necessary to stay on a long term course
2) push decisions through in moments when speed is critical
3) break conflicts that can't be resolved
They are not the chief achitect or the chief strategist or the chief anything really.
And if you are both the captain and the chief strategist, you need to recognize that you're playing two roles in one body and you need to be very aware at all times of when you're wearing the captain hat and when you're not. You don't get to boss people around when you're doing strategy.
When I started out, my goal was to have a meeting every week and to include everyone. It was a waste of time. People would throw out ideas they had no intent to pursue, and when they were not talking would start fiddling with their phones.
You'd be surprised how many people don't value other people's time, or even other people's ideas. It's easy to imagine you could make a difference or be that difference, but if you truly believed you should have a say, then you should make it known, and either prove yourself, or find a job that comes with the satisfaction you desire. Like, maybe a more team oriented environment.
The truth is, especially at a large tech company, you are replaceable. No one is asking for your personal touch be it at a Foxconn assembly line or an engineer at Cisco. Unless of course, your job title includes "designer" or "architect" etc. But otherwise you're there to do the impersonal work you agreed to do for the impersonal money they're paying you. That's all a job is. You get more for better skills and more experience / less risk. All they are looking for is a guarantee that the work will get done.
This isn't to say you shouldn't have fun or that you shouldn't make the most of it. It's just saying that if fun or "most" entails being heard by execs or barking up the tree, then you will pay for it one way or the other; either with your emotional well being, or with lower pay due to greater overhead for being noisy and needy.
Managers are paid human sound barriers that permit lower quality hires for less pay. This is an important role, as are those being managed. But to think you can get past the manager who's very job is to silence you is the wrong approach. Don't raise your voice or kick harder. You need to become a manager. Either that or go work at a smaller company where the CEO sits across the room.
This will sound harsh to many, but I believe it's basically true. At large companies, the innovation has already happened; they found a market and are now mining it. Very few large companies can continue to innovate (Apple being the main example), but the rest just ride off into the sunset. Sometimes the market they're in evaporates, and they die, but usually they muddle along.
Venkatesh Rao[1] wrote a series of blog posts on this that are frightenly accurate and jive perfectly with my experience.
[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
This isn't to say it isn't important. It is, and that is why they will spend time and money on it. But if, say, the cash is low, these are things that go, and rightfully so if it's to stay in business.
And the kicker is, the guys that run the show, the guys that start businesses and come to work with a mission, the guys everyone seems to want to be -- they don't need anything. They're already as motivated as can be, take on all the responsibility, and even sign the checks to pay everyone AND pay for the things they believe they will make them happy.
And this truly is the paradox. There is nothing cushy about an executive job, especially at a tech company. And I'd say never at a startup. It's cut throat as fuck. If you can't deliver, you're out. You should be out. Everyone is watching you, and everyone will complain. But you have no one to complain to. Having someone to complain to, having excuses, these are all pirks.
But if you can deliver, then you have professional freedom and high reward, at least in a capitalist economy. Then you get to make life cushy for yourself if that is what you desire.
At the end of the day, the "subordinates" are the ones actually doing the far majority of the work, and they far outnumber the managers. I don't see why the workers shouldn't at least have a seat at the table when the decisions are being debated that would affect them. Often the managers are so removed from the work that they lack a lot of the insights from the front lines.
The most common rebuttal I hear when I bring this up is, like you said, "too many people makes things inefficient". Bullshit. Sure a decision ultimately needs to be made, but there's no reason one shouldn't be allowed to provide input.
And in my experience, I do think it's more about people wanting to feel powerful, and fear of losing this power (eg. like the other commenter who mentioned fear of "power inversion"). The people in power are generally the most sycophantic, and thus have the least interest in interacting with or relinquishing power to subordinates because it doesn't personally benefit their position of power or ladder-climbing question.
If a bunch of executives make a bad decision, then "oh well, there's no way we could've known". If a bunch of executives make a bad decision after a meeting with subordinates who questioned their decision, then it makes the executives look bad and threatens their judgement and position of authority. So from a selfish perspective, it's better to keep the minions out.
Everyone should have a voice but not everyone needs to literally be at the table. Seeing companies go from small to larger and seeing how the flat structure begins to show caveats as a team grows, I agree everyone should have a voice, but ultimately a decision needs to be made and a big group of people are never going to agree on everything. You can bikeshed all day on which CI platform to use for example but ultimately a decision gets made by someone that there has been enough discussion and this is the platform to use.
That process can be horribly perverted and have the wrong people making terrible decisions but that is a separate problem, not a problem with the idea of consolidating many voices into a decision.
Else, as first poster said, the process is tyrannical.
Not every business decision requires every single persons input either, and although you may be affected that doesn't mean your input was as valuable as everyone elses. The CI team's choices might affect my branching structure. Tough, that is their responsibility. If it's extremely detrimental then you can raise concerns, talk to people, get out of your seat and work with the humans around you.
We don't need another revolutionary management fad, where a hundred employees sit around a satiricaly large table and vote by show of hands. That works amazingly at small companies and it's why I prefer to work at them. But let's get real, management at scale is hard.
Ultimately though, if you feel like you don't have a voice where you are, work to get a voice, or find a company with a structure that works for you.
It honestly depends on how much skin I have in the game.
The founder of my company spent years using his own money and getting personal loans to fund it. So the decisions that he makes directly impacts him.
A lot of the managers here also grew with the company and have invested years of time and money.
For me, this is just a job. It's a good job, but I wouldn't really be willing to sacrifice anything for it. I would leave for another job before it came to that.
I think a more fair way might be how law firms set up partnerships. If you want to be a decision making member, you have to put in a substantial amount of money.
I've been in this situation a few times and it's very hard to push back on a decision that's been 'made' even if it's not appropriate for the team you're on.
Nothing against the CEO. He's an extremely friendly and approachable person. Most people just fear questioning authority and power, and the CEO in a modern day corporation is revered similar to a king in a monarchy. It's always been like that at every company I've worked for.
My company sends out periodic anonymous surveys as an attempt to garner feedback from the employees.
The only problem I see is if employees, for whatever reason, don't believe such a system is truly anonymous and thus refuse to give honest feedback. I don't see that being a common trend though.
If so, it probably signals more serious problems between employees and the higher-ups ...
I personally will never trust any such survey at work.
Not that I give a crap anyway, I still tell the truth knowing full well it might be used against me. If they can't handle honesty, they need to surpass 16-year old mental age. And I can find another job before my notice period expires.
a) What was decided (obvious, but you'd be surprised how often people disagree)
b) Why it was decided - Now you can construct a basic "Given X, Y, and Z, it seems like a good idea to A and B"
c) The criteria for success or failure - how would someone who did not make the decision know whether it was successful or not?
Without all three, you can't make empirical decisions and then follow up on them. Decisions without any of those three are unmoored from reality.
It's like in chess, when people talk about making "principled" moves. It means playing the move that best fits the plan you have been pursuing, rather than a tactically more tempting move that is less consistent with your overall strategy.
Democracy is coming to the last bastion of dictatorship in modern western world. It won't be pretty - but it will lead to better companies
But public company democracy is hugely problematic; modern shareholders think as a herd and work on 60 day time scales. Fortune 500 companies need diverse signals (and sophisticated risk management) and visionary management - creating processes, people and markets over decades. This is the model of the private market, but sans the potential for fraud and collapse.
It still is a feasible idea imo. And would lead to an lot of new agm items !
There's definitely a loophole with "too big to fail" companies. Maybe those should be run more democratically. I'm not sure, I've never worked for a company that couldn't just fail if it persistently made the wrong call.
Just take simple comparisons of population (I know I know) and the smallest states like islands have tens of thousands - of the 233 nations in the UN we reach only 100k people at 200, and companies like Bank of America employ more people than "real I have heard of them" places like Iceland.
So I like the idea of just letting companies fail - but putting half a million people out of work is pretty bad.
The problem is exposure. Those people will capture all of the upside if they get it right, and their subordinates will take the downside when they don't.
In this field, we can in fact move, so "love it or leave it" is not a hollow demand. People in some other fields are far more stuck. A military officer's career is over if he says no to the hierarchy he is part of. He may find work after the army or navy, but it will be very different work, effectively the start of a different career. We on the other hand can move pretty much down the street and do very similar work.
Relying on your loyalty to be rewarded is a fast track to being played for a sucker.
While America was founded on the principles of democracy, didn't they make sure that only a select group of people could participate?
In that way, it's similar to how companies are run, with a select group of people making decisions.
For example, very few people are willing to leave their cushy jobs and grind it out a few years at a startup that might fail.
And sadly, I believe that even with UBI, people will still play their power games, do politics, all that. There might be less of it, but either that is part of human nature (if there is such a thing), or else it would take a massive change in society to make petty turf wars and office politics disappear.
Probably if we're talking engineering bureaus in late 1980-es. But even then the setting is quite Dilbert-esque. At best, the democracy was like you can go to hair salon at working time, but not like you can affect any management decisions or working process in any way.
It can be in part explained by the fact that there was no relationship between how productive or hard-working the bureau or individual is and how good payment is. In fact, at the salary was most of time constant for any given profession, the situation didn't incentivise hard working, so it's not a surprise if there was little production pressure at workplace. Which leads to one of reasons of failure of the USSR.
The key to have an impact is not to pose critical questions, but to make constructive suggestions. Instead of saying "you are doing this wrong", suggest how to do better. Good leaders appreciate and encourage this, in particular if the request comes in an actionable format, i.e. "I suggest to do X in order to achieve Y" is much better than "decision Z is stupid".
In those cases, as the underling, it's better to offer a suggestion because they can run with that.
Of course, it's easier said than done. Especially if you're busy, you know, doing your job, it can be hard to find the time to sit down and find solutions to what is probably a pernicious problem if it's being elevated to leadership.
When Steve Jobs Refused To Give Early Apple Employees Stock, Steve Wozniak Offered Them $10 Million Of His
http://www.businessinsider.com/steve-wozniak-gave-early-appl...
Amazon could also be another interesting example
Reminder Amazon treats its employees like shit
http://gizmodo.com/reminder-amazon-treats-its-employees-like...
In a workplace, if you are unhappy with how the management run the company, you vote with your feet and leave, nobody's forcing you to stay.
If you want to hire people, drop the attitude of "we don't want people who aren't willing to prove how much they want to work here". Instead, give them every reason to want to work for you.
"OH, the candidate dropped out of our recruiting process? But he was only at interview four after 6 weeks.... well it doesn't matter because clearly he didn't want to work here enough - we want people who really want to work here and are willing to do what it takes to get a job with us."
Even worse: "But he'd only done our coding test after 5 weeks, there's still three interviews to go."
The recruiter usually gets a phone call at this point "Got anyone else, this time someone who actually wants to work here?"
It seems a lot of C*Os forget this after a while. For a lot of rank and file employees the stock price makes no difference.
Here's an example - say I'm hired with 1000 units of stock over four years. Each year I receive a refresher grant of 250 units of stock, again vesting over four years. Once I reach Year 4, my stock compensation stabilizes, assuming my refreshers remain the same (I'm am obviously grossly simplifying - you could be promoted and get larger grants, the company could do badly and your dollar value be significantly reduced).
But what you can do, and what the parent is alluding to, is jump ship around year 3-4 and get the company you're going to match your current amount of outstanding stock, meaning your initial grant becomes much higher, and your refreshers do too. At least, that's the idea. It's worked for me.
Additionally, although personally I did very well on my refresher grants I know other people at my employer did not. So that's another factor.
Some places offer a bunch to start, but very little after that, which means people tend to leave once they have vested all their options/RSUs.
After the first year, sometimes your vesting schedule will be monthly, quarterly, twice a year, or once a year. As to why they don't allow everyone to be monthly - it's probably because they get to claw back a fair amount of the equity if people leave.
I may be being a little cynical, but if you vest annually or bi-annually you can get a pretty good idea of when your employees are going to leave and use that to plan your crunch periods accordingly. People are rather unlikely to quit the month before the annual vesting date.
To me, the first rule of rewarding someone is to make sure the recipient did all of the work before the reward. If you make them work afterward then it sours the desserts.
I would end up holding onto those little blocks until the next batch of original stocks vested because I had to push a bunch of buttons like a monkey (in a UI designed by monkeys) for a couple hundred bucks. Which just reminded me that I could be making more money and a bigger impact working just about anywhere else.
And then they cancelled the only project that any of us thought had any strategic value to the company. So my direct manager quit. Then someone else quit. Then I gave about 3 weeks notice, but was the 5th one out the door because 2 other people resigned in the week after I gave mine. In all about 8 people left in something like 12 weeks.
Because we all quit right after the end of the fiscal year, we were all owed a bonus from the previous one. When we got the bonus check (mine was a little over 2 month's pay, but the majority of the others got better reviews so got bigger payouts) we went out for beers. Someone, probably me, asked if it was worth it to stay for the last four+ months when things started going sideways. Only one person said yes, out of eight.
For executives and directors, I disagree completely. The shareholders are paying them to make and execute decisions that will grow the company (and share price) over a long period of time. The share-based compensation plan should reflect (and help align) that they are being paid to make long-term decisions.
Those are inherently "promise/award before the hard work is done" type of grants as I see it. (Why would I pay you more for a decision you've already made or work you already did, unless we're just talking about a modest spot bonus for a job well done?)
Also, stock options are worth less than nothing several times over if you are not in a position to make decisions. First, they're issued at market rate, so since they're options and not a stock grant, after fees you'd lose money selling them. Except you can't sell them because they are pieces of paper for a year.
And I know this will stick in the craw of a lot of developers, but as a non executive, any control you believe you have over the stock price is either tiny, illusory, or something the executives will take away if they notice. This is their game and to them you are a pawn, no matter how brilliant and indispensable your team and boss think you are. If you're affecting the stock price then it'll be up or out for you. You'll either be made a manager or treated as an unwanted variable.
Others do performance based refreshes, so job hoppers often think they’re never getting more stock, because they had their eye on the next gig or their side hustle or whatever.
>> "(By coincidence, the CEO was an intern at one of my startups more than two decades ago.)"
Admittedly, this isn't adding to the discussion at hand. Just one amateur writer picking apart another's writing style, but...
Is it just me, or do those lines serve no purpose except to boost the author's own ego and sense of self-importance?
I feel like they don't serve the reader in taking away the lesson in the least. They really strike me as an attempt to remind the reader of the writer's own value and importance.
Maybe I'm being too cynical...
A) Repeating what Steve told him and Steve had changed his mind about that advice?
B) Repeating what Steve told him but in the wrong context?
e.g If you read some financial advice on a random blog you might ignore it but the same advice coming from Warren Buffett will be taken seriously.
When a product innovation company turns to medium size, the process comes in with the executives and soon after innovation dies, but the product market value is realized and efficient. The problem comes if the leadership isn't repeating the cycle.
A company can thrive if they stay innovative and invest in new products always though, most of those companies are engineer led because it leads to happy development/value-creation: Amazon, Google, Microsoft (except for the Ballmer era), Valve/Epic in the gaming industry etc.
[1] http://www.cs.cmu.edu/~chuck/jokepg/joke_19970213_01.txt
One of his lines (verbal in person, not on paper) was "If you don't want to work here, there are plenty of people that do."
He was the only boss I've ever had that made me consider leaving a job I'd had for 7+ years (at the time) simply because of who my manager was. Needless to say, about a year later when he called a meeting to announce that he was leaving for a competitor, my back popped as my shoulders un-tensed.
I scheduled a 1:1 with his boss. Half hour meeting, didn't tell my boss what we talked about beyond "a discussion about my career". My manager didn't even come up in the meeting.
Instant improvement in manager's behavior. Assholes know they're assholes, and the appearance of connectedness (along with deliberate efforts to keep them off kilter) is usually enough to keep them in line.
With the first you can prepare for their fuck-up, with the unknown things could be a lot worse.
The only power you have in this case is to go elsewhere.
It went something like this.
Dev: Can we get 2 21" monitors for developers?
CFO: Why? Laptop LCD and that old 19" monitor seem to work together just fine.
Dev: Yeah, but we can be more productive if each dev can get 2 x 21 inch monitors.
CFO: Uhh, no. I get more year end bonus for every dollar I save for the company. So maybe we will revisit this later?
Doing work with a 3rd party firm on some simple dev work (integration into a few partner APIs). We're a big Azure customer, 3rd party knows this. Gives us ARM templates for resources needed to deploy.
Get on the phone with the IT folks internally, state we need these ARM templates deployed and monitored. Queue two week (plus) process, 100 questions, and department to department costs (all of it is outsourced) which are quite outrageous.
The costs are so high that they probably wash any revenue/profit from the partnership.
You know what? I have access to one of our Azure subscriptions. I'll just do it myself guys, to hell with the consequences.
Usually this results in noise later, but screw it, I made us money now versus incurring additional cost and made some money later.
Thankfully I work for someone who thinks making money is more important than self-imposed rules that in most cases just slow us down.
Problem is that, without that bureaucracy sometimes ,'defectors' as Bruce Schneier would call them, will take advantage of those systems and use them for their own personal gain. The "this is why we can't have nice things" rings true for a lot of things related to purchase, money, benefits, etc.
Same is true for many of these processes that are put in place. Everyone just needs to remember once in awhile that we all work for the same place, and all want to make money.
Best of luck either way, just remember humans aren't rational agents by any use of the word.
So I see what you're saying, but it's not an issue here.
As an aside, one shortcut to weeding out shitty companies is to simply filter out companies that say shit like, "we are on a mission to change the world." That's a guaranteed bad time.
I just want to work on interesting business problems, just like many others just want to work on interesting technical problems.
How could there even be dozens of companies that you'd want to work for at any given time?
Well, those people dodged a bullet, then...
I was puzzled that I would be interested in working for so many different places. I now realize that some people seem to simply not care where they work, at least at the apply-for-job stage. That was the piece that I was missing.
Still, having done my training at a slightly Dilbert-esque multinational corporation, I made a point of working for small-ish companies since.
Of course, small-ish companies bring their own share of problems, but all in all, I prefer that smaller companies tend to be less bureaucratic.
And I like the personal touch - at one company (~15 people), the CEO/co-owner walked up to each employee every morning and greeted them, shaking their hand. He was in some aspects a fairly difficult boss, but that little gesture made up for most of the difficulty.
The problem with a company treating employees like they were arbitrarily replaceable is that employees will treat the company the same way. If a company wants employees to identify with the company, to want to work at that specific company, it has to do better than that.
Do not confuse difficulty with prudence. Your organization will become slow and ossified by default unless you take specific steps to maintain flexibility. One of these steps is to install a culture of change. Things that are easily undone should not require approval to be done in the first place.
Do not allow long-timers in your organization use "caution" or "good engineering practice" as an excuse to slow everyone else down. Emphasize that the most important part of software development is moving fast. Let new people try new things. Minimize the number of people who can say "no".
Most of all, do not just _believe_ people who talk about best practices and software "quality" and stuff like that. Most of the time, they're just finding fancy-sounding ways of saying "nothing should change unless I say so".
You really can't make categorical statements like "formal process is the enemy". You put formal process into place, and that creates a dialectic where you're waiting for someone to come in and champion the antithesis: "formal process is the enemy". Then that works for a bit until it doesn't and someone synthesizes: "sometimes formal is better sometimes informal is better". Then that becomes the thesis.
Then there's a new dialectic in place. Someone will come in and say "the character of our company is such that we're generally better with formal processes". Then someone synthesizes that, and suggests that all processes are on a trajectory from formal to informal and the company is good at expediting that.
Then someone realizes we need a process for regular deformalization.
This continues forever. None of these ideas are really that much more generically true than any other.
So to embrace Hegel, the goal is just to question yourself as far as you reasonably can, so as to get the best view on the current situation and only the current situation. Make a choice and move on, knowing the next situation is likely to be different.
Edit: I should add this is the process by which we hurry into The Future, which some people might point out means turning our backs on Everything That Is Holy and is therefore a tool of Satan, but I'll leave you to explore that with the rapidly growing universe of anti-Hegelian YouTubers.
Being unwilling to adopt a necessary amount of structure and process is just as much of a hindrance once you hit a certain size.
That may be a newer or less common problem, but it's a very real one.
Every change I proposed was questioned to death and generally dismissed, I was micro-managed within an inch of my life, and I found the two key Directors just could not let-go of any control of their 'baby' (the company), to a point where any tasks I tried to assign to team members were met with pushback because the Directors had already assigned them other things, told them to work on other projects or asked them to report back before accepting any work from me.
One time when I was asked to work on a proposal to take over the migration, management and support of the Intranet for a large local University, I completed the initial RFP document and reported back to the Directors with a plan for a meetup with the potential customer because some key points needed elaboration, and some of the SLA terms could not be met without additional team resource, but they told me they had already phoned the Uni and agreed to go ahead 'as is'.
I left after 9 months.
No, that is not the case most times. The most important part of software development is, as with any other part of the company, to maximize the value of the company. That may be speed, but if you have 1m users the most important thing may be to preserve trust, to acquire new customers, to automate existing infrastructure, etc. etc. Speed of software development is not a goal in many environments. Thoughtful execution may be hindered by a cowboy attitude in development. I'm not saying that speed in development is not sometimes the goal (maybe in startups within an enterprise trying to test an idea), but often it's not the most important thing.
To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge effectiveness multiplier for top shelf dev teams. Slow development merely enables lazy programmers (since it conceals their apathy) and gives us waterfall disasters. "Thoughtful execution" is possible in any context, and most thought processes are greatly enhanced by evidential techniques such as rapid prototyping / feature spiking.
Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit.
In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.
Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization.
It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act.
A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!".
It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.
The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge.
I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).
Enabling people willing to act is important though and I fully support the do nothing aspect of failure, or better yet support and stabilize but not reward.
I think that's the key thing here. Rather than saying "whether you succeed or fail, you're still gonna get your $250 bonus", you're saying "if you try and succeed, you get $500- if you try and fail, you get $100, if you don't try at all, you get nothing."
I admit to inheriting a fairly smart-risk-accepting technical culture, but also worked to extend and cement that by holding regular blame-free post-mortems on production problems and reporting them weekly to our business operations meeting. Making failure and the analysis/correction thereof a regular part of company operations makes it normal, accepted, and less scary. We would also pretty regularly respond to asteroid-type production problems with "no preventative action intended; cost of prevention exceeds expected losses". (We held a view that there is [conceptual process] green tape and red tape; make sure if you're fixing problems with process that it's actually green tape and if fixing a problem required adding red tape to the system, we were very skeptical and tended to avoid adding that process/step/gate/check.)
Couple that mindset and transparency with a metrics-supported track record of making things better overall and management will support. I'm not sure our CEO ever saw any of that sausage-making, except for the very largest or most damaging problems and even then, it was mostly a courtesy message to him. He cared about the overall pace and metrics, not how many outages or bugs we had along the way.
The ratio of students that decided to major in engineering because they were good at math in high school vs. the students who decided to major in engineering because they they wanted to make something inspiring, I feel ( and let me stress my inexperience as a current undergrad, without experience in the actual field ) is vastly favored in career growth towards those that decide to create instead of simply learn.
While there is always room and lucrativity to tie engineers on a leash and juice mathematics and logic out of them until they reach an existential crisis, there is always (ALWAYS) room within the budget to let them set out upon a path which is in tune with their not necessarily young, but foolish and hopeful beliefs.
There's nothing wrong with process and best practices. Process is often scar tissue left behind after critical mistakes in the past. A company without some formal process is a company young enough to not have made disastrous mistakes yet.
I've worked in a company of more than 50 that was basically without a trace of software development process. It was a clown circus. Nothing could be released on time reliably, quality was a joke, there was no documentation, no code review, and no plan or roadmap. Sure, they moved fast, but it didn't matter.
This doesn't seem to me to be true. Can you expand on your thoughts here?
I'd agree that the ability to move fast is an essential part of effective software development, but I don't think it's the most important (the most important is producing business value accurately and reliably), and I think that moving fast for the sake of moving fast is likely to result in moving quickly in the wrong direction. In particular, it's easy to be so worried about moving fast that you have no time to take new business needs/opportunities into account (see also Tom DeMarco's Slack), and it's easy to get excited about shiny new technology and spend a lot of time implementing it and roleplaying Google for no reason, which is a great way to move very quickly while not delivering a cent of business value.
Finding somewhere with formal process, with full-time managers who aren't reluctantly moved to management for career advancement, with clear hierarchy and goals, was an important part of my most recent job search, simply because, as a good engineer, I hate to see my work go to waste. I have heard the same sentiment from lots of my talented friends.
By default, all software development organizations slow down. I say that developer velocity is the most important goal because, without focusing on this velocity, you end up solidifying, like a cooling lava, and it becomes difficult to accomplish any of your other goals.
I can make the exact same argument about automated regression tests. As the size of your codebase grows and the number of customers (i.e., people triggering edge cases) grows, unless you take conscious steps to make sure that every build doesn't regress previous bugs, all your effort will get sucked into diagnosing and fixing things that you've fixed before. And all your developers will be fixing bugs but you won't be fixing new bugs and certainly not shipping features.
In particular, if you want to refactor / rewrite parts of your code to improve development velocity, you'll suffer from the well-documented problem (see e.g. https://www.joelonsoftware.com/2000/04/06/things-you-should-... ) of losing all the knowledge of the weird edge cases you've fixed along the way. So, testing is strictly more important than development velocity!
I can make the same argument about a half-dozen other development best practices, and I'll have actual citations to back them up. Why is development speed the most important goal, why is formal process the enemy of speed (instead of its friend, because it makes sure work doesn't get duplicated or wasted!), and what is your evidence for these claims?
In particular, if your claim is true, we would not expect to see as much feature development / new products from old, large companies (I'm thinking of Oracle, Microsoft, Apple, Amazon, etc.) as we do. We would expect to see these companies grind to a halt and perform poorly in the markets (investors really want to see growth, not just continuing to be as good as you were last year), and that's not what's happening.
It's not a question of preventing formal processes, doing that indiscriminately is a recipe for disaster; every engineer will do things their own way, and once the head count exceeds the ability for everyone to talk to each other daily, there will be an explosion in complexity and duplicated effort. Rather, you need to put in the right processes, maintain them just as you would code, and kill them when they no longer serve the company. Where "process" goes wrong is when it's used as a hammer to address issues that would be better served by team structure, common tooling or architecture. For instance, if you have a quality issue, adding more code reviews will generally cost a lot more, and do a worse job than making the responsible team wear the pager for their own code.
The real secret sauce to staying agile as a company grows is small, cross-functional teams. This is where SOA (microservices for the kiddies) really pays for its overhead—by decoupling human teams and giving them agency. This won't make a big company as agile as a startup, because that's literally impossible, but Amazon and Facebook have shown how much more agile it can make you than any prior megacorp.
Funny you mention microservices, because I've been thinking about Susan Fowler's book about them and how the advice is basically "Here's how we made sure that we kept up our agility by introducing tons of process before anyone could think of deploying a microservice, because otherwise every team would do literally everything their own way and it would be great until it turned into an unquenchable tirefire."
I'm not aware of Uber's technology organization having stopped producing business value. That company has a lot of problems, but the inability of their software engineers to engineer software doesn't seem to be one of them.
You also have the situation that people invent rules and requirements in the absence of a documented process, which can change arbitrarily and are impossible to work with because it depends upon the changing whims of whoever feels they are in charge. Clairvoyancy and divination should not be a job requirement!
Process becomes problematic when the process grows and ossifies and becomes the end itself, rather than the means to an end. You end up with it being impossible to get work done because the process is so burdensome. When your bosses care more about the process being followed to the letter rather than the actual completion of the work which the process should be enabling, that's IMO the point where it needs a rethink. Unfortunately, organisations have a tendency to accrete the stuff; I've in the past argued for less to the amazement and incredulity of my bosses. It's also a factor that process is used as a blunt instrument to wield power over others, and I think that's certainly a driver as well. But often organisations favour accountability and rules over creativity and efficiency, even if you spend 95% of your time with process, and 5% actually doing productive stuff...
In reality these are ignored at times when required. But they're so embedded in company culture that you need a pretty good reason to do so and more importantly most employees are comfortable challenging management when they do.
I'm not sure how to replicate this but letting employees set the company values once you get to a certain size is likely a good call.
Could you please elaborate how that worked technicall? Does that affect git log authorship metadata? What about discussions on company chat/maillist about the issues being worked on, are they also anonymous? Does this make tracking real contributions of individuals impossible?
If you don't consider jobs and companies as something that should live longer than you, it's totally fine as it is. Switching jobs is not a big deal, if you have lots of new options and get paid well. When small start-ups get the next innovation loop better than the current set of big companies it's fine, because people still make money, just a set of different people.
People who want to make money by working, still make money. People who want to make money by investing, still make money. New innovation really happens, no matter if the current people on top get it or not.
Vertical structures create encapsulation of individuals and that leaves room to exploit information asymmetries.
e.g: stealing credit, favoritism, etc... rigging the game to their favor.
At the late stages of this game, people like this can get away with anything: hiring and promoting their friends, openly insulting people, just openly lie knowing nobody can do anything about it, etc.
However, I'm sure many companies meet that.
From dubious acorns doth startup management gurus grow.
Most of the narrative doesn't fit as this article presents it ( it might still be tesla, but you can assume the details are pretty one sided )
Neither CFO Tesla has had went to Stanford.
Can't find anything about Dorsey working at one of the startups listed on the author's wikipedia page, but he seemed to have been involved with many so it would be unsurprising if it just wasn't listed there.
Private equity firm cuts out RSUs and focuses on eeking out high margins without raising salary compensation to offset changes. All the senior people from Startup A and a number of senior people from B all jump ship within 6 months.
I'm just speculating that there may be more developers who are happy with the East Bay location in the wider pool of developers, not that this was a good move for the then current employees.
Hopefully they don't wise up.
Some do impress but others have limited lateral experience and so don't fit very well into any place but at prev bigco. But, but, I have five years of experience in X at bigco Y.
That is what I read from this article. Though all is speculation as there is no real information in there apart from a quote you can be for or against.
This is not "why good people leave large tech companies". It a sole example of a very small group in a very specific situation. Relocation loses people yes. But not amass and not as a hidden thing. The company is well aware of it. The quote itself was there for years and it is not why people left.
Large tech companies that loose good software people for instance often do so because they apply their hardware processes to software teams as well. In addition they don't want to spend money of software, software has to come for free right! The hardware is expensive but the software is a thing we had to add as cheap as possible. That means deny requests for fancy work setups; my hardware guys can work with one 19" monitor why do they need 2 24"?
Have no separate career ladder for the technical people, I.e. You can only grow into exec or fellow if you switch to the people's route and forget the technical (I.e. General managers, directors etc but no levels above lead software architect of a (smaller) department).
Now that loses people.
P.s. I work in a large tech company. 100k+. We recently resolved the last part but not yet entirely the former. Coincidence is that I'm being relocated in January 2018. It brings about 20 minutes additional travel time for me, but for most others it doesn't. Like the article. However, I'm not seeing how losing me (and some others) would outweigh the benefit of having the entire NL software group in a single location.
It's not merely about the decision to relocate, it's the indifference towards the engineers and viewing them as dispensable minions who are lucky to have the privilege of working for this company, often without the equity and earnings potential of early employees. Treating your workers as disposable pawns is a sure-fire way to generate disillusionment and cause valuable engineers to leave.
In a big company most people don't like all of their exec and HR statements yet they continue to work there because they know 90% of those statements is bullshit anyways and will not manifest. Very different from a small company mind you! Big companies change their bullshit slogans every 5-10 years. It's a pattern. Go through twice and you know the drill. So you smile when your department name changes and know the rest will stay the same no matter your objectives containing some new fancy words.
Moving headquarters 5 miles in any given direction is going to help some people and hurt other people. We just went through this ~20 months ago and some people who were on the "hurt" side have indeed left because their commute got pushed over a pain threshold. But, if we'd moved 5 miles in the other direction, a different set of employees would have been negatively impacted.
It's a small scale trolley problem and unless you can expand in exactly the same place, someone's going to get run over. When the CEO realizes this, it's entirely rational to draw conclusions like 'For those who are harmed, well at least they had the experience and name of working at [growing, perceived successful] company X.'
Another sign its time to leave: when the company starts doing "reorgs". Get out as soon as you can!
I know that the CEO when facilities where pushing for people to move to some industrial estate near Heathrow with zero pubic transport links "word class Telco's don't have a head office in a F%^king shed at Heathrow"
(as they keep all the money to themselves)
The dichotomy would be humorous if it weren't so sad.
Perhaps you mean something specific by "capable"?
I won't disagree that c++ (as a technology) can be a minefield, but this also holds for many technologies and markets (civil aviation being a great example).
I may have missed an implicit /s, for which I apologize in adavance...
:: Henry Mintzberg basically said it all in 2004 already: https://books.google.nl/books?hl=nl&lr=&id=zsYAeVgwHDQC&oi=f... ISBN-13: 978-1576753514, ISBN-10: 1576753514 " Managers Not MBAs: A Hard Look at the Soft Practice of Managing and Management Development"