Lego used to encourage building new things by putting alternate builds on the back of the box, but intentionally not giving you the instructions. Now they do 3-in-1 for certain sets instead, which misses the point of that.
I’ve been on teams that did generic names, and inevitably you end up with names like “work manager service” - whose work? Then it becomes an acronym, like WPS, and everyone ignores it anyways :)
Your site doesn’t explain your product very well. I know about GTD but I literally haven’t heard of any of the other products listed in the page. The screenshots are tiny and hard to parse on mobile. The descriptions of each feature include many paragraphs of philosophy before getting to what it actually _does_. I suggest “bottom line up front” and a clearer description of the product that better appeals to people who haven’t tried alternatives before.
Time to get a new TPM. Any TPM worth their salt should be doing everything in their power to catalog and mitigate those risks, and communicate them upwards. Lack of communication in both directions and adversarial conversations with engineers is a whole parade of red flags.
That said, Gantt charts absolutely have their place alongside Agile. Our budget and goals are set yearly so inevitably there’s going to be milestones and work back dates to meet, as well as cross-team/org dependencies to track.
The site doesn't do a good job of explaining what this is, precisely. It has several typos ("mailbox's", "corprate"). The "costco (sic) of helpdesk software" - what does that even mean? What's unique about this solution compared to other solutions on the market - why would I use this?
The "get started" button just takes to documentation about how to install it, but why would I click that without knowing what it is? The documentation is also broken, as mentioned.
Away teaming is definitely a last resort at Amazon, and has all the pitfalls mentioned here - much better to do a budgetary transfer so the host team is properly resourced to make the changes, assuming the feature doesn’t make it into the host teams operational plan.
Seems like Blind should get in on this game, since the premise of the app is that it requires a company email address. Use an LLM to extract insights from the comments and give them to prospective job hunters for a small fee, or even just run ads.
Even worse than that - Amazon spent dozens of engineer years migrating their wiki from PHP MediaWiki to Java XWiki, pretty much for that reason only, and for dubious customer benefit. There was a very epic post mortem at the end of it.
Amazon is actually better thought of as a collection of independent startups with their own software architectures, roadmaps and P&Ls. There’s commonly used infrastructure but very little is really mandated at the company level.
- make an operational plan (OP) for the entire year, which sums up all the HC on your team
- figure out your goals for the year
- have some senior engineers estimate those goals in # of HC (usually 0.5 HC is the lowest granularity)
- add up the HC, prioritize the goals and figure out the cut line against your budget for the year
- when the new year rolls around, start execution. Launch dates are usually set by quarter, with the majority launching by Q3
- individual teams have complete leeway to use whatever project estimation techniques they want. It really doesn’t matter at all. Even waterfall is “fine”. All that matters is whether they can deliver the goals they signed up for in their OP.
- if a goal goes off the rails, report a “traffic light status” (red/yellow/green) and path to green, and engage leadership accordingly to reset expectations.
People accuse this process of being too waterfall / unagile, but it’s actually really helpful in centering the deliverables with business value, while giving teams extreme autonomy to achieve those goals. Mature businesses think in terms of quarters and bottom lines, not sprints and story points.
Amazon's warehouses have incredible domain complexity which drives the complexity of the software architecture. It's also one of the oldest parts of the company with a direct lineage going back 20+ years. (for example, our inventory databases still have the same schema and are still using a RDBMS, albeit RDS Postgres instead of Oracle).
About five years ago we started rearchitecting to a centralized orchestration service which is being used to abstract this complexity from process teams. This is to avoid projects where 20+ service teams must be engaged just to launch a new solution.