Leading up to today’s discussion, we have talked about the psychological safety, and dependability of the Aristotle Project. Today, we tackle structure and clarity. We discuss a statement that lists understanding of job expectations, the process for fulfilling them, and knowing the consequences of one’s performance as important pillars for team effectiveness. We unpack OKR goal setting, how this enables individuals flexibility in choosing how to reach a predetermined goal, how OKRs can add structure and clarity around roles and responsibilities, and how setting team OKRs can create a danger of ‘bike shedding’, which isn’t a problem in individual OKR setting. We close with the suggestion that each person writes their own OKRs in order to create even more structure and clarity around their job expectations. We hope you join us today!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 223. Aristotle Project - Structure and Clarity
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez. Our producer today.
[0:00:09.2] WJ: William Jeffries.
[0:00:11.5] MN: And the intern.
[0:00:13.2] SC: Sophie Creutz.
[0:00:13.8] MN: Today, we’re talking about the Aristotle Project, specifically the structure and clarity portion. I believe this is the third part of the Aristotle Project, the list of five things we went over psychological safety, dependability and now, we’re doing the structure and clarity. Does everyone here have structure and clarity and in today, in the podcast episode we’re recording? I’d love to know before we continue moving on?
[0:00:44.7] WJ: Crystal.
[0:00:45.2] MN: Crystal.
[0:00:45.3] SC: Crystal clear.
[0:00:47.8] MN: Solid also. We’re going to start with the definition as mentioned in Google really quick in the document that we’ve been reading over the rework. I think it’s recall on work, I’m not sure if there’s a specific name for this particular document. It reads the following: An individual understanding of job expectation, the process for fulfilling these expectations and the consequences of one’s performance are important for team effectiveness. Any thoughts on that?
[0:01:19.8] SC: Wow, yeah, can we break that down a little bit because we’ve got understanding of job expectations so yeah, what am I expected to do in my job? What things do I need to prioritize and not prioritize? Then for the process for fulfilling these expectations, I take that to mean, how do I make sure I’m actually doing my job and meeting those expectations?
Presumably, this means that there is actually process in place that maybe there’s some kind of rubric so that you know that you're meeting the expectations, what do you think, Bobby?
[0:01:58.9] MN: Yeah, I imagine, because then like, how do you know whether you're doing the job correctly or not, right? First off, you got to know the job that you have. I think we mentioned off air that our job is to punch keys, right? I think it’s more than that.
[0:02:15.1] SC: If you boil it down.
[0:02:17.3] MN: If you boil it down, yeah, yes, monkey punch key, right?
[0:02:21.8] SC: Yeah, if you put those developers in the soup and you just put it on simmer, ultimately, what you're going to get is key punching.
[0:02:30.0] MN: Is key punching, exactly.
[0:02:31.6] WJ: There’s a book called, The One Minute Manager and in it they talk about the – this notion that a job should be explainable in one minute or less. The job description should be like one paragraph and your – actually, the employee should be able to explain back to you what their job description is in a minute or less and that’s how you know that everybody’s on the same page and that we have the structure and clarity that we need.
[0:02:54.6] SC: This is an interesting point though because I would wonder then, what is the minimum amount of time that you should take to describe your job, right? If a minute is the maximum, what’s the minimum? Because if you just said, “Oh you know, I’m a code monkey” or if you’re a teacher and you just said, “I say things to children” that wouldn’t be –
[0:03:17.6] MN: I speak to children all the time, I yell at them.
[0:03:24.6] SC: Right, quite descriptive enough. Yeah, how can we make that clearer perhaps?
[0:03:31.2] MN: I think the one-minute mark that William mentioned, I would say – I mean, I don’t know, I don’t think I read the book, maybe I should go and pick that up but I would say, it has to be close to a minute. It can’t be just one sentence either but it should be closer to a minute, right? A teacher for example would be, “I instruct children on a particular given topic.” The goal of that is to ensure they’re able to internalize and understand the thing that I’m trying to teach.
[0:04:02.0] SC: Yeah, very nice.
[0:04:03.1] WJ: I think as a heuristic, you probably want the employee to feel comfortable, that they understand what it is they’re supposed to be doing on a daily basis without having to constantly check in for guidance. You want the manager to have confidence that the employee is actually going to be working on the stuff that they need to be working on. That they have enough direction to actually be productive in moving toward the objectives that the company has set out.
[0:04:30.0] MN: I see.
[0:04:31.9] WJ: What makes that challenging is one minute requires a fairly high degree of focus because it’s easy to say, “Oh yeah, you're multi-talented individual, why don’t we have you help with recruiting and also interviewing and also, architecting a system and also fixing the test suite and also doing some performance testing” and also, and also, and also.
[0:04:56.1] MN: The startup life developer though.
[0:04:57.6] SC: I was just going to say, couldn’t you argue that in a startup, you have no option but to wear that many hats?
[0:05:04.5] WJ: I think so but then you probably need that to be clear for the employee when you go to hire them. The job description should probably make it clear, when we say, code monkey punching keys, my hands are typing words, we don’t actually mean that they only thing you’re going to be doing is writing code. This is a startup and you’re going to have a million hats and we don’t even know the work that you’ll be doing yet because it hasn’t been defined.
Maybe you’ll be interviewing or maybe you’ll be doing performance testing or maybe you’ll be trying to fix production and that’s part of the job description and something that might be exciting to you if you like working at startups or, it might be terrifying if you hate that.
[0:05:48.0] SC: Yeah, I am wondering too about the last part of this definition here, where it says the consequences of one’s performance are important for team effectiveness. In some level, it seems like yes, perhaps it’s obvious that your performance, if it’s good, it’s going to be good for the team and if it’s bad, it’s going to be bad for the team but do you think there’s more there?
[0:06:12.0] MN: I didn’t take that as it being more, it’s just like all their goals and there are anti-goals and once you kind of identify what the anti-goals are in you’re aware of them, then you know what it takes to be effective within your team.
Not that like, “Hey, if you don’t do a good job then you lose out on a bonus” but it’s more like, “Hey, your job isn’t to do these things because if we were to do that, then we get this.” It’s not like, decent dividing someone by telling them what the consequences are, just knowing that they exist. That’s why when understanding your job description it is important for us to move forward as a team.
[0:06:53.1] SC: Yeah, that makes sense. I think you used the words anti-goals there. What’s a good example of an anti-goal? Don’t bring octopi into your meetings?
[0:07:03.8] MN: That is one. I’m trying to think of one really quick, what comes to mind. Say if the job description requires us to be consultants and at clients, an anti-goal would be maybe try not to be too prescriptive and demanding on processes that you want to see change because the team may not jell well with that and could cause disruption and rift. It's what comes to mind, I don’t know if anyone has any better ones, love to hear it.
[0:07:36.6] SC: yeah, I mean, that makes sense as an anti-pattern, make sure that – because the anti-pattern would be communicating in a way with the client that makes it harder for everyone to work together it seems like.
[0:07:52.4] MN: Right. There’s a section here that talks about in the structure and clarity bullet about Google using OKRs. To help set and communicate short-term and long-term goals and I kind of want to dive into that. First off, what’s an OKR?
[0:08:10.8] SC: Well, first let’s say what it’s not, so perhaps it’s obvious keyword ramifications.
[0:08:20.6] MN: There you go, it’s definitely not that for sure.
[0:08:24.0] SC: Opportunistic, the K is challenging.
[0:08:29.8] WJ: Crinkly? No, that’s a C.
[0:08:35.4] MN: It stands for Objectives and Key Results. I personally am not too familiar with OKR, I don’t think I’ve ever had the opportunity to set them on my team in this fashion of OKR, I know it’s like some goal setting that we would do but I know there’s a process that I’m kind of unfamiliar with. William, you mentioned before in time that you may have done a thing or two whether it was on the past.
[0:08:57.6] WJ: Yeah, I’ve done OKRs before on several projects was that organization based or was that team based. You had like a C-suite usually coming up with the objectives for the organization, which were more constant and needed to tie into the mission for the organization in some way and then the key results were the thing that you mostly were negotiating over and leadership from different teams would be in charge of thinking what those would be and then the team would be accountable for delivering those key results.
As an example, achieve physical responsibility, that could be an objective. You could have some key results around that like, we need to reduce the general fund budget variants from 11% to 5% or we need to spend 95% of authorized capital project dollars by the end of the fiscal year, et cetera.
These are some specific things that a team could do in order to achieve physical responsibility which is the overall objective that leadership has decided on. What’s nice about that is that you have leadership guiding all of the teams in a single direction using the objectives but then the teams get to still be able to negotiate exactly how they deliver on that and there’s a fair amount of leeway for individuals to choose how to hit the goal.
For example, if you’re going to reduce the general fund budget variants from 11 to 5%, there’s a million ways to skin that cat, right? You as an individual can look at what is in the general fund budget and decide where that reduction in variants is going to come from without having to consult anybody in leadership.
[0:10:41.6] SC: I’m curious though, just to play devil’s advocate here. What if there’s a disconnect, right? You have these objective coming from leadership but what if they’ve not considered enough all of the day-to-day tasks that the team members have and their priority isn’t their job responsibility so that when it does finally trickle down to that level, you might find that it’s very difficult to find ways to meet this objective as a result.
[0:11:13.4] WJ: Yeah, I think one thing people talk about is the concept of rocks. If you have a quarter, there’s a lot of stuff that can fill your time, a lot of little things in particular. The stuff that’s urgent but not important, the phone call that you need to return or the email that you just got that can be a distraction from the key –
[0:11:32.2] SC: That Slack message perhaps.
[0:11:34.0] WJ: Yeah, exactly so what they say is the really important stuff should be like rocks, those go in first and then everything else is sand. It can fill in the space around the rocks but if you put the sand in first then you’ll never fit the rocks in because the sand will take up all of your time and energy. When you are working with OKRs you have to acknowledge that most of the stuff that teams are actually doing is probably not going to be super directly related to the OKRs because there is day-to-day work.
Accounting needs to do the books, there’s like engineering needs to fix the bugs and product needs to design the inter fit, whatever. Everybody’s has got lots of day-to-day work.
[0:12:17.6] SC: Yeah, so then in this metaphor, is the day-to-day work the sand or the rocks?
[0:12:24.1] WJ: The day-to-day work that is unrelated to the OKRs would be the sand, so there is an outage. Whatever you are working on relating to OKRs stops, you need to go fix the outage, right? But the OKRs are primary, that’s the thing that you’re working on by default.
[0:12:41.6] SC: I guess ultimately, if you are solving the outage like that is related to the OKRs too perhaps because an OKR might be something along the lines of, okay, let’s say it’s accelerate product revenue growth. Well, certainly there’s not going to be any acceleration happening if everything is down in the first place.
[0:12:59.3] MN: The page is down.
[0:13:01.1] SC: Yeah.
[0:13:02.9] MN: I imagine these OKRs in Google sense is that you would have team or personal OKRs for yourself as oppose to that being instructed by the organization and I imagine OKRs are written differently and not like smart goals for example just in the way that you like them, you write the very big rock like sentence and then you fill it in with the sand as well as you mentioned before. I definitely would think that that will add some structure to an individual and the team, which means that it will add structure to the team itself.
Everyone is clear at the goals at hand and their roles and responsibility and they’re able to exceed expectations in the work that is asked of them on the team.
[0:13:56.0] SC: For sure. I wonder though when you get down to the team level of OKRs or individual OKRs if this is the place where bike shedding might rear its ugly head.
[0:14:06.2] MN: Yes.
[0:14:07.0] WJ: What is bike shedding?
[0:14:08.5] SC: Well, okay so bike shedding, if you’ve ever thought about building a bike shed, right? This is not probably the most complicated thing you’ve ever tried to build especially if in comparison to building a bike shed say you are building a power plant, right? You’re going to approve the power plant right away. Yes, we’re going to build the power plant and then we’re going to go from there but with the bike shed, since there’s – everyone can have an opinion about the bike shed. For instance Bobby, what do you think we should choose for the color of the paint?
[0:14:40.7] MN: Definitely orange, orange is my favorite color and everyone should see my favorite color on this bike shed for sure.
[0:14:46.9] SC: Well, I have a different opinion. I think maybe it should actually be blue because blue is a beautiful calming color.
[0:14:56.0] MN: Right and you want people to be calm when they go to the bike shed. That’s the idea.
[0:15:01.3] SC: Yeah and also, how many bikes do you think we need to be able to fit in the bike shed and what sort of support beams should be in the bike shed and what shape should it be? Should it be hexagon? Should it be a square? Should it be a rectangle? Personally, I think maybe a hexagonal bike shed would –
[0:15:24.7] MN: Would fit more bikes I guess, there’d be enough space in there.
[0:15:27.5] SC: Perhaps it would, right? Because you could kind of, align bikes along each side there.
[0:15:32.3] MN: Each side, yeah until it gets to the middle.
[0:15:34.2] SC: Right, it might be hard to get the bikes in and out but yes, I’d take your point.
[0:15:40.0] MN: The idea of bike shedding is yeah, going on finding the nuances of the small things to nitpick at versus solid or more direct goals that you may have and you definitely want to avoid bike shedding in terms of goal setting I imagine on this that there is a lot of people who may have a different set of goals and those goals should be pertained to you as the person who are planning to achieve those goals.
[0:16:08.4] SC: Yeah and I mean not only definitely think about how does this goal pertains to me but think about it in context as well, which is kind of hard to do when I think maybe that is where the bike shedding could occur and it is really quite an interesting phenomenon I think. I’m sure you’ve witnessed this, right? It’s as soon as you’re discussing something where everyone is capable of having a strong opinion, all of a sudden it becomes so difficult to reach an agreement.
[0:16:40.1] MN: Right especially when more people are in the room. I think yeah and definitely if you are going to do the team based OKR that is definitely be mindful of other people’s opinions and how do you incorporate that into something that does not go down this rabbit hole of bike shedding and ensuring that you pummel the opinions out but definitely less likely to happen if you were going to do personal OKRs right?
Because it’s either the opinions that you have and goals you want to set or the direct before your manager who identifies these are some goals that one may have, right? That’s much easier to less likely to bike shed if you will.
[0:17:21.2] SC: Yeah, so guess maybe what would be an objective that would prevent us from bike shedding about the color of the bike shed? Maybe it’s create a bike shed that houses X number of bicycles and then the color of the bike shed becomes much less relevant than the shape or the size or the capacity or something like that. This is just an example though.
[0:17:48.1] MN: Right.
[0:17:49.3] SC: But I think it is interesting to think about this color theory because color is something in this metaphor that everyone is qualified to have an opinion about.
[0:18:01.2] MN: Right, if I have to think of a programmer’s perspective like, “Oh, you need to be able to type 45 words a minute.”
[0:18:07.8] SC: There you go.
[0:18:08.5] MN: As a goal, right? Where did that number come from? Is the question at hand and people are like, “No, you need to know how to type 60 or 85.”
[0:18:16.7] SC: I mean, I do think 60 is the minimum but I don’t want to be prescriptive.
[0:18:21.9] MN: Exactly but that is the thing though right? Does typing at a certain speed truly make you a software engineer or a consultant that’s the –
[0:18:30.3] SC: Oh, what a question Bobby.
[0:18:32.5] MN: Yeah, I mean people’s got opinions. I’m not trying to be spicy, I’m just trying to be – try to bring some examples here but that’s a team goal, I would revisit that like, “Hey, everyone on this team needs to type 65 words a minute or you’re out” where you’re like, let’s not do that for sure. I am sure there are other things that we can do as a team to increase – I mean to have this goal setting for our OKRs.
The other thing that’s mentioned is you should be missing some of your OKRs. I read this and I get like a little off because this is like, “Oh, I want to be able to write goal that I know.”
[0:19:08.4] SC: That I can meet.
[0:19:09.7] MN: That I know that I can meet or make them challenging but still be possible to attempt them because if you are missing some of your OKRs or you are not aggressive enough, you make new ones each quarter, right? It’s the North Star that’s guiding you personally or your team not in achieved or you’re fired kind of thing.
[0:19:30.7] SC: Yes, it’s just a directionality kind of thing. This is the direction that you want to go although I could see how potentially that could be a little dangerous because then people might start to think, “Oh okay, well I am not really supposed to achieve all of these so am I really supposed to achieve any of them, you know? How am I supposed to set my expectations clearly?”
[0:19:51.1] MN: Right, I guess it’s the objective is to as we mentioned in the past, that it is the North Star that’s guiding you so you tend to probably continue to use that North Star as you start getting your key results in under your objective but I agree it’s like I would potentially – I personally like smart goals where it’s like you know, you have them short and measurable and you can say you’re going to do this and this time and there’s a plan for you to attack that particular goal and then you go on and do it.
OKRs is kind of unfamiliar with, maybe I will give it a try and I’ll probably have to write my own personal OKRs that’s what’s going to happen. I’m just going to have to do that.
[0:20:33.3] SC: Got to write some personal OKRs.
[0:20:35.3] MN: Yeah and see how that works out for me. I’ll add some structure and clarity even more structure, even more clarity to the job that I do now.
[0:20:47.2] SC: Sounds great.
[END OF INTERVIEW]
[0:20:48.6] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Michael Nunez on Twitter
David Anderson on LinkedIn
