Part of my objective to be an inspiring leader is the key result to have SMART expectations of myself and others. And, despite knowing clarity of desired outcomes is key to setting expectations, I struggle.
I’m driven to live fully by living differently. And I’ve been pretty successful in doing so. However, I want to be doing so more conscientiously rather than by openness to circumstances.
Therefore, I’ve taken steps to identify my life priorities…
- Take care of myself
- Have healthy relationships
- Be an inspiring leader
Then, for each of those, I have an explanation, like for taking care of myself are…
- Mostly eat tasty, nutritious foods
- Move for the joy of it
- Sleep well each day
- Challenge the status quo
- Meditate for alignment
- Reduce debt when paid
And for a value like respect, I demonstrate calm presence, empathy, and kindness at every moment.
I feel that I’ve done quite well identifying what’s truly important to me and how I might act daily to be my ideal self through specific, measurable, achievable, realistic, and timebound expectations AKA SMART.
Yet, I’m not as confident about how I’m approaching expectations when it comes to my professional activities and setting a good example for others.
I’ve about a hundred people on my customer success team. They range from engineers to directors covering delivery and people management service areas.
Because of my visibility to others, what I do and how I do it, matters more than ever. Therefore, I’m deliberate and open about approaching my role of leadership development plus delivery and strategic program execution.
At this time, I believe that my words and actions must align. As such, I’m big on when asking myself or others to do something, to see it tracked. That tracking might be a reminder on a Slack thread, a sub-task to a Jira ticket, or something more relevant for the situation.
No matter how that request is made, the underlying concept is that it is an expectation. So for these things that could be written down, executed, and monitored, they typically comply with SMART criteria, except for time-binding.
Operational realities mean that priorities fluctuate and these things asked of people, should be reflected somehow.
The current way to deal with these vagaries is a weekly conversation around a service area’s project board of current To Do, In Progress, Peer Review, and Done things. Then, monthly, a backlog grooming discussion including must-, should-, could-, and won’t-have (MoSCoW) categorization and activity refinement.
Formal priority labeling rarely happens because of daily and weekly interactions, which provide by the moment clarity. That said, I’ll monitor for things that haven’t progressed in over 8-days as a way to catch items falling through the cracks.
Lastly, during the weekly and monthly conversations, when it seems that a task no longer fits strategically or tactically, change the status to Cancelled.
Canceled is my favorite status because we’ve realized, something didn’t matter as much as initially considered.
And through these regular conversations, we make time-binding real.
Job descriptions aren’t roles
I find job descriptions, pretty but not substantial enough to do something with. And, that is why I’m a big believer in using role descriptions.
A great role description explains the relevant domain of authority, responsibilities, and validation thereof. And, through this structure, I can guide people towards success.
For a role’s domain, the typical job description summary might work given the fluff is minimized, like the following.
After the role’s domain, responsibilities rather than requirements are shared. This is because a job’s requirements like the following are typically the core competences needed to perform the job.
- Experience using front-end frameworks like AngularJS, ReactJS, Ember, Zurb Foundation, Bootstrap, and other grid systems.
- Knowledge of CSS frameworks such as CSS, SASS, LESS, OOCSS, Smacss, BEM, etc.
For each role responsibility, I’ve learned to define them by accountability, responsibility, or support clauses per the RASCI responsibility matrix. This is because of role entanglement and career progression.
As an example, an architect is accountable for a built-right system, while it’s the engineer responsible for the execution, and the consultant supporting those people with their expertise.
More specifically, a front-end technical architect is…
- Responsible for guiding technical discussions with technical and non-technical audiences
- Responsible for negotiating mutually agreeable outcomes with clients, partners, and other stakeholders
To help people know they’re succeeding, each accountable and responsible aspect has a validation method to prove its accomplishment. When similar validations exist, combine the parent aspect.
And, when validation is not feasible, remove or refine that expectation until objectivity exists. Otherwise, the responsibility is solely wishful thinking.
Because standards and monitoring for consistency are critical for me in people management, I’m taking role descriptions a step further, by transforming them into role templates via 7Geese, a performance management platform.
This way, on a monthly or quarterly basis, a performance coach, reporting manager, or others like me can view a collaboratively defined and shared reference of what is expected of people and how we’ll guide them.
Beyond the role’s accountable and responsible aspects and their validations, there are company behavior and role-based skill competency checks.
Behaviors help ensure a person’s culture fitment through company values.
For example, the company value enthusiasm is refined further by self-management, quality, and continuous improvement with trait indicators. Like these of self-management:
- We are curious, can make decisions on our own, initiate change, and take action independently. Taking action doesn’t mean we do everything alone. Instead, we know when to collaborate and when to ask for help.
- We manage ourselves and don’t need someone to tell us what to do to be productive. Our first instinct is to take the initiative rather than expect a policy or ask for permission.
And, for skills competency, it’s recognized that like company values, sub-sets exist.
Therefore, instead of looking to know Drupal in general, it’s broken into Drupal Security, Drupal Front-end, Drupal Migration, and many others. Each of these with one or more levels of skill expectations.
I’ve learned much over the past years leading teams of all sizes. And, I believe the key to a team’s success is consistent clarity.
However, conversations that suffice for a small team should become processes for larger groups, and eventually, a system for all. By utilizing systems, I’m remaining focused on people and not administration.
And, by incrementally improving the things that support people and task management systems, great expectations are reached.