Engineer

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.