A Few Screenshots of the “July Prototype”

Keeping form with the new cadence of sharing screenshots of the project (a’la June Prototype Screenshots) I wanted to give you a snapshot of the next few iterations.

But, unlike last month, I wanted to give a bit more context around these screenshots so I can get a bit more exact feedback from our faithful readers and subscribers.

So, take a moment and dream with me for a bit, will you?

A Focus on the Team

Knowing an individual’s contribution to an engineering project is pretty self-evident in many ways, especially if you’re using tools like GitHub to build and manage collaboratively. And all of that data is useful but it becomes much more useful in the context of a team.

What we all know to be true is this: Truly great software (and companies) are built by great teams – there are too many examples to list. This is partly why collaborative tooling has grown so significantly over the past few years; we simply do better work with better folk and better collaboration tools and workflows allow us to get close to peak productivity.

But it’s not perfect and we’re not quite there yet when it comes to transparency and visibility as a team. Again, the data is there but the ability to see it collectively and cohesively is severely lacking, not to mention the challenge of simply communicating the data to team members or other interested parties (especially the non-technical stakeholders).

What I’d like to do (and what I’ve been doing) is thinking long and hard about these types of things and investigating the possibility of illuminating the data in a better way so that people can build better software.

The next four screenshots highlight some of these things in gist.



Of course, as an individual and team member you want to be able to see all of the projects that you are involved in and relevant information associated with them. Although it might be a small thing, information like “last updated” can be useful.

The question(s) that I’m trying to work through at this level is what else could be super-useful from a project dashboard perspective. I’d love your thoughts.

Team Metrics

Team Metrics

Getting insight into your team and the amount of work that’s being done is always useful. Using the same dashboard design, showcasing these facts/figures is fascinating. Again, the question is whether or not they are exceptionally useful or just “vanity” metrics.

In fact, that’s one of the biggest concerns and push-backs that I’ve received in my virtual and in-person interviews with folks: “Is this just another vanity metric system?” Obviously, my hope is that it’s not but it can be very difficult to present any sort of data in a dashboard and not feel as if they are just vanity metrics.

So, the worth challenge, of course, is to see if I can present the data in a way where the gut-level response is in the opposite direction entirely. If you have good examples of this I’d love to see them!

Active Projects

Active Projects

Just another look of a possible dash and arrangement of data.



If you cake a look at this for a moment you’ll see a “Daily Developer Snapshot” with some data related to work being done as well as one that’s related to the “Project“.  Another possible view of data that may or may not be useful depending on your role within the organization.

At the bottom I’m somewhat teasing a “Daily Challenge” feature that could excite a few of you or really be quite revolting. I’m trying to figure out what has best incentivized me historically as a developer and what we can do systemically to increase engagement with not only the system but with their projects.

And, perhaps most importantly, how we can use a system like this to coach and level-up staff. Is it possible to create intelligence through the existing data that would allow well-meaning managers to provide “coachable moments” for their engineering team, either virtually or through their 1:1 meetings and more? This is a theme that has also come up in my of my conversations as well.




This one isn’t related to the “team” but rather more aligned with “resources” for the user. As you might deduce, the email newsletter “Building Better Software” is a bit of a test for this type of user behavior and engagement.

I’m collecting resources and sharing them and looking to systematize the distribution and sharing of these resources through the tool. Consider this: Would something like this be of great interest to you? Could you see yourself using a feature within a development tool that kept you up-to-date with technical articles, resources, and news that was truly relevant to the work that you’re currently involved in? I think so.

What if we connected the technologies that you were using in your current projects and curated a feed that was specific to those technologies, platforms, stacks, and dependencies?  Now that would be pretty neat.

Love to hear your thoughts!