“It’s better to have a great team than a team of greats.” – Simon Sinek
As a leader, you can go a long creating clarity, generating energy, and driving results when you boil down the essence of a team’s values, principles, and practices.
You’ve probably heard the saying, “it takes teamwork to make the dream work.”
But what is the glue or the backbone that helps a team execute better together?
While the mission and the vision establishes the team charter, it’s the values, principles, and practices, that establish the foundation for effective teamwork and collaboration.
While it may sound simple, your measure of effectiveness is how well the team actually lives and breathes the values, the principles, and the practices.
Here is an example of the original framework we used to guide our team…
Example of the patterns & practices Way
There are so many ways I can share how we did what we did on the patterns & practices team at Microsoft, but I think the simplest approach is to share the values, guiding principles, and practices.
When our group changed leaders, one of the first things our new leader did was build consensus around what patterns & practices was all about. I suggested using the values, principles, and practices frame because it was a proven model.
The values, principles, and practices on a page set up the framework and the context in which we operated, which in turn, guided everything else.
In all of my experience, this is perhaps the best example I look back on where the leader really articulated the firm foundation for the team on a page.
Here on a page are the values, principles, and practices that guided our team:
Our Values
In patterns & practices we value:
- Continuous learning, innovation and improvement – we have a bias toward action (over more planning) and customer engagement and feedback (over more analysis)
- Collaboration — Open, collaborative, relationships with customers, field, partners and product teams
- Execution – we will take strategic bets, but we will hold ourselves accountable for creating value, shipping early and often, and delivering results that have impact with customers.
- Transparency — Explicit, transparent, and direct communication with customers and with our team and others in our company.
- Quality over scope — no guidance is better than bad guidance
Our Guiding Principles
We use the following principles to guide our work:
- Start with end in mind — think about end to end scenarios, and how the products we produced fit in the solution architecture and into the patterns & practices “catalog”.
- Focus on the goal — Help the customer succeed with their intent – the results they want to achieve, not just what they are trying to do.
- “Satisfice” and Ship it — Find the minimal solution required for a good result and ship it.
- Use the right tool for the job — Our tools platforms are assets that expand the types of guidance we can express – use all of what they provide where it naturally fits the scenario.
- Create constructive tension — Constructive tension between customer needs, technical strategy, and business strategy is expected – when we do our job well this tension is healthy.
Execution Processes, Practices, and Tools
- We decide which scenarios and technical challenges we will focus on and what we will deliver using a portfolio planning process.
- We organize to do our work in small teams, typically made up of a core teams and a variety of experts and specialized contributors.
- We run development using a baseline process and team dashboard that teams tailor to the unique scope and needs of an individual project. The common baseline process gives us a common view of the, velocity, and plans of each of the projects and project teams.
- Our projects run three to nine months with checkpoints at key milestones.
- We review and drive execution in our team using monthly, quarterly and semiannual reviews and checkpoints. Many of these are driven by or tied to the company’s processes for Strategy Planning, People Management and Development, and Operational Execution.
There you have it.
One a page, a simple balcony view of how the team collaborated using a simple framework of shared values, principles, and practices.
It wasn’t easy to get to this level of clarity, but I remember how once we did, we used the language to help shape our decisions and guide our behavior (and thoughts are behaviors, too).
Looking back, it ultimately created a language for sharing and shaping how we worked.
As a thought exercise, see if you can put down on paper your team’s values, principles, and practices.
It gets easier with practice, and simply by trying to do it, you force yourself to really get curious about what works and what doesn’t when it comes to great teaming.
You Might Also Like
5 Team Execution Patterns
Agile Results for Teams and Leaders
Dream Big, Start Small
High Performance Teams are Individuals at Their Best
High Performance Teams Have These 5 Dynamics
How To Lead High Performance Teams the Agile Way
Kanban for High Performance Teams
Leadership Skills for Making Things Happen
Lessons Learned in Project Execution
NLP for High Performance Teams
The Change Benefits Canvas
This almost all sounds pretty good, but this worries me: “Satisfice” and Ship it.
This is how, in 4 years, you end up with serious entrenched problems that were “good enough” but don’t scale anymore or turned out to be poor decisions for other reasons. They may affect tons of teams and/or customers. And those users won’t agree to allow those “Satisficeory” systems to be re-engineered because it might break their stuff.
Now your team’s got a giant heavy lift that nobody wants to do and you’re fighting your own company and a bunch of customers just so you can get it done *correctly*. It’s totally UNsatisficeory now.
That might be short-cuts versus satisficing.
It took me a while to fully appreciate the real value of satisficing.
Short-cuts happen when people don’t include the right perspectives and concerns.
The idea of satisficing is really being inclusive of all the perspectives you should be including (performance, security, reliability, manageability, etc.) and balancing across them, so you can actually address them.
The opposite is when people optimize for user experience, or tech feasibility, or skip performance, or skip security, etc.
Satisficing well means putting all the perspectives on the table, making all the choices around competing concerns visible, so that you can make a “good enough” fit that works across all the concerns, versus a good UI that’s not sustainable.
This is a very interesting article, and I get the gist of what you’re trying to say and agree with the conclusions. However I must point to the fact that there are a few errors that are not your own, but emanating from a general misunderstanding of these basic concepts that you refer to: Values and Principles.
If you love candy, it does not mean that Candy becomes one of your values. Maybe the love of sweetness would be one. You have to abstract these concepts to the true inspiration that stand behind them. A Value is a more fundamental and even foundational concept that should transcend the details of a given usage. “Continuous Learning, innovation and improvement” are also different concepts, and the detail you provide introduces even others (“we have a bias toward action” is totally different from, and does not explain, the three previous ones). So you have to dig deeper and ask yourself, what is the Value that makes me appreciate the importance of “continuous learning” for instance, and to do the same with the others. Identifying one’s values, personal or professional, requires a lot of introspection and abstraction, but will, in the end, make it easier to understand and explain one’s purposes, one’s objectives and one’s principles.
Your objectives, in life or professionally, or in this particular professional context, are dictated by your Values.
Principles become an expression of your Values, not just another set of titles, and the ones you provided here represent more of a Policy Statement, not a list of Principles. e.g. one of my Values is the sanctity of human life, as a result, one of my Principles would be the Principle of Humanity, which will lead me to define Policy Statements that may include things like treating people equally, never hurting anyone, being attentive to another’s human needs, etc…
So, I do respect where you’re coming from, and in the end I did get the message loud and clear, and I agree with the conclusions. But Values and Principles must be at a higher level of abstraction, otherwise you wind up with simple expressions of Policy or Objectives.
Good points.
I find it helpful to remember that values are not what a group says they value. They are what a group rewards and punishes, which truly reflects the culture.
And with principles, I find it helpful to distinguish and call out “operating” principles, which help people understand that the purpose of the principles is to help guide decisions. So when people are making crucial decisions, they can evaluate whether they are reinforcing the principles.
That’s actually the secret of how large organizations reinforce their culture across the board, and Amazon is prime example of principle-based management.