Embracing Risk, Reward, Success, and Failure

One of the biggest things you’re looking for in these growth goals is the learning that comes from achieving a growth goal. Note that when I use the term “learning,” I’m not just suggesting “problem solving” (as in, identifying and correcting errors in the external environment), I’m suggesting that people need to reflect critically on their own behavior, identify the ways that they’re inadvertently contributing to the problem, and then change that behavior. Part of the larger goal (the meta-goal, if you will) is for your directs to learn how the way they go about defining and solving problems can be a source of problems in its own right.

Consider the humble thermostat: When set to 68 degrees, it checks the current ambient temperature, and turns on the heat or AC to adjust the temperature accordingly. This is a simple, “single-looped” feedback loop. If the thermostat could be taught to ask, “Why am I set at 68 degrees?”, and then explore whether a different temperature would actually accomplish the deeper goals of the household—keeping warm in winter and cool in summer, relative to the outside temperatures—the thermostat would now have a second feedback loop in place, which would influence the first feedback loop, and more importantly, require less human interaction to find the optimal spot between comfort and energy conservation.

Most developers are very good at single-looped feedback—tell me what the bug is, or what the missing feature is, and I’ll go build it or fix it. Many developers, however, are not great at that second level of feedback—we often defer the question of “why” and that associated abstract thinking to the product owner or business analyst. “Just tell me what you want and I’ll build it,” they’ll demand. “I can’t tell you what you want.”

And yet, when the developer becomes a manager, much of the role is to do exactly that—help the client (the members of the team) figure out exactly what it is they want, before figuring out how to accomplish it. This “higher-order thinking” is a reflection of how they think, which is to say, the cognitive rules or reasoning they used to design and implement their actions. Ironically, what best helps us achieve clarity in that higher-order thinking process is failure: failure forces you to reflect on your assumptions and inferences. And part of the reason why developers are so bad at this second-level feedback loop is because they’re so good at the first-level loop, so they rarely fail. And thus, they never leverage the failure to learn better how they think.

Story time! A long time ago, as a new developer, I had a boss who, while very impressed with my knowledge of C++ and Windows programming, was trying to convince me that I had some blind spots that I, of course, did not see. “What Ted really needs to do,” he commented once to a friend of mine from the same team, “is fail. Twice.”

The first failure was on that team, although it wasn’t a clear failure—my feature was large and complex, with a lot of moving parts, and the specification that I was supposed to receive was vague and full of holes. Not my fault, I thought, if only I’d had a good spec I could’ve made it work.

The second failure, less than a year later, however, was a feature (at a different company) that I’d insisted would make everything better. It made things more complex, actually reduced the flexibility of the product, and was ripped out and replaced with the old code shortly after I left. That second failure was much harder to “reason away” inside my head, and it forced me to realize that the only thing in common with both failures was me.

That was when my education truly began.

Thus, one of the principle meta-goals of these goals is to embrace failure. Select some goals and challenges that your direct won’t automatically be able to hit. Ideally, whatever you select should have about a 70% chance of success—you don’t want to sign anybody up for an outright failure out of the box (a 0% to 30% chance of success), and you don’t generally want somebody doing something that has all the chances of a coin-flip to succeed (50% plus or minus 20%). Neither, however, do you want something that’s 99% likely to succeed, because it’s not embracing enough of a challenge. Hit them with something they’re at least possibly going to fail. Things like:

• A new project. Define a project within your team that makes the team or your feature work better. Perhaps it’s a code generator, or a user interface generator (based on the kinds of data it will be receiving), or it’s a framework to try and capture the reusable parts of multiple different UIs. Ideally, whatever this new project is, it should be challenging your direct in ways they’re not used to: if they’re a front-end developer, ask them to think about the server-side code; if they’re a back-end developer, hit them with presentation or database concerns. Keep this project internal to your team, so that if it fails, it’s not affecting anything outside the team.
• Technical decision-making. As the manager of the team, you’re often tasked with being the “deciding vote” in a debate as to what framework or technology or library to use. Delegate that decision to the growth-goal-seeking employee, particularly if it’s not a clear yes/no decision. Force them to examine the context from different angles—not just the impact to the team, but the impact (if any) to the users, and to the people that will inherit this code five years from now. What are the support implications of using this new thing? And so on.
• Feature development. Next time the product owner drops by to talk about what’s involved in the new feature they’ve got cooking up inside their head, delegate your growth-goal-seeking direct to meet with the product owner and figure out what’s feasible and what’s not. This forces them to take a more holistic view of what the feature would require, and think more about how all the various stories and tasks would need to be welded together.
• Prototypes/experiments/research spikes. Every development manager knows the inward groan they get when a team member comes to them, hot new technology in hand, suggesting that “if only we rewrite everything in this new thing, we’ll be amazingly productive and incredibly resilient and and and–”. Let’s put it to the test! Let the growth-goal-seeking direct build out a prototype using the new thing, answering a specific hypothesis (which must be developed as part of the prototyping cycle) about the new thing. It forces your direct to, again, start thinking more holistically and consider different points of view they’d not perhaps seen before.
• Presentations. “You can’t teach what you don’t know. So if you want to know it better, try to teach it.” One of the most important things your direct will need to know as their career advances is how to communicate to others a message or vision. Put your direct in charge of doing the sprint delivery demo to your boss or to the wider group. Put your direct in charge of running the team meetings or standups. Put your direct in charge of the proposal to add a new service to your boss. This will force them to think about not just the solution, but how to frame the conversation, “read the room” for feedback, and cogently answer questions that come up, particularly from their skip-level management.
• One-pagers/six-pagers/ADRs. The same goes for writing. Writing documentation about existing code is often tedious and uninspiring and doesn’t really stretch the mind, but writing a one-pager (or executive summary) describing a proposed new process or feature forces the author to think not only about the anticipated questions, but also how to do all this in a single page. Six-pagers, made popular by Amazon, are typically used as proposals or as meeting agendas and materials—forcing your direct to write those forces them to again stretch their communication skills, such as how to create a coherent “story” out of the various elements that make up the proposal, as well as how to find evidence to justify the proposal, while still keeping things concise and focused. (Six-pagers are notoriously difficult to write.) Likewise for architectural decision records (ADRs).

To be sure, these aren’t the sum total of potential challenges; there’s certainly other sorts of things that come to mind (such as mentoring the new kids), but many of them make the assumption that your direct is an experienced “old hand” at the game, and the above challenges can be handed to even the most junior of developers to stretch them.

Throughout this process, remember, the meta-goal is to embrace failure, and learn from it. The old myth about Thomas Edison and his 10,000 failures to invent a light bulb come to mind—when asked about them all, his response was that “Now we know 10,000 things that don’t work,” highlighting the extreme confidence common to superbosses. Encourage your direct to try something and see if it works, and if it fails, shrug and toss off your best Edison impersonation.

Which, by the way, brings up a related point: The best way to get your team to embrace failure, is to embrace failure yourself. Try stuff, tell them you’re trying stuff, and if it doesn’t work, shrug and toss off your best Edison again. Your team models what’s acceptable at the company, and what isn’t, by what they see from you, so if you want to encourage the team to feel comfortable when they fail, learn to be comfortable when you fail, too.