Scott Parker
Scott is a generally okay human
He writes on this website sometimes
scottparker.co
I’ve been reading THINKING FAST AND SLOW by Daniel Kahneman. There is a real risk this blog temporarily becomes flooded by small bits from this fascinating work.
It includes this really interesting tangent on the possible role of emotion in making good decisions. From the author:
Neuroscientist Antonio Damasio proposed that people’s emotional evaluations of outcomes, and the bodily states and the approach and avoidance tendancies associated with them, all play a central role in guiding decision making. Damasio and his colleagues have observed that people who do not display the appropriate emotions before they decide, sometimes because of brain damage, also have an impaired ability to make good decisions. An inability to be guided by a “healthy fear” of bad consequences is a disastrous flaw.
(emphasis mine)
I really need to dig into this further. This correlates with a number of software engineers I’ve worked with who often try to discount or deny the role of emotion in their work. As a result they make sub-optimal decisions, often because they can’t rationalize how that decision will impact the humans who intersect with these decisions.
When coaching leaders on big decisions, I often say something like “If you’re not scared, you’re crazy.” Usually this is meant to reassure and build confidence. Perhaps there is a deeper truth here though.
Friends know that I endlessly talk about team values. They’ve made a huge difference in my career - I still have a framed copy of Obtiva’s values next to my desk (complete with our Big Hairy Audacious Goal courtesy of Dave Hoover).
Many organizations capture their values in fancy signage and slide decks. Typically they become something of a joke, a bar bet to see if anyone can name more than 1 or 2. How do you make these values stick in a way that helps new hires understand what it means to be successful in your team though?
Your onboarding process is the ideal way to start that journey.
I love this description of Toyota’s onboarding from Kim Scott’s Radical Candor:
Wanting to combat Japanese cultural taboos against criticizing management, Toyota’s leaders painted a big red square on the assembly line floor. New employees had to stand in it at the end of their first week, and were not allowed to leave until they had criticized at least three things on the line.
Toyota combines two powerful learning techniques to make sure employees learn this critical value:
You can imagine an alternate universe where new Toyota hires sit through a presentation with a slick graphic encouraging them to “question everything.” I’m guessing these employees don’t need such a presentation though - they’ve already lived it.
Another example from a totally different company: one of Reverb’s biggest competitive advantages is a culture that expects everyone to care about the product deeply. To that end, they developed what they called “The Contest” - all new hires are given a budget and told to buy and resell as much inventory on the site as they possibly can. By the end of your five weeks in The Contest, you understand the product’s strengths and weaknesses firsthand. They even hand out bonuses to people who make suggestions on how to improve the product from the contest.
In both cases, employers have identified what they value most in their employees and have incorporated those values into an engaging, hands-on onboarding processes. New employees have no choice but to learn and demonstrate the company’s core values.
If your team isn’t finding a way to turn your values into action through your new hires, you’re missing a huge and early opportunity to convert good hires into good hires for your company.
Let’s say you only have 5 minutes with one of your teammates to answer the question “How satisfied is this person with their job?” What do you ask and what do you look for?
Of course many readers immediately reject the premise at this point. I know – ideally you get more than 5 minutes for these kinds of checkins because you’re proactively scheduling skiplevels and other forms of soliciting feedback. Let’s just hypothetically assume that perhaps your planning and scheduling don’t quite go to plan. I know this definitely never happens to you but it certainly happens to me on a regular basis.
So what do you do with those five minutes? What do you look for?
When I have only a few moments to check in with someone, I look for indicators of what I consider the three pillars of job satisfaction:
In a deeper conversation like a skiplevel, there are many other things I look for about their career and their relationship with their manager. When I don’t have much time though, these three qualities are often a leading indicator of all sorts of problems.
I define utilization as “the mapping of your job to your skills and interests.” While this isn’t always the same as utilization from the business’ perspective, it’s a useful proxy to gauge how motivating an individual finds their work.
I list utilization first because the other pillars take a backseat when there are problems. If I value myself as a designer but most of what I do is backend coding, I won’t feel well-utilized regardless of how much I’m growing or making a difference.
Utilization can also swing too far in the other direction, feeling over utilized. This generally means someone has a work-life balance issue or has to juggle too many competing demands for their time at work. For most people this is just as serious a problem as under utilization.
If someone’s skills are well-utilized, the next pillar of satisfaction is growth, the rate at which they acquire more skills. This should be a key motivator for virtually all members of the team. If it isn’t, you have a deeper problem than someone’s satisfaction.
Growth is also a reasonable proxy measurement for challenge. This is particularly important for high-performers - they often report a lack of growth when they aren’t feeling appropriately challenged.
The last metric I look for is impact – whether they feel their work makes a difference. Even if you are growing and well-utilized, feeling like your work has no impact is a sure path towards burnout. The root causes of this can be everything from organizational communication problems to challenges outside of work. Finding an impact problem rarely presents an immediate solution, but it directs you where to keep digging.
Assessing impact can be particularly important for spotting burnout in newer engineering managers. These folks are often still coming to terms with the transition from maker to manager. They can feel like their new workload lacks the same visible impact as shipping code to production.
Digging into impact can also reveal problems even when someone believes their work makes a difference. Sometimes, an underperformer will still believe their work is making an outsized contribution. This is a sign that feedback mechanisms are broken - perhaps they aren’t getting enough feedback or aren’t interpreting it correctly.
I would hazard a completely unscientific guess that these three factors cover about 75% of the typical satisfaction problems in an engineering organization. The remaining 25% is a myriad of issues which are specific to the individual and the organization. Typically those are only uncovered by deeper conversations though.
In time you’ll find your own ways to dig into these pillars and perhaps come up with a different three. My set has evolved several times until I landed on the three here. Regardless, it’s important to have a consistent gauge for happiness and to make sure you have the opportunity to dig into each team member’s satisfaction whenever you can.
Many new managers define 1:1 meetings as something like “a regular opportunity for a manager and their direct report to check in.” That’s a fine starting point but it misses out on a significant learning opportunity for leaders of all skill levels: the peer one-on-one.
Used effectively, these conversations can be a catalyst of growth for you and your organization.
Let’s start with a totally incomplete list of what an effective manager covers in a typical 1:1
When you’re still a full-time maker, limiting these conversations to you and your manager is very effective. Your manager has a high degree of impact on your challenges and context on your work.
This degrades as your scope grows within your organization. Your manager’s context decreases as they delegate more and more to you. The onus for solutions falls increasingly on your shoulders just as your key ally is less able to help.
If this sounds familiar, you need a peer one-on-one. These are periodic checkins with the closest person you have to a peer. In a large organization that might be an actual organizational peer. In a smaller organizations that might be a senior engineer on another team, a manager in another department, or a management coach.
This is easily the most common question when I suggest these checkins. The answer might seem counterintuitive, but it’s the exact same list of topics I outlined for “normal” one-on-one meetings.
While your peer might not have the same context and assistance that your manager can provide, there’s a few other benefits that your manager can’t provide so easily.
The biggest is that these meetings can be a safe space for a variety of topics you may not feel comfortable bringing to even the most supportive managers. This might include getting feedback on half-baked ideas or asking “how would you solve this” questions of your peer. If you share the same manager, these peers can be an invaluable asset in helping you understand your manager and “manage up” to them.
Peer one-on-ones have also addressed one of my biggest challenges of leadership: finding safe opportunities to vent. Leadership can be a lonely and isolating job - it’s inappropriate to vent to your direct reports and it can be dangerous to vent too much to your own manager. This leads to keeping your frustrations and challenges bottled up. This allows them to build over time into major problems for you and your team. Peer one-on-ones create the space to talk about these frustrations with someone who understands (and perhaps even shares them.)
Starting these checkins can be intimidating - you have to make yourself vulnerable to a coworker in a way which feels like asking someone out on that first date. Just like that though, the best way to ask someone is just to ask them.
Until you’ve had enough of these meetings to find your rhythm, it can feel a little awkward at first. Push through that - learning to be vulnerable as a leader is a huge skill that pays dividends over the long-term.
Just like all one-on-one meetings, the cadence and structure will vary as you find what works. Having these conversations offsite can help reinforce the idea of a safe space separate from work, but find what works for you.
When I moved into director-level management at Braintree, I did so with one other person, Pedro. We started these checkins out of necessity as we each went through the journey of figuring out what our jobs actually were.
Pedro and I kept these meetings long past the point where we understood our new roles. They became opportunities to get feedback on our plans, discuss performance issues in our organization, and sanity check reactions from our teams or stakeholders. Without intending it, these meetings were catalysts for each of us.
It also had other unexpected benefits. When a crisis came up in Pedro’s organization while he was on paternity leave and his manager out, I had the context from these conversations to drop everything and cover for him for a week. This would have been a rough transition for all involved if we hadn’t been spending an hour every other week comparing notes.
These checkins aren’t just for peers in the traditional sense as well. I’m a huge fan of these 1:1’s with my product partners as well. At Reverb, these checkins helped Engineering & Product stay aligned and keep our people unified as one product delivery team.
I hope this has convinced you to start these checkins of your own. If you have any questions or concerns about finding the right partner or starting these conversations, let me know in the comments below. If you have additional tips or insights from these checkins, I’d love to hear about that as well!
Here’s a fun fact about my career: in almost a decade of working in Ruby, I’ve never been paid to write rails new into a console.
At Groupon and Braintree I’ve helped build some of the largest and longest-lived Rails monoliths in the world. As such, I’m sometimes asked for advice on writing Rails code that lasts.
Someday I’ll write more on this subject. For now my definitive answer is my last talk at Ancient City Ruby, “Ancient Rails”
I’d also be remiss if I didn’t link to this excellent series on the topic from Braintree’s original CTO, Dan Manges, who had a major role in many of the things we got right.
In a recent coaching session, a manager said of a teammate “Why can’t they follow my example and act more like me?” It’s a natural desire but an effective manager has to recognize a hard truth: leading by example doesn’t work, at least not the way we expect. That’s not to say we shouldn’t use it, but as managers we shouldn’t expect any behavioral changes in others based solely on how we conduct ourselves.
Bummer, right? Why is that?
Leading by example leans hard on the assumption that your audience actively wants to emulate you. Even if I admire your work, there’s countless reasons why I may not want to mimick the way you work. This is true even of my direct reports who also manage - just because we have similar roles, not all of them want my job or ask themselves “what would Scott do in this situation” at every turn.
Communication and observation is hard. We’re raised on fables and parables which cut out all the extraneous information so that a lesson is made obvious. These have nothing to do with the real world though. Consider this simple story:
Taylor takes a breath before speaking in a flat voice. “Production is hard down - we haven’t had any 200-level responses in the last two minutes. I need someone to dig into our stack and see what’s wrong while someone else reaches out to Customer Service and makes sure they’re aware.”
Ask yourself this: if you want to do one thing to be more like Taylor, what behavior should you emulate?
Here’s an incomplete list of possible answers:
If Taylor is trying to lead by example then it’s anyone’s guess what we’re supposed to pick up.
Even if you cheat and say “all of the above,” you’re still relying on others to make detailed observations of you in the middle of your interactions. On a good day I’m just about able to walk and talk at the same time, let alone get all the subtleties from the above. That’s a big ask and one that is unlikely to pay off.
Let’s say you get lucky – someone wants to emulate your behavior and even picks the right one. In the lack of explicit conversations about these behaviors, there’s no way for this individual to get feedback on how well they’re doing. The only hope is that you notice their mimicry and are able to give them further guidance. Otherwise, you are just hoping they figure it out themselves.
Leading by example is still an effective management technique despite all these issues, particularly with other managers. To make it work, you have to employ one of the most important tools in the managerial toolkit: explicit expectations. In other words, you have to have a detailed conversation about the behavior you want someone to emulate in detail.
Using yourself as an example can be awkward the first few times you do it. You also have to be careful about how often you do this - if each 1:1 drifts into a conversation about your own behaviors and challenges, you risk becoming a narcissistic leader. When these conversations are used thoughtfully, it can be a powerful way to mentor your team and bond through shared challenges.
Going back to the earlier example, imagine if Taylor had said something like this in a 1:1 prior to that moment:
“The next time there’s a production outage, I want you to focus on making fast decisions and communicating them concisely.”
Now Taylor has framed their behavior in a whole new light. The extraneous details can be ignored and Taylor can provide quality followup feedback as someone does or does not emulate this behavior.
What do you think though? Have you found other ways to make leading by example work for you? I’d love to hear them if so.
Engineers crave explicit feedback and expectations, and yet it’s often hard to provide these when coaching on ownership and leadership. It’s frustrating for all involved - as managers, we want to provide goals but oftentimes struggle to go beyond “I want you to handle problems like I do.” To solve this, I’ve found the following tool super helpful for this - the Four Levels of Autonomy. I’ll outline them briefly and then explain how I use them.
From highest to lowest autonomy:
In general, I coach leaders to work at those top two tiers depending on the domain, its risks, and their expertise. In both cases, the individual is responsible for identifying opportunities, the top skill I need leaders to develop. It allows me to throw increasingly big problems at them without devoting significant time to getting into the details of their expertise.
The third tier, “Identify problems” is generally a good starting place for juniors or those learning a new role/domain. I’ll typically provide gentle coaching to get to that next step, identifying and recommending solutions, but it’s okay if that skill is still developing. Ultimately though, I want teammates to grow out of this level for two reasons. It requires an inordinate amount of time since their manager has to have most of the same context as the individual so that they can design solutions instead. It also robs the team of the creativity and insight that this person would otherwise bring by working on solutions.
The last tier, “Wait for instructions,” is a dangerous spot to be in for very long at any skill level. The challenge of waiting for instructions is that it requires another person to develop enough context and detail on their teammates’s responsibilities in order to provide detailed instructions and identify problems. It’s a colossal waste of time and is usually only acceptable at the very beginning of someone’s tenure.
Of course this framework doesn’t cover all leadership gaps and still varies on a case-by-case basis. Still it’s been a great way to take feedback like “I need you to take better ownership of problems” and distill that into specific outcomes which are or aren’t happening. If you end up using this framework, I’d love to hear how it goes.
A hundred years ago, lighting lamps was a great way to earn a living. You’d carry around a giant pole and go from lamp to lamp lighting them up. See the city while starting fires, I can see the appeal. Many others did too and created a rich set of traditions, practices, and quirks.
Things changed without advance warning though. We figured out how to make gas lamps light themselves and a profession was extinct. A dedicated few kept it alive through sheer force of will but by and large lamplighting was dead even before the advent of electricity.
Such is the danger of specialization, a horribly easy trap to fall into. It’s tempting to focus your energies on improving the process of using long sticks to ignite lamps. However, it’s career suicide to forget that your customers want light, not sticks.
Bringers of light will never go out of fashion, but the demand for people with sticks is always a time-limited affair1. Be very careful about tying yourself to just one way to set things on fire.
-SP
Especially for my friends who call their stick Silverlight, but others have written about that topic better than I can. ↩
I interview a fair amount of software developers (although not as often as I used to, sadly), and so I have people ask me about a variety of issues related to finding programming gigs. What certifications, what schools, what questions to ask, and even what attire to wear.
I really thought interview attire was something of a solved problem, but apparently not.
I digress. When I’m asked one of those questions, I usually try to stress that it’s hard to hurt yourself when answering any of the above questions. Yeah, some schools are better than others, but that doesn’t matter too much for programmers, especially once they have a year or so of experience. Certifications usually don’t hurt or help too much unless it helps you meet a job’s requirements (although an XML Master Certification is resume poison).
However, there is one particular brand of resume that, regardless of talent, really irks me and makes it difficult to get on my good side, let alone get a recommendation from me. I hate, hate, HATE finding a “spray and pray” resume. This is the kind of resume that is two pages long for every year of experience and is absolutely crammed with a wide range of unrelated technical terms. It’s the kind of resume where someone has liberally sprayed the document with verbiage and prayed that some of it tricked someone into interviewing them.
It doesn’t work.
Many people would say these resumes looks desperate, and you generally want to avoid looking desperate in an interview. I don’t really care too much about that however, as Lord knows I have been desperate for work before and lucked out to find a job despite it.
A more significant problem with this kind of resume is that is just looks lazy. If you can’t make the time to trim your resume down to only those things the interviewer has a chance of caring about, then why should the interviewer make the time to talk to you? Just 2-3 minutes spent making a specific objective statement, removing irrelevant items (or moving them to a Hobbies/Interest section if you really, really want them on your resume) and tightening the resume up in general can work wonders.
Worse than looking lazy is looking dishonest. If you are confident enough in some skill that you put it on a resume, then you’d damn well better be at least at an intermediate level in it. If you haven’t touched that programming language since high school, leave it off your resume. Otherwise, as soon as you have to tell an interviewer you don’t know much about something on your resume, you bring everything into question. It reflects poorly upon you, and the interviewer will subsequently devote a fair amount of time fact-checking your resume rather than really engaging with you.
Even if you don’t look lazy (which you might), and even if you don’t seem dishonest (which you will), you’re still doing yourself a disservice. Why? Because your strengths will be lost in the “noise” you create with unrelated terms and bullet-points. I promise you, even if you are just graduating from school, you already have strengths that are worth showcasing on a resume. It’s many times more effective to have three bullet points that prominently highlight things you excel at than to hide those amongst umpteen other areas where you aren’t so hot. By paring down your resume and saying less, you can let your strengths shine that much more and seem stronger.
Almost all of those problems listed earlier can be solved by simply going over your resume, and asking yourself “Could I answer a simple question about this?” If the answer is no, leave it off your resume. Otherwise, you might just be sitting across from someone like me who ALWAYS picks one of the programming languages you put at the end of your list and asks you to compare and contrast it against a language from the front of your list.
Oh, and never list XML as a programming language. (Although if anyone ever says that they really meant XSLT and that XSLT is Turing complete, I’ll be suitably impressed to overlook the mistake. Throw in a “Duh” for good measure though)
I have a bit of an insecurity obsession with the quality of my code given how long I’ve been at this programming thing. I know that must seem like an awfully vain thing to wonder about, the technological equivalent of thinking about every passerby “Am I hotter than that guy?”
That’s not quite it though. Rather than blather on about it for paragraphs before getting to my point, I’ll let Ira Glass (definitely hotter than me) explain in this wonderful video passed to me via my dear friend Nwokedi
Ira may be talking about storytelling, but I think it definitely applies to nearly any endeavor you care about. I’m at a point where I can recognize the qualities of good code, but the code I’m writing isn’t at all legendary, and I think a good number of junior-to-mid level developers have much this same problem.
It’s made worse in software since many of our heroes are chaps like Linus Torvalds and Sergey Brin - people who were extremely good right away, who seem like “naturals” to us mortals. We read things like Great Hackers and get the impression that if we haven’t developed groundbreaking technology by the time we’ve left college, we’re doomed to obscurity and mediocrity.
It’s no small comfort then to know that Ira was still churning out less-than-stellar copy after 8 years of making radio professionally.
Does this really apply to software development, though? Facts are hard to come by, not least because “Man develops amazing software after 15 years in the industry” doesn’t make for as great a headline as “Kid Doctor Can’t Buy Beer… Can Prescribe Drugs.” So rather than do all that horrible research and come up with a nice general overview, let’s just blow one example out of proportion: SubSonic lead developer and .Net guru Rob Conery.
It just so happens that Rob posted a brief bit about his programming background recently. Thanks to a bit of back-of-the-napkin math, Rob must have been programming for a living around 7-10 years before he first publicly released SubSonic to the world. That seems about right for a bright and motivated person, even quite a bit ahead of the “Ira curve,” if you’ll allow me to compare software to NPR stories.
By that metric, I’m pretty happy with where I’m at. I’m not writing any earth shattering code at the moment, but I’ll get there.