> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/culture/our-week.md). # Our week **Our few regular meetings are in the morning or right after lunch.** That keeps the rest of the day free for work. [How we communicate](/culture/how-we-communicate.md) and [The office](/company/the-office.md) describe how and where we work together between the meetings. **At exactly 12:00, to the second, the whole company starts lunch together.** Some people bring their own food, while others get something from a restaurant nearby or from a supermarket ten minutes away, such as Aldi, Lidl, Netto or Rewe. We eat together so that everyone gets to know each other and feels part of one team. You also hear about the problems, worries and successes of departments you don't normally work with. ## The written standup **Every morning before the 09:30** [**check-in**](#daily-check-in)**, you post a written standup that tells others what you need from them.** Post it in #dev-5-daily, as a reply in the thread under the newest GitHub review digest from the previous evening. The digest is a bot post that lists the pull requests waiting for review. What you need can also be something you might need soon, for example a review of an open pull request. Because the standup gets information across without a meeting, it should hold more than what you say in the check-in. You also write what you are working on. If you work from home, are away that day, or have a vacation coming up, you say so there. ## Daily check-in **The daily check-in goes through the blocking customer requests and anything that needs coordination with others.** It is at 09:30, Monday to Friday. People meet for it in the office or join remotely when they work from home. It starts with the [blocking customer requests](/product/product-manager/blocking.md). After that, we only talk about what needs coordination with others, because everything else is already in the written standup. On Mondays, we also plan the [all hands](#all-hands) and remind each other of the [pitches](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets) for Wednesday. ## All hands **At the all hands, the whole company hears updates from** [**go-to-market**](/culture/working-with-the-rest-of-umh.md) **and sees the work that product and engineering have fully released.** It is on Monday at 13:00. Alex leads it as CEO. We record it for internal use. Go-to-market's updates cover, for example, the current lead pipeline, the monthly go-to-market numbers and larger projects. Product and engineering then show only work that is fully released. Fully released means that its [feature flag](/engineering/development-process/how-to-ship.md#stages-and-the-feature-flag) is on by default and customers can already use it. After we plan the demos in the Monday check-in, the [Product Manager](/product/product-manager.md) posts the list in #dev-2-product. When the engineer who built something is away, the Product Manager presents it. ## Product meeting **The product meeting goes through the** [**important customer requests**](https://linear.app/united-manufacturing-hub/view/customers-with-important-customer-requests-d3cf463d28be)**, then** [**all rollout tickets**](https://linear.app/united-manufacturing-hub/team/ENG/view/all-rollout-tickets-9b3c8de62203) **from right to left.** It is on Wednesday at 13:00. The Product Manager coordinates it. Product, engineering, the [Value Engineers](/culture/working-with-the-rest-of-umh.md#value-engineer), product marketing and the CEO take part. Each owner gives a short status on their [rollout tickets](/engineering/development-process/how-to-decide-what-to-build.md#rollout-tickets). For a new pitch, the meeting decides on the [bet](/engineering/development-process/how-to-decide-what-to-build.md#the-bet). ## Engineering weekly **At the engineering weekly, engineering improves its practices.** It is on Wednesday at 14:00, right after the product meeting. Examples of such practices are stacked pull requests, what a review should cover and how to work with feature flags. When we agree to change a practice, the person who raised it updates [How to build](/engineering/development-process/how-to-build.md) or its subpages. Longer discussions from the check-in also move here. If you want to bring a topic, feel free to write your thoughts in #dev-1-engineering beforehand so that others can already comment. ## VE weekly **Engineers regularly join the VE weekly on Thursday at 13:00 to learn what they don't know yet about our customers.** The Value Engineers explain their current projects, what they build at customers and what they need. Engineers ask questions about all of this. By presenting there, a Value Engineer can influence what all engineers pay attention to. When a Value Engineer presents a customer problem there, an engineer can pick it up and write a pitch for it. When a Value Engineer reports a problem, ask whether it [blocks the customer](/product/product-manager/blocking.md) and whether there is a workaround. ## 1:1 with the CTO **Every engineer and the Product Manager have a weekly 1:1 with the CTO, Jeremy.** You talk about how you are doing, your professional development, your learning goals for the next one to two quarters, or any other topic. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://engineering.umh.app/culture/our-week.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.