What makes a good or bad designer, developer, sys admin...

One of the most challenging parts of leading a team is figuring out how you want to do it. In the last year, Chris and I have hired a lot of new, amazing team members. Wildbit is growing, and with that growth we encounter new needs and areas we need to improve. As we add new people, we have to make conscious decisions on how we structure the teams and company. Do we create management roles? Or do we stay flat? Up until this point, the only managers were always Chris and I. As more people come onboard, will we be able to continue in this way?

Turn the Ship Around!

To answer this we have spent a lot of time soul searching and reading as much as we have time for (not easy with a 5 year old and a 5 month old!). Two books made a big impact in helping us structure and plan going forward. The first is Turn the Ship Around!: A True Story of Turning Followers into Leaders, a must-read for anyone leading a team. David Marquet explains how he managed his nuclear submarine, as captain, by enabling his entire crew to be independent. Establish the mission, and then allow the team to execute in their capacity, as they are the experts in getting the task done. This is the best way I can see continuing to stay flat. We are honored to be surrounded by some of the best people in their fields. They know what they need to do, our job is just to help set the course!

The Hard Thing About Hard Things

That solved the first issue, we’re going to stay flat! But how do we then make sure that everyone is doing their part, and that new people know what we expect. Everyone wants to know what they need to do to be successful. In knowledge work that’s often a big challenge. Our jobs rarely have a hard stop. There is always more code to write, more design to design, more writing to write. How do Chris and I help the team feel like they’re doing a great job? How do we help them understand when they are missing the mark? What is the mark? We knew that to make this work we had to write out clear expectations that we all have of each other. And that’s where the next important book comes in, The Hard Thing About Hard Things by Ben Horowitz. This is one of the most influential books for me in the last year, in so many ways. But, for expectations, there’s one section that really inspired Chris and I to do a group project.

At one point in his history, Ben Horowitz was managing a team of product managers. He noticed that there was an inconsistent set of expectations, some PMs were performing well, and others were not. His solution was training, and starting with writing out what makes a Good and Bad product manager. The essay made very clear what defines someone who performs their job to Ben’s expectations, and someone who doesn’t. It’s not a bulleted list, instead it’s a story, describing behavior that one can clearly relate to. We LOVED this, so we set out to create a similar document. However, instead of writing this for management, we decided to write one for each discipline at Wildbit.

On the last retreat in April, we asked the entire team to read Ben’s Good/Bad essay. Everyone then spent an hour writing out what they think makes a good or bad developer, designer, QA engineer, etc. We wanted each person to put their expectations down for their teammates. We then regrouped and read them all out loud. We made comments and put together common themes. Finally, each team (designers, developers, QA, success, etc) broke away, and started crafting their own essay on what makes a good/bad _______.

I’m very excited to share with you all what we have come up with. In addition to our values, we’re going to use these definitions for new hires and for a way to evaluate ourselves. We hope to use these during evaluations, 360 reviews and just throughout our time together to make sure we’re all hitting our marks.

These are all living documents, and will change and be adapted over time. So we’ve made them public, and opened them for your suggestions. You can leave your thoughts as comments in-line on Google Docs. Please help us make them better, and you are welcome to use them in your own organization. Just please reference back the source documents so we can see how you're using them and give more feedback to the community.

In the next few weeks we’ll dive into each one of the documents to really talk about the thought and history that goes into their writing. We hope you will join us in improving the way we evaluate each other.

Comments

Our products