Providing Developers Value-Focused Feedback in Security Software Development
I recently wrote an article on attracting and retaining A-Players, and one of the key elements was to ensure that leadership share the mission with developers to create a sense of purpose. Having purpose and seeing impact is incredibly important for anyone, but for engineers, understanding their impact in the context of a larger program or product can be particularly challenging. I wanted to dig into this further and share a few anecdotes that might help managers of security software development teams be very deliberate in providing feedback.
One of the unintended consequences of working in cyber security is you tend to hear much more about when things go wrong, than when they go right. Security software is blocking threats continually. Sometimes they do what they intended, but as we all know, a well-crafted phish will fly through a secure email gateway, land in an inbox, get clicked on, cause a compromise, and make a total mess. Far too many engineers in the trenches don’t take the time to lift their heads to see context, so when good (and bad) things happen, this is a great management opportunity that you should take full advantage of.
I’d like to share four opportunities for providing value-focused feedback:
1) At the Point of Ideation
I know as a manager of development teams, my time is often toggling between strategic and tactical activities. I’m engaging customers, meeting on strategic vision, sharing progress, and even putting out personnel or technical fires. On any given day the amount of context switching makes it hard to step back and take the time to address the “why” we’re doing something. When a backlog item is reprioritized (we very rarely say ‘deprioritized’ because it implies the item isn’t still important) or it naturally comes up for development, there is an entire story behind it. If there isn’t a story to tell, you probably don’t have a reason for this in the first place. Take the time to set the context of that item relative to the role you are playing and engage managers above and below you to help support the story. Describe revenue expectations; adoption metrics and customer value that is expected. This value can be extremely motivating, and I’ve seen it time and again, when a great idea is properly shared, the development teams light up and do the job much faster.
2) Post Feature Delivery
When we are delivering a feature, we will often instrument the application so the feature being built can be monitored for usage. Regardless of how you do this, it is worthwhile to set up metrics ahead of time, to determine if the marketing or other notification methods are driving adoption rates appropriately. These metrics are context-related, but a few common ones are usage, time spent in a feature, as well as performance or load parameters. From the developer’s perspective, these metrics can have a very positive impact in that they validate assumptions and inform future prioritizations of features. This closed-loop feedback process can build trust in the strategic direction of your portfolio, help drive future decisions, and establish a line of sight between the value of a feature and the development efforts you are applying to them.
3) After Customer Engagements
Customers are a wealth of feedback and Cofense is fortunate that much of the feedback we get is positive. This is great for motivating teams, but sometimes a feature, or workflow isn’t quite right for a customer. Either way, we value that feedback, and use it to provide learning opportunities to the engineering team. After getting feedback, we will often perform, as a former supervisor of mine would call it, a ‘blameless autopsy’. What were our assumptions, what features came from those assumptions, and what was the customer experience that resulted? Often these reviews can be challenging to hear for the development teams, but if they are done constructively, the team will continue to lean forward and take appropriate risks. Likewise, when a customer loves something, it is important to share that as well. In particular, share the value that feature is providing the customer. Just be careful to not create false patterns in the approach to developing software. Innovation is often the mindful breaking of patterns, so be careful to not just automatically do what worked in the past. Think critically about successes as well as challenges.
4) During Organizational or Other Strategic Meetings
I seek to have regular strategy sessions with my team. In these meetings, we walk through a strategic overview to place each product in context. These discussions don’t need to be elaborate, however, every year before review season, I like to set the stage for establishing goals. Engineers’ goals should always, and clearly, align with the organization’s goals, and it is in these strategic meetings that the context can be set. If goals don’t align with business objectives it will cause discontentment, and ultimately a loss in performance. Strategies are never adopted or fully understood the first time they are heard, and they never survive unrefined over time. They evolve, and therefore the value and context to the engineers needs to evolve with it.
By implementing value-based valuable conversations, your teams will be positioned to understand where in the overall context of the company their work lies; how a specific action will impact the bottom line; and when released, how they will receive feedback and confirmation of how effective the efforts they had were against those strategic objectives.