One of the biggest lessons that we have learned growing from a small team (5-15) to a medium-sized organization (30+) is the balance between releasing control and building controls that ensure quality. Controls are procedures that provide a reasonable assurance that a system operates as intended. However, we believe that true quality comes from a culture of trust within an organization, and we recently went through an exercise that has further reinforced the trust that I have in our team here.
I recently went for a mentoring lunch with someone in a senior leadership position within the federal government. When I asked him what his biggest leadership issues were, he spun out the following analogy -- here’s the ColesNotes version (CliffsNotes for you US copycats).
Building on Trust
Imagine that you are working in water quality control, ensuring that the water in a stream meets safety standards. Each day you can go stand in the stream, take measurements, and be confident in the quality of the water. You trust your equipment and you trust yourself.
However, if you are promoted over the years for a job well done (or, in our case, as your team grows), then eventually you may be in a position where you supervise a team of people who in turn manage the testers who are out standing in streams. The perspective is very different from this position. The person at the top needs to be absolutely confident that when they sign off on water quality, that each person standing in a stream has given an accurate report based on accurate measurements and that their manager has ensured that they have the right equipment and techniques for the job.
I asked how the person at the top could sign off on a report that encompasses the work of so many people. The answer is trust, and the source of that trust is the controls that are in place. Each manager below the leader has to trust their team, and then sign off on work based on that trust. That trust then moves up the chain and at the top leadership takes an act of faith based on many steps of trust.
This analogy rang true for me and reminded me of the trust game where one person falls backwards and believes that their team will catch them.
Losing Control, Building Controls
A small organization cannot grow until the person at the top delegates control of the work to competent team members. If they retain too much control, then the team can only do the amount of work that the person at the top can participate in directly. However, if the person at the top does delegate control, that organization will not succeed unless appropriate controls are in place to ensure that quality, timeliness, and cost are all in check. Sometimes the lack of these controls can be fatal to a business trying to grow past 10-15 people.
Even with all the controls in the world, I don't think a business or a team ever does great work unless they are powered by trust. We build (and sometimes break) trust within our team here at Yellow Pencil on a regular basis as we learn and grow. We also build (and sometimes break) trust with our customers. This is how people grow and learn and how teams become great. You just need to make sure that build is winning the battle over break, and you need to learn to apologize in a meaningful, action-oriented way.
Trust Takes Practice
One of the activities we recently went through with our team was what we called a Fundamental Practices exercise.Fundamental Practices are the way we work and what is important to us about that work. This list should grow and change over time, so this is our first iteration.
We asked three questions of our team:
- What are the qualities of your work that are important to you?
- How do you measure the quality of your work?
- When others look at your work, what do you hope that they see?
We got a lot of answers. Some of them challenged how we do things here; some of them celebrated our successes. But all of them came from a group of people who are passionate about their work and about delivering quality.
As we grow and build a world-class team here, and as we create those controls that will consistently lead to high quality work for our customers, I can confidently say that I trust the people who are standing in the streams watching the water. That's a great feeling.
Here are the responses. They are compiled and edited, but most of the words are untouched. If you hire Yellow Pencil, these are the people building your web project.
1. The qualities of my work that are important to me are:
- In every interaction with a client, they should feel respected and receive clear communication about whatever issue is under discussion.
- My co-workers have what they need to get their job done.
- I contribute to company success by increasing efficiency, resolving problems, removing roadblocks for team members, create smart processes that everyone understands and cut costs.
- Challenging, well-researched work where I learn something new from each project and collaborate with clients.
- Make the high level, structural ideas about a client’s content come to life on the web by writing, coding and editing it into existence.
- What I produce is well thought out and considers the long-term solutions for the clients as well as the continuing relationships we have with them.
- My work is functional, attractive and true to a purpose or goal. It starts with the WHY.
- Pay attention to the fine details: taking the time to tune and revise my work.
- Not technology driven. Everything is based on design thinking.
- Take responsibility to ensure that projects pass accessibility standards and push limitations. I seek out new standards when current standards are not adequate.
- Delivering on time and on budget. Walking away satisfied that I have put in my best effort.
- Ability to take existing ideas, see potential and make improvements.
- Committing a lot of effort towards setting reasonable expectations, being honest with the client, and making them feel important to us as a client.
- Being open to constructive criticism and using the vast pool of talent from my fellow team members.
- See the “big picture” of a project. Design and build through a research-driven process for every job.
- That the code I write is well engineered: clear without needing documentation, reusable and refactored. Another developer should be able to read through it and add features without much trouble.
- Deal with conflict quickly, open communication, keep balanced and calm under pressure.
2. How I measure the quality of my work:
- I know when I have done a great job when I have completed each part of a task to the best of my ability.
- Seeing team members who are motivated, happy and working well together with their colleagues to solve problems internally and for their clients.
- When a client can see a positive shift in their web channel due to the work we’ve done. When the work helps set further wheels in motion.
- When the client is excited about the results and likes to talk about them.
- When the work is sustainable and will thrive without anything more from me.
- When our reputation as experts in our craft precedes us in the industry and with clients.
- If the content is semantically structured, concise and tells a client’s story, then I have done a good job.
- We should measure ourselves by spending more time with clients after a project and defining what made the project a success (or failure).
- That my work has a positive impact on the working culture at the client’s office or business.
- When there is a noticeable difference in the bottom line at YP.
- The thing that really makes me feel good is when the client themselves makes an acknowledgement of the accomplishments within the project, which goes back to setting reasonable expectations so that clients can feel like we exceeded those expectations.
- I hope that if someone looks at our work they don't really see anything in particular. I think we've done our job well if someone can effortlessly get information on a website and not even really think about the fact that they just sought out information from the web.
- When your customer pages you, the timer starts: return their call immediately.
- I know that I've done a great job when both technical and non-technical people who review it are satisfied.
- If I'm working on open source projects, I hope that my work is well received by the community.
- When end users find that what I have made is easy-to-use, and when it delivers unexpected and useful functionality in addition to what was asked for.
- Striking a balance between stringent W3C validation and treading new ground.
3. When others look at my work, I hope they see:
- Trust, openness, transparency, honesty
- Effort and thoughtfulness
- Fair treatment
- Balance between business and user goals
- Good writing
- Well structured content
- An experience that doesn’t feel like a website
- A clean and organized design file
- An aesthetic that tells a story
- Something that connects with them
- That the WHY of a project glows as they move through the various states, interactions, content, tasks
- Something that brings a higher level of delight to their day
- Something that just plain works
- A design system that they recognizes
- The heart that went into a project
- That they are clearly understood
- Code is clean, simple and well documented
- That this was done by someone by someone who cares about what they are doing
- That this work was done by a team much bigger than it really is