> 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/working-with-the-rest-of-umh.md). # Working with the rest of UMH **Product and engineering work closely with Value Engineers and Account Executives.** As part of go-to-market, both have the goal of winning and keeping customers. An Account Executive owns the commercial relationship for the life of the account, from the first sale to renewals and escalations. A Value Engineer owns the technical side of the same account. Value Engineers typically work with the [power user](/product/who-we-build-for/the-power-user.md), the [OT team](/product/who-we-build-for/production-ot-team.md) and [IT](/product/who-we-build-for/it-system-administration.md). They also work with [the people who use the apps on the shop floor](/product/who-we-build-for/production-the-shop-floor.md), such as the shift supervisor or the operator. Account Executives work with [the person who pays](/product/who-we-build-for.md#our-users) and the people around them who decide on the purchase, such as managers and procurement. ## Value Engineer **A Value Engineer is a** [**forward deployed engineer**](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) **who is responsible for everything working technically at their customer.** They join the sales process once an [Account Executive](#account-executive) has found a real opportunity. Each customer has exactly one Value Engineer so that the customer always has the same technical contact. They build the customer's data pipelines, [bridges](https://docs.umh.app/usage/data-flows/bridges) and dashboards on top of UMH. These run in production inside the customer's own systems. The Value Engineer only gives the project its initial push until it delivers business value. In the long term, the customer's [power user](/product/who-we-build-for/the-power-user.md) runs it, trains people internally and coordinates with everyone involved. So the Value Engineer hands the setup over slowly and trains the power user until they can do this. ### Workarounds **Value Engineers find temporary workarounds for everything our product does not support.** If a [Product Engineer](/engineering/product-engineer.md) makes a mistake, the Value Engineer has to somehow fix it for the customer while the Product Engineer builds the proper solution. Customers pay for Value Engineering to get a business result, such as a running MES. Time a Value Engineer spends on a workaround is time they do not spend on that result. ### Working with Value Engineers **Value Engineers are a good proxy for the users of UMH.** Reaching the actual users always involves some politics. We do not want to annoy those users too much. Value Engineers also use our product and often feel a lot of its pain firsthand. It is the Product Engineer's job to reduce the pain they feel. A good relationship with Value Engineers is essential for surviving your first weeks here, because they are an important source of context. As a Product Engineer, work closely with them to prototype new features and test deployments. They hit our rough edges under real customer workloads before anyone else does. When they find a bug or a product gap, they report it as [Customer requests](/engineering/development-process/how-to-decide-what-to-build/signals/customer-requests.md) describes. ## Account Executive **From the product demo onwards, an Account Executive leads the customer meetings.** The Value Engineer leads the technical discussion. If you want a customer to try something early, ask that customer's Value Engineer and Account Executive. As the product team, we would like to test as early as possible. In the end, the Value Engineer and Account Executive decide when and if the customer tries it. ## If you are a Value Engineer or Account Executive * When a Product Engineer wants customers to try a feature, the Product Manager passes you a [customer validation ticket](/engineering/development-process/how-to-build.md#the-rollout-plan). * If a release breaks something at your customer, the Value Engineer switches the feature flag off for them. The Product Engineer then fixes it, as [How to ship](/engineering/development-process/how-to-ship.md#stages-and-the-feature-flag) describes. * Value Engineers join the [product meeting](/culture/our-week.md#product-meeting) and present their projects at the [VE weekly](/culture/our-week.md#ve-weekly). --- # 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/working-with-the-rest-of-umh.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.