Exponential Leadership: Foundation #2 — Fast Feedback
I believe technology leaders can have an exponential impact on their company, and by extension, the world. Achieving the integration between people, process, and technology is THE job technology leaders have, and doing it well results in an exponential impact. I call this exponential leadership. You can read my first installment on Foundation #1- Empathy here.
This is the second installment of my blog series on the foundational elements of exponential leadership. Today, I’ll cover the importance of fast feedback.
Foundation #2 — Fast feedback
Respect learning loops
Provide timely feedback
Getting timely feedback is useful in all areas of life. If I’m working on a golf swing, getting feedback while I’m practicing is far more useful than a week later. If I’m low on gas in my car, I’d rather get an annoying ding than find out by coming to a slow halt.
Getting feedback is how we get better at things and bust assumptions. However, in technology, we have a super power. With software, entire environments can be created and destroyed in short order. Ideas can be tested and validated quickly, leading to iterative innovation. As a technology leader, understanding the power of learning loops and the necessity of your role in giving your team timely feedback is fundamental to success. Without fast feedback, you’ll be operating mostly on moonshots and luck.
Understanding your learning loops requires an understanding of the environment you operate within. Many organizations utilize agile frameworks for software development, but still have several gates before and after, slowing down the learning loop.
Alternatively, the technology you are working with may require some level of ‘big bang’ change. Switching from Oracle to SAP requires some very large and very bulky change. I appreciate the enthusiasm that movements like DevOps bring to the technology industry, but I’ve come to the conclusion that your mileage may vary based on the business and technology context you are working in. A funny example that comes to mind was when John Willis (co-author of the DevOps Handbook) was talking with me and some other technology leaders at a power company. John told us that when it came to our nuclear control systems, ‘fail fast’ probably wasn’t the right approach (which was a surprise to no one, thankfully!). The reality is, services for Netflix and Facebook can be iterated upon quickly and feedback can be collected transparently. The risk of failure for these services is not the same as other business contexts. For some services, feedback may be slower and more time consuming.
The goal isn’t to get your team or company looking like Netflix. The goal is to ensure that learning loops have been optimized for your context. This can look like a lot of things, but if it doesn’t include frequent customer conversations and prototyping of some kind, you’re probably missing the mark somehow.
These learning loops should be concentric as well. There should be very tight learning loops with individual pieces of work. You can get this quick feedback by breaking work into small chunks. Once you’ve gotten enough small chunks of work done, you should be getting feedback from users and stakeholders ASAP. If you’re working on a piece of a larger system, the larger system should be aiming for releases at least quarterly (ideally, with deployments decoupled and happening much more frequently than that). Release cadence depends on your architecture and business context, though, so keep that in mind when setting targets. Whatever your delivery pipeline looks like, there is likely a way to improve the rate at which information flows from one part to another. Optimize for the rate of learning, and your outcomes will naturally improve.
The diagram above assumes that you know what to build, which is a risky assumption. I’ve recently become aware of the ‘Riskiest Assumption Test’ method of thinking, which I find incredibly useful. The problem I have with the ‘Minimally Viable Product’ (MVP) way of doing things is that we’ve lost the forest from the trees. It’s important to point out that MVP is often misunderstood as “viable usable product” instead of “minimum required for learning”.
Testing assumptions should be done quickly and cheaply. For example, if you are creating something brand new for users, draw a picture of how you expect things to work and test it out with people. You can use a whiteboard, Mural, Miro, Figma or heck, even MS Paint! Rather than focusing on building a viable product, your goal is to test an assumption. If your assumption doesn’t hold water, that may mean you should pivot or abandon your effort. Focusing on learning quickly will improve your results and the morale of your team.
While learning loops are important for product development, they are also important for personnel development. As a leader, your job is primarily to support and develop people. A key component of this is providing timely feedback. An embarrassing example of an anti-pattern from my own career was when I first became a manager. I was a few months into being a manager and it was time to give annual performance reviews. I had one employee that I didn’t feel was quite hitting the mark, so I let them know during the annual review. They were shocked and angry (understandably so, in hindsight!). Why hadn’t I given them this feedback earlier in the year so they could do something about it? Why was I letting them know now, after it had been written up and being put in their permanent file?
Performance conversations can be awkward and hairy, but doing them frequently, with humility and specific examples, is incredibly important in leadership roles. If you aren’t willing to do this, you shouldn’t be a people leader- period. Fortunately, I learned from my feedback mistake and now realize annual performance reviews, if required by the people team, should be seen as a formality. The real feedback mechanism for your team is a tapestry of compliments and critiques given throughout the year. The ‘work’ is ensuring you’re keeping a journal of the feedback given and making sure the quantity of compliments greatly exceed the quantity of critiques. The book ‘How Full is Your Bucket’ really drives this home, busting the ‘compliment sandwich’ 2:1 ratio. The book suggests around a 10:1 ratio of compliments to critiques. As a leader, find specific things your people are doing well, and let them know about it. That way, when there is a critique to give, they won’t feel beaten down. A small word of caution- make sure you are critiquing sometimes. If all you do is compliment work without ever giving constructive criticism, people will think you are blowing smoke (or don’t understand the work they do).
Feedback is the lifeblood of growth and improvement. As a technology leader, you are in a unique position to optimize your team’s learning loops. First, focus on your own behaviors and norms to ensure your team is getting the feedback they need from you. This is entirely within your control and will pay dividends throughout your career. Second, in whatever context your team works in, ensure that you are optimizing for fast learning loops. Introduce your team to risky assumption testing and paper prototypes and iteratively improve your delivery pipeline. With fast feedback in place, you’ll be positioned to have an outsized impact.
