When not reading the adventures of Jules Verne, or mysteries of Sir Arthur Conan Doyle, my non-fiction reading list usually consists of biographies, or something historical. After a few urgings, I picked up, read, and thoroughly enjoyed "The Culture Code: The Secrets of Highly Successful Groups" by Daniel Coyle.
As the title suggests, it provides insight on how highly successful teams are formed. However, the conventions don't always follow the traditional pattern. It's not hiring the smartest people. It's not building a team with the most experience. Team dynamics is equally important.
It's an engaging read where kindergartners can succeed where CEOs and MBAs fail. There are multiple stories where the team with the biggest budget, the most experience, and the most confidence wasn't the team to win the prize. Where great ideas are ruined by mediocre teams, yet mediocre ideas are turned into success by great teams.
How leaders, real leaders, will create an environment that makes a great team. For example, how did Google come out of "nowhere?" How does Pixar consistently make such great movies? How can sports team repeatedly win, when on paper, they don't have the best players?
It's multiple stories about how you need to fail early and often so you know how to succeed. To embrace those failures as they make you a better person.
It also shows how asking for help is a sign of strength rather than weakness. Getting help is how we establish and build trust.
There were dozens of great moments throughout, but here are two that really struck a chord.
- When a team dynamic sends the message to each member, "We are together now."
- When a restaurant owner turns to his manager and says, "We know tonight will be a success when you ask for help at least 10 times."
Those statements stopped me in my tracks.
There was so much to take in, it will take a second reading to dig deeper into these fantastic ideas and methods.
I was so drawn in, I'm reevaluating my own work situation. Things have been "off" for about a year, if not a bit longer. Culture Code has shed light to give me a better understanding as to why.
Several years ago, we were a pretty successful company because of the people, the mindset, the communication and the "togetherness" we shared. I felt that when I interviewed, but did't have the language or understanding to articulate it.
Our success lead to merging with another company who, in their sphere, functioned in the much the same way. They had formed their own mindset and togetherness.
We worked great together. Unfortunately, working side by side, "shoulder to shoulder," we don't share the same kind of togetherness. Before we could sort through that, we were acquired by a much larger company. They have their own identity, which doesn't blend with the first two. Both of our cultures and identities have been changed.
- The psychological safety of the original company I joined is gone
- There is no time to ask for help, and no one to give it if you did
- The mindset has completely changed
- The team dynamics have radically shifted
- People are now driven by titles and self-promotion
- People want to be recognized for their individual success at the expense of the team
To that end, I feel my future probably lies elsewhere. I don't feel I "belong" anymore, meaning, the sense of belonging I felt 5 years ago is disappearing. Our culture code has changed.
Sure, it's possible to get it back, if the company at large worked to make it happen. But, we aren't the small company we used to be. Further, we have new demands and definitions of success from on high.
My story aside, Culture Code was absolutely worth reading, even though it was a little depressing. It was hard to acknowledge what was missing from within my company. To see how we used to behave. To look back and see the points where things didn't change for the better.
Yet, Culture Code demonstrates the possibilities. Bad process can be reshaped into success. Seemingly underperforming teams can be given the tools and freedom to recreate themselves into incredibly successful ones. Great ideas don't start off that way, they are formed and shaped through honest feedback and candor.
Culture Code has given me a lot to think about this year. If I truly am to change course and seek out another company, I have a dozens questions to ask of whoever I talk to.
With "team" taking on a whole new meaning under current conditions, Culture Code, will help be a lighthouse for better communication and success as we find different ways of working together.
Other articles of interest:
- Agile will save us! Not if your team dynamic is shit
- 8 Weeks of working remotely, and all’s well
- Too many cooks, too many managers
- At work on a weekend
- Dell wants to be their own company again
- Thank You 2020
- Quarantine Summer Reading List
- Chin up! It could always be worse
- Think twice, delete once
- Affinity offers big discounts and extended trials on Photo, Designer and Publisher
Since we are still hiring and going through the interview process, a disappointing trend has emerged. When asked of their future plans, and where they see themselves, people with very little experience make the claim they want to be a "lead" or manager within a year.
They don't speak of going deep and being proficient in the role they're interviewing for. There is no mention of being the go-to person for help and information. No mention of being a subject matter expert. Taking this job is merely a stepping stone. After checking off a couple boxes on their mental to-do list they will take on bigger and better. Never mind they only have two years of experience in this field.
It's pretty clear their desire is to pretend to be in charge and tell other people what to do, not produce great results they can be proud of and others might emulate. I don't want to work with people like that.
There is nothing wrong with aspiring to take on a leadership role, but it's more than just telling people what to do or thinking you have organizational skills. "My desk is tidy, I can be a manager." "I attend meetings on time, I can be a manager."
I'm not a manager, and have no interest in being one, or a PM, or a Lead, or a insert grand Poobah title here. I've been around for awhile and over my career, I've had some absolutely terrible managers and I've had some horrific product managers, including a PM that finally left earlier this year.
Even now, we have bouts where people take up the mantle of manager and make an absolute mess of things. Their lack of depth and understanding led to multiple missed deadlines. Their total lack of experience made them unable to adjust to changing conditions, time constraints and customer demand. This lead to a lot of team frustration, which ultimately sent a handful of people looking for employment elsewhere.
Before taking up the mantle of being a manager or even a lead, be a pillar of support to the person your current manager and team. If they need help, give it. If they have questions, answer them. If the project is going off the rails and chaos begins to ensue, be the calm voice of reason. Or at the very least, don't get swept up in it. If that's not happening, not management material.
In addition, go deep within your current project, discipline, or area of expertise. Understand what your company wants from a project. Understand what the customer wants. Understand what makes a good UI. Anticipate what features may help them. Know what it takes to stand up a database and the challenges people face. Learn the customer business so you can anticipate problems, offer suggestions and be aware of potential hazards.
Just as importantly, know the people. Understand how they work. Understand what they need to be effective. What are they good at? What are they not so good at? It's more than just strengths and weaknesses. If they're not effective, you won't be.
Even above that, be the perfect manager of yourself. Meet deadlines. Be efficient. Be productive (not just busy). Create methods and process others want to emulate.
We have multiple examples on two specific projects, where there is chaos and disorder because everyone feels they are in charge, which means no one is in charge. There are arguments over how things should be done, people want their process and agenda to be the one that other follow, they don't support each other, they go around each other to get their "priority feature" implemented first.
Even simple things can't be done correctly. During the standup the question is asked, "Does anyone have an update?" That's totally incorrect. Right from the start people are interrupting each other, talking over each other, and there is no sense of leadership. Immediately they're frustrated.
Call on people directly. Establish order and method. "Joe, can you give us your update?"
Another example: we had a QA engineer who got the help of two temporary resources to cover an End of Year process for the customer. Instead of giving them all the information they would need to test, get everyone up to speed, and make the project a grand success, he chose this opportunity to exert himself as a "manager" and held court on how to be an effective QA engineer. Or more specifically, what he thought it took. He's no longer with the company.
But unfortunately, that mentality is quite common.
In the recent past, I've had conversations with managers and project managers that where in effect, "What do I need to do to make you successful? We can either work together and produce great results, or we can work against each and produce some serious crap."
I don't have the answers on how to be a good manager. It's more that I've observed far too many people jumping to the head of the line with ambitions of being a manger, way before they are ready. They have no career capital. They have no depth to their knowledge. They have no previous successes to their name. Yet, they state and feel they should be in charge and have what it takes to manage.
What they don't realize is that there is a massive difference between managing, and leading.
Other articles of interest:
- Building Relationships with Developers
- Agile will save us! Not if your team dynamic is shit
- Culture Code
- Exchange 2010, you confuse me
- Setting up the long excuse
- Building a Development Environment
- Ballmer is asleep at the switch
- Why does everything have to be multiplayer?
- How I Use Scrivener for Journaling
- CopyLess and PopClip Jump Aboard the Party Barge