I really enjoyed John Doerr’s TED Talk on OKRs:
However I found the Google OKR playbook to be extra helpful. I have not used OKRs in the past but found the challenges with them to be well enumerated in this Google document.
Team managers are expected to assess the resources required to accomplish their aspirational OKRs and ask for them each quarter, fulfilling their duty to express known demand to the business. Managers should not expect to receive all the required resources, however, unless their aspirational OKRs are the highest priority goals in the company after the committed OKRs.
In some ways the magic of OKRs appears to be that everyone in the organization is setting their goals and resources are being allocated in the same way. The act of writing goals down in a big organization and having folks at the top write their goals down before the folks that are individual contributors helps create alignment. OKRs are a two way street. If the folks at the top are not doing them, then it makes it much harder for folks at the bottom to write OKRs that are in alignment with the goals of the organization.
One of the biggest cultural transitions from working a political campaign to working in government and running Code for Boston is that I am no longer surrounded by Type AAA personalities that all want to be leaders. When I worked for the Connecticut Democratic Party you would go to a meeting and folks would fight for their ideas. There would be a battle for the floor in meetings. People would press each other to make decisions. This difference in personality brings a lot of strengths to the group. Empathy, compassion, and openness. However it also leads to one pattern that is very challenging: the punt.
The punt is paralysis. When a group of people are charged with making a decision and do not know the answer they can be quite skilled at not making a decision. Sometimes it is to avoid conflict. They do not want to appear to disagree with others and upset the group harmony. Other times they do not want to take on the risk of advocating for a position that later fails. The punt happens when an email is ignored. A decision can be tabled at a meeting. Discussion happens but a conclusion does not. Suddenly the group lacks a mandate or direction.
Solutions to the punt can vary. You can simply charge ahead. However you risk wasting time and effort if the group does not follow through. If the folks in charge are the ones punting then there is not much you can do other than press them on making the decision. If you can find urgency to force a person or group to make a decision then they will do it. Otherwise the punt may simply be a pocket veto. Often times folks are too afraid to say no to something so they punt instead. In politics they teach us that maybes are often the same as a no (and a yes can be a maybe).
My favorite way to handle this is the Jeff Bezos’s disagree and commit framework:
Second, most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.
Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
The punt is a challenge I still am trying to find good patterns to surmount. However I am a strong believer that making clear decisions quickly often is a better alternative to making decisions later.
An interesting insight from Annie Lowry at the The Atlantic:
More than that, Iowa’s tight labor market has forced employers to offer training, reach out to new populations of workers, and accept applications from workers they might not have before — expanding and up-skilling the labor pool as a whole as a result. “Their attitude really seems to be changing,” said Soneeta Mangra-Dutcher of Central Iowa Works, a workforce-development nonprofit. “They are looking at populations differently, who they they should be looking at when they have jobs to fill, or people being screened out for things that really don’t have an effect on the job.”
Often times “we cannot find the right worker” is simply code for “we are not willing to pay the right worker” or to train them.
When we run Code for Boston the majority of our new members find our group on Meetup and do not have a great understanding of who we are or are. In order to help people understand what we do we run an orientation session for all the new members. It helps them understand our organization and how we work. We spend most of this orientation explaining what we do, but we also spend a good part of it explaining what we do not do.
The main thing we disclaim expertise in is teaching people to code. The reason is that people who are good at coding are not necessarily good at teaching people new to coding how to do it. Furthermore most of our members do not show up to Code for Boston hoping to teach others how to code, but rather to contribute to a specific project. There are different phases of learning and we are good at taking folks who have taken a boot camp or gone through their own tutorial and project and helping them learn how to contribute to software projects in a group setting and give them an opportunity to be mentored and learn from peers.
Another thing we know we are not skilled at is marketing and user acquisition. Although we may have some members with skills in those areas, most of our members are not MBAs. So we get around that barrier by making sure our projects partner with a government or non-profit that has an existing user base they can reach out to. We often tell people that our best projects “help the helpers” do a better job. I have yet to find a marketers for Boston that can help us with this part of the equation but whenever someone wants to collaborate with Code for Boston and thinks that we’re going to bring the users, I usually warn them that is not the case.
These are not the only things we do not do well, but it is always helpful to understand some of the things we do not do well so that partners and participants are not disappointed. It also helps us shape our projects to work around these barriers and find partners that can help with that. We also see these as future opportunities for our own growth. It is clear to me there is demand for workshops so we are working on putting together workshops on topics like data science so people can learn more skills and participate in future projects.
I thought that Mark Headd had an interesting tweet yesterday:
This tweet gave me a few thoughts from my own experience that I shared:
After a couple legacy app rewrites (not from mainframes but old Python Django —> Rails) you quickly learn how tough it can be when the best you can do is “match” what was there before. Apple still has whiplash from Apple Maps and that was years ago…
Things I’ve discovered about legacy software:
- Undocumented functionality is discovered by users. Turns into an “important feature”
- Users map their own abstractions into the existing system as the real world system changes but software stays stagnant.
Also after writing software on a rather stressful deadline for a City of Boston project I expected it to get junked after. Instead they opted not to rewrite. It’s not the best code I’ve written, but it was battle tested. Never realized how important that was until gov’t.
Ultimately rewriting legacy software often “feels” like the right thing to do but the distance of the rewrite feels like it is less than it actually ends up being once you attempt to do it. It is not that it is never worth doing a rewrite, but the value of the rewrite often is less than you initially think it will be.