> Contemporary work culture influenced its creators, so you’re likely seeing a reflection of that when you watch the show.
Many of the writers on the show have only ever worked in show businesses, which is its own mutation of work culture. Not many have actual worked in stereotypical corporate work situations.
Mike Judge (Office Space, Silicon Valley, etc) probably comes closest having started in corporate life and made a transition.
It's the general knee-jerk reaction that's brought out whenever people try and have modern ideas for the US, like modern healthcare or high-speed rail. "B-but, it's so big!"
>Given how long this "REAL ID" standard has been in effect, why have the non compliant IDs not expired yet? Do some states not issue REAL ID compliant licenses?
It's only been in effect for a short while, then we had COVID. It took them two decades to even get it live.
Some state licenses don't expire for 10 years. Americans will avoid trips to the DMV until it's absolutely necessary to go. YMMV on if your local one is well-run and efficient or a madhouse with long wait times.
My DL expired this year. I renewed it with an online web form, so I was not able to upgrade it to real ID
I have a passport, and apple wallet recently enabled support for US passports, so I personally don’t see myself going to the DMV until I absolutely must
But as long as it’s possibly to renew without realID, I think most people will take that option
A society is a business entity. They have some control over all houses in an area. Most societies are large. Hundreds or thousands of houses/buildings.
The administration of the society is usually done by the original developers. They decide how big the plots of land are, decide the rules houses must follow in their design. The houses themselves are built by the owners of the plots.
They society collects monthly fees typically. It is usually responsible for trash pickup. Richer societies will arrange water supply and even backup electricity plants. Larger societies create commercial areas and parks within their bounds as well.
They are not always gated as the parent states. Only the ones rich enough to hire security.
Thanks for the insights and apologies for the late reply. So it's somewhat similar to a development in the US - developer buys the land. But in this case, its the homeowner paying for and building the house vs the developer (like in the US).
> Early in my career, I got into solving some of the barriers to software project management (e.g., requirements analysis and otherwise understanding needs, sustainable architecture, work breakdown, estimation, general coordination, implementation technology).
Was there any literature or other findings that you came across that ended up clicking and working for you that you can recommend to us?
I could blather for hours around this space. A few random highlights:
* The very first thing I read about requirements was Weinberg, and it's still worth reading. (Even if you are a contracting house, with a hopeless client, and you want to go full reactive scrum participatory design, to unblock you for sprints with big blocks of billable hours, not caring how much unnecessary work you do... at least you will know what you're not doing.)
* When interviewing people about business or technical, learn to use a Data Flow Diagram. You can make it accessible to almost everyone, as you talk through it, and answer all sorts of questions, at a variety of levels. There are a bunch of other system modeling tools you can use, at times, but do not underestimate the usefulness and accessibility of a good DFD.
* If you can (or have to) plan at all, find and learn to use a serious Gantt chart centric planning tool (work breakdown, dependencies, resource allocations, milestones), and keep it up to date (which probably includes having it linked with whatever task-tracking tool you use, but you'll usually also be changing it for bigger-picture reasons too). Even if you are a hardware company, with some hard external-dependency milestones, you will be changing things around those unmoveables. And have everyone work from the same source of truth (everyone can see the same Gantt chart and the task
* Also learn some kind of Kanban-ish board for tasking, and have it be an alternative view on the same data that's behind the Gantt view and the tasks/issues that people can/should/are working on at the moment, and anything immediately getting blocked.
* In a rare disruptive startup emergency, know when to put aside Gantt, and fall back to an ad hoc text file or spreadsheet of chaos-handling prioritization that's changing multiple times per day. (But don't say that your startup is always in emergency mode and you can never plan anything, because usually there is time for a Kanban board, and usually you should all share an understanding of how those tasks fit into a larger plan, and trace back to your goals, even if it's exploratory or reactive.)
* Culture of communicating and documenting, in low-friction, high-value, accessible ways. Respect it as team-oriented and professional
* Avoid routine meetings; make it easy to get timely answers and discussion, as soon as possible. This includes reconsidering how accessible upper leadership should be: can you get closer to being responsive to the needs of the work on the project (e.g., if anyone needs a decision from the director/VP/etc., then quickly prep and ask, maybe with an async message, but don't wait for weekly status meeting or to schedule time on their calendar).
* Avoid unnecessary process. Avoid performances.
* People need blocks of time when they can get flow. Sometimes for plowing through a big chunk of stuff that only requires basic competence, and sometimes when harder thinking is required.
* Be very careful with individual performance metrics. Ideally you can incentive everyone to be aligned towards team success, through monetary incentives (e.g., real equity for which they can affect the value) and through culture (everyone around you seems to work as a team, and you like that, and that inspires you). I would even start by asking if we can compensate everyone equally, shun titles, etc., and how close can we practically get to that.
* Be honest about resume-driven-development. It doesn't have to be a secret misalignment. Don't let it be motivated solely as a secret goal of job-hoppers that is then lied about, or it will probably be to the detriment of your company (and also, that person will job-hop, fleeing the mess they made). If you're going to use new resume keyword framework for a project, the whole team should be honest that, say, there's elements of wanting to potentially get some win from it, wanting to trial it for possible greater use and build up organizational expertise in it, and also that it's a very conscious and honest perk for the workers to get to use the new toy.
* Infosec is an unholy dumpster fire, throughout almost the entire field. Decide if you want to do better, and if so, then back it up with real changes, not CYA theatre and what someone is trying to sell you.
* LeetCode frat pledging interviews select for so much misaligned thinking, and also signals that you are probably just more of the same as the low bar of our field, and people shouldn't take you seriously when you try to tell them you want to do things better.
* Nothing will work well if people aren't aligned and honest.
How do you know when to call it quits? How do you know when people are not aligned or honest, or that you are not right for the team, or when the team is not right for the client/project?
How much time is normal for a team/project to get its bearings? (It depends, I know...)
> How much time is normal for a team/project to get its bearings? (It depends, I know...)
If you mean figure out their process, this can happen incrementally, starting simply and building up as you go, with a team of people who are open to that.
It can also happen that some people come in and want to recreate the fleet of tools and best-practice processes that they know from a different company. This isn't my style, but it's not necessarily a bad idea, if everyone is onboard with that. But their prior experience might not fit the different situation (e.g., trying to do things the FAANG way in a post-ZIRP early startup).
If you mean get their bearings on what they're going to build, I don't know, but it usually starts with figuring out your users'/customers' needs, and the business constraints (e.g., resources, milestones that need to be met for revenue or to get funding, etc.).
If there's a new or unfamiliar technology, there might also be exploratory/learning time with that, in parallel (e.g., there's a bias that you will use certain emerging tech or an approach someone thought of, to solve what you initially suspect is the MVP problem, and you have to play with this a bit, and see what you can and can't do with it, in parallel with figuring out what problem you're actually going to solve for MVP).
> How do you know when people are not aligned or honest,
I'm not an expert on this, but do have some conventions and thoughts, so partial off-the-cuff answer...
Of course, at some point, actions will speak pretty clearly about alignment or honesty.
Before that, a lot of tech workers aren't deceptive by default, even if they're approaching the culture assuming a mercenary environment, and they will tell you straight what they are thinking. Maybe especially more if they think you are straight with them. I tend to think you can discuss and find common ground with these people.
Some tech workers have a "California nice" persona that can obscure a few distinct categories, some fine or innocuous, one of them non-deceptive mercenary (once you start talking with them), only one of them deceptive mercenary.
IMHO, just treat everyone honestly, and they will often meet you there, or often indicate when they aren't meeting you there. If you don't meet people honestly, some people will immediately adapt to that too.
I think if you create an alignment-nurturing culture, and communicate and demonstrate it consistently from very first contact, you will scare away a few people, and onboard a lot of people who either are looking for that, or willing to try this unusual thing.
As soon as you start introducing perverse incentives (e.g., individual performance metrics), or mercenary culture (e.g., why is this option pool so small and have worker-hostile terms), or signs of misalignment yourself, or even just sound like more of the same (e.g., "<we're-arm-fuzzy> <we're different> oh btw leetcode frat hazing bro do you even lift"), I think people will revert to the default pretty mercenary tech industry worker culture. And that's rational of them, because the worker's dominant strategy for a mutually-mercenary tech industry environment was figured out a couple decades ago, for a reason.
This is an amazing summary of good advice for software projects! I literally pasted it into my notes for reference. You should write a blog or something on this topic if you don't already.
Thanks for the very kind words. No blog yet. The closest thing to a blog was that I was writing a book, "Racket Tactical Field Manual" (RTFM), which would teach a programming language (Racket) and effective software engineering practices incidentally using Racket tooling, in one tractable, self-contained book (and beg Randall Munroe to do the cover illustration)... But then it looked like Racket was determined not to have commercial uptake, so I abandoned it.
I suppose, if I had a software engineering blog that was fortunate to be well-received, maybe I wouldn't get 90%+ interviews wanting to give me a LeetCode frat hazing. We could instead speak like colleagues, who can see that the other person has, say, written a bunch of open source code, and skip ahead to getting a feel for more important factors about how we might work together. Instead, the signal I get is that they really, really want to do the frat hazing. (Like the AI company I just got off a successful recruiter screen with, minutes ago.)
>which Adobe probably does an excellent job of “customer relationship” with
It really depends. We have a good CSM. But s/he has to defer to CSM's on other teams for more specialized knowledge. Any problems there have been far, far down my list of issues with that company.
Adobe's leverage is big, especially in creative industries so they can keep coasting.
> the entire corporate world for 2 decades while being that mediocre
Because most of the corporate world is mediocre. Employees put up with a lot of BS every day, Acrobat and PDFs are just the icing on the cake. And they're risk adverse. "This is what I know".
It's like when the complaints Windows and Office come around (for decades). People got used to it enough, and don't have to pay for it, so why change.
All periods can be replaced by ? if you want...I'm merely speculating having been in all sizes of companies by now. :)
Hulu had some major problems during the broadcast of the Oscars so I was surprised but not surprised to hear about the issues with this.
>Disney's internal systems for something like this are a hodgepodge of the Hulu, D+/Bamtech, old corporate disney, and some bits sent out to SaaS. There's been multiple layers of layoffs and service ownership changes since the pandemic. I don't think the org would be able to rate limit by faking crashes if it tried.
Finance bros and execs love M&A because they can hire a consultant to do all the hard work and get a nice paycheck yet they really suck for the little people and those trying to keep the lights on. Good luck out there.
Maybe one day we'll figure out this anti-trust thing.
Many of the writers on the show have only ever worked in show businesses, which is its own mutation of work culture. Not many have actual worked in stereotypical corporate work situations.
Mike Judge (Office Space, Silicon Valley, etc) probably comes closest having started in corporate life and made a transition.