In blog posts, job postings, and our culture and handbook guides, we provide a view into some of the uncommon (but fantastic!) characteristics about being part of the LinkORB team. For candidates and new team members, key themes found in those resources include LinkORB’s:
With a strong technical acumen for most team members and a Holacratic approach, for much of LinkORB’s history, project ownership was a shared responsibility across technical team members. As the user base, business, and organization grew, LinkORB has been investing in dedicated project ownership and project management roles.
The purpose of this guide will be to share best practices for project owners and project managers working (or considering working) at LinkORB. Specifically, it will cover best practices like:
While the concepts presented apply for both project owners and project managers, for brevity only the term project owner will be used. Understanding titles, roles, and role desigations provides further detail on the distinction between project owners and managers at LinkORB.
As a project owner, you will primarily engage with other team members through the below tools and processes.
Cyan’s is the primary asynchronous communications tool used at LinkORB. Effective project owners at LinkORB:
A thorough review of the culture and handbook guides on Team HQ project and task management should be a first step in any new project owner’s onboarding. Two specific Team HQ project owner best practices of note however include:
Parent and child tasks: As the name implies, any task can have one or many child tasks. Use of child tasks is useful to coordinate concurrent and distinct tasks in support of desired outcome. Effective project owners continuously seek to break larger efforts that involve multiple team members into smaller, individually assigned tasks.
Input and review status: When a task is blocked because information or feedback is needed from another team member, instead of creating a child tasks, project owners (and team members) can simply put the task in Input or Review status and re-assign it to the team member they believe can best provide necessary guidance.
While process and automation are central to LinkORB’s way of working, we do not seek the false comfort of ceremony for ceremony’s sake. As such, we prefer to work in a Kanban model. At LinkORB, project owners and teams can invest time otherwise spent on story pointing and sprint planning in task clarity and execution. We hold ourselves accountable to daily progress, but are not centered on arbitrary timelines. The weekly status update for projects and tasks is the only required “ceremony” and that too is designed to take less than 15 minutes to complete.
While project owners at LinkORB are tasked with maintaining a macro view and creating conditions for other’s success, they also contribute tactically each working day. Examples of doing so include:
Successful project owners at LinKORB have an independent desire to continously grow their technical skills and understanding of the LinkORB ecosystem. They are driven to earn the trust of and increase their value to technical team members one day at a time. Similary, project owners seek to close the gap between their work and end user impact.
Project owners are driven to earn the trust of and increase their value to technical team members one day at a time.
At LinkORB, project owners recognize that publishing reports and schedules about what other people are doing does adds little value. The most effective project owners at LinkORB make independent and recognizable contributions to the team’s effort.
The section above discusses ways that project owners at LinkORB can be active, tactical contributors. Arguably one of the most important tactical contributions that a project owner can make at LinkORB is to ensure all work items are clearly defined.
In most cases, a project owner will create the team’s work items themselves. In all cases, the project owner is responsible for triage and curation of all work items before assignment.
While the burden of execution falls to the assigned team member, the burden of clarity falls to the project owner.
Well-constructed work items provide:
The purpose of the task overview is to provide team members the necessary perspective and understanding to support independent decision-making while completing an assigned task. In an asynchronous-first, fully remote team project owners want to empower team members with:
Sometimes an overview only takes a couple sentences. Other times, it’s a couple of paragraphs. Generally speaking, work items should be written in a way that they can be read a year or two later and the reader would get a clear picture of what was being requested and why.
After an overview, the work item must include clear acceptance criteria and requirements to describe the future state. In most cases, acceptance criteria is simply a bulleted list of conditions to be satisfied.
When creating acceptance criteria, project owners are encouraged to think through scope, edge cases, dependencies and ultimately create clear, atomic work items. Similar concepts were discussed above about the importance of keeping Cyan’s topics discrete and focused as well as the use of child tasks. With proper consideration, writing acceptance criteria is the ideal forcing function to identify when a task should be broken down further.
If a project owner can’t explain desired outcomes clearly, the assigned team member has little-to-no chance of achieving those outcomes.
Under a Kanban approach and in a world where everything appears urgent, the project owner plays an important role in looking for what can be de-prioritized. Subsequently, remaining tasks should be prioritized according to:
In an asynchronous-first, fully-remote, Kanban world, there’s no daily stand-up or “drive-by” visit to a colleague’s desk. Often, project owners will not have visibility to the full scope of another team member’s work queue. In this environment, project owners should focus their time and energy on ensuring team members have task and outcome clarity and the space to do their job.
Team members will let you you know if they are blocked or need assistance. Asking for status or when something will be done does not add value. Seeking ways to be of service does add value. Along the path of execution, project owners at LinkORB are expected to celebrate others, make it fun, and cultivate healthy teams.
At LinkORB, project ownership is a service role first and foremost.