Engineering managers, how do you keep track of team productivity?
I’m recently engineering manager with a handful of direct reports. We have weekly 1:1s to check in and make sure I’m engaged with their career development and experience at the company.
Apart from this, how do you track your engineers productivity? How do you spot issues that might be blocking their work or slowing them down?
What is important to keep tabs on as an engineering manager?
Trending on Indie Hackers
Create a culture of ownership within your team. Empower your directs to own what they should be doing, and make sure to give feedback constantly. The best way to have a productive team is to have a team that's motivated, that has a drive, a purpose. That's your role to start that engine!
Agreed. You can try as many philosophies, tactics and workflows but at the end of the day if your team is not comfortable talking with your or motivated to work on the project none of those option will work properly.
I could agree with this :).
Great point! Ownership of the work product is key.
I start cringing when I think about "Tracking productivity." Not because it's a bad thing to do...but because it's often accidentally weaponized.
I don't know how your team is structured, but "productivity" in a software sense isn't about slinging code...it's about delivering value to users and business stakeholders. The team is productive if validated value is getting released on a regular basis, and that value is getting adopted by the appropriate audience.
This is one of my favorite topics to chat about. I spend my days working for a branch of an organization that's helping enterprises and government agencies change how they build software. I've seen a lot and paired directly with CTOs and CPOs to transform their culture and processes. I'd be down to chat about this type of stuff at any time!
@andrewgassen, great points all around. I don’t believe in tracking developer productivity by lines of code written... at one job, after 18 months my net contributions in git was -100k lines of code :)
Also, what strikes me about your response is that there is you care about developer productivity—but you measure it by validated value delivered to clients (not commits, LOC, tickets closed, etc. Can you say more about what measurements you collect if any to determine if validated value is being delivered and adopted?
(Btw, I’ll drop you an email—we’re practically neighbors. I live and work in Arlington, Va)
Small world! Once everything clears up, we should go have a drink.
There are a few different metrics I think about, but they all measure different capabilities up and down the stack to answer these questions:
Is the product providing value, aka doing what it's supposed to?
Is the team able to move forward with steady progression?
Is the product continuously usable?
Is the product maintainable?
For each individual product and product team, the specific metrics will vary but I think those four questions still need to be answered. If the team is not able to move forward with steady progression, you can ask, "Why not?" and start to put actions in place to solve those problems. The metrics you capture should be indicators that let you know the answer to that question may be no, or trending toward no.
The product metrics need to be tied to the product itself, not a blanket set of numbers. There's no sense in tracking the number of daily logins per user if the product is intended to only be used once per month, as an example. Your product could be perfectly healthy and doing what it's supposed to do, but if you're tracking and optimizing for the wrong thing, you may end up making silly changes. The same is true of team-based metrics.
Hi Andrew, that makes a lot of sense! Do you have a blog (or some other channel) where you share your insights? I'd want to learn more about what you have to say.
I do not have a blog that I post to regularly. Using the internet to share what I know is the thing I suck at the most.
Answering questions? I can do that all day. Proactively sharing something I know, however, is very unnatural for me and feels arrogant or something, I dunno. I have mental hangups about this for some reason.
:) Sure.
I am a huge fan of ClickUp (https://clickup.com). I have been using it over a year and have not looked back.
I think great management is responsible for crafting a mission, a vision and a strategy, that is accepted by team and motivates them to go forward. Execution in IT could be pretty good handled by Scrum or Kanban process.
I would recommend to use OKRs and let your team members to come up with their objectives that aligns with company vision and be as transparent as possible.
As engineer I would not like weekly 1:1s, I think it's way too often. I am fan of setting up goals, but week is too short time for goals, it's a time period for few issues and feels very much as reporting.
Another thing that might help in building a team is https://sociocracy30.org/
Thanks for the thoughts! I’m a fan of OKRs as a framework for thinking about the stuff
My favorite managers have been those that truly care about how the employee is doing one wanting the best for them. I like having 1-on-1's with my tech lead every month we discuss things such how we can improve as a team, how we feel things have been going, has anything been bothering us lately, etc. It helps make people feel like their voice is being heard (especially is there is action being taking afterwards).
With regards to tracking productivity of the engineers/developers, I don't think you need to track how productive an individual is, since it will make them feel as though they are under a microscope. It's easy enough to see who is able to get their work done and who isn't just by seeing what people are able to accomplish in terms of tasks within a given timeframe. Also, if you're a tech lead, you will likely see who is contributing code in GitHub (or any other version control system the team uses) and who is contributing less. If you see someone contributing less, it could just be that they are frequently blocked on issues and the tech lead should inquire on how they can help them get unblocked. You'll also quickly realize who is blocked on issues if you do daily updates as a team (AKA "standups" in the scrum world).
As a manager/team lead, the best way to see where people are getting blocked is through continuous communication and then you should try and find ways to help facilitate things for you team so they don't get stuck up on things as often.
Make sure they collaborate towards the same goal with the same guidelines. Make sure they are part of creating the processes that will get them there. Nothing worse than forced morning standups :)
We have introduced an engineering "Health check" to our small team. This is inspired by what is done at companies like Spotyify, Newrelic, Atlassian and many others.
This includes :
This has helped us surface problems that the team is facing early on and address them before they turn into big pressing issues.
You can read more about the Spotify one here: https://engineering.atspotify.com/2014/09/16/squad-health-check-model/
Will check out this health check model. Spotify has done some interesting and thoughtful stuff with their teams
Scrum has a process for it. Ask your devs to rate tasks/tickets with points based on difficulty and then compare how many the team gets done per week. The estimates aren’t really accurate on their own, but you can watch trends and then look for clues if you encounter an abrupt change or see prolonged decline.
We’ve recently adopted a similar method for estimating points on story’s. We’ll see if it bears fruit over the next few iterations :)
I've been using Clubhouse for everything. It's a great alternative to Jira or Pivotal
Thanks for the tip! Will check it out.
This comment has been voted down. Click to show.
Thanks for the reply @fuzzy_logic!
A couple questions in response to help me understand your points in a bit more depth.
Why would you suggest less frequent 1:1s? Is there something about weekly that’s not good? Or better at a fortnight?
What problem arises when your directs feel too much ownership about their work product/area of the codebase/product?
Why would you suggest less frequent 1:1s? Is there something about weekly that’s not good? Or better at a fortnight?
too many 1-2-1's will create an environment of familiarity! (like I mentioned you're here to manage not become friends) They will end up trying to please you and not get the job done OR it could work against you and they will hate and blame you for taking too much of their time.
If you really want to know what your team is doing - like I mentioned use tools like O365 productivity, Git, Ms DevOps, Jira, etc., etc.,
I once had a colleague whose report complained to his boss when things started going south that her manager was too pally with her and micromanaging and not providing her with the big picture. (all bs...but it did its damage).
What problem arises when your directs feel too much ownership about their work product/area of the codebase/product?
Ask your questions - who will get a Bollocking if things go wrong?
Ownership sounds all 21st century, however, structure is important and timely delivery is critical in a Software delivery environment and that's why you're the manager. (when things fail you'll start hearing excuses like - oh! but it worked on my system - blame DevOps etc., - you can't go complaining about the staff under you to your leadership...you'll be looked as an ineffective manager.
This comment was deleted 3 years ago.
Good idea on the group chat. Will keep that tip. Thanks!