The following is an excerpt from an email I sent to DeveloperTown in March 2017.

I've been thinking about ownership recently. A few months ago I listened to an interview of DHH, where he shared his thoughts on ownership. He's written about it in the past - a short article on assigning blame. I'll summarize DHH's thoughts - it's your fault. 

This is not a new idea. It's a fairly established leadership principle. Blame always goes up the chain of command. If a team is struggling, it's likely because they haven't been given what they need to succeed. I'm a bit of a Jocko fan-boy these days (the podcast is excellent), and in his words (emphasis is mine): 

“On any team, in any organization, all responsibility for success and failure rests with the leader. The leader must own everything in his or her world. There is no one else to blame. The leader must acknowledge mistakes and admit failures, take ownership of them, and develop a plan to win.” 

I also like SmallBox CEO Jeb Banner's short article on the topic. Jeb relates it nicely to agency life - and talks about ownership from the customer's point of view.  From Jeb: 

"Why is it always our (the agency's) fault? Because if the client is unhappy, then we have failed in one, or more, of these three ways: We failed to deliver as promised. [...] -or- We failed to manage expectations. [...] -or- We should have never taken on the work to begin with. [...]"

But it's not always clear how to apply this principle. It's easy to take blame once you get used to it. Taking blame is useful, because once the leader takes blame - everyone else stops blaming each other and they start focusing solving the problem. 

If you read the accounts of the most recent Amazon outage, you'll find that it was caused by someone making a typo at a terminal. A typo - brought down thousands of websites, and likely caused millions in damages. (I saw $150M in one estimate.) Amazon's response (paraphrase)? "It's our fault. We knew that issue existed. We even had a project queued up to put protections in place. We just didn't give it the right priority. And there are likely other steps we could have taken."

Over the years, I've heard Julie talk about assigning blame a lot. When teams get bogged down in assigning blame, they aren't fixing the problem. When you're focused on CYA, you aren't focused on helping your team members resolve the resulting issues. If someone on the team steps up and takes blame, it creates space for the team to focus on solutions. But there's an even better way. Have a team culture that doesn't worry about assigning blame in the first place.

If you behave like you own the outcome - you don't care how we go to this point. You're focused on what needs to happen to resolve the issue and get things back on track. Later, you might want to circle back and figure out what we need to change so it doesn't happen again. But even that's not a focus on assigning blame, that's a focus on fixing what's clearly a broken system. 

Ownership isn't just about blame. Ownership is also about: 

Caring about the outcome. If I own something, my first goal is to finish. To get it done. Deliver the thing that's needed. And not just to deliver the minimum, but to deliver the best version of that thing I can do with the resources (time, money, etc) that I have available to me. And to do it in the timeframe that I agreed to do it in.  

Caring about the quality of the result. This is certainly similar to caring about the outcome, and could arguably be included in that statement. But it's worth focusing on as it's own aspect. When I deliver a thing to you, I own all aspects of it's quality. Even if I didn't do all the work, I'm implicitly telling you that all of the work met my quality standards. 

Caring about the way in which we reach outcomes. In my push to deliver, I can't burn people out. I can't take short cuts that will undermine the long-term value I'm trying to create. I can't change the process - just this one time - because we're under pressure. When do pilots most need their pre-flight checklist? When they are rushed, tired, and not focused. They most need it when they are most likely to want to skip it. 

Communicating progress. If you ask me to own something - and I accept that - then I'm also accepting the responsibly to make sure you know where I'm at in my process of delivering it. It's on me to make my progress visible. If you have to ask me for an update, I've failed. 

Stepping up, without being asked. See something out of place? Fix it. See someone struggling? Offer to help. See a problem down the road that no one else sees or is focused on? Come up with a solution and pitch it to the team. If I own it, no one's going to ask me to do something. I need to know to step up and handle it. 

Giving people feedback. If I truly own the outcome, the quality, and the process - and I'm working as part of a team - than that means I need to be prepared to give the team around me feedback. If you're not meeting expectations, I owe it to you to tell you realtime. If you're deviating from the process the team agreed to, I owe it to the team to step up and say something. If you're a jerk in a meeting, I owe it to you and the team to pull you aside afterwards and say something. Did you know that own and owe come from the same root word? "...before 900; Middle English owen to possess, be under obligation, have to pay;..." Owners (leaders) have an obligation to provide feedback. 

