A take-away from this great book.
A year ago my long time friend Sean Tierney joined our company as our Dir. of Sales. After a few weeks he hands me a book and said something to the effect of “whether you know it or not, this is how you run the company”. I read most of it quickly, then finished it a few months later (the last few chapters are gold). Highly recommend, buy it.
Of late, we have been growing at a good clip at Pagely, new faces at the weekly standup’s. A focus of mine as we have grown is to reinforce the culture that has made us successful.
A core tenant of that culture is that our team members are responsible for managing themselves on a day to day basis and are fully accountable to the team as whole. They are also given our complete trust to make and execute decisions within their universe of responsibility. Our team(s) excel within this framework.
Do less of this.
In a typical company structure you have a strict hierarchy of top down leadership. The Authority (and mission planning) resides in the C Suite and carved up among VP’s and various Directors. However the responsibility of executing against the mission goals resides at the department, team, and individual which collectively are held accountable for the success of the mission.
Employees are responsible and accountable for the success of the mission, but often times given zero of the authority to decide or determine how that mission goal should be achieved, or even given a say in if the mission is a valid one.
In a sense, leadership does not trust the workforce. Have you ever talked to a customer support rep somewhere to be told they had to send this up to a manager or that they did not have the authority needed to make that change?
Would you want to work at a place like that? Would you give 110% for someone who does not trust you?
Do more of this.
What Sean was telling me when he gave me that book, was in a sense we run a bottom up organization. We assign responsibility to our team members along with the authority necessary to make decisions and take action to accomplish the mission, then hold them accountable for the results.
Well first and foremost we attempt to hire for culture first: Is this person someone likely to consider the possible consequences before taking action (mindfulness). Is this someone who has worked remote before and has solid references from peers to attest to their ability to self-manage (accountability).
Obviously then we look for the following: expertise in their field (competency) and what I call the ‘no sheeps’ personality traits of critical thinking and willingness to act.
If we did our screening right we are hiring people that we can trust with the fate of our company. The formula does not always work perfectly, we’ve made bad hires too.
Each potential hire is screened in the above manner. The final interview before they are hired is with me where we discuss almost exclusively our culture, the expectations we (as a team) have for them, and those they may have for us. We talk about the current mission(s) (globally and for their respective role) and if they have any suggestions at that time to improve the mission. Later on at our weekly standup’s everyone is encouraged to discuss and refine it. The mission is owned by everyone and is malleable.
On their first day a Pagely Support Engineer is granted SSH key based access to every single Amazon server we manage and tasked with solving any and all customer issues that come up (responsibility). They are expected to solve these issues to the betterment of the client relying on their skill set, the joint expertise of their team, and their ability to research and learn (accountability).
As they get up to speed: They should never ask for permission, they already have it. They should never fear making a mistake the first time as new mistakes are a valid part of the learning process.
Most importantly they should always default to a state of mindful action: using reasoned intelligence to process the current mission goals (whether that is a specific customer support task or a global task such as documentation or product improvement), share their intent (sanity check the action plan), and finally execute the action plan (authority).
This is not authority in the sense of Boss > Employee. It is the authority to take action. Trust is the mechanism the authority flows through.
Ultimately we place complete trust in our team. We hired them for a reason, why second-guess them at every step. They can refund a client, they can reward a client, they can go to any length to serve a client. Very little happens in their support universe that they personally do not have direct authority or influence over.
It works across teams as well. They can reach over to InfoSec, or DevOps, or Engineering or elsewhere for resources, guidance, or to lodge feature requests and request feedback.
We push the authority down to the level of the responsibility and accountability so they are one and the same.
In the book they call this Leader-Leader (the opposite of leader-follower). It is not the elimination of corporate hierarchy but it has the effect of turning everyone into a leader that makes decisions and is expected to act on those decisions in accordance with the mission goals. The ‘subordinate’ decides how to accomplish their specific mission goal and simply state’s their intent to do so (with context) to their ‘superior’ for confirmation.
“If all you need to do is what you are told, then you don’t need to understand your craft.
However, as your ability to make decisions increases, then you need intimate technical knowledge on which to base those decisions.
Control without competence is chaos.”
Excerpt From: L. David Marquet. “Turn the Ship Around”
A real support case at Pagely.
Mission Goal: Return clients server to functional state after an automated alert from our DevOps channel.
A to Support Team: “I’m going to restart the php process on server x as it appears to be in a stuck state after the client’s latest code deploy. It seems to have created a bunch of runaway processes, likely a slow query. I will confirm the cause and remedy as needed, informing the client as I progress”
B to A: “Yes. We patched that once before, appears they did not commit our patch, the patch is at [github link].”
A to B: “Yeah I saw that in the account notes. Thanks for confirming”
… a few minutes later
A to Support Team: “Applied our patch again, and confirmed the client has commit to their repo for the future. Their wp-admin is back to < 1 second page loads.. Closing case.”
This scenario, not the client caused failure, but the demonstration of how our support team works together happens every minute of every day. The same in DevOps, Sales, Engineering, etc. We are a team of teams (another great book) that work cohesively to accomplish our mission goals and to set new goals.
Would we be as effective if say; the support agent notified their ‘superior’ of the issue, the superior being the gate-keeper of authority and knowledge either then has to clearly instruct the agent how to solve it and follow the resolution, or maybe has to escalate to someone else with authority to access the servers who fixes the issue and reports back, which is then reported back to the originating agent, who then reports back to the customer. Um, no.
A long story short.
- Craft and communicate your mission goals.
- Trust those responsible and accountable for the mission’s success with the authority to act.
- Reinforce good outcomes.
It’s working for us, YMMV.