Part of our quest to build a product that people need and want is to identify opportunities that create high levels of value for the users that we hope to attract. This is the same goal that most, if not all, product companies have and so it’s not entirely unique to us.
But what is distinctly different is how we’re going about our own discovery process and instead of asking the folks that we’re interviewing their obvious needs we are, instead, asking to help us identify what they know they don’t know.
Sure, it feels a bit nuanced, but, the thing that we know to be true about software development today is that there’s this widening gap between what we know what to do with and the actual data that we have.
This is full of irony because engineering is arguably the most data-driven part of any organization. In fact, everything an engineer does is captured through inputs and outputs, through systems and programs, and so you would think that we’d have a ton of data that can ultimately result in action.
But that’s not what engineering leaders, managers, and software developers know to be true. Even though we have more data than we’ve ever had we’re having a hard time translating this into actions. Succinctly, actionable data is what’s missing.
Scott Adams has recently been hitting some of these topics in his Dilbert series that have really struck a powerful chord with our team. You can’t help but not start nodding in agreement with some of these:
One of the most common challenges that software developers have (as well as the teams at large) is communicating to leaders and other important stakeholders why things are “taking so long” to get done.
Essentially what we have here is a fundamental communication gap, a lack of a common language and understanding that translates what is actually being done in terms that do not require deep technical know-how and knowledge.
These strips, of course, ends with punchlines that hits too close to home: The engineer can be “punished” for this misunderstanding and the team and organization as a whole suffers or at least are accused of something that isn’t actually true.
These two are similar and also hits a bit close to home. Velocity and speed, especially for a startup but for any organization of any size, is one of the most important competitive advantages that can be leveraged or lost.
Therefore, it is a leader and managers duty and responsibility to minimize friction for the software team so that they can continue to build the product(s) that create revenue for the company.
But we know that this is an all-too-familiar challenge, especially in the larger companies. Software developers are spending more time in meetings and less time building production-ready code and most of these meetings hold very little value, if we’re to be honest.
What the software world needs are tools that interpret and communicate insights without interrupting workflow. Simple as that. Again, we all have the data – it’s right there in front of us! We just don’t have the systems in place that automate these (actionable) insights in way that gets them to the necessary parties without breaking folks out of the “zone” (or software Feng Shui).
Lastly, we know that software development is just as much about people as it is about process. It reminds me of this tweet that I particularly love:
There are only two hard problems in computer science:
— Zach Holman (@holman) September 15, 2016
Although tongue-in-cheek we know, fundamentally, that great software is first and foremost built by highly capable, highly motivated, high-performance teams. And without the right understanding, without the right communication systems and tools, we’ll never quite get there.
And as Dilbert argues with the Pointy-Haired Boss, it’s not about working longer hours but about managing the people building the software better which requires better knowledge of what is actually happening in product development and how those individuals and teams are performing.
Essentially, if we could create a software world (and organizational environment) that has less ambiguity, a more common and understood language, and access to actionable insights without breaking workflow, the individual engineer(s) would win, the team and product would win, and the organization as a whole.
This entire universe, by the way, is what we’re calling #EngineeringOps (#EngOps for short): Actionable insights and analytics for software teams.
And every day we’re getting closer and closer to delivering something publicly (we’re in Closed Alpha right now… want an invite?) that’s going to help teams build better software – we couldn’t be more pumped to show it to you soon.
Also published on Medium.