Engineers are entities, people or organizations, owning engineered elements and working on endeavors, e.g. issues.

Engineer extends Persona and as such can have goals. Because Persona extends Engineered Element it may have issues associated with it.

When applied to an Engineers it may be development issues, e.g. training. Say, Joe Doe may have an issue “Team lead training” assigned to Jim Smith, his supervisor. What it means that Jim trains Joe and it is tracked in the same way as tracking of product development, i.e. you can develop (engineer) your organization in the same way you develop (engineer) products and services offered by your organization.

Engineers may have capacity to work on endeavors and that capacity can be allocated to engineered elements and issue categories.

In addition to owning engineered elements, engineers may have expertise in them. Ownership primarily means authority to make decisions about the owned elements. Expertise means knowledge of how to use them. Usually ownership assumes expertise, although the owner may consult the experts and then make decisions base on their inputs. Owners and experts form a community for an engineered element.

Engineer may define increments, issue categories, and issue statuses. Typically it would be done at the top-level organization.

Engineer may define personas and represent them. E.g. in an organization there might be a “Developer” persona defined at the “Developer Experience” organization and represented by developers. This allows to define personal goals by interviewing the representatives and then align organizaiton’s endeavors to the persona goals.

Engineers may also have objectives associated with endeavors, e.g. increments. E.g. “Developer” persona may have a goal “Automate routine tasks” and there might be an annual objective “Create code generators” aligned to that goal. Then, subsequently, a feature “Cloud microservice code generator” can be aligned to the “Create code generators” objective or it’s key result, say “5 code generators for the cloud”.

Engineers may contain modules. E.g. a team may contain libraries developed by the team and then ownership of these libraries may be assigned to team members.

Engineers may also provide services - shared activities used by other engineers or personas. For example, a performance testing team may provide a testing service used by development teams to performance test modules they own.

Services may be defined as journeys leveraging services provided by other engineers. For example, the performance team’s service “Performance test an application” may use a service “Provision cloud environment” provided by the cloud infrastructure team.

And, finally, engineers may post messages to topics of discussion forums.

Supertypes

Subtypes

Referrers

Default engineer rate. Can be customized in capacity.

Type EDouble
Cardinality 0..1
Changeable true
Derived false

Engineer assignments.

Type Endeavor
Cardinality 0..*
Changeable false
Derived true
Opposite assignee

Engineer’s capacity for a particular endeavor

Type Capacity
Cardinality 0..*
Changeable true
Derived false

Allocations of this engineer’s capacity to work on an engineered element issues for a particular endeavor and issue category.

Type Allocation
Cardinality 0..*
Changeable false
Derived true
Opposite engineer

Engineer’s domains

Type Domain
Cardinality 0..*
Changeable true
Derived false
Key path
Type EngineeredElementStatus
Cardinality 0..*
Changeable true
Derived false
Key path

Engineered element which this engineer has experience with.

Type EngineeredElement
Cardinality 0..*
Changeable false
Derived true
Opposite experts

Increments are defined under engineer/organization.

Type Increment
Cardinality 0..*
Changeable true
Derived false
Key path

Issue categories are defined under engineer/organization.

Type IssueCategory
Cardinality 0..*
Changeable true
Derived false
Key path

Issue priorities are defined under engineer/organization.

Type IssuePriority
Cardinality 0..*
Changeable true
Derived false
Key path

Issue severities are defined under engineer/organization.

Type IssueSeverity
Cardinality 0..*
Changeable true
Derived false
Key path

Issue statuses are defined under engineer/organization.

Type IssueStatus
Cardinality 0..*
Changeable true
Derived false
Key path

Engineer manager(s).

Type Engineer
Cardinality 0..*
Changeable true
Derived false
Opposite manages

Engineers managed by this engineer.

Type Engineer
Cardinality 0..*
Changeable false
Derived true
Opposite managers

Discussion messages authored by this engineer.

Type Message
Cardinality 0..*
Changeable false
Derived true
Opposite author

Modules (products) are defined under engineer or organization.

Type Module
Cardinality 0..*
Changeable true
Derived false
Key path

Engineer’s objectives for a particular endeavor

Type Objective
Cardinality 0..*
Changeable true
Derived false
Key path

Engineered elements owned by this engineer.

Type EngineeredElement
Cardinality 0..*
Changeable false
Derived true
Opposite owners

Personas which this engineer/organization builds products for.

Type Persona
Cardinality 0..*
Changeable true
Derived false
Key path

Personas which this engineer represents.

Type Persona
Cardinality 0..*
Changeable false
Derived true
Opposite representatives

Engineer may perform shared activities (services) which can be parts of persona journeys.

Type Activity
Cardinality 0..*
Changeable true
Derived false