When Feedback Loops Get Too Tight

There's a commonly held belief in building software that feedback loops should be tight. It's a sentiment that I agree with but I've come to realize that there's such thing as too much of a good thing in some cases. When feedback loops get too tight, software teams tend to get bogged down in the details, sometimes losing sight of overall business goals or just plain wasting time.

I've noticed this in personal projects that I've worked on. I work hard to set up processes and tooling to make communication lightning quick.  I iterate quickly. I pat myself on the back for being able to change direction on a dime. I mean, that's how smart people write software, right?

The trouble is, as the time and effort required to request a change gets smaller, there's a tendency to think less about the request itself before making it. I've found myself endlessly pushing pixels around on the screen to make a feature work just so, later realizing that I hadn't slowed down to think about whether the feature should really be built in the first place.

It became much clearer to me when I started to drastically reduce the amount of time that I was investing in GSD, a productivity tool that I've written for myself. Early on I was working on GSD almost every day. I'd make a change each morning, use the product during the day, and determine the next change based on what I had learned.

When I stopped coding on weekdays the daily feedback loop stretched into a weekly feedback loop. I had assumed that my product would evolve more slowly but what I'm finding is that it's evolving more quickly instead. Daily feedback often focused on what made the product easy to use, while weekly feedback has a healthier perspective of what makes the produce useful.

I've come to realize that at some point, feedback loops become so tight that they focus on what feels urgent rather than what's truly important. There's a lot of value in taking a deep breath and spending a few minutes in reflection, sometimes spread over the course of several days, before shooting off that email or Slack message with your most recent feedback. You may find that you speed up by slowing down.

My Favorite Question to Ask

I spend a lot of time talking to entrepreneurs and I've come to learn that the most insightful question I can ask is "What keeps you up at night?" I've found that it usually leads to a palpable feeling of relief and that the conversation digs a whole lot deeper from that point on.

Being responsible for a business, especially one that has the livelihood of others wrapped up in it, is stressful at times. To make matters worse, business leaders find themselves wanting or needing to put a happy face on to put employees', investors', and loved ones' minds at ease.

"What keeps you up at night?" gives the entrepreneur permission to talk about things that they otherwise feel that they have to keep to themselves. It cuts to the chase because it's clear that there's no need to keep up appearances. I've been thanked many times just for asking.

In some cases it's useful to frame the question so that we can home in on a specific topic. At MojoTech, for instance, I speak to entrepreneurs about building web and mobile applications that are critical to their businesses. The answer to "What keeps you up at night about this project?" gives me a much better idea of how to make the project a success.

That said, it not as easy as just asking the question. The hard work comes in listening carefully to the answer, asking important follow-up questions, and making good use of the information. I've found that "What keeps you up at night?" makes that hard work a whole lot easier - you may too.

What's Your Professional Superpower?

I'm a VP of Product with a superpower. Sounds kinda impressive and kooky, doesn't it? It certainly did to me when Mike AbiEzzi, our amazing interim VP of Engineering at Simpler, told me that my ability to code is a superpower. After some reflection it started to make a lot of sense, and I started thinking about what superpowers others have.

Interested in an interim CTO/VP of Engineering? I hired Mike AbiEzzi to conduct an architectural code review and subsequently asked him to act as our interim VP of Engineering. I highly recommend him. You can get in touch with him here.

Many people in a VP of Product role don't have a strong technical foundation. Many don't need one - that's what a VP of Engineering is for. It's certainly handy to have, however.

The fact that I can jump in to lend a hand gives our engineering team extra flexibility. Need more horsepower leading up to a release? Need an extra set of eyes on a tough problem? I can put my developer hat on and pitch in for a while.

It's also helpful to Mike that technical debt isn't an abstract concept to me; I feel the burden first-hand because I'm contributing code regularly. He spends less time defending his decisions to maintain a healthy code base and more time getting it done.

Perhaps most importantly, I have an appreciation for what engineering entails in general. You won't find me saying "this feature seems pretty straightforward to build" very often. I understand that custom software is rarely as straightforward as it seems on a whiteboard.

Mike sees these as a reflection of my coding superpower; a superpower that makes me stand out among the product people he's worked with throughout his career.

While you probably haven't thought of yourself as a comic book hero, I'd recommend giving it a try. If you're a recent developer bootcamp graduate, for instance, you should be thinking about what makes you stand out among the rest of your class. Do you have a strong design background? Experience with data analytics and visualizations? What can you brag about a little?

What's your professional superpower?