Unlike most people here, I liked this post, both for OP's ability to put his learnings into words (something I've learned I'm awful at) and the learnings in general. A lot of people are harping on the internal podcast/ learning about how your boss thinks, but I think that's actually good advice. Even in places with remarkably flat hierarchies, at the end of the day someone will have to settle ties, and knowing how those people think is a good practice to end unproductive discussions quickly. Besides, this isn't any different from having a director with creative vision at the helm of your project: you need to meet that person's vision, because that is really what matters. The podcast actually sounds great to me, because I'd prefer a slightly cringe-y "how do you do, fellow kids?" podcast over having zero or insufficient communication from leadership. It's not like people make decisions for no reason, and knowing how they think can help you appreciate what went into one without having a knee-jerk reaction.
Reading this gave me the exact opposite impression - the amount of work it takes to extract takeaways from this writing is IMO one of it's biggest failures. It felt like pulling teeth to try and even get meaning out of some sections. #3 in particular is so nebulous I struggle to find the lesson at all. To me, this seems like a case of bad writing organization. If done better, I bet this piece would be half the length of current.
As to the contentious content: taking time to understand how your company works, great! Needing 6 months before being considered useful? Huge red flag.
> When you’re in a company full of smart people, like Shopify, it can often be quite tricky to resolve disagreements and impasses
Here's another huge red flag for me. The later explanation around having an idea of how the leadership/company thinks? Great. But having that philosophy/approach outlined should make resolution a lot easier. The "full of smart people" excuse could be rooted in a few things, but I struggle to think of a good one.
> "In your first six months, you’re gonna be useless anyways. You’re going to be drowning in new information and context and it’ll take you a few months to learn how to swim."
Useless is their word here, and the way they continue to describe it gives the same impression.
I'm in agreement that knowing how organizations work takes time and experience, but six months is indicative of a larger problem in the org. Brevity and succinct, digestive philosophy is valuable. If you can't at least communicate a good outline to new hires in a month or two, something has gone wrong. The minutiae of course will take far longer than 6 months in total, but you should be able to "swim" by then, just not as fast as a 2-4 year vet.
I just read point #3 after reading your comment, and I don't see what's nebulous about it. Perhaps different people are good at grokking different writing styles, because it was quite easy for me to extract the lessons:
- It really is true that big companies move much more slowly than startups.
- Consequently, startups should be wary of projects that depend on partnerships with big companies.
- Big companies are slow because knowledge is widely distributed and tough to wrangle, and liabilities and gotchas are numerous. Even simple things require a lot of know-how.
- To minimize slowness, find a single person who knows all of the moving parts involved. Avoid hodgepodges of people who each know only a tiny part of the whole challenge.
- It's important to start with this person, because problems snowball. An ounce of prevention is worth a pound of cure.
I like your summary a lot better, and much of this info is buried. Something that speaks volumes is reading the first sentence part of each paragraph in that section, you get exactly zero of these points.
The storytelling flow of consciousness might work for some, but generally it's well established that for this type of writing, leading with your point and backing up with examples after tends to be more effective. But also in this case, a lot of the details don't actually add context to the lesson and can be removed without hurting the content of the piece.
As an example, here's a possible rewrite of section #3 that I think reads a lot better and really doesn't lack any material:
> A long time ago, I was told “if you’re a startup, try not to waste your time talking to big companies unless you’re doing it deliberately. They have an absolutely endless capacity to consume your time with meetings.” I didn't truly understand until I got a chance to work with a partner for my first time within Shopify on our partnership with Operation HOPE to help start 1,000,000 new Black-owned businesses over the next decade.
> It’s clear to me now how this happens. In a partnership, I have found the most important thing is making sure that someone who understands every piece of the project is involved from the very outset of the project. If this fails, you end up spending a lot of time (like I have) straightening out requirements and capabilities on both sides. This creates meeting after meeting as new groups get pulled in, but never solves the real problem.
Not to mention brevity being a sign of good communication. The same point is covered over and over with slight changes. You really slog through and feel like things aren't really clear. I have worked a bunch of tech companies and am having trouble figuring out how I could possibly be "useless" for an entire 6 months. What is going on there? He never really says.
This! Agree completely and having worked in different companies, including huge enterprise, Shopify sounds like a great company to me based on this post! When a company grows it starts to function like an enterprise business and being aware of it and managing it is just great management and it sounds like that’s what Shopify is doing (long learning period expected, transparent leadership).
True. But this is why Goliaths get run over by Davids. When it take half a year's salary to begin getting return, that's six months of high risk. And then when your product cycles are six to twelve months, you're slow and venerable.
Full disclosure: I do some Shopify development. It's a love hate relationship. There are things that are great. But there are things where I stop and think "For Ford's sake??!!?? Really??" This article explains the excess of the latter.
How is uber and lyft not the goliah when they have billions of dollars poured into them vs the local tax companies...?
Uber is global, your local tax company is not. Plus your local tax company is restrained by you know, laws.
Amazon vs Walmart is also not a good comparison .. I believe this david vs goliah is mostly start up people that think too highly of themselves! In reality you have Google, Facebook, Amazon, Apple, Microsoft... all huge companies that have been dominant for decade + and aren't too different from the post.
Walmart online growth was directly cannibalized by AMZ for some time. Walmart stopped getting eaten, but the history stands.
As it stands, you have the poorest Americans (the long tail) competing against a small section of the rise who can afford and trust that shipping goods to their door. The overlap is minor, excepting for perishables.
Now. Maybe. But when Walmart was #1 they could have - and should have - never let Amazon and the like get a toe hold. Jeff ran up and over Walmart in less than a decade. It took Walmart well over a decade - and a few acquisition - to find their feet and sort it out.
David is so far ahead Walmart is looking in the mirror thinking they're ahead :)
I agree. I find it interesting how many people are saying something to the tune of "I'd rather spend my time adding value to the company's product than learning office politics". Firstly, I don't think they're mutually exclusive. And secondly, at least in my experience, the first six months at a new company is mostly an information gathering exercise. You're not going to be able to make valuable changes to the company's product in your second week, and attempting to force through something before fully understanding why things are the way they are is probably just going to leave a bad impression on people. If that happens, good luck getting the team to buy into those good ideas you're so eager to spend your time on.
It actually sounds like their structure is really sycophantic and codependent. Possibly even cult-like. You are taught to view things as a small handful of leaders and never challenge their viewpoint. Sounds kind of not a great place to work.
I think a key piece of info omitted from this article what OP actually does at Shopify. I'm assuming based on context that he's maybe a mid-level developer.
Not even just at entry level. Gas lighting and bullying at this company are nuts, people constantly having breakdowns and having to go on stress leave, looking forward to more updates of and when this guy stops drinking the cool aid.
Yikes, this post gave me really, really bad vibes about Shopify. Maybe that’s unfair, but wow, that is a seriously pretentious post. It’s hard to imagine anything screaming “out of touch, incompetent execs” more than that. He makes it sound like a place where success means mastering office politics, not actually improving the product and growing the company.
If you can't play office politics then you can't get the leverage and context you need with which to improve the product. Office politics is table stakes for a manager. Why? Because a company is thousands of people and dozens of divisions which each have different goals. Office politics is how you make sure that what you want fits in with what everyone else wants. Blindly trying to improve the product without taking the rest of the company into account is a recipe for disaster.
edit: The worst companies are the ones who claim they don't have office politics (ie: we're a flat meritocracy) but instead simply make it hidden and much harder to understand.
Yeah there are a crazy amount of comments here that can be summed up as 'we make the product so we are above office politics' and attitudes like that are a huge part of the problem.
>>> Office politics is how you make sure that what you want fits in with what everyone else wants
Correction: Office politics is how you work toward some goals in spite of other departments having other goals, some goals are incompatible/opposite and cause the other department to actively work against yours.
> He makes it sound like a place where success means mastering office politics, not actually improving the product and growing the company.
This sounds like a pure and narrow-minded engineering-like only POV.
In reality, specially in big companies, you need a mix of both Politics and shipping great product.
If you believe people make rational decisions all the time, you will be surprised with the amount of feelings that goes into making them.
This post is great advice to anyone that wants to be a high performer anywhere in any field of work.
When I mentor juniors, we spend a lot of time on the topics of communication, coordination, working within the company's hierarchy, involving others, and so on.
Most mentees accept it, but a growing minority are preemptively cynical about these things, dismissing them as "office politics". Especially for junior engineers who get a lot of their information from angry comment sections on HN and Reddit, there's a growing desire to view engineering as the core of the company and expect all other departments to serve engineering. This results in a lot of pain when they're dropped into a real company where they have to work side by side with other departments to generate revenue.
If you want to be successful, it's important to accept that communication, relationships, and rapport are just as critical to getting anything done as the engineering work itself. It's not office politics, it's just the nature of working with other people. The longer people resist this idea, the more time they waste fighting reality instead of finding a way to make things work.
It really doesn't take much effort to build relationships and rapport within a company. You're going to have a long, painful uphill battle if you spend all of your time resenting and fighting it, though.
The poster doesn't mention this but there is an insistence at shopify from c level that there is no politics at shopify. But then this guy gets told by his gm that the key to the company is politics, which is definitely true there. Weird place.
The advice is probably good for any large organization, having worked at very successful startups with a few hundred people and mega-corps ... you absolutely have to understand how the decision making works if you want to get anything done.
FYI 'politics' is not bad, it's just all the bits that are unspoken about the operating nature of a company.
That is literally the one thing which I wish I had understood when venturing into a much bigger company.
In fact, what he should really say is 'I wish Shopify would formalize' the nature of how decisions are made etc..
Edit: I think younger people with less familiarity about the 'real nature' of large organizations might possibly misread that because it's sometimes hard to understand how some companies work, and it's easy to be cynical (frankly, many companies are 'political' in a bad way). In reality - this 'advice' is the revelation that anyone in middle management makes when they get into their 30's. Everything is making sausage, nothing is obvious except in hindsight, getting anything done is kind of hard, the company has limited ability to innovate on the margins, and social organizations are made of people, which means 'it's political' that doesn't mean it's bad, it just means you have to think about it differently. Middle management is hard, especially for those in staff positions without 'direct power' and are not high enough up to have meaningful legitimate authority for the scope of a project.
Agreed. It might (or might not) be lovely if personalities and culture and power and ways of learning didn't come into things, and everything was truly meritocratic/anarchist/optimised or whatever, but this is not the human condition, and never has been.
Much better to understand the working reality and either live with it or try to change it from a position of understanding.
This is what culture and history teach, whether its Xenophon or Succession.
Slightly off-topic generalisation, but maybe one of the reasons hackers disdain good management consultants, is that the latter are experts at understanding "the bits that are unspoken about the operating nature of a company", whereas the former see this as unnecessary overhead to doing what they want to do.
I have heard the codebase at Shopify is a horrific, GIANT Rails monolith. I can't imagine working on that being pleasant in the slightest.
It's probably one of those companies where fixing a bug a week is "productive" because everything is so hard to do. Ripe ground for the rest and vest types to hang around being dead weigh
I worked at Shopify in the past. Your assessment is incorrect.
Shopify main app is a giant Rails monolith. They also have several hundred other apps as well (eg, App Store, partners, burst).
Shopify has done a good job on defining clear interface boundaries between various parts of the monolith, which makes changes more compartmentalized. As well, they’ve invested significantly in developer tooling to make developers more efficient. It’s not perfect and there’s always more to do, but ask any Shopify developer about the magic of ‘dev up’ or about ShipIt.
I’m not quite sure how or why you extrapolate that having a large monolith immediately equates to having a culture cantered around low productivity. Perhaps you’re projecting from your own experience?
Most of this seemed like feel-good fluff, but the last one was interesting to me. At AWS I often heard one phrase echoing around: “There’s no compression algorithm for experience”, and without unpacking† all the consequences and corollaries (for they are many) the idea of acquiring management experience by proxy through games, whether to build customer empathy or because it’s cheaper than an MBA, was not amongst them. Nevertheless if I look through all the games that’ve engaged me to completion, over the years, most of them are basically management games. Even ones that didn’t purport to be, like Shadows of Mordor or Fallout 4, in hindsight had something to teach on topics from organisational change management to implementation of strategy.
I’m still waiting for a AAA title that requires inferential analysis of financial statements. After all, as Ben Affleck demonstrates in The Accountant, there’s nothing quite so satisfying as explaining discrepancies in a receivables footnote via a thorough analysis of quarterly EBITDA reporting. The closest approach I’ve experienced in a game, both cognitively and emotionally speaking, is probably completing the Challenge in “The Witness”. I live in hope.
Let the record show that I'm burned-out veteran of the Great Northern War and its aftershocks, and haven't played Eve since 2012. My kit is mostly in 5ZXX-K but I left my heart in Tenal. No you can't have my stuff.
In my opinion it is not a game, though. Eve:Online is a job.
This is a good post because it details to me how horribly broken Shopify's process and culture are. Here's why:
If your software company revolves around getting a director or VP to say "you are allowed to do x technical thing", then your company has already lost. Here's what you need to do instead so you don't waste developer salaries and be outcompeted by better companies:
Every dev is allowed to spin up their own service. Teams can self organize and self govern around business problems they feel like solving. The best teams are the ones that produce the services that product owners rely on the most to get things done.
If you have a culture that involves saying no to dev ideas by default, it's only a matter of time until you lose.
You can find gripes about process at every single company. Yet companies like Shopify are some of the biggest success stories and I know engineers who are very, very happy there.
You can give every engineer and team complete freedom, and you’ll end up with too many microservices to count, with ineffective higher level strategic alignment. The result? Horrible environment to get the things that matters done. Little upside for your stock.
Stop thinking of VPs and executives as harmful gatekeepers. Done right, they add incredible value to the business, and incredible value to your output as an employee. Done wrong though, yes, find another company; just as you should if engineering is dysfunctional.
If my company’s executives threw up their hands, and decided to stop doing their jobs and tell every team to solve whatever, I will look for another job immediately.
The top down these three people decide everything can lead to abuse or neglect. Most importantly it makes people do irrational personal things to win over the top three. This leads to internal cults.
Not necessarily true either. All organizations ideally have a goal. Vision. Mission, whatever you choose to call it. People at the top decide on that goal, and they decide on a strategy that might let them reach their goal.
That strategy should start by considering the things that cannot be changed (legislation like GDPR, maybe scalability, availability of resource, or health and safety regulations).
The leaders would then consider mutable factors, things they DO control like number of employees, technology options, business model, geographic location.
These two broad things (immutable and mutable factors) will lead to a list of things that need doing to achieve world domination. Sorry, I mean success.
That list of tasks is handed off to employees who will repeat a similar process within their areas at a more granular level.
Good reporting up and down the chain allows people at all levels of the organization to adjust course when needed, with a level of autonomy suited to whatever level you're in within the organization.
If the organisation is small enough people at the bottom may will seek out people at the top for direction.
"That list of tasks is handed off to employees who will repeat a similar process within their areas at a more granular level.
Good reporting up and down the chain allows people at all levels of the organization to adjust course when needed, with a level of autonomy suited to whatever level you're in within the organization."
Yeah this is the part that is missing at shopify from my experience. And it has caused all sorts of brutal problems and mental health issues for people.
Giving devs the green light to go crazy is also a recipe for disaster. Devs don't necessarily understand everything going on within a organization or even have a grasp on the security controls in place. In the last six months, I have experienced devs publishing secrets to open buckets, using insecure algorithms for creating customer and session ids, go to production with 3rd party vulnerable code, attempt to bypass a waf, attempt to bypass penetration testing and the list goes on. All of these things were done by developers with at least 4 years of "experience". Saying NO is sometimes the best way to save your business and brand from ending up on krebs as the latest breach.
> Every dev is allowed to spin up their own service. Teams can self organize and self govern around business problems they feel like solving. The best teams are the ones that produce the services that product owners rely on the most to get things done.
Can't emphasize this enough. The only way to tackle complexity in tech organizations is by introducing at least one degree of freedom for innovation per employee.
Where would Uber be without three thousand microservices for three thousand engineers?
I enjoy reading the spectrum of views on Uber, which seem to range from “they’re dumping rides below the cost of providing them” to “they have ridiculous profit margins”.
for the more credulous readers in the room I want to point out that the above comment is dripping with sarcasm. took me a while to determine it as well. poe's law is a cruel master
This sounds a lot like the Google approach, and I've seen a number of persuasive arguments that this is why they have 14 different, semi-competing chat apps and shutter most of their new services a couple years after introducing them. I expect somewhere in the middle there's an optimal balance between a completely top-down approach and one with too little hierarchy.
Of course the counter-argument is that Google still does quite well, but how much of that is due to their search and advertising monopoly, as opposed to the result of more recent innovation?
> Every dev is allowed to spin up their own service. Teams can self organize and self govern around business problems they feel like solving. The best teams are the ones that produce the services that product owners rely on the most to get things done.
I’m sorry but this sounds like a nightmare where you end up in Uber-esque situations where 80% of engineers are reinventing every wheel with 1,000+ “microservices”. Nothing wrong with a hierarchical organization where everything is run like a tight ship.
What you’ve described is a recipe for endless technical debt and a culture that focuses on playing with whatever new tool is popular on HN this week instead of growing revenue or improving profit margins.
> Every dev is allowed to spin up their own service. Teams can self organize and self govern around business problems they feel like solving. The best teams are the ones that produce the services that product owners rely on the most to get things done.
Have you considered handover, people moving on, new hires, etc? One guy running one service sounds like entrenchment to me. You need, as a company, to ensure people are replaceable. One way to do that is to for example stick to one or two programming languages.
You cannot, as a company, afford to have your services be written in a dozen different languages by a dozen different people. That's a huge risk.
It’s a huge risk if the unit of ownership is “engineer”. It’s less of a risk, but still not zero risk, if the unit of ownership is a squad/team/whatchamacallit, because you’ll get more brains applied to “should we really use Haskell for this?” and are isolated from the one Haskell engineer quitting. (Teams do rarely quit together, but individuals leave all the time in comparison.)
It’s also a risk to force your entire company to use 1-2 languages (one of which is [practically for most] hardwired to be Javascript, so you get to pick the other one).
At some points in time, c, c++, php, perl, or C# would have been reasonable choices for web dev. Do you want to be leading a company of Perl experts maintaining a large Perl codebase right now? Doing it, I can say that even C# is painful when it’s your mono-language monolith. (Inertia in language cuts both ways.)
"You can give every engineer and team complete freedom, and you’ll end up with too many microservices to count"
"Giving devs the green light to go crazy is also a recipe for disaster"
"Where would Uber be without three thousand microservices for three thousand engineers?"
"What you’ve described is a recipe for endless technical debt"
It's crazy that these replies do not even entertain the possibility that devs might be responsible enough to not abuse that freedom. I could spin up a hundred services tonight without approval but I obviously don't because it would be a nightmare to maintain, and I'm pretty sure my colleagues feel the same.
I'm getting a few downvotes, so let me try a different approach.
To the people I quoted: you evidently understand that runaway tech debt is a bad idea. So let's start a company where all of you are founders! At inception, this company would not need heavy approval processes around spinning new services and so on, since all of you share the same ideas about tech debt and can trust each other to do the right thing there. Security is more tricky, but all of you are responsible enough to actively seek feedback from security experts instead of just pushing insecure services to production, even though you would technically have the freedom to do that.
Now let's hire a few people to scale the company to 10 employees, while maintaining that same culture of responsibility. Now let's scale to 100. Then to 1000.
Why does necessarily stop working? Why is there necessarily a point where you cannot trust your colleagues to behave responsibly anymore?
(Note: this doesn't apply to everything. Personal information for example may legally require strict processes to be in place from day 1, and even if not legally required you may still want to do it by abundance of caution and respect for your users.)
Maybe all of the replies are from managers and CIOs :)
I agree, it keeps working just fine. You see it every day on the real internet.
You expose an API to me, I build a website around it. If one day your site disappears, I need to alreadt have backup strats in place on how I can get data like yours elsewhere. I have nobody to blame but myself-- after all, I'm getting the data from you for free!
Depends if we're talking prototyping or production. Prototyping? Sure, go for it. Production? It depends. If you're building a social media platform for cats, knock yourself out. If you're in a regulated industry, e.g. financial, it will create headaches when the auditors and regulators come around.
The "where would Uber be" comment you quoted from seems to be expressing the opposite sentiment from the other two, at least the way I read it. Sure when I saw that thousand microservices talk I thought "what a (comparative) shit show" but many people admired the concept.
They decide what to work on? How does that work. Hey Joe, we need the payments module improved. Can you take a look? Nah, I’m rewriting the flux capacitor in JavaScript. Oh, ok. I didn’t know we had a flux capacitor. I’ll ask someone else.
Engineers are great - i am one - but the focus needs to come from the business.
If every dev is allowed to spin up their own service, what happens when the dev leaves? Or the service goes down while the dev is on vacation? What if the service becomes a single point of failure other devs' services rely on?
>if the dev leaves?
Their code should be in a viewable repo and it should maybe even be documented. If it's not, no sweat, because I've seen lots of undocumented code in my life from bigger teams. Continue using the service until someone becomes an expert in it or the business problem is solved again. But, ideally you would have a few devs as experts on a few different services. It doesn't need to be 1:1.
>Service goes down while dev on vacation
I'm thinking a production service should aim to have 2 devs and 2 ops supporting it. They could each be responsible for 2-3 major services and 2-3 minor or experimental services.
>Single point of failure
Let's say you have a service that, if you give it a user id, returns only the history of that users orders. It doesn't fulfill orders or give delivery statuses or help initiate a customer support conversation. It is conceivable that if this service goes down in production, there may not be a way to get order history from anywhere else quickly. The information definitely exists in another db in another service somewhere, because that's the db where the order history service gets its information in a read only status. But it's not all neatly organized and available over HTTP. What do you do? You make the order history team own their SLA, otherwise their SLA will own them. In microservices world, you can't blame other people if you go down. You just have to do everything you can to keep your service running, by configuring AWS yourself and being on call yourself.
This post makes it look like Shopify's leadership is authoritarian and patronising. I don't know their turnover numbers but companies like this suit very specific people, and some developers run away when they get a chance.
The article touches on this, but their turnover is probably low because there aren’t many other places for engineers to go in Canada.
I’ve worked at a place that had a similar sort of “artificial retention” due to a lack of local competition for talent, and curiously that place also had a very top-down and controlling executive team. It was still a great workplace but I was mystified on more than one occasion by how much time I had to spend getting permission from folks 2-3 layers above me in the organization.
Man shopify sounds like a really shitty place to work. Your first 6 months are about learning how to get people to say yes to things? Besides that I don't care at all about their business (and I don't take jobs in which I don't care about the business), no thank you.
I work at one of the big companies that many would say is at the forefront of innovation in our industry. If you’re young in your career with scope limited to your own team, then I agree getting people to say yes is a red flag. If you have broader scope across teams and organizations, you’ll quickly realize that different managers and directors have their own priorities. While yes, at the end of the day they might be working towards the same goals, it turns out that they have different ideas on how to reach those goals. They all have their own biases —- it could be as simple as one team wants to use X to solve Y and another team wants to use Z.
Convincing people to listen and follow your ideas or deliver on your timeline can be very problems.
I’ve worked with a number of ex-Shopify employees and they all loved it. It sounds like it’s an intense experience, but they are willing to let people make very long bets.
Also I can’t agree with point 5 enough. It really is true that the biggest (by volume at least) customers of software are software.
Excuse me, what does this guy actually do besides being mr trying extremely hard to impress my bosses?
These are not lessons, these are random thoughts.
Shopify's website is starting to compete with Stripe for 'what am I even looking at'? I can always tell when sane engineers have completely lost control of a company and useless marketing and buzz-word-gurus have taken over. The cycle is complete when a company claims they're using 'AI' or 'machine learning' to help your business. Is Shopify there yet? I can't be bothered to click through their random offerings to find out.
I'm reading various comments in defense and criticizing Shopify:
kenrose: "I worked at Shopify in the past. Your assessment is incorrect. [...] Shopify has done a good job on defining clear interface boundaries between various parts of the monolith [...] they’ve invested significantly in developer tooling to make developers more efficient. It’s not perfect and there’s always more to do..."
sushshshsh: "This is a good post because it details to me how horribly broken Shopify's process and culture are."
In my work I'm exposed to many different online store and POS applications. Shopify is in a unique class. They have a diverse third-party apps community, and a documented API.
For my needs, their app community allowed me to extend Shopify reporting to suit my firm's particular requirements.
Other companies have their product and if their design doesn't fit your needs, is missing a feature in a report, or whatever, you're just SOL.
I think it's worth noting these details when reading about this person's experience. There might be a hint of it from the article: "Working on [Operation HOPE] was the first time I’ve ever really interacted with an outside organization from inside Shopify." (as near as I can tell this program is a drive to put more stores on the platform, and not including US based black owned _developers_ in their App Store).
Other comments here note the author does not identify their position (as developer), either.
> And in order to be effective, you need to know how to get those people to say Yes to things, and how they would think through a decision down to a detailed level. If you can do that, then you can get basically anything you want done. If you can’t do that, then you’re never going to get anything done.
Translation? After 6 months with the company we'll find out if we should have offered you a position; and you'll find out if you should have accepted that offer?
Certainly, there's go to be a better way?
Also, going 6 months without feeling productive in some way, without feeling that you're contributing to the cause in some way feels like a big ask.
Again, is there not a better way?
Pardon the editorial but this sounds like a cult, not a 21st Century tech titan.
Good post, but that advice about the first 6 months, learning how the top caste thinks. Is the grossest thing I've ever herd. Shopify must be as ridiculous to work in as their APIs are to use.
If you have this luxury: don't accept a job unless they have a concrete problem in mind for you to solve. Beware generic always hiring listings for Kingdom building at large companies.
Currently exactly there. Was hired to fill a real and actual 'gap between engineering and business'. As senior with decades of experience.
Turns out the team I'm working in (not above) really does not like change (i.e does not accept been-there-done-that-failed, as valid argument to do things different), looks down on 'business', often even on 'users' (technical pureness above everything else, above working software even) and most of all hates me for pointing out problems.
I'm still trying to find ways to fill my original 'problem' for which I came on board, but am also close to giving up, due to the negative energy all this is costing me.
So: good advice. But be certain the 'problem' you're hired for, is actually something that people want to solve.
I've been where you are and on this guys exact team. Give up and move on. Saw everyone who came in like you as a crafter leave or be fired after around a year.
This happened to me on my last hire, I asked what I should work on and didn't get much direction at all. I think I wasted like a year doing the wrong things and strongly considered quitting during that period.
Then I figured that just as I got rather vague direction on what I should do, there also wasn't anyone telling me what I should not do. So I started doing things in the intersection of being interesting and beneficial for the product.
So my advice would be: If there's no concrete problem to solve, find one that you like and be glad that you were given the freedom to do so.
As a CEO, this sounds like an incredibly broken company model. It’s obviously working in a lot of ways, but why would you make it so hard to get things done once you’re at scale?
The c levels are oblivious. They think the company is one thing when its the opposite. This is what adds the to head fuck of working there, you behave how the ceo recommends and you will get targeted for dismissal by your boss more than likely.
Similarly, I've written 28 lessons from working at Shazam as a web developer for 5 years, where I discuss how I made the most of my career there (hackdays, 1:1's, code reviews, drinking culture, deadlines, meetings, open source etc.).
I'm not sure what this person thought they'd gain from writing an article like this about your current employer. It's all risk, no reward. Incredibly naive.
Should it really take so long to become effective at an organization? I understand it is different at a larger organization, but that still sounds incredibly inefficient?
Evidently publicly drinking the kool aid is the 7th lesson op learned. There are maybe 3 actual lessons, and quite a few “Shopify is so great” lessons.
Separately, I cannot possibly imagine an internal podcast is anything but awful.
I don't get it. Is it an update? A dissemination? A directive? Just for funsies?
I worked at a place with an internal podcast and never had time to listen during work hours and doubted I would learn anything I didn't from trusted water cooler comrades.
I just get Heaven's Gate vibes with an updated medium, honestly.
One of the main duties of executives is communication to employees, to make sure that everyone is swimming in the same direction. For a small firm, Friday afternoon beer bashes work. For a mid-sized firm, those usually slip to monthly events and the beer quality drops..
For a large firm getting everyone into the same room for a meeting isn't possible any more - either because they're remote (especially so these days) or there just isn't a room large enough. So something like a podcast or a Teams meeting becomes the best way to communicate with everyone.
My company can still get it’s entire HQ into one room by renting the ballroom of a large hotel. The beer is average, and it happens only twice a year, but the worst part is that the executives are talking mostly air. I think they’re good people, but I can’t say I’m interested in what they’re showing me.
Last time they were talking about remodelling the office to be more ‘open’, and I asked if anyone had given any consideration to how easy it would be to focus there? Nobody had.
I used to expect new hires to take a month or two before shipping real work. I think it’s still good as a courtesy - starting a new job can take some adjustment - but new hires regularly start shipping real work in a couple weeks.
This stuff where you’re supposed to be useless and confused for 6 whole months... that doesn’t seem good to me. Everything in our industry moves too fast for that, for one thing.
