21 commandments.
Zero bullshit.
The operating principles for teams working in a disposable technology model — with emphasis on fast delivery, iteration, and the human side of change.
I. Technology is Disposable
01
Treat every solution as a prototype that may be thrown away. The value lies in solving the business problem, not in code elegance. If it needs to be rewritten in a month — that means a month ago you did the right thing, because the solution worked, and now you know more.
PS: "We have confirmation from the Domain Problem Owner that the direction is right. Let's build an MVP in Google Apps Script — it's enough to validate the hypothesis. If it works, TI will rewrite it in something more robust." TI: "Ok, I can set this up in 2 days. No database — data in Sheets. We'll see after that."
TI: "Before I start, I need to set up a Kubernetes cluster, because how will this scale later? And we need to choose an ORM, because migration later will be painful." PS: "Makes sense. Let's also add a CI/CD pipeline and monitoring from day one."
02
The only KPI at the start: how fast does the Domain Problem Owner see something working and say "yes, that's it" or "no, that's not it at all." The faster, the less wasted work.
PS: "The Domain Problem Owner described their reporting process. TI, let's build a mockup in Sheets with real data and show it to them on Tuesday." TI: "Done. I filled it with sample data from their domain. Sending the link."
PS: "We have a detailed specification. TI, start with the data model and API. Demo in 3 weeks." TI (after 3 weeks): "Done, but the Owner says this isn't the problem they had in mind."
03
Every deployed solution must have a Change Card: where it's connected, how it's maintained, how to report issues, business context, links, test data. No Change Card = no formal acceptance. This isn't bureaucracy — it's the team's memory.
TI: "Solution accepted. Filling in the Change Card: - Connected: Google Sheets + Apps Script trigger every hour - Maintenance: logs in 'Logs' sheet, email alert on error - Issue reporting: Google Chat channel 'TV-Buying-Support' - Test data: 'Test Data' sheet with examples"
TI: "It works. Here's the Sheets link: [link]. If you have questions, just write." 2 weeks later — nobody remembers where it is or who maintains it.
04
When the Owner reports a change — start by diagnosing what already exists, not by building from scratch. Change Card + domain knowledge + adoption process = context that the AI New Feature Briefer aggregates. Use it.
PS: "The Owner wants to add a new report type. I'm checking the Change Card — the current solution lives in Sheets with a trigger. Domain knowledge from the AI Domain Briefer shows we already collect this type of data. TI, extend the existing script with a new tab."
PS: "New request from the Owner. TI, create a new project — this time in Python, because Sheets doesn't scale." A new silo forms, the old one dies, nobody migrates the data.
05
Disposable technology means: don't write tests for code that will live 3 weeks. Don't refactor a script that might be replaced tomorrow. Test on real data, not on mocks. Invest in quality proportionally to the expected lifespan of the solution.
TI: "This is a one-time data migration script. I'm not writing tests for it, but I'm doing a dry-run on a copy of the sheet and checking the result manually."
TI: "I wrote 47 unit tests for this report-generating script. 93% coverage. Took me 3 days." A week later, the Owner changed the report format and all tests are garbage.
II. Role Division: PS Thinks, TI Builds
06
PS doesn't tell TI which tools to use. TI doesn't question the business priority. The boundary is clear: PS is responsible for solving the right problem. TI is responsible for making the solution work.
PS: "The Owner needs a daily sales report broken down by channel. Deadline: Friday. Data is in BigQuery." TI: "Ok, I'll do it as a scheduled query + Data Studio dashboard. Faster than writing a script and the Owner can filter on their own."
PS: "Build this in Python with FastAPI and deploy on Cloud Run. Use pandas for processing." TI: "Ok..." (thinking: the same thing can be done in Sheets in an hour, but PS said so...)
07
TI attends meetings with the Domain Problem Owner (kickoff, team assembly) — listens, asks technical questions, builds domain understanding. But negotiations on requirements, scope changes, and priorities are exclusively PS's domain. The Owner doesn't direct requests to TI — PS translates business language to technical language and vice versa. This isn't hierarchy — it's protecting TI's time and communication quality.
At the kickoff: The Owner describes the reporting process. TI listens and asks: "Does the BigQuery data update real-time or batch?" PS takes notes on requirements. After the kickoff, on Google Chat: Owner writes: "This report is weird, the numbers don't match what I have in Excel." PS: "I understand. I'll investigate the discrepancy and come back with a diagnosis. Can you send your Excel?" PS → TI: "The Owner sees a difference in totals. Probably a date filter issue — they count from the 1st, our script from Monday. Check and align the logic."
Owner → TI directly on Google Chat: "Change this column to green and add a monthly summary, and it's loading too slowly." TI makes three changes at once, without priority, without context, without a Change Card.
08
If something blocks work — the blocker goes to Google Chat immediately, not waiting for the operational meeting. Operational meetings (Tue/Thu 11:00) are for review, not for discovering blockers from 3 days ago.
TI (Google Chat, Monday 2:00 PM): "Blocker: I don't have access to the BigQuery dataset 'sales_channel'. I need viewer role. Who can grant it?" PS: "Writing to Wojtek, should be done within the hour."
TI (at the operational meeting, Thursday 11:00 AM): "BTW, since Monday I haven't had access to BigQuery, so I didn't do anything on that task."
III. Domain Problem Owner — Respect Their Time
09
Don't flood the Owner with open-ended questions. Use the AI Problem Explainer to generate a questionnaire with A/B/C options and a suggested direction. The Owner picks, doesn't write an essay.
PS (via AI Problem Explainer on Google Chat): "We need to clarify the report scope. Please choose: A) Only data from the last 30 days B) Data from the current quarter C) Full history (may load slowly) Suggestion: option B — best balance between completeness and speed." Owner: "B, but with the option to switch to C."
PS: "Hey, what date range do you want in the report? And which columns? And what filters? And what format? Should I send you a survey?" The Owner has 15 minutes a day for this project. They won't respond.
10
Acceptance is the moment when the Owner explicitly confirms: "yes, this solves my problem." Not "cool," not "we'll see" — a concrete "ok" or concrete feedback. PS is responsible for making this moment happen.
PS: "To summarize the demo: the report generates daily at 8:00 AM, shows sales per channel, data from BigQuery. Does this solve the problem you described?" Owner: "Yes, that's exactly it. One note — add a margin column." PS: "Sure, minor change. TI will add it tomorrow. Generating the Change Card."
PS shows the demo. The Owner nods. PS assumes it's ok. Nobody confirms anything. A month later: "But I said I needed the margin..."
IV. Adoption — Your Solution is Worthless Until People Use It
11
You don't finish when "it's in production." You finish when people are using it and know what to do when something breaks. The AI Adoption Writer generates the adoption process, but PS must run it with the Owner.
PS: "Solution deployed. Adoption plan: 1. Sending a 2-minute screencast on how to use it 2. Google Chat channel 'TV-Buying-Support' for questions 3. In a week I'll check with the Owner if the team is using it 4. In 2 weeks metric: is the report opened daily"
TI: "Deployed. Here's the link." A month later — nobody uses it, because nobody knew it existed.
12
People fear change — especially when AI enters their daily work. Don't say "there's nothing to worry about." Show them specifically: what changes, what does NOT change, and how the new tool helps them instead of replacing them. Every PS and TI is an ambassador of change.
PS (at a meeting with the Owner's team): "This report doesn't replace anyone. Your analyst Kasia still interprets the data — she just doesn't have to spend 2 hours a day collecting it anymore. She can focus on insights."
TI (in a Change Card comment): "Automated the reporting process. Manual report creation is no longer needed." Kasia reads this and thinks: am I being fired?
V. Documentation and Measurement
13
You write documentation for someone who will join the project in 3 months and will have no idea why you did it this way and not another. Change Card, domain knowledge, adoption process — these aren't formalities. They're organizational memory.
Change Card ("Business context gained" field): "The TV Buying department counts sales from the first day of the month, not from Monday. Their Excel historically used SUMIFS formulas with range A:A, which caused discrepancies with BigQuery. We agreed with Kasia that BigQuery is the source of truth."
Change Card ("Business context gained" field): "Sales report."
14
The success metric is not "how many things we deployed." It's: how many deployed solutions are actively used after 30 days. PS is responsible for defining the adoption metric BEFORE deployment.
PS (at the kickoff): "Success metric: 2 weeks after deployment, the report is opened at least 4 times a week by at least 3 people from the TV Buying team. I'll check in Google Analytics / logs."
PS: "Success: the report runs without errors." Runs without errors because nobody opens it.
15
The AI Meeting Analyst analyzes meeting transcripts and generates action items. There are no "off the record" meetings. If something is important enough to discuss, it's important enough to write down.
PS (at the start of the meeting): "Recording is on. At the end we'll generate action items and send them to the channel." After the meeting: Action items on Google Chat within 15 minutes.
PS: "Great meeting, lots of decisions made. Tomorrow I'll write up what we agreed on." Tomorrow PS remembers half. TI remembers a different half. The Owner remembers a third version.
VI. Supervision and Process Discipline
16
PS checks that tasks are moving forward and heading in the right direction. Doesn't stand over TI asking for status every hour. Operational meetings (Tue/Thu 11:00) are checkpoints — between them, TI has autonomy.
PS (at the operational meeting): "TI, yesterday you said you were finishing the BigQuery integration. How did it go?" TI: "Done. Today frontend — dashboard in Data Studio. Should be ready by 3:00 PM." PS: "Ok, let me know when it's up, I'll send it to the Owner for a preview."
PS (Google Chat, 10:15 AM): "How's it going?" PS (Google Chat, 11:30 AM): "Anything ready yet?" PS (Google Chat, 1:00 PM): "Drop a screenshot of what you have."
17
The TI+PS team works on one priority. Not two "because both are urgent." Not three "because we're waiting for feedback." If you're waiting — work on adoption, documentation, Change Card. But don't start a second priority.
Bart: "I have two topics — TV Buying reporting and onboarding automation." PS: "Which has higher impact? We'll do that one properly, deploy it, take care of adoption, close the Change Card. Then the next one."
PS: "Let's do both in parallel. TI takes reporting, I'll handle onboarding." A month later: two solutions at 60%, neither deployed, neither accepted.
18
The weekly with leadership is for making strategic decisions, not for reporting what you did this week. Come with questions that need decisions, not with a task list.
PS (at the weekly): "Status: TV Buying report accepted, adoption in progress. Decision needed: the Owner wants to expand to Radio Buying. Do we treat this as an iteration of the current solution, or as a new priority?"
PS (at the weekly): "On Monday we built the API. On Tuesday we fixed a bug. On Wednesday we met with Kasia. On Thursday TI wrote tests. On Friday we deployed." Leadership doesn't know why they're here.
19
After closing a priority, the team runs a retro with another PS+TI team working for the same client — so learnings transfer across workstreams. This isn't a formality or a "nice to have" — it's the only mechanism through which the department improves. Taking a moment to reflect on what worked and what didn't is a natural part of the work, not a break from it.
PS (after closing a priority): "Retro on Friday at 10:00 AM. I prepared 3 points: what went well, what went wrong, what we'd change. Inviting the other PS+TI team — let them listen, they had a similar problem with access." The other team avoids the same blocker a week later.
PS: "Priority closed, Executive Summary sent. Let's move on to the next one." A month later, the other team hits the exact same problem. Nobody remembers how the first team solved it.
VII. AI as a Tool, Not an Excuse
20
The 8 AI agents in the process generate artifacts, structure knowledge, write documents. But every agent output must be validated by a human. The AI Domain Briefer might misstructure knowledge. The AI Problem Explainer might suggest the wrong direction. PS is responsible for output quality — not the agent.
The AI Domain Briefer generated a knowledge model for TV Buying. PS: "Checking. Point 3 is imprecise — Kasia said rates change quarterly, not monthly. Correcting and approving."
PS: "The AI Domain Briefer generated the document. Sending it to the Owner without reading." The Owner reads nonsense. Loses trust in the process.
21
The AI Change Card Writer generates Change Cards. The AI ExSum Writer generates Executive Summaries. This saves time on writing. But choosing the priority, diagnosing the problem, deciding the direction — that's PS's job and you can't delegate it.
PS: "I diagnosed the problem, aligned on direction with the Owner. AI ExSum Writer — generate a summary based on our findings."
PS: "AI, what should our next priority be?" AI doesn't know the political context, company relationships, or what the CEO said over coffee.