What do you own right now at DT? A project? A process? A story? A feature? A client commitment? Nothing? 

For the things you own, are you stepping up, caring, communicating, and providing feedback? If you aren't, who's to blame? 

The following is an excerpt from an email I sent to DeveloperTown in October 2016. 

As I'm sure you've noticed, the company meeting has fallen off your calendar. We're moving it to once a month. This email provides a bit of background around why we have the meeting, why we've moved it, and what we hope to accomplish with it going forward.

The $115,000 meeting

Let's do some math. We have around 40 billable people right now at DeveloperTown. Let's assume that when they bill, they bill at an average rate of $100/hr. That's lower than we typically charge, but if we use that rate we can assume it accounts for things like discounts, bench time, etc.

If we wanted to pull those 40 billable people into a room together for 30 minutes, it would cost us $2,000. If we then layered on all the other folks who attend the meeting who aren't billable, and what their time costs in hard costs, you might get to $2,300 for the total cost for that meeting. If you hold that meeting 50 times a year, that's $115,000 annually. Gulp.

Do you feel like we got $115,000 in value over the last year? I don't.

While the math isn't really that simple, it's a great little thought exercise. It shows how small things add up over time. And it also illustrates how we've grown as a company. That same meeting, in 2011 would have cost the company something like $35,000 annually.

Spec night, Five Guys, and a company-wide Scrum

Let's go back in time. My memory isn't perfect for things like this, but I'll do my best. If I get some of the specifics here wrong, you can fact-check with ChrisScales.org. Please forgive me if it's not 100% accurate. The spirit of this history is correct.  :)

Our first informal company meeting started happening within the first few months of DeveloperTown opening. We started going out for drinks at Rock Bottom one night a week. It was always a very late night. We'd close out the bar most times we did it. It was a chance to review the week together and share some laughs. It was a completely informal event, where whomever was available and was working late attended.

Our first regularly occurring company meeting was a meeting called DT Pitch Night (sometimes called Spec Night). It also started in our first year, and occurred after hours. We would provide beer and food. Everyone would pitch different product ideas that we considered building as a firm. There were some small firm-wide updates that would happen at this meeting, but it was mostly about pitches and collaboration. Pitch nights died off after about a year. We didn't end up doing most of the projects, so people lost energy. Dave Christiansen morphed them into Hack Nights - which did survive for awhile. But those were much less formal.

Our second informal company meeting took the form of Five Guys Fridays. These all happened in 2011. Each Friday, whomever was around would go out together to break bread. No agenda, just food and catching up. When we switched offices, we tried Boogie Burger for awhile. But it wasn't the same. They died off after only a year of all-day awesomeness.

When we moved to the new building (where we are now), we started our second formal company meeting. You'll love this one. We did a company-wide daily standup, and it was in the classic Scrum format: What did you do yesterday? What are you doing today? Any blockers? This was actually kinda awesome when we started doing it. We were a smaller firm, so it probably didn't take us much longer than it takes the Tyco team to do theirs today. But - as you can imagine - as we grew this became unsustainable. A really great idea, that became a bad idea over time. It died in 2013.

In 2011, we started a meeting called the DeveloperTown Retrospective. Playing off the theme of doing Scrum activities firm-wide, we did an all hands retrospective once a month. This one didn't last long. As you can imagine, it also got too unwieldy as we grew.

Finally, we have the actual Company Meeting. The one we all know and love. It started off in 2010, and it was monthly. Here's one of the early agendas I sent out for that meeting. I found this randomly while doing my history research:

Company Meeting Agenda

1) Quick "state of project" updates

2) Current "active" sales leads

3) Housing Update

4) Financial Summary/Highlights

5) Questions

6) "Get ready to be social."[4,10].sub(/a/,'e').delete('').split('dyto').join.reverse.capitalize

Heh.. I'm a dork.

The format and the frequency for the core company meeting has changed from time to time, but some basic themes continue to come up:

 financial updates
project updates
housing updates (*sigh*)
sales
events
introduction of new team members

What's the real goal?

At this point, you might be wondering what the real goal of the meeting is? Why experiment with so many formats? Why does it change? How did it get to be so ineffective? I think there are a number of reasons why companies like ours hold all-hands meetings:

• Community

• Culture

• Information

• Education

Community

One reason is to build community. That's what you see in Rock Bottom, Five Guys, and Spec Night. Those were community building events, where we got to know each other. I see Peter Lockhart about three times a year, and each time I see him I kinda want to hug him. That's how close we were as a team.

