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.
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.
No cult required.
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.
Not saying that devs shouldn't be allowed to experiment, but a lot of times they need supervision.
My current company does this and it’s great. If I do something bad it gets destroyed in 30 minutes unless I fix it (we get notifications).
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?
Tells a lot about the system right?
I recently discovered New Relic has yet to make any profit.
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?
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.
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 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.
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.)
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!
Engineers are great - i am one - but the focus needs to come from the business.
>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.
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.