Non-technical founders - would you use a tool that helped you understand your tech team better?
I've been working on a SaaS MVP that helps non-technical founders (or any leaders of tech teams actually) understand how well their development team are performing.
It's something I really wanted for myself when I was a CTO with a fairly large tech team - just a quick way to see at a glance how everyone is doing.
I've taken the idea a bit futher and offer more insights to those who are less technical so they can understand the common problems you'll come across when running a tech team, plus suggestions on how to fix them.
What do you all think? Is this something you'd use and pay for? Are there features that would be particularly valuable to you that I have missed?
P.S. I've put up a really basic landing page here http://getdevinsight.com but the layout and design will be changing very soon.
yo, @JamieO
First, maybe to give you some heads up, there are products like that (for example https://www.gitclear.com/), so this might be a good reinforcement for you.
On the other hand, I'd be very very very cautious about this. As a non-technical manager, you'll be left to assess your developers according to [biased] metrics, opinions and attributes that someone else has developed, which is a big problem in my opinion. There are a lot of metrics that you could judge the developers by, but inspecting the code repository is hardly the best.
I can game the system by "producing" a lot of lines of code that do not solve the problem, do not move us closer to complete our goals or that do not affect anything at all except the metrics you're measuring me by.
The slightly better metric could be the number of reviews or the times the code has been rejected. This is still far from ideal, especially if you're having big changes (which will absolutely require a lot of reviews and a lot of legitimate updates).
The best "system" in my opinion is judging by the completed tasks. Basically, don't monitor people like a babysitter - trust them enough to do the work in the timeframe they're given. If your dev cycle is 2 weeks - sure, check-in once a day, and then weekly, but don't seek out specifics like lines of codes written, or the number of code pushes into the repo. Seek out problems. Check if they need help achieving what they need to achieve by the end of the cycle. And if they fail to meet their cycle goals consistently, then have a chat to figure out why. Are there too many tasks? Were the time assessments wrong? Are they working to the fullest? Are there external factors impeding their work?
I urge you to not turn "performance" of a developer into numbers of "something" specific. For a manager, that's a really poor way to assess performance, and once developers figure out how are you judging them, they can easily play the system.
I highly recommend reading ShapeUp (https://basecamp.com/shapeup/webbook) for approaches to work planning and following up.
Hey @alourie, thanks for the detailed feedback I really appreciate it.
As a long time developer myself, I know that counting lines of code is not a good metric which is why DevInsight doesn't do that.
Instead, patterns and metrics are derived from tracking developers changes to the code over time in a way that highlights key areas to managers.
For example, DevInsight can tell if a developer is potentially stuck with thier work by a combination of tracking the areas of code they are currently working on, the levels of churn (replacing new code) they are producing and their throughput patterns compared to their own past levels and the team averages. DevInsight will then highlight to the manager this could be an issue and offer a bunch of suggestions on how you might fix that (clearer project requirements etc.)
DevInsight can tell how often developers are helping each other out (for better or worse) or highlight commits that are higher risk and therefore need more testing. Lots of other things along these lines but you get the picture.
Nowhere does DevInsight try to rate "performance" in a way that you describe as I'm well aware this is not valuable. There isn't a way to game the system as it flows naturally from the work that forms the developers job.
Thanks for the reading suggestion, I do believe I read that (or at least scanned it) when I was building a team and wanted to refine our agile processes but at the time it didn't fit the company.
Awesome. I was afraid this is one of those, line-of-code counting ones :-)
I'm all for getting more insights into how things are going on, the thing I really hate is non-technical managers judging my progress with "tools" they have. It's like judging an artist for using colours in a wrong pattern.