Going out for burgers is a great way to build community with ten people, but it doesn't work with 50. Don't get me wrong, it's huge when Julie or Korey organize a cookout. And I know the marketing team has a regular monthly outing. But it's almost impossible to recreate that level of intimacy when you reach our size. Donuts and Kolaches on a Monday morning just don't cut it. I want them to, but it's not the same.

Community is also built when you know who everyone is. It's intimidating to join a new company. And I think our company might be more difficult than most if you're new. I suspect houses don't help when you're first trying to get to know people. Having people introduce themselves is one small way we can help folks start to get to know who the new folks are. And at a minimum, you know you'll get a chance to run into everyone at least once a week.

Culture

Most consulting firms take steps to recognize top performers. It's not always by calling them out publicly at a meeting, but recognition is an important part of building the culture you want. By highlighting the behaviors you want others to exhibit, you can signal to the rest of the team what are viewed as effective behaviors.

The company meeting is also where we (the leadership team of DT) get to visibly show who we are. There's something special about watching Jason Vasquez do live coding. I think in that company meeting you could see how approachable he is, how humble he is, and how measured he can be with his responses. I don't think he could effectively communicate those traits through email or Slack. You need to see those traits in action - interact with them. For most of us, when will we have time to do this with Jason outside of the company meeting?

Information

I think we'd love to do open book accounting. We've flirted with it over the years. It turns out it's really hard to do. It takes time, attention, and consistency - none of which Michael or I possess. :) So it just never happens. But we've always been fairly open with the financials here at DT. We think that's part of building the culture we want - where our consultants understand the core numbers and metrics that move businesses.

We also think people want to know what each other are working on, and what future projects are coming that you might get a chance to work on. It's fun to hear stories about what others are doing. It's nice to see something cool, and say "Wow! We built that?" Sharing project results and sales efforts can help build pride in the work that we do. Hopefully that helps with retention - and helps keep folks motivated even when their current project maybe ins't the most exciting.

Education

One of our values is Level Up. While that's about you as an individual getting smarter, better, faster, it's also about us as a firm getting smarter, better, faster. How do we actually do that? It's easy for any one of us to pick a topic and get better at it. But how do you move a firm to change? How do you roll out something new company wide? How do you introduce a new idea?

One of the things you've seen over the last year was an experiment to give each team focused time to dive deeper into their practice area. This resulted in educational and working sessions focused on trying to level up the company. I think we had some winners and we had some losers. It's a hard thing to be entertaining and enlightening at 9 AM on a Monday morning when people are still rolling in ten minutes late and you can't hear more than ten feet away.

Fixing what's broken

I'm aware that many people are frustrated with the current meeting. There are good reasons why we try to hold the meeting, but they are (currently) ineffective. We can do better. We will do better.

Here are some of the changes coming, and why:

1. Moving to Monthly: The meeting will be going back to once a month for 45 minutes. This is partially due to physical logistics - we're going to do a venue change. But it's also because we want to spend more time prep'ing as management team. This should hopefully translate into more crisp and meaningful content.

2. New Location: We're going to try to hold the meeting in the Starts space (2nd floor - big blue building). The goal of the venue change is to make it a bit more of an intimate setting, and to make the remote experience better. This should make acoustics all around better for all.

3. New Format: We're going to experiment for a bit, but the idea is to lock into a fixed agenda for topics going forward. No more team-specific meetings. We'll move back to a standing agenda format. (Have some patience as we attempt to settle into a routine.)

4. Meeting Notes: I haven't decided if this will be actual meeting notes, or if Aaron and I can rig up a recorded version of the meeting based on fancy new technology. Either way, if you miss the meeting - we will have either the cliff notes version available for you, or a recorded session you can watch in between episodes of the Walking Dead.

5. Better Participation: This is where you come in. As a leadership team, we're going to up our game. Here is where I ask you to up yours. Participate. Get there before 9 AM. Try to engage with the topics - when appropriate. Be supportive. Not asking for you to become a cheerleader. Just asking for you to engage in the same way you would if a client were in the room.

We have a number of methods of communication: company meeting, team meetings, these emails, newsletters, etc.  Our goals for the company meetings are (in this order) Community, Culture, Information, and Education. The first two only happen with your help. The last two should start to go up in quality now that we're back down to monthly.

Looking forward to seeing you at the company meeting on the 10th.