These days it is not uncommon to see large companies trying to make do with less, which often means trying to maintain the same amount of output with less manpower. Working efficiently to improve a product while battling engineer burnout in parallel has never been more crucial. As an engineering manager at ThreatQuotient, I’ve found myself coming at this problem from a slightly different angle (that of a small company graduating out of start-up mode), but I feel pretty confident that the solution is the same.

Let’s start with a recent project as an example – a feature we just introduced at the beginning of this year, CAC Authentication. A customer expressed an immediate need for this ability, so our Product team sprang to work on requirements. The deadline was short, and my team had little direct experience with CAC internals (aside from using a CAC card themselves in previous lives). I found myself retreating to a valuable, albeit blunt, piece of advice that my father drilled into my head when I started high school physics – draw the damn picture.

This was never going to happen if we couldn’t draw the damn picture. And so we did – in the form of an Engineering Response Document – the template for which has been evolving across many projects since I transitioned from primary contributor to manager. This document is alive in the sense that updates never stop until the project is complete – it is the primary source of truth for Product, Engineering, QA, Tech Pubs, and later Support. It has the added benefit of helping with onboarding down the line. Where the damn picture comes in is that it needs to be able to speak to all these different levels of communication, expertise, and familiarity with the innards of the platform itself.

So we start with research – what is the most common certificate standard that we should focus on supporting? What is the most common way that an analyst in the field uses their CAC card? How can we ensure that if a CAC card is lost or disabled that an analyst can reset their credentials and not get locked out of their account? What do we need to do to ensure the security of the credentials and who should be able to set up a Certificate Authority? The document starts filling with links, designs, and accompanying tables of detailed use cases and open questions. Storage and component communication are diagrammed. QA begins a list of risks and areas of the platform that could potentially be affected. Spikes are identified so that developers can fill in the remaining knowledge gaps, and by then tickets that have practically written themselves begin to appear. Once the work starts, the mantra shifts from “draw the damn picture” to “What does the ERD say?”. Unknown unknowns are unavoidable, but for the most part it’s smooth sailing, and if we miss something it’s added to the checklist for next time. We drew the damn picture. Everyone on the team knows what they’re doing, or who to ask if they don’t. 

I realize that all of this reads as painfully obvious – if you plan something, it will be easier to execute. But when you’re working in start-up mode, it’s the part that most often gets lost in the weeds. Not because of any malicious intent of anyone involved, but because there is no time, there are not enough people, and the person who does build the feature will be shifted onto the next important project as soon as they are available again. This is a necessity when you’re trying to get your feet on the ground – maybe more so when you’re trying to keep your feet on the ground. But plenty of people have written more eloquently than I about the incredible shift in mindset that has to take place once the seats start filling up (or when the seats that were once filled start disappearing, for that matter). Ultimately, what any engineer needs is to have a source of truth they can use to see the path ahead, and from that perspective, drawing the damn picture becomes the most important thing you can do to ensure success.

To learn more about ThreatQuotient and the ThreatQ Platform, please contact us or request a demo.