Unmonitored Risk In Software Development: A Silent Killer.
Google docs, disparate tools, ad-hoc reporting systems. It’s not the early 2000’s. This is the state of risk detection in software development in 2020 used by well-funded companies around the world.
A couple of years ago, I launched my first startup. Among many scaling struggles, the ability to detect software development risks early on was one that stood out most. I hosted daily morning stand-ups, configured Jira to match our development process, and conducted regular 1-on-1’s. All good practices, but none that helped to foresee a 2-day task turning into an 8-day task.
The same day I realized this, I was driving home from the office, and a light came on in my car. It read, “Rear left tire air pressure low.” As I clicked through the interface to see what else I needed to know, I saw my engine oil level was at 40%, and I would have to fill up on gas in 124 miles. There were better risk detectors — or at least more understandable risk detectors — for a $25,000 car than there were for a $325,000+ software development project.
Anyone that has managed an engineering team or worked on a software development project will have similar stories. Whether they are attempting to get heads-down engineers to break their workflow and update project boards or navigate clunky and overly complex dashboards, the experience is sub-par because of a lack of proper risk-detection.
In fact, risk detection is backward, and we almost expect it to be; or simply take it as is, and expect no better.
For engineering managers, engineers, cross-functional teams, this overload and disconnect of products, processes, and projects as a whole, is soul-sucking. As it turns out, the risk detection software they use, if any, needs deep configuration, typically lots of training, no AI, and often requires a double confirmation of the data shown.
In fact, data shows that engineering managers spend an average of two hours on understanding sprint progress to every one hour of planning. Plus, another 1.5 hours in 1-on-1’s that are focused on status updates vs. employee check-ins. If you were to reverse that equation, you would “double” the efficiency of engineering managers thus affecting the entire product development chain.
That is Staat’s ultimate goal: to double the intuitiveness of the software development process through better software.
Staat was a collective idea.
In 2019, my first company’s team and I decided to move on from the first company we built to tackle a new problem. During dinner, our CTO and co-founder, Paul muttered, “Engineers have it hard in some places, but managers need help everywhere.” It resonated with me because I was our “engineering manager” and felt that all of my challenges were due to me being non-technical.
As we pressed deeper, Paul insisted that it was incredibly hard to track a myriad of things from a management perspective because engineers were the ones most intimately connected to the work. This caused a disconnect between engineers and management resulting in substantial software development waste: mismanaging the backlog, rework, unnecessary complex solutions, low morale. And that’s just scratching the surface.
With a background in data analysis, I started to wonder if you could track data disparities across tools as well as change deltas to help bridge the gap between managers and engineers. The analogy I used was from my time playing competitive tennis. My coach would use change deltas within a 2-hour match to define why I won or lost as well as inform which part of my game needed improvement.
David, our third co-founder, brought a strong perspective on product design. With a background in anthropology and customer experience strategy, David knew that we would have to design the user experience, unlike any other risk detection/analytics tool. It would need to deliver insight quickly and comprehensively — augmenting a person’s knowledge base in ways that they couldn’t do on their own.
As our thesis formed around change deltas, we started testing by building small experiments where we would monitor changes in code and issue data. Not only did we get a quicker and clearer insight on project status, but we also found that data disparities across tools can surface discrepancies in the process that help fill gaps in how we understand the health of our projects.
Without understanding change deltas and data discrepancies, our ad-hoc systems could cause our projects to bloat to such inefficient levels that we completely underutilize innovation and top talent. The biggest risk in software development isn’t a lack of process or technology, it’s a lack of communication — between people, processes, and technology.
What is Staat?
Staat is a risk detection software for engineering managers. Of course, it has the code, issues change delta monitoring, and more. We have data discrepancy detection to better understand the true state of your software development project. We even have recommendations on who you might need to communicate with to keep your project on track, tooling to save companies millions and managers hours by finding bottlenecks.
But Staat is focused on tackling the core workflow of the engineering manager. We are a total rethink of risk mitigation software: change tracking across tools, integrated design through a Google Chrome plug-in, drill-down links that help you navigate through tools. And so much more coming soon.
Software Development is an exciting place for a data person like me to play. It makes the marketing and Martech I worked on as Lead Strategist & Analyst at Coca Cola and Founder of Partnr look easy in comparison.
How do we show an engineering manager that has 30 seconds to spare the state of their software development projects? Is someone unproductive or do they work better at night? How much of the backlog needs to be displayed to understand the context of a change? How much data is needed before an engineering manager gets bogged down? How do we reduce friction between engineering managers and engineers? Are pull request comments or scope changes more important? Should we highlight what the last engineer committed or does that introduce too much bias?
The product aspects of risk detection are endlessly fascinating. They require research, data, and discussions with managers, engineers, and cross-functional partners. They require intuition and vision for what software development can be. We’re committed to cracking the code. We’re committed to making software development more intuitive. We’re for fewer surprises. We’re for managers and engineers. We’re for your customers. We are Staat.
