What Silicon Valley gets about engineers that traditional companies do not(blog.pragmaticengineer.com)
blog.pragmaticengineer.com
What Silicon Valley gets about engineers that traditional companies do not
https://blog.pragmaticengineer.com/what-silicon-valley-gets-right-on-software-engineers/
339 comments
We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers.
I suggested instead engineers get looped earlier into the process with stakeholders. The director said it was a bad idea as we couldn’t possibly hope to understand the business side of things.
Very glad I got out
I suggested instead engineers get looped earlier into the process with stakeholders. The director said it was a bad idea as we couldn’t possibly hope to understand the business side of things.
Very glad I got out
In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.
In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.
This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it.
I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
> requiring the engineering staff to do a Socratic-like process to pull tangible requirements out
If you've got good business analysts, this is what they're supposed to be doing.
I think if you have great product people, great business analysts, and great developers, the system of PO-Analyst-Developer can work. The problem is that BAs and product people aren't generally making a ton of money, so the great ones will move on to more lucrative positions, and great developers get bored quickly if they're just given a list of JIRA tickets. So pretty soon, one of the three things breaks down then all hell breaks loose. The product folks don't have a clear business vision. The analysts are soft technically and don't know what questions to ask. The developers are either building a space shuttle when they need a bike, or they don't know how to build the bike in the first place.
If you've got good business analysts, this is what they're supposed to be doing.
I think if you have great product people, great business analysts, and great developers, the system of PO-Analyst-Developer can work. The problem is that BAs and product people aren't generally making a ton of money, so the great ones will move on to more lucrative positions, and great developers get bored quickly if they're just given a list of JIRA tickets. So pretty soon, one of the three things breaks down then all hell breaks loose. The product folks don't have a clear business vision. The analysts are soft technically and don't know what questions to ask. The developers are either building a space shuttle when they need a bike, or they don't know how to build the bike in the first place.
On the other hand, I can certainly imagine situations where the requirements aren't "hardcoded" but rather they are flexible and heavily driven by what's feasible and what's hard from the engineering perspective (so they can't be "pulled out" from the product leader), and determining that vision properly requires involvement of engineers and can't [technically can, but the outcomes suck] be prepared by someone else and just handed off to engineering.
Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things.
The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
Junior engineers and PMs need the software to have a skeletal structure on which they can hang their features. This skeletal structure has to be put together by the lead engineer and lead PM. Usually I see both PMs and engineers churning with bad design when such a clarifying structure is missing or ill-defined or has become broken due to hard pivots in pursuit of business/product-market fit.
I would tweak that just a bit that bad developers just want to be told what to build.
The best engineers I've ever worked with and for were constantly asking "why" and would get incredibly frustrated in this "Product Owner runs the backlog" type of organization.
The best engineers I've ever worked with and for were constantly asking "why" and would get incredibly frustrated in this "Product Owner runs the backlog" type of organization.
My past work is Very much this.
Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.
Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.
That...is so insightful that I am speechless.
I’ve never considered it from that angle.
Brilliant.
I’ve never considered it from that angle.
Brilliant.
That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?
My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
Hmm, that is a weird conclusion to draw from the observations.
The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them.
That model is generally far from cooperatives and still has plenty of hierarchy.
Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction.
(Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.)
Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them.
That model is generally far from cooperatives and still has plenty of hierarchy.
Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction.
(Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.)
Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
I would be interested if you have a few names of software cooperatives (still running or not).
I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
This book had an interesting take on the subject: https://leanpub.com/developerhegemony
It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.
It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.
On a more macro level, doctors and lawyers use regulation to keep the competition at bay.
In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers.
(In eg Germany, that even applies to pharmacists.)
In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers.
(In eg Germany, that even applies to pharmacists.)
Even if they use regulation to limit how many and who is a practitioner, this doesn't give a satisfying answer to why they organize themselves that way and we do not.
Just because anyone can be an engineer, it doesn't follow that we can't form partnerships. I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.
Another argument I heard was that partnerships are required in certain fields due to liability concerns so that risk can be contained to individual partners. But this only explains why they must, not why we can't.
Just because anyone can be an engineer, it doesn't follow that we can't form partnerships. I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.
Another argument I heard was that partnerships are required in certain fields due to liability concerns so that risk can be contained to individual partners. But this only explains why they must, not why we can't.
> I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.
A big part of the regulation of doctors and lawyers is the part that keeps the competition out. Google or your favourite startup can't just train up a few neural networks and start dispensing legal or medical advice; even if that advice was much better than what you'd get from your median human lawyer or doctor.
The organisation into partnerships might be more about who's excluded, than what the people in the club are allowed to do?
You are right about liability concerns playing a role, too. And then there's also tax issues.
A big part of the regulation of doctors and lawyers is the part that keeps the competition out. Google or your favourite startup can't just train up a few neural networks and start dispensing legal or medical advice; even if that advice was much better than what you'd get from your median human lawyer or doctor.
The organisation into partnerships might be more about who's excluded, than what the people in the club are allowed to do?
You are right about liability concerns playing a role, too. And then there's also tax issues.
> I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
I agree. I just mention it because the companies that 'eat the world' will be the ones people have heard of. And those are not collectives.
I agree. I just mention it because the companies that 'eat the world' will be the ones people have heard of. And those are not collectives.
As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.
Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders.
Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse.
Sample phrases include: "Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or
"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse.
Sample phrases include: "Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or
"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
>"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
I don't get it. Can you explain?
I don't get it. Can you explain?
Boss owns two companies.
Staff at company A have negotiated a profit share / performance bonus.
Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
Staff at company A have negotiated a profit share / performance bonus.
Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
This is a dirty tactic, but I've seen it used... a lot.
It has slimy tax advantages too, for the company.
If you're getting profit sharing, you should be able to see the books, and have controlling shares, too... IMO.
It has slimy tax advantages too, for the company.
If you're getting profit sharing, you should be able to see the books, and have controlling shares, too... IMO.
Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?
The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have.
They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources.
This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be
> getting in the way
However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
Product folks (generally) can't implement their ideas on their own. Devs can.
Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.
I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.
So much this. I actually studied a joint course of Engineering and business, which was supposed to be two thirds of the Engineering course, two thirds of the business course. When you put it together the Engineering was still about two thirds of the total, with the business stuff mainly being simple things that took a long time to read. Everyone thought it was unsubstantiated just-so stories (Betamax, five forces, etc), but the point was to know the stories so you could communicate with business people.
If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend.
The reason they keep you from the info is of course you'll see the naked emperor.
If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend.
The reason they keep you from the info is of course you'll see the naked emperor.
Business is super complicated. It's more complicated than science, because it's not science.
Science is "easy" because we can model it, to a degree.
Non-science is so hard that we can't even model it, it's that complicated. So instead we try to voodoo our way around it, rely on simple heuristics, history, etc.
Science is "easy" because we can model it, to a degree.
Non-science is so hard that we can't even model it, it's that complicated. So instead we try to voodoo our way around it, rely on simple heuristics, history, etc.
Business isn't really all that complicated. It's just opaque and intersects with other things that are complicated, like finance and law.
But the man who invented 1-800-GOT-JUNK and plastered the phone number on the side of every one of his bins was not some better of Richard Feynman. He understood one thing really well: If you solve a problem, have simple messaging, and unabashedly self-promote you will win.
The lawyers, and accountants, and technologists, will all come and help you with the complicated stuff in exchange for a piece of that mountain of cash.
But the man who invented 1-800-GOT-JUNK and plastered the phone number on the side of every one of his bins was not some better of Richard Feynman. He understood one thing really well: If you solve a problem, have simple messaging, and unabashedly self-promote you will win.
The lawyers, and accountants, and technologists, will all come and help you with the complicated stuff in exchange for a piece of that mountain of cash.
Business is just dependent on thousands of factors that are fundamentally impossible to control. You can model pretty much every factor of it, individually, but you can't model the whole matrix because some parameters are random and wide (earthquakes, pandemics, etc) and some you cannot account for (were you were born and from whom, what education you get and where, who you can befriend, how your brain works, etc etc).
I think one has to differentiate between "complex" and "complicated". Complex stuff requires Big Brains. Business is not complex, all its processes are simple and fairly well-understood; but it is complicated by the interaction of so many factors.
I think one has to differentiate between "complex" and "complicated". Complex stuff requires Big Brains. Business is not complex, all its processes are simple and fairly well-understood; but it is complicated by the interaction of so many factors.
I think a more correct statement would be that people are complicated, and therefore business is also complicated.
Maybe.
If you have ever been in a relationship, you know how irrational people are: ergo, ability in logic and mathematics plays little role.
Went to MIT in engineering/science, and I would do a mental face-palm when I heard other engineers try to ‘sell’ what they are working on.
It’s the “curse of knowledge” where you forget how to relay ideas because you forget your axioms have been updated but the person you are talking with has not had theirs updated.
This is to say some people (in all fields) can sell ideas, and some can’t. Just as some can do high level mathematics, and some can’t. Those curves overlap in unexpected ways.
If you have ever been in a relationship, you know how irrational people are: ergo, ability in logic and mathematics plays little role.
Went to MIT in engineering/science, and I would do a mental face-palm when I heard other engineers try to ‘sell’ what they are working on.
It’s the “curse of knowledge” where you forget how to relay ideas because you forget your axioms have been updated but the person you are talking with has not had theirs updated.
This is to say some people (in all fields) can sell ideas, and some can’t. Just as some can do high level mathematics, and some can’t. Those curves overlap in unexpected ways.
Oh yea, I don't mean to say that every single individual can run every single aspect of the business personally. Marketing and social skills are not evenly distributed, but they can all understand it at least, provide input, and have a conversation about it, and I believe, often avoid critical errors.
This goes a little further beyond this point I was making, but I also see collective decision making like this as being more fair. Everyone at the buisness is affected by these decisions, so everyone should share in the decision making process. Natural leaders and experts should become apparent and people will listen to them if they don't attempt to bludgeon them with their credentials.
This goes a little further beyond this point I was making, but I also see collective decision making like this as being more fair. Everyone at the buisness is affected by these decisions, so everyone should share in the decision making process. Natural leaders and experts should become apparent and people will listen to them if they don't attempt to bludgeon them with their credentials.
Eh. A lot of engineers really don't have the social skills to navigate the business situations. Some do, sure, and should be given the opportunity to shine. But I would still say the majority don't.
And what kind of "high level physics" do engineers know? A typical masters track doesn't cover the hard maths like in GR, sounds more arrogant than anything... kind of proving my point ;)
And what kind of "high level physics" do engineers know? A typical masters track doesn't cover the hard maths like in GR, sounds more arrogant than anything... kind of proving my point ;)
[deleted]
Doesn't this basically argue that "business" is basically the same thing as schmoozing?
You could argue that people are a more complicated system than any software system you would see in a talented shop, and people change in real time.
tbf doing things like GR or QFT is not even required for a graduate degree in physics depending on your field of research
I don't know... We don't assume that people who make it through business classes can figure out engineering either.
That said, I do always try to bring along "business people" in engineering challenges and considerations, for which you don't need a full engineering degree. I do appreciate when I get the same treatment.
That said, I do always try to bring along "business people" in engineering challenges and considerations, for which you don't need a full engineering degree. I do appreciate when I get the same treatment.
It's funny, how that would be one of the major differences between Amazon and other companies I worked for. Only for Supply Chain management and logistics.
[deleted]
[deleted]
Yes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers.
The ironic thing about Agile is that it has a cottage industry of "scrum consultants", "scrum masters", project owners, etc. which advocate ostensibly for letting developers self-organize but which also has a vested interest for career and self-preservation reasons in inserting itself above software engineers in the decision making process.
The ironic thing about Agile is that it has a cottage industry of "scrum consultants", "scrum masters", project owners, etc. which advocate ostensibly for letting developers self-organize but which also has a vested interest for career and self-preservation reasons in inserting itself above software engineers in the decision making process.
Keep in mind that Agile (using the term loosely) was invented by software consultants who wanted to maximize the value they provided to the business they worked with. It’s a formalization of the ideas to make them more “acceptable” to execs and the decision makers (who care about such things).
When applied to in house engineering teams, it is largely ineffective if it doesn’t come with the same kind of freedom that highly paid software consultants get. This is manifested concretely in how many companies have corrupted agile methodologies by focusing too much on the perfecting practices (or “ceremonies”) rather than focusing on the foundational principles.
When applied to in house engineering teams, it is largely ineffective if it doesn’t come with the same kind of freedom that highly paid software consultants get. This is manifested concretely in how many companies have corrupted agile methodologies by focusing too much on the perfecting practices (or “ceremonies”) rather than focusing on the foundational principles.
I'm convinced that the vast majority of business-y manager types that always trumpet "we have to be more agile" have never read the agile manifesto - specifically the "individuals and interactions over process and tools".
It's regretful that it caught on so well and has (incorrectly) evolved into a concrete process in most places rather than an ideology.
It's regretful that it caught on so well and has (incorrectly) evolved into a concrete process in most places rather than an ideology.
I'm convinced of the same thing. I once had a rather enlightening conversation with an Agile consultant who had never read the manifesto. When I showed him, he said "I'm not sure I agree with this".
I've long imagined a position just above the scrum masters: the scrum lord.
I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.
I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.
Click [here] to sign up for my Free Introductory Scrum Lord certification course! Join our hundreds of Certified Scam Lords earning well above industry standard after just 12 months of online training!
(Credit card required. Rebilled at $29.95 per month until cancellation. Minimum period of 12 months. T&Cs apple.)
(Credit card required. Rebilled at $29.95 per month until cancellation. Minimum period of 12 months. T&Cs apple.)
Why settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?
Scrumplestiltskin. He promises to teach you to spin stories into code but then takes credit for your prototype.
God-Emperor of Scrum. The code must flow.
In the grim darkness of the future, there is only Scrum!
Now fly my scrumlings! Bring me their estimates! Eeehehehe
Meh. A real Evil Scrum Lord makes his victims enter the data by themselves into Jira.
Hell no. At least then I know it’s entered in a sensible way. If I let the scrum lord do it it’ll be a mess.
Twice. Once in points after Planning Poker has sized the story -- the second time in hours.
OMG planning poker. Never again.
Value based scrum black belt.
Pope Scrootus the 1st
I definitely agree with you, but I don't think that's sufficient. I think at larger companies it would be helpful to spend a day or two every quarter having a scrum increment meeting. The SI would let scrum lords and scrum masters plan what experiments would occur during the next quarter.
Isn't that just the Scrum of Scrums meeting, only at higher level perhaps?
What you are looking for is RTE; Release Train Engineer
Still, at my company I have an even more lofty title. I am the Kanban King...
I appreciate your sense of humor
not sure you're going far enough there. Obviously we need a scrum king to guide our scrum lords as they help our scrum masters transform our organization.
[deleted]
The scrum lord spends most his day in his office making spunk charts. The making of spunk charts is an intensely personal task that uniquely suits them for office ownership. There have been cases where two or more scrum lords create spunk charts together but it is more rare.
These are people whose entire job consists of sitting in meetings and firing off emails. They can't conceive that other people do work collaborating outside of a meeting room.
Not just collaborating. Any kind of work.
We plan 8 hours a day of work for developers, but they spend 4 hours in meetings, 2 hours fielding questions and just 2 actually working.
We plan 8 hours a day of work for developers, but they spend 4 hours in meetings, 2 hours fielding questions and just 2 actually working.
At my job its more like 10-12 hours a day, since you are counted on to do 6-8 hrs of programming despite all the other stuff.
To be fair, I've seen engineers with a similar role.
yep, and thank god. Because I sure as hell dont want to do that as a developer
When I was managing engineers, I would insist that the engineer talk 1:1 to the engineer on the client (or customer) side when doing fixes or feature enhancements that happened to be requested from outside the company. This always caused consternation among scrummasters and product managers, and there always had to be a discussion about it. But it sped things up tremendously, because the engineer could do things like say "well, what if we did this other thing instead, which would give you what you need, and also solve another problem we have". In almost all cases the other engineer was happy to talk to our engineer, and very easy to work with.
This needed to be a private conversation as well, so that both parties not need to worry about optics. Preferably phone.
Once a scrum-master tried to insist that these conversations take place on a public slack channel so that we could "capture" it! And yes I understand why, but it would have skewed the process into something less effective.
This kind of works fine until you have many customers.
If you have < 5 customers, then this works fine.
If you have > 10,000 customers, then this works fine, because you can rely on analytics.
If you have 100 - 500 customers, then it kind of breaks. You can't rely on analytics because those customers are too important, and you can't rely on 1-1 interaction with engineers because there are too many customers to consult on each change.
If you have < 5 customers, then this works fine.
If you have > 10,000 customers, then this works fine, because you can rely on analytics.
If you have 100 - 500 customers, then it kind of breaks. You can't rely on analytics because those customers are too important, and you can't rely on 1-1 interaction with engineers because there are too many customers to consult on each change.
I've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.
When I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer
followed up and apologized and informed me that if there was anything they could do, to let them know.
I never wanted to bang my head against the monitor harder than in that moment.
I never wanted to bang my head against the monitor harder than in that moment.
For anyone like me who had never seen the term "NPS e-mail", this seems to explain it pretty well:
https://www.questionpro.com/blog/nps-email/
(I don't know anything about this company and am not endorsing them, just noting it as a reference.)
https://www.questionpro.com/blog/nps-email/
(I don't know anything about this company and am not endorsing them, just noting it as a reference.)
NPS stands for Net Promoter Score. It's supposed to get a sense of % favorable - % unfavorable and leaving out the middle.
I've seen this at many companies and its one of my biggest pet peeves. Almost nobody uses it correctly. They don't net anything. They take the average. It's not clear at all why it's any different from any other score. I think most people think its some sort of collection or measurement thing rather than a calculation on the data. I hate it. Reeks of innumeracy.
Not that it really matters if you use average vs. nps...
I've seen this at many companies and its one of my biggest pet peeves. Almost nobody uses it correctly. They don't net anything. They take the average. It's not clear at all why it's any different from any other score. I think most people think its some sort of collection or measurement thing rather than a calculation on the data. I hate it. Reeks of innumeracy.
Not that it really matters if you use average vs. nps...
or you could offer - optional non compulsory - support for recording and transcription to the engineers and pay them overtime to jointly produce a final copy / summary (destroying the materials unless required for compliance) as we used to do.
There’s some value in capturing these conversations for the record. If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them.
I do agree that if this process is used to score political points though, then it loses all value. Maybe a compromise is to capture the summary of these conversations somewhere. But honestly if an org has become this political.... I would start looking elsewhere.
I do agree that if this process is used to score political points though, then it loses all value. Maybe a compromise is to capture the summary of these conversations somewhere. But honestly if an org has become this political.... I would start looking elsewhere.
> If eg the engineer engaged in these conversations decided to leave, it would preserve the record for the person replacing them.
How many of those recordings are ever played back? None, in my experience.
How many of those recordings are ever played back? None, in my experience.
I was referring primarily to slack conversations. Usually when searching for a unfamiliar service or tool, I first do a slack search, then look at a KB/Wiki, then at code etc.
Public slack threads are pretty great since you can follow the decision making process when solving problems. Great slack threads may even include data on what the author tried/didn’t try etc.
I agree with you that video recordings are for the most part useless. Until we find a way to get high quality automatic transcription of videos and add them to a good search index, they will have limited use.
Public slack threads are pretty great since you can follow the decision making process when solving problems. Great slack threads may even include data on what the author tried/didn’t try etc.
I agree with you that video recordings are for the most part useless. Until we find a way to get high quality automatic transcription of videos and add them to a good search index, they will have limited use.
The idea of capturing ppl's conversations is weird. Details of that work are captured in the project stories and version control commits.
There's a big difference between internal work and external work, where that discussion can matter a lot in antagonistic disputes (in court or outside of it) over whether a particular change (and its consequences) was requested or not, and if so, by whom and when.
In a perfect world yes. But the majority of JIRA stories that I’ve come across often don’t contain complete information. The best, well disciplined folks recognize that they will inevitably forget details and write careful summaries, most people write a few bullet point to satisfy the acceptance criteria for the story.
Slack conversations often contain more data. It’s also easier for me to follow a human conversation than a poorly written summary with many missing details.
Slack conversations often contain more data. It’s also easier for me to follow a human conversation than a poorly written summary with many missing details.
> traditional companies that are doing Agile.
Aka "Wagile".
"We have a standup every morning, where you're required to report on how many of your assigned Jira tickets you completed yesterday and get berated for any incomplete ones no matter the cause! No excuses! We've committed to these deadlines and budgets, that you know nothing about having not been consulted on anything."
Aka "Wagile".
"We have a standup every morning, where you're required to report on how many of your assigned Jira tickets you completed yesterday and get berated for any incomplete ones no matter the cause! No excuses! We've committed to these deadlines and budgets, that you know nothing about having not been consulted on anything."
That’s just the tip of the ice berg... I call it the tyranny of project managers.
When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes.
I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a post mortum after. One project manager for every 3 engineers. Dealing with them I felt like I was looking some sort of Project Managers Gone Wild porn set
Then I moved away from the BA and found out most places are like this, it’s real bad
When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes.
I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a post mortum after. One project manager for every 3 engineers. Dealing with them I felt like I was looking some sort of Project Managers Gone Wild porn set
Then I moved away from the BA and found out most places are like this, it’s real bad
Just print this FAQ and hang it by your desk.
FAQ
Q: What are you working on?
A: Look at the issue tracker
Q: Are you working on X?
A: Look at the issue tracker
Q: Are you still working on X?
A: Look at the issue tracker
Q: Is X finished?
A: Look at the issue tracker
Q: Did QA look at X?
A: Look at the issue trackerBasically every single standup, "update", meeting I've ever had with a manager could have been avoided by them looking at the issue tracker beforehand. Which I'm sure they did anyway, since they spend most of their days organizing the board. They just ask you questions to which they already know the answer.
Let A and B ∈ Team.
After standup, ask A what B did yesterday, what is B working on today whether or not B is blocked. And viceversa.
Then wait for 30 min, do the same. Then wait 3 hours, do the same.
What will happen? they will forget about it because it is irrelevant to them.
Therefore the scrum ceremonies are just bullshit and a waste of time.
Quod erat demonstrandum. Fuck scrum.
Then wait for 30 min, do the same. Then wait 3 hours, do the same.
What will happen? they will forget about it because it is irrelevant to them.
Therefore the scrum ceremonies are just bullshit and a waste of time.
Quod erat demonstrandum. Fuck scrum.
How about “people over process”? Yet we are slaves to Agile Scrum process and procedure.
Double talk.
Double talk.
The reasons behind the creation of Scrum and the reasons behind the adoption of Scrum are different.
Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all.
The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader.
Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all.
The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader.
And product owner and scrum master need to be highly skilled people with a lot of responsibility instead of whoever has nothing better to do at the moment as is so often the case.
I still can’t figure out how line managers and architects fit into a well run scrum environment. Seems they would be losing a lot of power.
I still can’t figure out how line managers and architects fit into a well run scrum environment. Seems they would be losing a lot of power.
Scrum does not formally recognize levels of seniority. All members of the development team have the same role.
You can read the official Scrum guide here, it's a few pages long:
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...
I think Scrum exists only to expand the adoption of Scrum. That is at least the reason behind the role of "Scrum master".
By maximizing adoption, the authors can personally benefit and become rich and famous.
You can read the official Scrum guide here, it's a few pages long:
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...
I think Scrum exists only to expand the adoption of Scrum. That is at least the reason behind the role of "Scrum master".
By maximizing adoption, the authors can personally benefit and become rich and famous.
There is a reason why they pay that much, they have trouble finding people comfortable with their insanity. That's also what I think is the real reason behind why the interview processes are so contrived and kafkaesques, they reflect the place.
I think the key is whether you consider an engineer a business person. That is what links most of the things in the article: a business person needs to know certain business things to be effective, and so if you're considered a business person you get told things like what the competive landscape is, what the budget is, and so on.
For me, the engineer is actually the only person who can do those business functions properly, if the business is solving new problems (rather than a cash cow). I tolerate people who aren't engineers, because I often can't avoid them, but once you get more than a few of these people in your business, things get awkward for the actual engineers.
I also tend to think of engineering as more than just coding. An essential part of it is communicating. You can't do that without technical skills, there's just so much friction.
For me, the engineer is actually the only person who can do those business functions properly, if the business is solving new problems (rather than a cash cow). I tolerate people who aren't engineers, because I often can't avoid them, but once you get more than a few of these people in your business, things get awkward for the actual engineers.
I also tend to think of engineering as more than just coding. An essential part of it is communicating. You can't do that without technical skills, there's just so much friction.
Maybe (or not, I didn't think that idea fully yet) it is time to start cutting the software development jobs in two jobs: Technicians and engineers. And maybe it is also time for developers to organize take the lead of their craft.
As a person who was there for the early days of Agile, I just want to say it's sad that's what Agile has become. You're right, of course. But that's not what was meant. Somehow "Individual and interactions over processes and tools" became "individuals, please stop interacting and conform to these processes and tools".
It gets worse. If you're caught in a power grab/political game as a developer, some manager consciously use this to slow you down in comparison to their favorite developer.
I was a developer brought into a team along with codebase. They would allow their own devs to go full SV-style, free. But when it comes to me; "please check with PO, create a jira subtask for this"
I was a developer brought into a team along with codebase. They would allow their own devs to go full SV-style, free. But when it comes to me; "please check with PO, create a jira subtask for this"
> Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.
This is of course because the thing that traditional companies call "Agile" is really just the same business-as-usual top-down manager-controlled garbage software process they've always used but with the cool-sounding name "Agile" slapped on it.
Whereas what SV companies do is much closer to what Agile is really about, regardless of what they call it.
This is of course because the thing that traditional companies call "Agile" is really just the same business-as-usual top-down manager-controlled garbage software process they've always used but with the cool-sounding name "Agile" slapped on it.
Whereas what SV companies do is much closer to what Agile is really about, regardless of what they call it.
That would give developers too much power and make them non replaceable/interchangeable.
They already aren't replaceable in that sense. It it impossible to open a can of developers and hope to get results straight away or hope nothing gets lost if someone leaves.
If you drop your expectations low enough, then yes, it's possible. It involves a steady churn state and the idea that "it's just how it is".
I was a lead developer on an agile team at a $10B+ 50,000 employee pet store chain for 9 months, and never met the product owner.
All backlog was generated by having two analysts or their boss meet with the product owner, a direct marketing exec, writing down what she wanted, then meet with team to give marching orders.
Being a direct marketing exec, all she cared about was “engagement”, so our product was mainly just feeds of pet advice, tips and tricks along with a game (that the bored analysts played all day).
The app also allowed booking store services such as grooming, vet visits, and boarding. But the implementation of the service bookings was so poor it took over a dozen steps with lengthy spinners for network requests. Our metrics showed less than one third of service booking attempts completed.
I pointed out that since the company was terrified of Amazon, that store services were a key differentiator and margin producer and we could make booking services far faster and easier with some design changes.
The response was, that’s not in our backlog. So next build after completing my work, and helping other devs complete theirs, I worked over a weekend and cached some booking data in the app to eliminate spinners on entry into the booking system.
I proudly showed it to the analysts that Monday and they nearly had heart attacks. That wasn’t in the backlog!
All they cared about was making the product owner happy (she was a teller, apparently) and all my efforts did was make me unpopular with them and their boss.
All backlog was generated by having two analysts or their boss meet with the product owner, a direct marketing exec, writing down what she wanted, then meet with team to give marching orders.
Being a direct marketing exec, all she cared about was “engagement”, so our product was mainly just feeds of pet advice, tips and tricks along with a game (that the bored analysts played all day).
The app also allowed booking store services such as grooming, vet visits, and boarding. But the implementation of the service bookings was so poor it took over a dozen steps with lengthy spinners for network requests. Our metrics showed less than one third of service booking attempts completed.
I pointed out that since the company was terrified of Amazon, that store services were a key differentiator and margin producer and we could make booking services far faster and easier with some design changes.
The response was, that’s not in our backlog. So next build after completing my work, and helping other devs complete theirs, I worked over a weekend and cached some booking data in the app to eliminate spinners on entry into the booking system.
I proudly showed it to the analysts that Monday and they nearly had heart attacks. That wasn’t in the backlog!
All they cared about was making the product owner happy (she was a teller, apparently) and all my efforts did was make me unpopular with them and their boss.
sold my company to atlassian in 2006. i worked at atlassian for nearly a decade. ran bitbucket for years. ran product at docker after that.
any notion that engineers should not be on customer calls, or driving engineering specs is the opposite of what i would consider the best implementation of agile.
any notion that engineers should not be on customer calls, or driving engineering specs is the opposite of what i would consider the best implementation of agile.
> So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs.
I've gotten more than funny looks. They get downright mean or irritated, because to them it sounds like you're trying to take their job away.
Remember, these are the people who bring the requirements to the engineers.They have people skills! Can't you understand that? What the hell is wrong with you people?! https://www.youtube.com/watch?v=fcIMIyQnOso
I've gotten more than funny looks. They get downright mean or irritated, because to them it sounds like you're trying to take their job away.
Remember, these are the people who bring the requirements to the engineers.They have people skills! Can't you understand that? What the hell is wrong with you people?! https://www.youtube.com/watch?v=fcIMIyQnOso
I think it also depends a lot on the type of dev and if they want to take responsibility. I have experienced many devs that just didn’t care about the business and design side of things. “Leave me alone and go talk to the product owner”, was something I gotten quite often. But, to be fair I often also got “We want to be more involved in decision making”.
If you set up the responsibility, power & accountability right. Then the developer will have to care and take responsibility. Otherwise, their deliverable is wrong, and they're out. As simple as that.
Exactly, a lot of devs complain about meetings and just want to code.
> "Product Owners" who are there to give instructions via Jira tickets
A good product owners facilitates the communication between business people and engineers (or designers, or others). They don't dictate instructions, they regularly spend time with business people to understand their needs and what they care about, work with engineers and designers to craft solutions that are the best suited to what the business needs. When the relationship works well engineers are shielded from constant interruptions, and can rely on one person to answer their business questions instead of trying to have discussions between all the stakeholders.
As an engineer I was myself very skeptical of the role in the past but then worked with 2 awesome product owners for a few years and it was a fantastic experience.
A good product owners facilitates the communication between business people and engineers (or designers, or others). They don't dictate instructions, they regularly spend time with business people to understand their needs and what they care about, work with engineers and designers to craft solutions that are the best suited to what the business needs. When the relationship works well engineers are shielded from constant interruptions, and can rely on one person to answer their business questions instead of trying to have discussions between all the stakeholders.
As an engineer I was myself very skeptical of the role in the past but then worked with 2 awesome product owners for a few years and it was a fantastic experience.
Regular practice in other industries don’t need Agile to work fast, be creative, or hold people to account for their work. How is software different in this regard?
I think in a lot of industries the work "speaks for itself" like a creative agency or people producing widgets. For creative work you can walk through the assets produced and everyone can theoretically see that there is value being created. I believe software development gravitates towards heavy processes mostly because it's hard for "decision makers" to accurately gauge good software from bad, or even understand what progress is being made at all.
Having more engineers in decision making positions certainly helps, but I think it boils down to whether the organization is set up for trust.
Having more engineers in decision making positions certainly helps, but I think it boils down to whether the organization is set up for trust.
[deleted]
So true.
Then they don't understand what RAD / SCRUM is for - and I would bet had crappy outcomes before the switch.
This post just made me miss coding so much. I spend basically all my time these days understanding the business. Sometimes I just want to blindly code: create an algorithm to calculate x, make a screen to display y. But those roles don't pay.
I have noticed that as SV companies get larger they tend to adopt the more "old school" approach. Not that it's a binary - it's a spectrum, and depending on management chain/how an org runs, people can have different experiences.
I think it's caused by
1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Even if on average most of them aren't micromanagers, it only takes a few.
2. As you grow you start pulling in more people with experience outside of SV who bring in culture with them. Note that "SV" is also not monolithic here. Companies like Microsoft (ok, technically not SV) are farther to the "traditional" side of the spectrum.
3. "Horizontals"
I think it's caused by
1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Even if on average most of them aren't micromanagers, it only takes a few.
2. As you grow you start pulling in more people with experience outside of SV who bring in culture with them. Note that "SV" is also not monolithic here. Companies like Microsoft (ok, technically not SV) are farther to the "traditional" side of the spectrum.
3. "Horizontals"
The "SV style" runs into scaling problems. Engineers making product decisions requires that they have a solid grasp on everything the business cares about, which gets harder as the business gets bigger. Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers.
As you grow I think reducing engineer autonomy is unavoidable, and the goal is merely to stick to reducing it and not eliminating it.
As you grow I think reducing engineer autonomy is unavoidable, and the goal is merely to stick to reducing it and not eliminating it.
> Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers.
This isn't true in my experience. I'd say it's more like a binary search than a fully-connected network. I talk to my immediate team first. If they can't help, I dig through the company-wide documentation and codebase, then message people who have done or considered something similar to what I'm trying to do; they either give me the information I need, or direct me to someone more likely to have it. Each hop gets me closer to an answer, and I typically end up having to talk to 1-3 engineers rather than the O(500) who work in my organization.
Part of the reason this works is because there are a handful of very senior engineers who have a good sense of what's going on across a big part of the company. Complex requests often get routed through one of these people, and they always seem to know who to talk to. I guess that's a form of hierarchy, but without the "command-and-control" aspect. I see it as an occasional escape hatch rather than a primary means of problem-solving.
This isn't true in my experience. I'd say it's more like a binary search than a fully-connected network. I talk to my immediate team first. If they can't help, I dig through the company-wide documentation and codebase, then message people who have done or considered something similar to what I'm trying to do; they either give me the information I need, or direct me to someone more likely to have it. Each hop gets me closer to an answer, and I typically end up having to talk to 1-3 engineers rather than the O(500) who work in my organization.
Part of the reason this works is because there are a handful of very senior engineers who have a good sense of what's going on across a big part of the company. Complex requests often get routed through one of these people, and they always seem to know who to talk to. I guess that's a form of hierarchy, but without the "command-and-control" aspect. I see it as an occasional escape hatch rather than a primary means of problem-solving.
I have to ask though: if a company built on engineering doesn’t empower its engineers to make product decisions, who can make them?
In my anecdotal experience, the “product” people generally have lesser context than the engineers, and often rely on engineers to do their jobs. The good ones make a serious effort to get at least a vague understanding of how the product works and are hungry to hear ideas on how to deliver more value.
However most PMs will not be this way. Their primary instinct is to interface with the product hierarchy and explain to engineers what the “higher ups” want. They exercise this power by vetoing ideas that don’t fit into this narrative, even if these ideas would improve the product. Engineers then mostly don’t really share everything that they’re working on with the apathetic PM; the motivated ones build things anyways risking rebukes while others will do just what product asks for.
The only scalable solution really, is to create processes and career paths for engineers who are inclined to product design to become PMs, or at least spend part of their time as PMs.
At Service Oriented B2B companies, there is another class of people who become excellent PMs: the Customer Service Managers, who have dealt with Customers and their issues, and have a deep understanding of the problems and frustrations faced by users of these systems.
In my anecdotal experience, the “product” people generally have lesser context than the engineers, and often rely on engineers to do their jobs. The good ones make a serious effort to get at least a vague understanding of how the product works and are hungry to hear ideas on how to deliver more value.
However most PMs will not be this way. Their primary instinct is to interface with the product hierarchy and explain to engineers what the “higher ups” want. They exercise this power by vetoing ideas that don’t fit into this narrative, even if these ideas would improve the product. Engineers then mostly don’t really share everything that they’re working on with the apathetic PM; the motivated ones build things anyways risking rebukes while others will do just what product asks for.
The only scalable solution really, is to create processes and career paths for engineers who are inclined to product design to become PMs, or at least spend part of their time as PMs.
At Service Oriented B2B companies, there is another class of people who become excellent PMs: the Customer Service Managers, who have dealt with Customers and their issues, and have a deep understanding of the problems and frustrations faced by users of these systems.
It's not the only solution for building products. But you can still maintain dev autonomy. Instead of having senior team-members break apart work into story-sized pieces a system can be broken apart into smaller pieces. Devs can still be working towards a specific business goal, but they can own a larger portion of their work, and they can work with longer deadlines.
Also, I think dealing with those large scale issues is what separates a staff/principal dev from a senior dev.
Also, I think dealing with those large scale issues is what separates a staff/principal dev from a senior dev.
This is where I think Apple does really well by having lots of small teams that each focus on a particular product area (Calendar, Remote Desktop, etc).
Teams have very limited scope in exchange for enormous autonomy. “Inmates run the asylum” as my former manager put it.
Teams have very limited scope in exchange for enormous autonomy. “Inmates run the asylum” as my former manager put it.
4. Middle managers are going to do something with their days. Once the growth frenzy stops and they're longer occupied by procuring and filling headcount, they go the next thing they know, implementing systems of surveillance ("accountability") and control ("alignment").
I hate the word “alignment” with a passion.
It never means “let’s do things in a coordinated and mutually beneficial way”. It always means “you will do the thing that I want you to do, or the way I want you to do it”.
Weasel word, if ever there was one.
It never means “let’s do things in a coordinated and mutually beneficial way”. It always means “you will do the thing that I want you to do, or the way I want you to do it”.
Weasel word, if ever there was one.
Some middle managers also serve as individual contributors
Or, in short, "middle managers gotta middle manage".
That is a brilliant take on middle management!
Completely agree, see it at companies like Google turning more and more into deep management chains. Some of the good remains (code & documentation transparency, engineer to engineer communication), but much off the decision making is shifting up the chain
Do you mind expanding on what you mean by "Horizontals" here?
Do you mind expanding on what you mean by "Horizontals" here?
>Some of the good remains (code & documentation transparency)
Not after the infamous need-to-know memo.
Team docs visibility defaulted to "only to people I explicitly share with" for almost a year now.
It's only a question of time until code branches follow suit.
Not after the infamous need-to-know memo.
Team docs visibility defaulted to "only to people I explicitly share with" for almost a year now.
It's only a question of time until code branches follow suit.
> Not after the infamous need-to-know memo.
I couldn't find that memo, could you please link to a copy?
I couldn't find that memo, could you please link to a copy?
Here you go[1].
The audacity of that email was that it made accessing "need-to-know" documents internally (!!!) a fireable offense.
In a kafkaesque move, "need-to-know" was not determined by labeling or access restrictions. Therefore, you can't know you are accessing a "need-to-know" document until you do.
In short, this made using internal search engine fireable. It made clicking any link on the mail list fireable.
That was a year and a half ago.
[1]https://www.buzzfeednews.com/article/carolineodonovan/google...
The audacity of that email was that it made accessing "need-to-know" documents internally (!!!) a fireable offense.
In a kafkaesque move, "need-to-know" was not determined by labeling or access restrictions. Therefore, you can't know you are accessing a "need-to-know" document until you do.
In short, this made using internal search engine fireable. It made clicking any link on the mail list fireable.
That was a year and a half ago.
[1]https://www.buzzfeednews.com/article/carolineodonovan/google...
It said that everything should only be shared on a need to know basis, basically ending the culture of all documents being open by default unless there is a need to hide it. When that change took into effect all documents I had were automatically set to hidden and I had to reshare them with everyone who needed to see them.
Related: the "Moral Maze" of Robert Jackall fame, recently "popularised" (if Less Wrong can be considered "popular") by Zvi Mowshowitz (https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summa...).
This is a big part of Amazon’s success. Service oriented architecture gives teams enough autonomy to define their own processes. “You build it, you own it” often extends to products as well as services.
Perhaps: as size increases, relationships don't scale and mechanisms of control and coordination become more shallow.
No focus on a structured product definition and leaving it to engineers to 'figure it out' does not bode well for the end user or business itself.
This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced.
One of tiny feature was the ability to download and self manage security certificates (upload again if any issue with security), it took literally weeks to define this feature by the engg and UX team. From tiny things like how to name the downloaded security files.. should we have the app name in the file or not - otherwise how would IT admin locate the file when they search, should file have time stamp because later we discovered that these d**n things expire, is there a 'standard' to begin with that defines the naming convention of these things, and so on..
All this because? The detailed level of spec is never written by product managers. Which I think is a very foolish culture, particularly in enterprise space.
This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced.
One of tiny feature was the ability to download and self manage security certificates (upload again if any issue with security), it took literally weeks to define this feature by the engg and UX team. From tiny things like how to name the downloaded security files.. should we have the app name in the file or not - otherwise how would IT admin locate the file when they search, should file have time stamp because later we discovered that these d**n things expire, is there a 'standard' to begin with that defines the naming convention of these things, and so on..
All this because? The detailed level of spec is never written by product managers. Which I think is a very foolish culture, particularly in enterprise space.
I think there is certainly a middle ground between "engineers do all the decision making" and "engineers do none of the decision making." I'm not sure the author was advocating the former. Rather, I think the author was saying that the possibility to influence the decision making at a fundamental level is what makes the SV-like companies great.
This follows my experience. Even at a FAANG, product managers aren't going to get every detail and edge cases are going to pop-up, so requirements are going to come from a back-and-forth between product and eng throughout the process. That back-and-forth is the key, not expecting engineers to figure out all the requirements, nor from product managers either.
This follows my experience. Even at a FAANG, product managers aren't going to get every detail and edge cases are going to pop-up, so requirements are going to come from a back-and-forth between product and eng throughout the process. That back-and-forth is the key, not expecting engineers to figure out all the requirements, nor from product managers either.
This actually just sounds like a successful example of agile design...
A subtlety complex feature took a couple sprints to iterate on stakeholder feedback and fully define the business need. The story doesn't seem that bad to me.
A subtlety complex feature took a couple sprints to iterate on stakeholder feedback and fully define the business need. The story doesn't seem that bad to me.
In this particular example, the engineer and designer had very little incentive to make it bulletproof (as there was no check), and there was no guarantee that the decision taken were not wrong (ex. not complying to Security Standard XYZ.NNN)
There was no "stakeholder" feedback as there is seldom an owner for these kind of decisions. If PM is the 'stakeholder' then these folks would have asked her "why are you not defining this?"
There was no "stakeholder" feedback as there is seldom an owner for these kind of decisions. If PM is the 'stakeholder' then these folks would have asked her "why are you not defining this?"
Do you believe the product managers would have defined the spec both faster and equally correctly in all the details, if they'd done it in advance before getting the engineers involved? (My guess from experience of comparable situations would be no, but keen to hear alternative perspectives)
That would depend on the experience and domain expertise of said project manager, no?
Also on their willingness to defer to the engineers when the problem involves some technical details that need to be got right.
I've seen it too many times where the non-technical manager gets to make technical decisions and refuses to listen to the engineers.
I've seen it too many times where the non-technical manager gets to make technical decisions and refuses to listen to the engineers.
This is an informative counter-example to those presented in the article. Thank you for sharing.
The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong.
I have worked at a good number of places, including a FAAMG.
The freedom that was given to me directly correlates to company size & seniority.
When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems worse by trying out new things.
When a company gets larger, it will bump into problems, missed features, deadlines or massive bugs. New procedures will get be implemented to make sure that those don't happen again. Ticketing is a good thing, so long as its developer lead. It allows delegation of tasks, and simple tracking of state. Its an artform that should be taught.
I was at a start up for two years that was bought out by a FAAMG. We were working on cutting edge computer vision research. We had a tight process, tracked with ticketing. We had complete autonomy.
We were chucked into SV "culture" only to find that is somehow managed to make cutting edge research both more chaotic and boring. Ironically I have much less freedom than I did when I worked at a large financial newspaper.
I have worked at a good number of places, including a FAAMG.
The freedom that was given to me directly correlates to company size & seniority.
When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems worse by trying out new things.
When a company gets larger, it will bump into problems, missed features, deadlines or massive bugs. New procedures will get be implemented to make sure that those don't happen again. Ticketing is a good thing, so long as its developer lead. It allows delegation of tasks, and simple tracking of state. Its an artform that should be taught.
I was at a start up for two years that was bought out by a FAAMG. We were working on cutting edge computer vision research. We had a tight process, tracked with ticketing. We had complete autonomy.
We were chucked into SV "culture" only to find that is somehow managed to make cutting edge research both more chaotic and boring. Ironically I have much less freedom than I did when I worked at a large financial newspaper.
Jira, for all it's warts, is a massively configurable piece of software that can be deployed/used in a hugely broad variety of ways.
I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a company of around 40 devs, 8 QAs, and 6 PMs, running perhaps 10-12 concurrent projects (almost all websites/webapps). It worked _really really_ well. (And I've spent th3e last 5-6 years looking for excuses/opportunities to poach that specialist...)
The key takeaways I learned from her was to identify and get leadership agreement right up front about whether a particular project was going to be "agile" or "waterfall" - because if you are going to be agile, Jira wants to be set up as a high level todo list of features/functions. If _any_ of the Jira tickets start to decree (from a PM/BA/manager) _how_ a feature or function is to be accomplished, you're fooling yourself and should have set it up as a waterfall project full of disposable-worker-bee style tickets.
I'm sure my takeaway was only scratching the surface of the deep understanding she had about project planning and managements styles, but that has work OK for me over the years. Either provide Jira tickets for features, and let the devs create their own sub tickets to document how they're doing things (and to get discussion/signoff on thing they ask for input on), or have the PM/BAs document a project in minute detail and fill each dev's schedule with sprints full of tickets representing 2 hours work or less.
I guess my point here is "Don't blame Jira. It's widely criticised flaws are largely a problem with the way it's used rather than a fundamental flaw in the tool. Poor project management results in shitty Jira use. Great project management will shine even if using postit notes stuck to devs laptops every day."
I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a company of around 40 devs, 8 QAs, and 6 PMs, running perhaps 10-12 concurrent projects (almost all websites/webapps). It worked _really really_ well. (And I've spent th3e last 5-6 years looking for excuses/opportunities to poach that specialist...)
The key takeaways I learned from her was to identify and get leadership agreement right up front about whether a particular project was going to be "agile" or "waterfall" - because if you are going to be agile, Jira wants to be set up as a high level todo list of features/functions. If _any_ of the Jira tickets start to decree (from a PM/BA/manager) _how_ a feature or function is to be accomplished, you're fooling yourself and should have set it up as a waterfall project full of disposable-worker-bee style tickets.
I'm sure my takeaway was only scratching the surface of the deep understanding she had about project planning and managements styles, but that has work OK for me over the years. Either provide Jira tickets for features, and let the devs create their own sub tickets to document how they're doing things (and to get discussion/signoff on thing they ask for input on), or have the PM/BAs document a project in minute detail and fill each dev's schedule with sprints full of tickets representing 2 hours work or less.
I guess my point here is "Don't blame Jira. It's widely criticised flaws are largely a problem with the way it's used rather than a fundamental flaw in the tool. Poor project management results in shitty Jira use. Great project management will shine even if using postit notes stuck to devs laptops every day."
Yes, Jira is very configurable. But whether you'll be allowed to configure it is an open question.
I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.
I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.
That is a company problem, not a Jira problem. (A very common company problem, and quite likely the underlying cause of a lot of people's Jira problems.)
We can't even install plugins on ours!
> The article uses JIRA is a touchstone that seems to equate to no autonomy.
Technically I don't think JIRA by itself means no autonomy, it's just how it's used. But JIRA can expose a ton of metrics to upper management. And I think that management influencing how JIRA is used probably indicates lower autonomy.
For instance, story points and velocity being tracked by management might be problematic. Is the team tracking everything with story points? Otherwise certain types of work could be hidden, and slow down velocity. Is management using those metrics for team or individual performance reviews?
Technically I don't think JIRA by itself means no autonomy, it's just how it's used. But JIRA can expose a ton of metrics to upper management. And I think that management influencing how JIRA is used probably indicates lower autonomy.
For instance, story points and velocity being tracked by management might be problematic. Is the team tracking everything with story points? Otherwise certain types of work could be hidden, and slow down velocity. Is management using those metrics for team or individual performance reviews?
> JIRA is a touchstone that seems to equate to no autonomy
Jira doesn't intrinsically take away engineers' autonomy but in many cases it's the most visible manifestation of company policies/procedures that do.
Jira doesn't intrinsically take away engineers' autonomy but in many cases it's the most visible manifestation of company policies/procedures that do.
Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.
Dunno about research, but I've worked in a few SV startups that organized development with Jira and had high autonomy for engineers. Some of the features of those teams:
1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.
2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.
3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.
4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)
Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.
2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.
3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.
4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)
Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch...
What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems.
But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems.
But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
Thx for your thoughts. You mentioned R&D flavor tickets. Really curious about the mechanics of this. Does the responsible engineer update once a sprint, weekly? I've seen junior staff spend months on dead ends .. curious how to manage that via process.
Also, if the R&D project is a team project involving multiple people, what is a reasonable update/sprint cadence?
Also, if the R&D project is a team project involving multiple people, what is a reasonable update/sprint cadence?
I had a similar experience years ago. It was not Jira but bugzilla, but you can use it in the same way (I told you it was years ago ;)).
Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course.
Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list.
Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.
Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course.
Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list.
Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.
How it worked for us was as follows:
the business goals were translated into "epic" tickets, after that it was entirely up to the engineers.
An example of this would be something like:
We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z)
Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface.
After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.
the business goals were translated into "epic" tickets, after that it was entirely up to the engineers.
An example of this would be something like:
We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z)
Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface.
After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.
The best way to tell if a company values engineers is to ask which cost center they are in.
Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.
Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.
That's a good theory, but it doesn't always work that way. I was working on the most profitable product the company had, but was laid off anyway. The new 6 month CTO had a new idea for how software development should be done and I wasn't part of it. Meanwhile at my prior job in IT my boss begged me to stay, I think because I made him look good.
Can relate to the latter. I've left about half a dozen jobs before striking out on my own, and the places where my boss actively pleaded with me to stay were places where I was definitely an operations cost centre and a galaxy away from anything resembling a profit centre or a revenue driver.
Politics. I was competent, precocious, energetic, participated in many meetings and liaised with lots of teams with which people in my position don't usually liaise, bailed out some people in other parts of the business with unexpected skill sets and initiative, and made the manager look good.
Meanwhile, the one job I was actually fired - not laid off - from, I was sitting very close to the money train.
Politics. I was competent, precocious, energetic, participated in many meetings and liaised with lots of teams with which people in my position don't usually liaise, bailed out some people in other parts of the business with unexpected skill sets and initiative, and made the manager look good.
Meanwhile, the one job I was actually fired - not laid off - from, I was sitting very close to the money train.
The money train is usually the part of the company that attracts the wrong kinds of people. They know it’s the easiest way to succeed: by being part of the team that brings in a lot of revenue. It becomes easier to show your “contributions” in monetary terms even if you may have not been directly responsible for that. As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.
> The money train is usually the part of the company that attracts the wrong kinds of people.
Waiting for it...
> As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.
Ah, there it is. I had to learn this lesson the hard way, and let me tell you, the kool-aid is no longer so sweet. The money train is often just a mobile coliseum. There's no escaping the gladiator aspects role. It's disappointing.
Waiting for it...
> As a result, these competitive types will also try to remove anyone who isn’t an “ally” regardless of whether these people provide value to the business.
Ah, there it is. I had to learn this lesson the hard way, and let me tell you, the kool-aid is no longer so sweet. The money train is often just a mobile coliseum. There's no escaping the gladiator aspects role. It's disappointing.
I've found if you are good at your position being part of the cost centre operation side means you will be left alone and ignored. Because of that you are less likely to be promoted. The profit side often gets random kudos, awards and probably bigger salaries.
For me being unimportant enough that money spent on a scrum master doesn't make sense is the right work-life balance.
For me being unimportant enough that money spent on a scrum master doesn't make sense is the right work-life balance.
A question I like for non-tech businesses is: "do you see this as a software business or transitioning to become one?"
Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.
Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.
I dearly hope my cast iron skillet will never require a firmware upgrade.
A company that makes cast iron skillets can still have software as a core part of their business. Logistics, monitoring the manufacturing process, forecasting demand. All of these things can be software that is core to business. Or even more important, having a useful website for selling their products.
Sure, but Le Creuset will never describe themselves as "a software business"...
(And if they did, I'd immediately be looking for a different cookware supplier.)
(And if they did, I'd immediately be looking for a different cookware supplier.)
Ah yeah I don't think asking if they are a "software business" is actually a good question.
But I'd still be wary of working for them if their software engineers were in IT.
But I'd still be wary of working for them if their software engineers were in IT.
This kind of companies don't have software engineers per se, they outsource everything and just keep management around, even IT.
[deleted]
But it's sold by a company with a website, and if it's in-house, (probably quite a big 'if') its developers probably don't want to be lumped in with its phone line, office PC etc. sysadmins (and I'm sure it's mutual).
I think that's the point. Cookware's just a further-from-tech example of it.
I think that's the point. Cookware's just a further-from-tech example of it.
I'd be perfectly happy being lumped in with the Sys Admins. They are, in most companies, the most misunderstood role. There's an expression that basically says "When things are going great, everyone wonders what sysadmin does. When things are going poorly, everyone wonders what sysdamin does". A good sysadmin team is amazing and, in many cases, vital to a successful business.
I think the only other role that gets ignored as much is the Executive Assistant(s). Much like sysadmin, good ones make sure everything runs smoothly, and should be prized like gold.
Being viewed as a value multiplier (like good instances of the above should be) is a fine goal in life.
I think the only other role that gets ignored as much is the Executive Assistant(s). Much like sysadmin, good ones make sure everything runs smoothly, and should be prized like gold.
Being viewed as a value multiplier (like good instances of the above should be) is a fine goal in life.
I wasn't saying their useless at all, I said the feeling's probably mutual, is just a different role, so if they're lumped together then as you say, at least one has been misunderstood.
I think a better question is: do you consider your software systems a competitive advantage?
This can be carried too far. Every business now has a director or consultant whose job is to chart the company's progress towards becoming a software business. This can have any number of effects:
1. It's not a slam dunk that software development is an asset to a business. Entire books have been written on how to keep software projects from eating your business alive. Many software businesses fail.
2. The hardware people notice that they're being treated as second class citizens, and wander away. Remember, the best leave first, including the people who fully understand how your product works.
1. It's not a slam dunk that software development is an asset to a business. Entire books have been written on how to keep software projects from eating your business alive. Many software businesses fail.
2. The hardware people notice that they're being treated as second class citizens, and wander away. Remember, the best leave first, including the people who fully understand how your product works.
If development is in product, how long has development been in product? Is this a recent change where development was transitioned from IT to product during a recent transformation?
Not directed at you, just some general comments.
As someone hinted at in another comment, it seems a better (less dichotomous) framing is:
- tech first (developer lead, selling software or hardware),
- tech enabled (developers are a key collaborator with the business, e.g., logistics, manufacturing, ecomm, marketing, really every company should be), or
- tech as a cost center (the “traditional” company in the article).
What about the trifecta of product, engineering, and design advocated for by Marty Cagan?
I think the same argument that’s being made for giving developers more weight in the development process could be argued equally as well from the side of design.
Edit for formatting.
Not directed at you, just some general comments.
As someone hinted at in another comment, it seems a better (less dichotomous) framing is:
- tech first (developer lead, selling software or hardware),
- tech enabled (developers are a key collaborator with the business, e.g., logistics, manufacturing, ecomm, marketing, really every company should be), or
- tech as a cost center (the “traditional” company in the article).
What about the trifecta of product, engineering, and design advocated for by Marty Cagan?
I think the same argument that’s being made for giving developers more weight in the development process could be argued equally as well from the side of design.
Edit for formatting.
Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.
I haven't done it myself, but I've hired people who were stuck in IT.
Just don't talk negatively about your old job. "I'm looking to move because I want to have more impact". "The work I'm doing now is not core to company's success and I want to have more impact". Etc.
I never looked down on someone who was doing boring work if that is what they were supposed to be doing. I'm looking for people who can communicate well and have strong core fundamentals. If you can demonstrate those things then you're doing well.
What kind of red flags are you worried about?
Just don't talk negatively about your old job. "I'm looking to move because I want to have more impact". "The work I'm doing now is not core to company's success and I want to have more impact". Etc.
I never looked down on someone who was doing boring work if that is what they were supposed to be doing. I'm looking for people who can communicate well and have strong core fundamentals. If you can demonstrate those things then you're doing well.
What kind of red flags are you worried about?
I guess I’m worried about talking about how we have really poor development practices. It’s hard to describe what I do, they try to block people from learning about what their kanban card is for. I just write proprietary scripting language functions then fill out a Word document “unit test” about them. I guess I can editorialize and try to steer the conversation towards what I can bring to the company. Thanks for the advice!
If I was interviewing you and you told me "my current company has very bad development practices" and then gave me a list of all the things you think they are doing wrong and all the ways it could improve, I'd probably be really impressed. Then I'd ask you why you don't change those things, and I would hope you'd tell me a story about how you tried to change it but got blocked, or maybe small changes you are making to make things better.
This would tell me that you're really engaged, up to date on the latest methods, and motivated to make things around you better.
This would tell me that you're really engaged, up to date on the latest methods, and motivated to make things around you better.
Good advice. Also: don't blame the people around you for why you couldn't fix something. Even if it's because your manager was a short-sighted idiot, or the senior engineer on your team was jealously guarding his territory, you don't have to say that in the interview. See if you can reframe it in a more blame-neutral way.
For example, if you couldn't remove a bad pattern because it was too deeply entrenched for you to handle it yourself, and you couldn't get anyone more senior interested: that's expected for a junior developer and probably wouldn't be held against you.
For example, if you couldn't remove a bad pattern because it was too deeply entrenched for you to handle it yourself, and you couldn't get anyone more senior interested: that's expected for a junior developer and probably wouldn't be held against you.
I've actually asked this question in an interview before to a candidate. "Is there anything about the process you work in now that you would change, and how would you do it differently?"
That sounds not great. Two years into your career you need a better experience and great mentors. Get any job that is writing code. What's great is that you're only two years in, I see people like this 10 years into their career. They get laid off and can't find a job because they don't have any skills others value;
I am sure this will just get buried, but you could consider searching for a company that appreciates honesty.
You can talk about wanting more ownership. That can include talking about working closely with end users and making long term design decisions.
I made the switch you are talking about. I did talk about my job in the interviews, and in retrospect that would have been a pretty clear signal than I didn't know how that type of company works. I think I got the job because my employer is primarily looking for competent problem solvers, and they are willing to teach the rest on the job. Not all companies may be like this, but the big ones probably will.
That’s good to know, thanks. Congrats on the move!
I guess the question to ask is, what do you talk about? When I talk about working in those types of companies I mention that I like to work in cross functional teams, interact with product and design, being part of the ideation process, wanting to understand the business and deliver value quicker.
What types of things do you say and why do you feel they may be red flags?
What types of things do you say and why do you feel they may be red flags?
And the geography too. If a european company outsources its development to India, even if they hire the top of the basket there, and they often can’t, the devs are so remote from the business that I hardly see how it could emulate the sort of dynamism you have in the SV.
I'm lucky enough to make products for our company while being in IT, so it is a hybrid. With data driven decisions becoming more important to businesses these days, I see IT's transitional role as the cost side (vs. profit side) starting to change.
> The best way to tell if a company values engineers is to ask which cost center they are in.
Duh! Companies don't put all the engineers in one cost center. It's either by teams/product/business unit/function
Duh! Companies don't put all the engineers in one cost center. It's either by teams/product/business unit/function
This is a good article but there is a causality problem. I know a lot of pure software companies in the EU that work like that. If software is your core business, developers are in the loop at every decision, if your core business is building power plants...they are not. Now the Marc Andressen argument might be that software eats the world and everybody should run their business like this, and that might actually be true or not. Beside this product/core relationship problem, I see one other issue and that are margins, many SV companies are comparatively young and are in new markets with high margins (or ridiculously high funding) these high margins change their way of doing business.
I think funding and margins are the thing that are actually causal here: when you're swimming in funds, can afford to hire whoever you like to do whatever you like and you don't need to be turning a profit for at least 5 years, the organisation can be run very differently to one in which quarter to quarter cashflow really matters and there are margins to think about.
Funnily enough I work at a software company which is bootstrapped and where cashflow matters, I'd love to run things like a fully funded SV startup but I can't. We just can't afford it.
Funnily enough I work at a software company which is bootstrapped and where cashflow matters, I'd love to run things like a fully funded SV startup but I can't. We just can't afford it.
This is an important comment. Would you put an engineer in charge of a bank product? What about a medical service? It's one thing to be consulted, it's another thing to be the decision-maker.
I agree with the premise of the article that more engineers need to be in powerful positions, but some domains are just too complicated and require substantial domain knowledge to make "product" decisions. It's the collaboration between product and engineering that's important, not switching one for the other. The biggest problem I have with the article is that it presents the problem as too binary with only 2 possible outcomes - someone being in charge.
Tech companies put engineers in charge because the engineers are the domain experts, not because they figured out some secret sauce.
I agree with the premise of the article that more engineers need to be in powerful positions, but some domains are just too complicated and require substantial domain knowledge to make "product" decisions. It's the collaboration between product and engineering that's important, not switching one for the other. The biggest problem I have with the article is that it presents the problem as too binary with only 2 possible outcomes - someone being in charge.
Tech companies put engineers in charge because the engineers are the domain experts, not because they figured out some secret sauce.
Good point on having developers in loop in a software business. Tesla might be a counter example, where it is often touted to be run like a "tech" company. Are developers in loop in the design of non-software stuff? (is chassis design an example? or maybe not?)
The other point on triangular communication with middle managers I think is known problem that Musk has publicly spoken about..
My problem with non-software companies is that they don't treat programmers as equals. To them they will always be "code monkeys" and below the mechanical or electrical engineers. These companies are led by people who think all programmers are stereotypical "nerds" and try to create software departments according to the script of The Big Bang Theory. Just look at this crap I was sent by a recruiter: https://www.mercedes-benz.io/ It's chock full of buzz words and infantilizing language. I don't want to "impact", "move the world" or whatever bullshit the marketing department can pull out its ass. I want good pay, good work-life balance and I want to be treated as a professional.
I once had a rather prestigious developer position in a Silicon Valley company. The "approachability" was a double edged sword.
One problem I fought was that a lot of people expected handholding from me, or wanted me in their meeting to "feel important." There really is value to having your manager act as a gatekeeper.
Another problem I had was that less ambitious people in other departments (support, qa,) would throw their work over the wall to me. I eventually had to get involved with triage to train the other managers to push back on this.
One problem I fought was that a lot of people expected handholding from me, or wanted me in their meeting to "feel important." There really is value to having your manager act as a gatekeeper.
Another problem I had was that less ambitious people in other departments (support, qa,) would throw their work over the wall to me. I eventually had to get involved with triage to train the other managers to push back on this.
> would throw their work over the wall to me
I can relate to this. One way to look at this is that dev-team is where majority of IP is created and not in teams like support/qa/docs/PMs. Over the period of time, they are also the reservoir of domain knowledge.
This often results into nuisances like:
1. Instead of reading product docs people will ask questions directly over slack (e.g Do we support Windows 2008? Do we have feature X?)
2. Adding dev team in a slack channels in which sales can directly ask questions which ideally should be answered by Product Managers.
I can relate to this. One way to look at this is that dev-team is where majority of IP is created and not in teams like support/qa/docs/PMs. Over the period of time, they are also the reservoir of domain knowledge.
This often results into nuisances like:
1. Instead of reading product docs people will ask questions directly over slack (e.g Do we support Windows 2008? Do we have feature X?)
2. Adding dev team in a slack channels in which sales can directly ask questions which ideally should be answered by Product Managers.
yes! I'm more junior than you are, but once I got a rep as a gung ho problem solver, I started getting approached by random sales associates asking me to implement features. I would usually do it out of love for the business, even if it meant I was staying up until 2am hacking shit together. But then I burned out. My quality of life improved significantly when I started being strict about people communicating with me only through my manager or product manager.
Yeah, but if you are like me someone who always wanted to get out of software completely, this would have been a god send. But over here in the UK I've never been at a company that has allowed me to even have a sniff of the business side. And I'm nearly 20 years into an IT career spanning 8 different companies.
As an outsider observer I always get the feeling companies in the UK are particularly guilty of viewing developers as a resource which merely produces code and which should be kept separate from the business. Not sure why that is but I feel like I read something to that effect every month.
> would throw their work over the wall to me
For myself as QA, I would see the throwing the opposite direction. Devs started having me close out unit tests, giving incomplete work hoping I find their issues, gathering requirements to know what to test etc.
The requirements should be coming from elsewhere and hopefully you are involved at the start of the project.
Hopefully you should be catching all issues regardless and the increase catches look good to your matrix.
It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom.
But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly structured JIRA tickets.
Would they get better talent if their fronds tended more toward the SV model of compensation and autonomy described in the article? Absolutely. But in terms of marginal productivity or ROI, it's far from clear that it makes much of a difference to the financial performance of Cluky Java Accounting Application for Insurance Companies #574. That means massively overpaying for skills, or skill levels, that aren't really needed, or aren't needed enough to matter.
No, it's not the kind of software development any of us want to do, and I think the audience for this post are for the most part in no danger of having to. But I think it's important to be honest about the fact that this sort of dimly-lit, cubicle-dwelling sweatshop software work _is_ a high percentage of software development occurring on the planet. For that type of company, following the "SV" philosophy would arguably constitute a dereliction of fiduciary duty.
My view may be somewhat coloured by my exposure to medium to enterprise-sized companies in the telecom world, where a lot of the work is tedious, unimaginative and formulaic, using unexciting but established technology stacks, and so forth. But it still needs to be done, and there are companies who darken the skies with people to do it.
Lastly, I incorporate by reference everything that has been said elsewhere in this thread about the nature of large organisations and the poor scalability of engineering-led company process. Most software work, by volume, doesn't consist of skunkworks innovation or the development of something new. Most software work is incremental, in many cases strictly maintenance mode, and caters to many stakeholders. Large organisations and big capital serve an entirely different purpose that is realised at points further along the technology and product lifecycle. In this comment, I merely chose to focus on (1) the problems of empowering "average" talent this way and (2) the poor prospectus for doing so.
But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly structured JIRA tickets.
Would they get better talent if their fronds tended more toward the SV model of compensation and autonomy described in the article? Absolutely. But in terms of marginal productivity or ROI, it's far from clear that it makes much of a difference to the financial performance of Cluky Java Accounting Application for Insurance Companies #574. That means massively overpaying for skills, or skill levels, that aren't really needed, or aren't needed enough to matter.
No, it's not the kind of software development any of us want to do, and I think the audience for this post are for the most part in no danger of having to. But I think it's important to be honest about the fact that this sort of dimly-lit, cubicle-dwelling sweatshop software work _is_ a high percentage of software development occurring on the planet. For that type of company, following the "SV" philosophy would arguably constitute a dereliction of fiduciary duty.
My view may be somewhat coloured by my exposure to medium to enterprise-sized companies in the telecom world, where a lot of the work is tedious, unimaginative and formulaic, using unexciting but established technology stacks, and so forth. But it still needs to be done, and there are companies who darken the skies with people to do it.
Lastly, I incorporate by reference everything that has been said elsewhere in this thread about the nature of large organisations and the poor scalability of engineering-led company process. Most software work, by volume, doesn't consist of skunkworks innovation or the development of something new. Most software work is incremental, in many cases strictly maintenance mode, and caters to many stakeholders. Large organisations and big capital serve an entirely different purpose that is realised at points further along the technology and product lifecycle. In this comment, I merely chose to focus on (1) the problems of empowering "average" talent this way and (2) the poor prospectus for doing so.
I feel like the article is mostly written from a product perspective. I worked in an area that was billed out by the hour, it was just complicated enough to require developers to do the work, but the work pieces were very quantifiable (add text to say xyz based on a business rule, show different images based on a rule, etc). It meant graduate programmers, immigrants with limited English skills, or others without much talent or drive would end up there. It's a good safe role for someone who just wants to get paid and go home on time (usually).
It was very much a factory in the way the article says, but I feel like it has to be because of the nature of the work. I did talk to customers directly on larger projects but since I was building on top of internal systems and processes my role was mainly implementation/glue coding. Most of my frustrations were with our internal dev and IT who built and maintained the systems - over time they became more walled off, not less, which definitely impacted our work. And unfortunately as we were more 'client facing' any outages came back to bite us, not them, which was an annoying organisational dysfunction. They simply weren't incentivised to care as much as we were.
It was very much a factory in the way the article says, but I feel like it has to be because of the nature of the work. I did talk to customers directly on larger projects but since I was building on top of internal systems and processes my role was mainly implementation/glue coding. Most of my frustrations were with our internal dev and IT who built and maintained the systems - over time they became more walled off, not less, which definitely impacted our work. And unfortunately as we were more 'client facing' any outages came back to bite us, not them, which was an annoying organisational dysfunction. They simply weren't incentivised to care as much as we were.
Those companies will die...
It's probably easy to believe that if you're developing a SaaS app on the Pacific Coast, but in actually-existing reality -- no, they won't.
Their business processes and products are often sclerotic, and so are vulnerable to disruption by smaller, more nimble startups. That's the central premise of virtually all B2B software from the Valley. But they certainly aren't going to die.
In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. So, they're a vital part of the biosphere and they're not going anywhere.
Their business processes and products are often sclerotic, and so are vulnerable to disruption by smaller, more nimble startups. That's the central premise of virtually all B2B software from the Valley. But they certainly aren't going to die.
In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. So, they're a vital part of the biosphere and they're not going anywhere.
> In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups.
I think this is becoming less and less true, unless one is competing with the tech giants directly. In the past enormous capital investment was required to build out the minimum viable capacity needed to serve larger customers or market segments. Today you can rent that capacity. In the future more and more types of capacity can become rentable, such as logistics, compliance, manufacturing, etc.
I think this is becoming less and less true, unless one is competing with the tech giants directly. In the past enormous capital investment was required to build out the minimum viable capacity needed to serve larger customers or market segments. Today you can rent that capacity. In the future more and more types of capacity can become rentable, such as logistics, compliance, manufacturing, etc.
To make many things a household name, one has to compete with the giants directly. I am not necessarily referring to the 'tech' economy. Most uses of tech are not in the 'tech industry' itself but to fulfill ulterior aims in other sectors.
I don't think so. At least not all of them.
Agile is not always the right approach. For highly regulated or safety critical industries, it's quite likely to be the wrong approach.
(On the other hand, Waterfall for B2C mobile apps or casual games is also almost always the wrong approach too...)
Agile is not always the right approach. For highly regulated or safety critical industries, it's quite likely to be the wrong approach.
(On the other hand, Waterfall for B2C mobile apps or casual games is also almost always the wrong approach too...)
Those companies have been around forever, and have will be around longer than most SV-like companies.
The big take away for me here is: does the company see engineers as a "cost center" or a "profit center"?
You can almost directly correlate the "traditional" approach to seeing engineering as a cost center, while startups/S.V. style companies see engineering as a profit center, and they treat their employees accordingly.
You can almost directly correlate the "traditional" approach to seeing engineering as a cost center, while startups/S.V. style companies see engineering as a profit center, and they treat their employees accordingly.
I think part of this is because in SV a software engineer is closer to the value creation of the end product. In a traditional company, the software developers are more of an enabling function than a primary one
This is probably because Silicon valley companies have tech cofounders and first early hires are also engineers who become involved in important decision making beyond engineering, like product and even strategy. This creates a culture of empowering engineers.
On the contrary, companies where tech is an afterthought-- well why would you empower your engineers to make business critical decisions if you're running a hospital or a sports team.
On the contrary, companies where tech is an afterthought-- well why would you empower your engineers to make business critical decisions if you're running a hospital or a sports team.
A nontrivial part of this blog post is essentially saying "Silicon Valley practices leader-leader management more than most industries", in the sense of David Marquet's "Turn The Ship Around!". Points 1, 2, and 5 are precisely aspects of leader-leader management.
This article hit me hard. I work in a non Silicon Valley-like company. I became a developer because I thought I love coding. But I found out that, in fact, I love problem solving. Tightly defined Scrum tasks make me sad and I would love to have more autonomy.
I strongly encourage you to go out and find such a job then! You certainly don't have to move to SV to find one, and we spend too much of our lives at work to forego the opportunity of having work we're passionate about.
I'm the same way. I spend a good amount of my time being pulled into production issues or debugging a particularly difficult issue with the product. In both of those cases, the "code" changes often take only a few minutes, the problem solving can take hours.
I get a lot of satisfaction from that. Of course that means that as a team lead/manager, I have to have a lot of self discipline to allow my team members to do the same and not try to solve every problem.
I get a lot of satisfaction from that. Of course that means that as a team lead/manager, I have to have a lot of self discipline to allow my team members to do the same and not try to solve every problem.
I was at Apple during the golden SJ era and it was like this. I remember asking my manager (in my first year or so, fresh out of school) about something and he replied "That's what we're paying you for!"
I was at Skype during the eBay years and it was similar. Lots of autonomy. Then Skype got sold, Silverlake instituted Scrum training for everyone, and well, look what happened. Product owners took over; the engineers became Jira-ticket minions.
That said, I do understand the problem with giving engineers too much freedom, if there's not enough maturity on the business side. I've been at places like that, too. Engineers gone wild. Just burning money.
I see too many startups adopting Agile/Scrum for lack of a better clue on how to run software development. These days I refer people to Basecamp's Shape Up for "just enough" structure.
I was at Skype during the eBay years and it was similar. Lots of autonomy. Then Skype got sold, Silverlake instituted Scrum training for everyone, and well, look what happened. Product owners took over; the engineers became Jira-ticket minions.
That said, I do understand the problem with giving engineers too much freedom, if there's not enough maturity on the business side. I've been at places like that, too. Engineers gone wild. Just burning money.
I see too many startups adopting Agile/Scrum for lack of a better clue on how to run software development. These days I refer people to Basecamp's Shape Up for "just enough" structure.
We have product and tech roles in our company. Product always goes to tech for design and implementation advice. This is taken care of during sprint planning. I see product getting a lot of hate from engineering types recently. It just smacks of myopia. Engineers are being well paid because the company makes good money from the whole solution not just the technical implementation. What an engineer thinks is important may not be that important from the business perspective which is where product comes in. If product wants to do something that will cause technical problems that's where engineering comes in. It's a team effort. As an analogy no soccer team fields only goalkeepers or only strikers etc.
Interestingly enough most of this applies to one of the SF tech darlings I worked for when it was growing between 200-1,000 people. Every day I'd get either a pile of Jira tickets or a PDF full of mocks to build. Several projects I worked on were canned at the last minute by the "product" clique.
I don't think it's about SV companies against traditional companies, but more about companies that intrinsically value technology versus those that do not.
I don't think it's about SV companies against traditional companies, but more about companies that intrinsically value technology versus those that do not.
From my experience, the triangle communication is great within the engineering department. It can cause big problems if persons from outside engineering wander in and communicate with an engineer. Typically, this is a problem when the engineer happens to want to be helpful and winds up spending time on a matter unrelated to the task they have committed to delivering. We've seen hours, days and even weeks of time consumed by such side-tracking.
We've had to smack it down pretty hard in a couple of cases, and pretty strictly enforce the triangle when communicating with non-engineering departments.
We've had to smack it down pretty hard in a couple of cases, and pretty strictly enforce the triangle when communicating with non-engineering departments.
We've run into the same problem. What's made this a particularly hard problem for us to address is that the intentions of involved parties are usually aligned with the best interests of the business in the short term despite being misaligned (and detrimental) over the medium and long term. In discussion it's clear that both parties are doing what they believe is right for the company, but their level and responsibilities might inadvertently encourage them to optimize for the short term. The ensuing conversation is usually a tight rope walk between trying to get both parties to understand short term vs long term outcomes and consequences while encouraging them to continue to execute on what they believe is right for the company.
What's worked for us is to not restrict communication, but to hold our engineers accountable to what they say they'll get done and when. If something slips and it's not for a technical or personal reason (i.e. some risk materializing or needing to take unplanned time off), but rather because someone floated in and asked for something that wasn't scoped in, that comes up in a review and reflects poorly on the engineer and the asking party. On the other hand, if the engineer is able to get all of their scoped work done and also get the unplanned work done, that reflects well on the engineer and potentially the asking party. In our experience, approaching these situations in this way also has the benefit of preserving and encouraging individual autonomy.
What's worked for us is to not restrict communication, but to hold our engineers accountable to what they say they'll get done and when. If something slips and it's not for a technical or personal reason (i.e. some risk materializing or needing to take unplanned time off), but rather because someone floated in and asked for something that wasn't scoped in, that comes up in a review and reflects poorly on the engineer and the asking party. On the other hand, if the engineer is able to get all of their scoped work done and also get the unplanned work done, that reflects well on the engineer and potentially the asking party. In our experience, approaching these situations in this way also has the benefit of preserving and encouraging individual autonomy.
The engineering job (regardless of specific engineering discipline) is essentially solving business problems using applied science. That's it.
If you don't let your engineers understand the business problem they're supposed to solve, you're wasting valuable resources.
If you don't let your engineers understand the business problem they're supposed to solve, you're wasting valuable resources.
As someone who has been on both sides, it amuses me to see programmers (many who could not be called engineers), reduce non-programming roles to sending emails and having meetings. There are absolutely some people who frustratingly cannot do any work on their own without a meeting - they are mostly good at guiding a group and making sure communication and progress is happening. However, there are SO MANY skills and functions outside of programming that go into building the right thing the right way at the right time. Costco doesn't beat Sams with more engineering, they did it with strategy.
This kind of reminds me of Paul Graham's article on how "suit culture" ruined Yahoo, a company poised to be bigger than Google but squandered it by being engineer-unfriendly.
http://www.paulgraham.com/yahoo.html
A quote: Hacker culture often seems kind of irresponsible. That's why people proposing to destroy it use phrases like "adult supervision." That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.
http://www.paulgraham.com/yahoo.html
A quote: Hacker culture often seems kind of irresponsible. That's why people proposing to destroy it use phrases like "adult supervision." That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.
In extremely small companies that are very technology driven (yet often pretty traditional in terms of the problem they are solving) you can find much of the same. (I work for such a company)
SV-like companies try to hire the best of the best so it makes sense to that they would give them more greater autonomy and more responsibilities. These observations may not help a 'traditional' company become better.
This mostly matches my experience...but I wonder if it ignores significant costs.
In particular, how this impact long term maintenance vs. the desire to build new interesting things? (e.g., see https://themaintainers.org/). And what about people who just enjoy the act of coding — of wizzing through tickets and gathering points?
For another potential cost, take the example given of the Like button in the piece. I'd be curious what Justin Rosenstein now thinks of the example of the Like button. The author says "The business impact of this button is well in the billions: allowing Facebook to (re-) target ads, and "track" users outside of the Facebook site. [...] Everyone is better off for it: the people with the idea and the business." Does everyone here include the users and world?
Perhaps if we had better metrics, this SV would work for everything. But in the current world, with profit, data, and growth metrics being incentivized, it may have real societal costs.
In particular, how this impact long term maintenance vs. the desire to build new interesting things? (e.g., see https://themaintainers.org/). And what about people who just enjoy the act of coding — of wizzing through tickets and gathering points?
For another potential cost, take the example given of the Like button in the piece. I'd be curious what Justin Rosenstein now thinks of the example of the Like button. The author says "The business impact of this button is well in the billions: allowing Facebook to (re-) target ads, and "track" users outside of the Facebook site. [...] Everyone is better off for it: the people with the idea and the business." Does everyone here include the users and world?
Perhaps if we had better metrics, this SV would work for everything. But in the current world, with profit, data, and growth metrics being incentivized, it may have real societal costs.
> And what about people who just enjoy the act of coding — of wizzing through tickets and gathering points?
That's not coding. Those people enjoy closing tickets and gathering points. That's fine, but they should try videogames, it's a similar experience but 100x more entertaining. Shame it generally doesn't pay.
That's not coding. Those people enjoy closing tickets and gathering points. That's fine, but they should try videogames, it's a similar experience but 100x more entertaining. Shame it generally doesn't pay.
What European companies are like this? I've been trying to apply for ages at US companies, for the reasons such as this. Reading HN for 6 years and being US-centered in general (thanks to tech) made me want to work like this. I've noticed that at European organizations people indeed try to pin me in a box, and then I can't thrive when I'm working there.
For what it's worth. I worked at multiple European tech companies and moved to SF a couple of years back to work at a SV startup, and later a FAANG and this post heavily romanticizes silicon valley companies. Except for the bigger pay, I found them to be not that different. I'm now working back in europe and really don't miss SF/SV
Another comment mentioned that a good indicator is whether or not software is a company's raison d'être or not. Compared with trad companies like old-school banks, B&M retailers, etc. If the entire value of the company is and always has been their software, it's likely they value engineers more.
FAANG can be found in Europe. And I believe companies like Spotify, Klarna, Skyscanner, Uber (Amsterdam), takeaway.com are also working like this.
Flipdish (HQ in Ireland with a distributed tech team) is one.
Full disclosure - I’m the technical co-founder.
Full disclosure - I’m the technical co-founder.
The article forgets one detail though: while attributing much of the fault in the traditional managers saying their engineers "Here's a ticket. Do this. Don't think.", there is also a class of engineers that actually seek this "state", less rewarding but also much less challenging altogether. If you try the SV model with them you will fail.
it's funny, as the faang interview process, as i know it, does not select for the hybrid dev/product skillset the OP describes. in fact, it shies away from it about as far as you can get, instead focusing on beloved algorithmic problem solving, which i guess is a good fit for standardized testing and leveling, but will tell you nothing about broad skills in both software development and product design/management as described here.
For senior engineering roles, faangs do have design related interview component. Usually, there will be 4 hour long interviews. With new grads, all of them will be algorithmic problem solving while for senior engineers there will be 3 algorithmic and one design session.
algorithmic problem solving is very close to IOI/ACM ICPC type problems, which test on combination of knowledge of data structures+algorithms and creative ability to combine both to create own algorithms while being under interview anxiety+time limti stress. Quite essential in everything internet-scale and filters top percentile candidates pretty well.
THis process is not required for your average company where IT is a cost center and CRUD-type apps generator.
THis process is not required for your average company where IT is a cost center and CRUD-type apps generator.
yeah, yeah. programming contest problems make better programmers, sure. OP is arguing that developers should be more involved in product design though. although in a large enough shop that will likely cap out with a single service...
There is a second kind of leverage that startups in particular can get out of their developers: expecting them to live for the job.
The choice between a company where (a) you work on assigned tickets, but standard business hours and weekends off and X days of guaranteed holiday per year versus (b) a high autonomy, high pay but if the company needs you to pull a 90-hour week then you do it without asking - it's a tradeoff. Whether you get to write your own JIRA tickets is just one of many dimensions here.
One of those two options is not compatible, for example, with having responsibilities outside of work such as childcare.
The choice between a company where (a) you work on assigned tickets, but standard business hours and weekends off and X days of guaranteed holiday per year versus (b) a high autonomy, high pay but if the company needs you to pull a 90-hour week then you do it without asking - it's a tradeoff. Whether you get to write your own JIRA tickets is just one of many dimensions here.
One of those two options is not compatible, for example, with having responsibilities outside of work such as childcare.
I suspect another important part of the story here is that SV companies are more selective in their hiring. Part of the reason SV engineers use their extra freedom well is because they're better at what they do.
[deleted]
I think that in an ideal organization, staff autonomy is conditioned on the risks and rewards of staff-initiated contributions to the business.
High autonomy is higher variance. Some of that may be good - innovation. Some of that may be bad - customer or market failures. The outcomes are money consequences to a business, and given business has some to downside tolerance to that. In some businesses tech innovations have huge realizable upside.
Maybe a way to see the autonmy tradeofff is in terms of manufacturing complexity. A business whose products reach customers via endpoints on hosted service is different than one whose products are tractors off an assembly line. Maybe that's understood as how capital-intensive it is to bring a marginal capability to market.
I'll say further than in an ideal organization, with respect to autonomy, the job of management is allocating attention and distributing context, and that management and staff alike are serving a well articulated mission through the vehicle of the business organization. In a given instance, we all can take a compass reading on "true north" for business.
A non ideal business, for starters, has a self serving and self interested control structure that views autonomy in relation to power.
Both SV and traditional companies can be ideal or not. I think the difference comes down a culture of thinking about risk - reward, and the collective, cultural engagement with mission.
High autonomy is higher variance. Some of that may be good - innovation. Some of that may be bad - customer or market failures. The outcomes are money consequences to a business, and given business has some to downside tolerance to that. In some businesses tech innovations have huge realizable upside.
Maybe a way to see the autonmy tradeofff is in terms of manufacturing complexity. A business whose products reach customers via endpoints on hosted service is different than one whose products are tractors off an assembly line. Maybe that's understood as how capital-intensive it is to bring a marginal capability to market.
I'll say further than in an ideal organization, with respect to autonomy, the job of management is allocating attention and distributing context, and that management and staff alike are serving a well articulated mission through the vehicle of the business organization. In a given instance, we all can take a compass reading on "true north" for business.
A non ideal business, for starters, has a self serving and self interested control structure that views autonomy in relation to power.
Both SV and traditional companies can be ideal or not. I think the difference comes down a culture of thinking about risk - reward, and the collective, cultural engagement with mission.
[deleted]
I think one of the most interesting thing about working for a tech company is how transparent everything is and how much more power engineers have in the decision process as mentioned in the article. There’s a higher tendency that transition companies are purely revenue focused (for reasonable reasons). When that happens, the engineers’ customer is sales. When a company is focused on the idea (which makes money too), the engineers’ customer is the product.
[deleted]
These things (1. autonomy for software engineers; 2. curious problem solvers, not mindless resources; 3. internal data, code, and documentation transparency; 4. exposure to the business and to business metrics; 5. engineer-to-engineer comms over triangle-communication; 6. investing in a less frustrating developer experience; 7. higher leverage --> higher {autonomy, pay}; the "biggest" is a repeat of 2) seem like plausible differences between "SV" and "traditional" companies.
I wonder if there's data (survey? perhaps correlated with compensation?) to back up and establish magnitude and trend/diffusion or refute any or all?
Also would be interesting to look at those characteristics for non-employer open source projects and government. There would surely be lots of variation across projects and departments/governments, as there would be across companies, though I'd guess for non-employer open source 1, 2, 3, 5 would be very high, 4, 6, 7 unclear or lacking, and for government possibly even lower than traditional companies across the board? Just speculating, again, curious about data, or more speculation. :)
I wonder if there's data (survey? perhaps correlated with compensation?) to back up and establish magnitude and trend/diffusion or refute any or all?
Also would be interesting to look at those characteristics for non-employer open source projects and government. There would surely be lots of variation across projects and departments/governments, as there would be across companies, though I'd guess for non-employer open source 1, 2, 3, 5 would be very high, 4, 6, 7 unclear or lacking, and for government possibly even lower than traditional companies across the board? Just speculating, again, curious about data, or more speculation. :)
So then what... Yes it’s been true and knowable for many years now but, not many orgs change to a highly leveraged style. So then how to succeed at it?
Hard to address in a comment, easier to check for some big red flags.
What percentage of people involved have lived it before? If 0%, then I’m not sure it’s even possible. Similar to trying copy Disneyland. You could read a novel describing it but if no one‘s actually been there it’ll be a rough ride.
What’s the plan for anyone leading people? Some people freak out when people are newly crossing the triangle below them, more so if they don’t know why it’s important or how to adapt to it.
What are the checks to make sure your org is not just choosing a fancy name (I.e. digital transformation) and merely mapping old processes back onto it but with more overhead?
It seems like maybe that’s the mistake is to think about this as a process difference when really it’s a systemic and cultural difference.
Take the example of a stakeholder talking to a new hire. If stakeholders do it to ‘do the new process’ it’s not there yet. If they do it reflexively because they expect they may get useful feedback, then that’s a good sign.
Hard to address in a comment, easier to check for some big red flags.
What percentage of people involved have lived it before? If 0%, then I’m not sure it’s even possible. Similar to trying copy Disneyland. You could read a novel describing it but if no one‘s actually been there it’ll be a rough ride.
What’s the plan for anyone leading people? Some people freak out when people are newly crossing the triangle below them, more so if they don’t know why it’s important or how to adapt to it.
What are the checks to make sure your org is not just choosing a fancy name (I.e. digital transformation) and merely mapping old processes back onto it but with more overhead?
It seems like maybe that’s the mistake is to think about this as a process difference when really it’s a systemic and cultural difference.
Take the example of a stakeholder talking to a new hire. If stakeholders do it to ‘do the new process’ it’s not there yet. If they do it reflexively because they expect they may get useful feedback, then that’s a good sign.
Software engineers can't always be the best or effective at solving problems that require specialized non-software engineering knowledge.
In an SV-style company that develops a SaaS product, engineers can make all sorts of decisions, since they are solving a problem they are intimately familiar with.
What about other industries that require specialized knowledge or regulatory bureaucracy, like finances or healthcare?
In an SV-style company that develops a SaaS product, engineers can make all sorts of decisions, since they are solving a problem they are intimately familiar with.
What about other industries that require specialized knowledge or regulatory bureaucracy, like finances or healthcare?
You just have other technical roles to handle those areas that are treated the same as the software engineers. Or "technical" roles in the case of bureaucracy (once it gets complicated enough to need entire people to manage it).
this, I work with mid-size ERPs that deal with some law, some tax, invoices and all this shit that ERPs deal with and I wouldnt trust myself to commit any "business logic" decision in that environment
there's so much stuff happening
there's so much stuff happening
In such an environment engineers should be working closely with these subject matter experts... you don’t just put fear in the engineering culture and throw layers of bureaucracy at the engineers.
I have worked in this field since 1980. The first time I was given the title "Software Engineer" was at Apple in 2001. Was I really a trained, licensed engineer in the traditional sense? Of course not. But it sure made me feel flattered and empowered. Silicon Valley HR execs use strategies like this to manipulate their employees, particularly the youngest ones.
C'mon, you're too cool for higher pay and worker's rights. :D
Software developers enjoy great pay, great perks, and have plenty of job opportunities if anyone abuses them, in North America at least.
Why do people keep pretending like Silicon Valley engineers aren’t one of the single highest paid demographics in the entire country?
Compared to other professions? maybe SV is just treating "Engineers" more like other older professions and has less of the class distinctions you see in the UK for example.
Initially this was true, certainly SV would use higher salaries to draw developers and engineers to the valley. But cost of living has exploded since then. A modern developer living in SV does not command a higher standard of living as food and housing costs are significantly higher than most of the rest of the country. A similar trend plays out on the east coast so it’s not just SV.
It’s balanced by the CoL adjustment. In short, SV engineers are not better off, and haven’t been for the past decade. This is apparent by the observed exodus in the light of Covid forcing a shift to primarily remote work. Engineers are trying to reclaim their wage advantage by moving to cheaper locations, and companies are fighting back by reducing compensation accordingly.
It’s balanced by the CoL adjustment. In short, SV engineers are not better off, and haven’t been for the past decade. This is apparent by the observed exodus in the light of Covid forcing a shift to primarily remote work. Engineers are trying to reclaim their wage advantage by moving to cheaper locations, and companies are fighting back by reducing compensation accordingly.
Sort of. Often a big chunk of your CoL is going into a massively appreciating asset. People always seem to ignore this when talking about the top n most expensive cities in the world. You can literally sell your apartment and go live in a mansion most other places on the planet when you feel like it.
hm. do many people in silicon valley buy their apartment or house there these days? Is it even accessible?
People in general or people in tech? Well what’s the typical mortgage multiple, 6 or 7 times salary? So for the latter, it seems pretty attainable to get an apartment at the lower end of the market to start out on. Correct me if I’m wrong, though.
Well if you're just renting the CoL difference is nowhere near the salary difference you'd get in other locations/careers.
Pay is nowhere remotely close to being proportional to impact on revenue though. Many engineers are much more offended by unmeritocratic pay than by absolute value of pay being low - hence why you can convince amazing engineers to work for peanuts at start-ups.
I want the greatest share of the returns of my own labor I can get. If that results in very high salary, great, it’s earned. If I take a risk at a place where that translates to much lower salary, that’s fine too - as long as it’s very objectively meritocratic.
If I am making $200k per year as a top, top performer, while my employer is paying far more mediocre performers $175k (perhaps based of geolocation), or where both of us are bringing in ~ millions of revenue, that’s super unacceptable.
As time goes on, the surplus of my labor productivity that a big corporate employer can capture beyond my total compensation should be decreasing heavily - and expert software labor is one class that has the negotiation power to actually push that issue.
So I’d flip your question on its head. Why do we pretend that rent-seeking executives deserve the surplus revenue generated by rare talented engineers? Why (with complete sincerity) aren’t many, many, many more software engineers paid on the order of what Hollywood actors are making, while executive salaries simply have to come way, way down in these lines of business?
I want the greatest share of the returns of my own labor I can get. If that results in very high salary, great, it’s earned. If I take a risk at a place where that translates to much lower salary, that’s fine too - as long as it’s very objectively meritocratic.
If I am making $200k per year as a top, top performer, while my employer is paying far more mediocre performers $175k (perhaps based of geolocation), or where both of us are bringing in ~ millions of revenue, that’s super unacceptable.
As time goes on, the surplus of my labor productivity that a big corporate employer can capture beyond my total compensation should be decreasing heavily - and expert software labor is one class that has the negotiation power to actually push that issue.
So I’d flip your question on its head. Why do we pretend that rent-seeking executives deserve the surplus revenue generated by rare talented engineers? Why (with complete sincerity) aren’t many, many, many more software engineers paid on the order of what Hollywood actors are making, while executive salaries simply have to come way, way down in these lines of business?
Hollywood executives get paid more than most actors. Only the absolute elite talent are making above scale let alone more than what the executives are making, and their managers (aka recruiters) are negotiating that for them.
Nowhere did I suggest executives shouldn’t be paid more than engineers.
Depending on your budget the min SAG rate can be anywhere from ~100-1000/day so many sw engineers in fact make much more than most actors
I’m exclusively drawing the comparison with high demand actors / athletes. Perhaps athletes has the better clarity - many NBA players are paid more than their head coach, and even those paid less are still paid much more competitively to their revenue contribution than engineers by comparison.
Superstar athletes/actors have much higher roi - nobody is buying your product bc of star c++ developer you hired. Besides there are only like 50 or superstar players/actors at any given moment. Pretty sure you can find this many engineers who made millions
I guess we need data to back this up - I’m not buying it without more data. Even the top, top valued sports franchises only have estimated market caps in the range of $5 billion.
In other words, for small cap companies, yes, the ROI of athletes to their franchises is relatively higher than engineers to their companies. But for most of the SP500 this is not true, and there are lots of software-heavy companies with much higher market cap to the extent that even with 10k or 100k employees, I doubt an athlete’s ROI for a small sports franchise is proportional to the ROI of employees in the large company.
For example, virtually any engineer at a FAANG company should be making top pro athlete money (not considering endorsements). There are literally thousands of engineers at Amazon and hundreds at Netflix that have this ROI on the soaring revenues of these megacorps, to a much greater degree than athletes have on their teams.
In other words, for small cap companies, yes, the ROI of athletes to their franchises is relatively higher than engineers to their companies. But for most of the SP500 this is not true, and there are lots of software-heavy companies with much higher market cap to the extent that even with 10k or 100k employees, I doubt an athlete’s ROI for a small sports franchise is proportional to the ROI of employees in the large company.
For example, virtually any engineer at a FAANG company should be making top pro athlete money (not considering endorsements). There are literally thousands of engineers at Amazon and hundreds at Netflix that have this ROI on the soaring revenues of these megacorps, to a much greater degree than athletes have on their teams.
This seems like it's incorrectly estimating orders of magnitude.
Some actual numbers:
In 2019, Google's gross revenue was ~$162b. ~$76b went to "costs of revenue", ~$26b went to R&D, and ~$11b to stock-based compensation. It's unclear what % of costs of revenue is attributable to "salaries of software engineers", though. Let's approach it another way. Google employs 30k+ SWEs, the vast majority of which are in the US. The median outlay probably falls somewhere in the L4 - L5 range, though there's a fat tail at the top. If we want to be conservative, we can just ignore the tail and say ~300k/dev. $300k * 30k = $9b (this is probably low).
Google's net income in 2019 was $34b. So you could multiply SWE comp at Google by not-quite-5 and zero out Google's net income.
What do top pro athletes make? Wikipedia says the top pro athletes earn mid-high eight-figures/year.
There's some headroom to pay engineers more, but it's definitely not "top pro athlete" more. Engineers can and do make that kind of money by founding & growing successful startups, not by working for FAANG (possibly with a very small # of exceptions at the top).
Some actual numbers:
In 2019, Google's gross revenue was ~$162b. ~$76b went to "costs of revenue", ~$26b went to R&D, and ~$11b to stock-based compensation. It's unclear what % of costs of revenue is attributable to "salaries of software engineers", though. Let's approach it another way. Google employs 30k+ SWEs, the vast majority of which are in the US. The median outlay probably falls somewhere in the L4 - L5 range, though there's a fat tail at the top. If we want to be conservative, we can just ignore the tail and say ~300k/dev. $300k * 30k = $9b (this is probably low).
Google's net income in 2019 was $34b. So you could multiply SWE comp at Google by not-quite-5 and zero out Google's net income.
What do top pro athletes make? Wikipedia says the top pro athletes earn mid-high eight-figures/year.
There's some headroom to pay engineers more, but it's definitely not "top pro athlete" more. Engineers can and do make that kind of money by founding & growing successful startups, not by working for FAANG (possibly with a very small # of exceptions at the top).
Also consider that top athletes can only sustain that level of pay for max 10y while engineers generally can increase their comp for much longer. All in all I don’t think it’s a good comparison bc film/sport industries have constrained supply and demand - there’s only so many teams/films each year and only so many players/credited roles.
Exactly. The funny thing is the same people making the counter to your argument no doubt don't bat an eye at 8 figure annual salaries for the best sports players. The argument is the same in either case.
Are there any German companies that work like this?
Yes, there are. By density you'll probably find most of them in Munich or Berlin. Some fields are of course more amenable to one or the other style (e.g. automotive middleware is not going to be done SV-like), and I wouldn't have high hopes with large, old, traditionally non-software companies. I would look at startups/small/medium companies where the founder(s) come from an engineering background.
I'm working in a kind of internal startup of a big German company and we operate "SV-like" as described in the article. My job title is Software Developer but most of the time I'm convincing other developer teams to share code to speed up development, inventing simple solutions to complicated sounding wishes of product management, helping project management to prioritize low effort features and trying to find out what the customers really need.
The only problem is that there is no leverage or scale because the software is coupled to physical goods, which means no big profits to pay above average salary and no career progression.
And that is the point where I don't agree with the article. I don't see the correlation between salary and autonomy.
The only problem is that there is no leverage or scale because the software is coupled to physical goods, which means no big profits to pay above average salary and no career progression.
And that is the point where I don't agree with the article. I don't see the correlation between salary and autonomy.
I wonder how much of this is actually determined by the organization size and business complexity rather than the company pedigree. In my experience, things like autonomy, decision making, understanding the business, and communication style seem to evolve towards the more "traditional" model as the business grows.
I have occsssionally espoused "metric-driven-development" where a metric is defined and measured and then a release is tagged with that metric - and over a period the release is seen as a success or fail if it moves the metric.
This keeps everything focused on the important usually externally facing issues.
This keeps everything focused on the important usually externally facing issues.
I agree with a lot of this article and it reflects the culture at the kind of places I like to work.
But - I'm curious what costs folks have seen in making this switch to giving engineers more autonomy and expecting them to be problem solvers for the wider business rather than code-factory workers. My hunch is that it's usually worth it - but what are the risks?
It's easy to mention a couple of anecdotes about some engineer who made an improvement or feature that represented millions of dollars for the company bottom line. But what about people going down strange rabbit holes, engaging in resume-driven development or following the allure of cool tech that isn't really needed for the use case (e.g. "let's use Cassandra for this!"), Not Invented Here syndrome, premature optimization, spinning up unnecessary microservices because that's the way to get promoted, building a fancy internal system that internal stakeholders don't actually need or want, etc. It's really really hard to simultaneously see the business big picture and also be down in the technical details, and very easy for engineers to fall victim to the Dunning-Kruger effect and go off in the wrong direction. Perhaps the few people who are able to do this well are able to compensate for all the waste, but I don't think we can assume that it leads to good results for the business in every case.
But - I'm curious what costs folks have seen in making this switch to giving engineers more autonomy and expecting them to be problem solvers for the wider business rather than code-factory workers. My hunch is that it's usually worth it - but what are the risks?
It's easy to mention a couple of anecdotes about some engineer who made an improvement or feature that represented millions of dollars for the company bottom line. But what about people going down strange rabbit holes, engaging in resume-driven development or following the allure of cool tech that isn't really needed for the use case (e.g. "let's use Cassandra for this!"), Not Invented Here syndrome, premature optimization, spinning up unnecessary microservices because that's the way to get promoted, building a fancy internal system that internal stakeholders don't actually need or want, etc. It's really really hard to simultaneously see the business big picture and also be down in the technical details, and very easy for engineers to fall victim to the Dunning-Kruger effect and go off in the wrong direction. Perhaps the few people who are able to do this well are able to compensate for all the waste, but I don't think we can assume that it leads to good results for the business in every case.
What you noted of engineers going down rabbit holes of cool tech for cool tech sake is certainly an issue, which is why management must help keep in mind that the autonomy is given with a goal of "solve business problems." It requires a bit of careful management but it usually becomes clear over time who enjoys playing with new tech for the sake of new tech and who does it to try to find a solution to a problem. The former group can be put into a research team if the company is large enough otherwise they are likely not a good fit.
As for risks, the biggest problem I've seen from this cultural change in a company is the disharmony it creates between the people who enjoy task-driven work and just working their 9-5 vs. the people who enjoy creative problem solving. It usually works better to have that culture from the start and also why it is so hard to change a company's culture to this way of working because it disrupts a way being that almost everyone in the company is used to.
As for risks, the biggest problem I've seen from this cultural change in a company is the disharmony it creates between the people who enjoy task-driven work and just working their 9-5 vs. the people who enjoy creative problem solving. It usually works better to have that culture from the start and also why it is so hard to change a company's culture to this way of working because it disrupts a way being that almost everyone in the company is used to.
Having no influence on decision making and being given tasks by an opaque task mill that also decides on arbitrarily tight and uninformed deadlines is a great way to burn out, because you learn that what you do doesn't matter.
>""SV-like" companies think of software engineers as the people best suited to solve the problems that the organization has. They hire not only for technical skills but communication and problem-solving ability. Their thinking is a bit more like this:
Software engineers are among the highest-paid people in our company.
This is because they can bring some of the highest leverage through coding and problem solving.
We want to expose them to the business, so while they are doing their "normal" work, they can also find more impactful opportunities for the business."
Software engineers are among the highest-paid people in our company.
This is because they can bring some of the highest leverage through coding and problem solving.
We want to expose them to the business, so while they are doing their "normal" work, they can also find more impactful opportunities for the business."
Having work at both styles of companies, in my opinion you really want a mix of both. Top-down decision-making is great! It allows your engineers to be engineers, cranking out good code and not "thinking up the stack" and worrying about the business logic. On the other hand, when engineers see a problem area, or see a feature that could be implemented in another way, you absolutely must stop everything and listen to them. This is a rare occurrence and they usually know what they're talking about.
If your engineers are not involved on the business side, they basically have no clue about who the customer is, how the user use the software, what problems they bump into etc. In the bigger companies I worked, engineers never even seen a customer or user.
A vision needs to flow top-down, but if you want your engineers to make helpful suggestions, they need to be involved on the business and customer side from day 1.
A vision needs to flow top-down, but if you want your engineers to make helpful suggestions, they need to be involved on the business and customer side from day 1.
I read the article and the comparison is improper. It is a narrow slice of a larger problem that is impossible to see if your processional experience is limited to writing software.
What the article compares: SVC-like vs traditional can be more accurately described as non-software employment versus software employment. It isn't that silicon valley has some magical solution that nobody else has, but instead is incentivized to leverage expectations common to all other industries. Again, this is impossible to see if your experience is limited to writing/managing software, but is clear as day otherwise.
The key reason why this is different for other industries is that the expectations are higher for employees where the investment per employee is higher. This is even true of lower paid and lower educated professions like truck driver or construction equipment operator compared to software engineer. In all other industries there exists some form of licensing or certification followed by some form of formal training such as a broker/agent relationship and then there is continuing education or periodic re-certification. These processes exist because of regulation. They take time and money away from the profession, which is an investment into each employee. With that level of expense more is expected in return by the employer.
The software profession has none of that. There is no investment in a software employee aside from keeping them happy enough to retain them. As a result its hard to think anything more of them than as a tool, like a janitor. This where you get the churn the article accurately describes as death by JIRA. SVC-like companies invest more in employees with higher salaries and thus expect more in return, which is not entirely the same as a formal professional process, but is a step in solving for this gap.
As for plain as day examples look at the common expectations for engineers at engineering firms, lawyers at law firms, and even truck drivers and police officers. There are all kinds of administrative and documentation expectations that are impossible to find in most software developers. Comparatively most software developers at the traditional companies seem largely illiterate. As an example most of these guys are scared to death of writing original software without a billion packages from NPM or Maven and are almost utterly incapable of writing formal documentation.
What the article compares: SVC-like vs traditional can be more accurately described as non-software employment versus software employment. It isn't that silicon valley has some magical solution that nobody else has, but instead is incentivized to leverage expectations common to all other industries. Again, this is impossible to see if your experience is limited to writing/managing software, but is clear as day otherwise.
The key reason why this is different for other industries is that the expectations are higher for employees where the investment per employee is higher. This is even true of lower paid and lower educated professions like truck driver or construction equipment operator compared to software engineer. In all other industries there exists some form of licensing or certification followed by some form of formal training such as a broker/agent relationship and then there is continuing education or periodic re-certification. These processes exist because of regulation. They take time and money away from the profession, which is an investment into each employee. With that level of expense more is expected in return by the employer.
The software profession has none of that. There is no investment in a software employee aside from keeping them happy enough to retain them. As a result its hard to think anything more of them than as a tool, like a janitor. This where you get the churn the article accurately describes as death by JIRA. SVC-like companies invest more in employees with higher salaries and thus expect more in return, which is not entirely the same as a formal professional process, but is a step in solving for this gap.
As for plain as day examples look at the common expectations for engineers at engineering firms, lawyers at law firms, and even truck drivers and police officers. There are all kinds of administrative and documentation expectations that are impossible to find in most software developers. Comparatively most software developers at the traditional companies seem largely illiterate. As an example most of these guys are scared to death of writing original software without a billion packages from NPM or Maven and are almost utterly incapable of writing formal documentation.
From personal experience on the product side, if you want to be more involved with the business, I'd recommend you work on two things from this article. First, curiosity is an absolutely must have. Without it, you'll not be able to truly learn what a customer is looking for. Second, demonstrate you can "talk with another engineer" without manager facilitation. It's a signal of ownership that I guarantee people will notice.
I've done both of these my entire career and no one ever cared, mostly because it's not remarkable.
Do you work somewhere that has a large management apparatus? These behaviors are sort of bare minimum expectation in smaller companies. It sounds like you perceived developers as a group to be mostly anti-social curmudgeons.
Do you work somewhere that has a large management apparatus? These behaviors are sort of bare minimum expectation in smaller companies. It sounds like you perceived developers as a group to be mostly anti-social curmudgeons.
I've worked in large and small, with good and bad cultures. And to be clear, that is not my view of developers. I point it out because I agree with the author of the article that there are differences in companies. I'm sorry that those traits did not get you where you wanted, but they are not bare minimum in a lot of companies. I've walked engineers from their seats over to the counterpart's seat and have had others who do not go outside of their area due to an inaccurate belief that it's not what their manager wanted.
I think this completely leaves out how user research and interface design influence the prioritization, process, and delivery of work done by the development team.
I think it's pretty similar. Like are UX and Eng working together to solve problems? Or is some VP telling UX what to design then telling Eng to implement the design.
Reading a bit deeper into this... the real big difference to me is "context".
If you want someone to critically think, they have to have business context and in many cases a vested interest in what they're building.
This crops up quite a bit when your engineering is primarily outsourced/overseas and your work involves an issue that might be a primarily US based problem.
How can you expect people to critically think when they don't have context around the issue?
If you want someone to critically think, they have to have business context and in many cases a vested interest in what they're building.
This crops up quite a bit when your engineering is primarily outsourced/overseas and your work involves an issue that might be a primarily US based problem.
How can you expect people to critically think when they don't have context around the issue?
> As a software engineer, pleasant places to work at is where you are a problem solver, not a factory worker.
It’s not so cut and dried as that, now is it. The pressure from the expectation and need to bring leveraged value can be detrimental. sometimes, and highly dependent on the person, this is life destroying. factory work is fine for most people, i believe. even engineers.
It’s not so cut and dried as that, now is it. The pressure from the expectation and need to bring leveraged value can be detrimental. sometimes, and highly dependent on the person, this is life destroying. factory work is fine for most people, i believe. even engineers.
meh I feel like SV companies are great to work at the last 10-15 years because they're making loads of money in a growing area.
Oil, Pharma, Banking have all had great times when employees there had lots of autonomy and made bank.
True with SV Engineers are the main type of employee so probably do better than at firms where engineers are helping other divisions make money.
Oil, Pharma, Banking have all had great times when employees there had lots of autonomy and made bank.
True with SV Engineers are the main type of employee so probably do better than at firms where engineers are helping other divisions make money.
What this article is saying in a very roundabout way is that companies whose primary products are software, hardware or hardware/software artifacts will 'get' engineers better than companies whose primary products are not these things.
If you have worked for a few years in this industry, you would know this.
If you have worked for a few years in this industry, you would know this.
This feels similar to the "MBA cofounder" profile of someone who has the mindset: if I just had an engineer to build my idea then this would be big.
Every engineer knows it doesn't work that way (but many who charge by the hour w/ consulting may be happy to take the job for a while).
Every engineer knows it doesn't work that way (but many who charge by the hour w/ consulting may be happy to take the job for a while).
Recently I had a discussion about an SV company with a friend in Texas. I mentioned to him, the company X is going to do great as they hire very good engineers. His question was - "what does that have to do good engineers?" Go figure ...
In my experience in the traditional companies none of this applies to “engineers,” it only applies to “software engineers,” mostly because they’re called “programmers” and are basically not considered “professionals.”
Sounds very true to me.
I'd summarize the problem as lack of real engineering leaders. It's as if programming/engineering is looked down on or not taken seriously enough.
- Biotech (in Silicon Valley to boot!)
I'd summarize the problem as lack of real engineering leaders. It's as if programming/engineering is looked down on or not taken seriously enough.
- Biotech (in Silicon Valley to boot!)
Europe is horrible. Idiots at a biology lab that I had the misfortune of working for a while categorized Bioinformatics devs and analysts at the same level as technicians.
One could have said that about electricians a century ago. "Men and Volts", a history of the first 50 years of the General Electric Company, makes that clear.
Interesting, what the author describes has been the norm at every company I have worked at, and I've never worked for an SV company.
Same.
I don't know if this is just an american thing, because this sounds like any company I've worked at in the UK
Autonomy is certainly a huge factor. Providing engineers with the tools and compensation they deserve is how you set them up for success. If they have to think about being underpaid or potentially having higher outcomes elsewhere, that’s mindshare / allegiance you’re losing out on as a company. Part of the reason why comp packages for senior level roles are so high especially in stock, see https://levels.fyi
Money
[deleted]
[deleted]
Nice article, short and to the point. I hear a more general version a bit like it: There are 2 types of employees Saint Bernard's and Hyenas. The Saint Bernard needs to be told what to do all the time. Everything needs to be planned and organized for him. If he doesn't have a pen he cant write. If there is one pen in the building all the hyenas can write. If you chose the Saint Bernard's, as a manager your job is to make sure all the Saint Bernard's stay productive. If you chose the hyena your job is watching them like a hawk because they might run away and take your company (or chunks of it) with them. Early on you should work with nothing but hyenas but at some point they should all be replaced with Saint Bernard's. During the transition you have to elaborately compensate the hyenas to keep them in line.
Clearly old-world type of reasoning.
This article...exaggerates...the difference between SV and 'not SV' companies. A lot, actually. I've worked at a few places in SV, and several outside of SV, too. For the most part it's similar: use the existing infrastructure and implement a service, front-end, whatever, within that, to solve a business need. Very little in the way of novel or new solutions to genuinely new problems is required. The difference is mainly in pay and, to a much lesser degree, respect.
Regarding autonomy--usually a high degree of autonomy is found in two places: 1) at larger companies, a very senior, trusted individual who has proven himself to be competent and capable of making big decisions; 2) at startups, a very junior individual scratching an itch and loading up on technical debt.
For the most part solutions are prescribed or narrowly constrained--99.999% of engineers are going to use the same services architecture, libraries, and compute infra every other engineer is using.
Regarding curiosity and problem solving: I guess I have a different definition of "curiosity" and "problem solving." What I've seen in this industry ain't either, generally: it's mainly driven by personalities at the individual or corporate level, e.g., "everyone" doing what Google does or following Fowler, and empirically unsupported anecdotes/fads (e.g. TDD, agile, etc.). The vast majority of engineering work in any established company is to use an existing tool or infra to implement a generally well-defined need. Most of the interesting details are already solved, and the implementation work, while also interesting, isn't really solving the problem, per se.
Regarding autonomy--usually a high degree of autonomy is found in two places: 1) at larger companies, a very senior, trusted individual who has proven himself to be competent and capable of making big decisions; 2) at startups, a very junior individual scratching an itch and loading up on technical debt.
For the most part solutions are prescribed or narrowly constrained--99.999% of engineers are going to use the same services architecture, libraries, and compute infra every other engineer is using.
Regarding curiosity and problem solving: I guess I have a different definition of "curiosity" and "problem solving." What I've seen in this industry ain't either, generally: it's mainly driven by personalities at the individual or corporate level, e.g., "everyone" doing what Google does or following Fowler, and empirically unsupported anecdotes/fads (e.g. TDD, agile, etc.). The vast majority of engineering work in any established company is to use an existing tool or infra to implement a generally well-defined need. Most of the interesting details are already solved, and the implementation work, while also interesting, isn't really solving the problem, per se.
One of the things I worry about is that even at companies that are doing "Agile transformations" and adopting methodologies like Scrum, in practice have "Product Owners" who are there to give instructions via Jira tickets. Other roles like "Business Analysts" are there to ensure that lowly developers never have to worry about things like understanding the business themselves.
So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs. Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.