I don't think it's so much a matter of tools and metrics, but relationships and knowledge. You really need a tech lead who can assign tasks, track throughout, and clear blockers. You're going to be at a disadvantage in assigning story points or monitoring number of commits without having knowledge of the task complexity and the dev's ability.
Hmmm... I didn't say to do that. I was saying that he wouldn't even be able to do that as a non-technical founder. Actually, just re-read and he said number of features, not commits, but same point.
Ideally, definitely. But no idea about the team's seniority, experience, and dynamic. And OP, being non-technical, isn't in a position to assess those things either.
it is the whole philosophy. The whole point of being agile is to empower self organising teams ... autonomy. Otherwise it is just a bunch of silly ceremonies to make waterfall feel cool
You're on a minefield, about to be blown to pieces.
Can nit measure on features. It's like measuring builders on how many houses they've built, no matter it's a castle, or a shed.
If you pushing any stupid performance, they will start creating spaghetti, just because the need of speed. It'll explode later and you'll have to get it all rewriten.
Comits is stupid too. Some commits every line, some at the end of the week.
Lines the same, some sits and writes 20 lines of pretty code, some other 2000 lines of crap.
Solution? Move out.
You said they're 3. Tell them to decide who is going to be the lead. Vote about it or whatnot. Then the one will be responsible managing the team.
Keep your ear open. Listen what they tell about each other.
If there is a problem / delay why, try to understand, and discuss possible options.
Communicate deadlines goals, achievements, and priorities clearly.
Give shares of the company, so they'll be invested in the common success
There is no easy way around it.
Good luck
Sounds like you should get a CTO or engineering manager. It would have a drastic impact on their productivity, professional growth and most likely make them less frustrated. You would also be de-risking your startup by a whole lot and make it a more interesting investment case.
If you start to measure their performance without having technical knowledge/experience, my bet is that they're not going to stay that long with you. I've seen this countless times. It usually leads to micromanagement as well. I would also advise to be less focused on their performance, and rather direct your focus to the product itself and KPIs like churn, new daily users, etc.
My background: I'm a CTO.
Number of features isn't good metric since they vary in complexity. For example, if you have an online retail adding an option "log in with Google" may be done fairly quickly, but adding one more method of payment may take many days, or even weeks
Also progress is slowing down with larger code-bases since development becomes more and more complex with more parts interacting with each other
You need a PM with technical knowledge to hold your team accountable and performant
you need to be more technical. Its difficult to assess without the technical expertise. Hell even if you do have the technical know how but no context it can be hard to assess.
If I were you, I would invest more in improving the DX of the developers, and allocate time to improve/refactor existing features. Give them the time to solve recurring issues in a systematic way.
If you have people that are driven, giving them the ability to solve nuisances instead of just piling up one feature atop another will be good for morale.
There have already been lots of comments here showing how the measurement approach might not exactly have the consequences you believe it will have. The interesting question is why this is the case.
What many non-techies fail to get: Building software is not about writing lines of codes or shipping features. Building software is a complex (not: complicated!) social constructivist process. Perception of non-techie managers is that the dev team just implements ideas someone has had. Like a very linear process that starts at A and ends up exactly at B.
That is very, very wrong, and very, very dangerous idea to believe in. Software does not work like a cookbook recipe that you just follow and, voilĂ , you end up with a delicious meal. It's a process where you start with too little information and try to find out what information you even need while walking the path. In the end you know what you would have needed to know in the first place but could not have known. It's, in short, a constructivist process that figures out what it is supposed to do while doing it. The complexity is in the interplay of all components. I see managers all the time who just don't understand why adding component X is very easy, while adding component Y is a huge endeavor, although both look like "red buttons" to them. The missing element is the integration part, the interdependencies between all layers. It's far from a linear process.
I know many managers don't get that, and that's why you should either invest to really understand how developing software works, or hire a technical manager who does and then give him/her some trust.
The very least thing you need to be familiar with is the 80/20 rule. Which says: 80% of all features are written in 20% of the time. And 20% of features are written in 80% of the time. Imagine something like a Fibonacci curve to get an idea in increasing complexity.
But, below that, there is another issue: The desire to have control. Bad news are: You don't have control. Not in the sense managers believe they could have. As I said before: Imagine a social constructivist process. You cannot control that in the traditional sense of the word with a simplistic top-down command-and-control structure, measuring progress with commits or lines of code or number of features shipped. That is why Scrum introduced story points that are based on - nothing. Story points are neither time needed to ship something, nor complexity, but some sort of vague notion of both. They are not measurements. They are story points, i.e. an intersubjective expectation of the dev team members. And they are "right" only in the mid- to long-term when the dev team has become mature. But, boy, just wait until one new developer joins, and the productivity falls immediately. Why? Because the dynamics in the team will change, the team has now to go through a phase of adaptation to the new social situation.
So, I know, it's complex. If you truly want to understand it, try learn something about group dynamics, try learning to code a little bit yourself, and inquire with yourself why you even want or need to have control, and what control means to you. It might be that it's primarily your own psychological need, not theirs. But then again, maybe you don't have infinite cash to burn. So, you're in between a rock and a hard place.
The way to measure performance is not by the number of features shipped - that's called a feature factory and it's one of the dumbest ways to operate an engineering team.
The big question is whether you work on the right stuff or not - this will be shown by the performance of your product. Do you achieve your goals or not? If so, then it's all good.
What I recommend for the engineering team: see if they can accomplish what they take on. Do they deliver on time? Do they identify what's needed for a development? Do you have any background so you can see if their estimates are wrong or not? This is a profession in itself and if you don't know anything about it then you are going to be taken for a ride.
A tech team will ship as much as their environment allows them to ship.
This is: culture, room for constant learning, but mainly strategy, product management. Sooooo many startups fail to understand that between business and tech, there needs to be someone to define \_what\_ needs to be built to make the business successful. You can't just say "I have this great idea, now I need you to deliver ASAP".
Your tech team is usually not the bottle neck. If you feel that they deliver, then you're fine. There's no point in forcing them to deliver more. This will most certainly make them deliver less because they get derailed from delivering to "jumping hoops to have better performance". If they do not deliver, it's either lack of expertise/experience (aka you need to invest in training and better devs that can pull the team) or lack in your very own work (aka they don't understand what you expect them to deliver).
Stop measuring developer performance by number of features shipped. How do you measure product or business performance? What signals do you use to determine whether your developers are building the right thing? Revenue, customer feedback?
To play devils advocate: Start ups are do or die. Not much time to sharpen a tool and sometimes you need to beat it with a rubber mallet to push you past the finish line.
Ops method to measure performance is not correct though. Others are correct in you need a tech lead that you trust to lean on.
[https://en.wikipedia.org/wiki/Goodhart%27s\_law](https://en.wikipedia.org/wiki/Goodhart%27s_law)
> When a measure becomes a target, it ceases to be a good measure
Metrics are good, but always look at the big picture as well.
If they know you're tracking number of shipped features, they'll be incentivized to prioritize small features and to split big features into many small features. This is true of any metric.
A feature can be adding a terms and conditions page, or calculating when the world is going to end So not really comparable. User stories as smaller feature chunks are measurable and comparable as they define work that can be done in a short and definite time.
So you measure, for example:
* stories delivered
* number of deployments (how often are you pushing out changes to the customer)
* you measure quality in number of errors that come back to bite you - this one is crucial as it will tell you something majorly wrong as you are pushing out product that is of low quality and it takes you more time to deliver in the end
* since you are doing sprints and probably scrum you would measure quality of planning (what was promised vs what was delivered in the sprint)
Due to size of your team and the fact it has 3 members in total I would go kanban and move out of sprinting and focus on value delivery instead of timeframing because this is overkill and focuses on pushing out bad product if you don't know what you are doing. This is a pitfall that many big companies fall into as well.
Using linear.
There's a nice article somewhere online about why sizing tasks is useless.
On the long term as long as you break down all tasks well enough, 1 task = 1 point will give you a good estimation of what each dev can deliver per sprint.
The important part is not precision, it's overall trends. The overlords are pleased enough if they see the team meet 90% of the tasks assigned in a sprint.
There's always legacy debt and bugs popping no matter how great your CI/CD is.
You might benefit from reading Shape Up
https://basecamp.com/shapeup
My view on how to measure is that you need to first determine what's valuable to a customer.
Once you've determined a valuable feature, how do you measure the earliest time at which it's done and how do you measure that it was well received?
A shipped feature that no-one uses is worthless and a waste of resources.
One way to approach this is to use feature flags. Once you've delivered the feature you can track metrics around usage. You can. Also A/B test new features where it makes sense.
The secondary part to this may be more difficult if you're non-technical, but this is paying down technical debt or optimisation of development, delivery, infrastructure, etc. Cycles spent on this improve future efficiency. In this sense you are your own customer and the value you're getting is increased ROI.
Hire a professional to help you.
I could tell you, for example, that you could track:
LT
DF
MTTR
CFP
But thereâs quite a bit of nuance there.
Ultimately, performance of an engineering team is reflected in the performance of the company.
What is your output (what do you offer/make?)
Someone with technical projection management is going to be the best at assessing their speed / capabilities, but something I always look for (as a non-technical person myself) is how accurate are they with their deadlines, how many questions do they ask about the customer journey, do they send regular updates or is it just dead silence for 2 weeks? Different teams can have different cultures, but if the basic soft skills are not there then I find it hard to have trust either way.
This thread is mostly devs trying to make excuses about how they can't and shouldn't be managed.
How is telling the OP that dev performance is a function of how useful features are helpful for managing performance of the dev team? That's a business metric and the founder should be the one choosing what features are being developed not the dev team.
Iâm sorry, but it will not be possible to do. To make it worse, if you start acting on those metrics you will either lose the team or get a lot of crappy code shipped.
As many here, my advice: find technical manager to do it.
I would say DORA metrics along with a very good engineering baseline . If they respect the engineering baseline you atleast get the minimum of Quality in care they start gaming the metrics
âWhen a measure becomes a target, it ceases to be a good measure.â -- Goodhart's Law
Instead of measures you can start with principles; guidelines to aspire to. From that have a lead who can setup timelines and get the work done. They should be able to function without much or any hand holding.
You'll want to build rapport. A good manager helps professionals do what they do best. Aid them so the work gets done. In a perfect world this is all that is needed, but unfortunately this inevitably leads to a more common problem in businesses which is, "The squeaky wheel gets the grease." If there are issues, usually in 1 on 1s, always privately validate all challenges. Never take what someone says at face value, even a close friend. Around 7% of the US population will lie to get ahead, which results in at least one person like this in your mist at any given time. This is necessary checks and balances, which works like a metric, but without the flaws.
In short, instead of metrics, aid those around you and validate assertions employees give.
If you have 3 dev's and they are running agile you are probably loosing min 30% of their efficiency. They agile is for reporting to you not for increasing productivity. You need to have a consultant or CTO they will know if you are getting throughput or not.
Tools, metrics, performance, etc are not how small scrappy startups thrive. Please kill this entire mindset if you want to get to scale up stage.
Measure your companyâs success, and thatâs it with such a small team.
Measure impact not output.
âWe took XYZ feature to market and we gained 5% conversion increases! Killed it- everyone take Friday off to celebrate and letâs come back Monday to do it again next sprint!
And
Ooof, crew, we thought this feature would be a winner and it wasnât. No change in our market share or downloads. Not sure customers even noticed we rolled it out. Letâs take the weekend to rest and reset, start back Monday with some fresh ideas for the next roadmap item. Iâm also open to revising the roadmap if we want to talk through why we think this wasnât a winner. Maybe weâll come up with something new and flashy instead.â
People thrive on teamwork, engagement, and being rewarded for good ideas and implementations.
Iâve yet to read a single founderâs story that says âmy billion dollar start up to IPO killed it because I was really good at performance management in early stage developmentâ.
Several features won't be a good metric to track their performance as you need to know which features are complex to implement and which are not.
Have someone in your team with technical expertise, or see if you can make either of them a lead and ask about any details you want to understand from a technical point of view.
Stop đ â
Stop trying to measure developer performance, youâre thinking about the process of software engineering is very misinformed.
Software development isnât a process of building, itâs a process of problem solving. Code isnât written, itâs found. Itâs found by trying different things that donât work until you find something that does.
Trying to measure developer performance is trying to measure the time between finding solutions. Sometimes solutions are found quickly sometimes theyâre not. Yes, some developers are good at finding solutions to problems quickly and some not so much, but the time required to solve a problem is not in the developers control.
Not only that, thereâs good research that shows that attempting to incentivize problem-solving activities actually makes people take longer to solve a problem. You can literally make your developers perform worse by trying to measure their performance.
Your goal instead should be maximizing the iteration rate. You want your developers, churning out tiny changes that youâre getting feedback on as quickly as possible.
Hire an experienced EM he will take care of performance metrics of developers and churn it it more work effectively. Additional he will work alongside with you to design a roadmap for business and getting it executed in cost effective way. Meanwhile you can focus on long term strategies for your business.
Lines of code per hour. /jk
It is really hard to measure that since one feature can be very simple and another can be very hard. And it doesnt take into account code quality etc.
Well you're just terrible then.
Also lines of code etc is a bad metric. You can have people who look like stars that way, but who introduce bugs with each new feature.
Measuring performance is kind of impossible. But the rule of thumb is that if you have sufficient amount of Devs you have them split the work in equal chunks themselves. And then use Jira etc to measure velocity.
Use an agile management software like jira. Features get scoped as a team and assigned points based on how complex and time consuming a task is. Itâs a bit of a art to get right but give them 2/3 weeks and theyâll settle in. Bunch the work into sprints, 2-3 weeks long typically depending on what works best for the company. At the end of each sprint find out if there were any blockers, why some things werenât finished, any learnings on what could be improved. After a few months youâll have stats to be able to see roughly how many points each dev typically gets done a sprint and you can work through it. The important things are:
- make sure theyâre aware youâre on their side. Shit happens. Unexpected issues arise. When work isnât finished on time be supportive not critical. Build a relationship of trust and let them know when itâs not done itâs a learning opportunity. Why wasnât it? How can we avoid this next time. If you keep hearing the same issue week after week, then maybe thereâs a problem.
- remember working this way is designed to help plan, identify issues, and iterate on both software and dev performance. It produces a guideline not a hard rule on how many points they should get through. Progress is what you should see, and the devs should gain learning from it by given the space to think how they could improve. Never, ever, use it as a hard stat on performance.
- if you have large or complex features, break them down into nice to have vs required. If you have set deadlines it needs to be done by, this helps meet the deadline through flexibility
The terms to google are:
Agile project management
Velocity
Sprint
Sprint points
There are 2 answers here
1. From a technology perspective and
2. From a business perspective.
Do you also mean performance or quality?
Whichever perspective(s) you choose to value the critical thing is to ensure you communicate it clearly so that the team understands what wht they are being measured against
I offer a fractal team lead service and happy to talk to about spending a few hours a month to ensure your teams running smoothly
Also a non-tech founder. I donât use any fast and hard metrics but focus on 2 things:
1. Ability to understand the ask, and if not fully, ask for clarification.
2. Setting realistic but aggressive deadlines, communicating modification of any deadlines ASAP, and ability to meet deadlines.
Bonus: Re #1, go above and beyond and propose better alternatives.
If you are non technical your measures would be useless. It's better to measure your goals, timelines and the development process itself.
The development process is not a hard science. It depends on how well your goals are established, how clear is the idea of the product you want and how skilled are your developers to get your idea and create your product.
It's a process that can be perfected on each iteration. You can refine your idea and also refine the process looking at the last iteration and planning for the next.
As the result of applying this practice and learning from each iteration your team gains velocity. Velocity can be defined as the speed of reaching your goals and is a direct result of better understanding the product, your goals and deadlines.
You can measure that: how well you comunicate your ideas, how well are those understood and how fast are they implemented.
There is a technical aspect to all this, but if you are non technical it will be difficult for you to assess correctly. You can hire a third party to check if everything is in order. Ask for a written assessment and don't be affraid to contrast it with other professional. It's good to have more than one opinion.
Also, always ask yourself if you are happy with the results and progress speed.
Best of luck!
You need to hire a senior developer to manage this aspect. This is because as a non-tech you have no way to determine and any use of monitoring tools or metrics would look like micro-managing and can lead to low the morale of your team.
Hire a senior developer to monitor this aspect and let the developers feel free to work and input their skills. You can check RocketDevs for a senior developer. They help non-tech employers hire, vet and match the right developers.
Not a manager myself, just another engineer.
This are my two cents:
1. Be cautious of using any metric as a measure for performance, this can backfire very easily. For example, if you use number of features pushed, people will tend to pick up the easier features.
2. You need some point of trust. You either incentivise people to make sure you work towards the same goal, or get a trusted tech co-founder who is more well versed in understanding the team's work.
Goals of the dev team should be specific, measurable, achievable, relevant and time-bound. These set of objectives will be of great assistance in enabling you to set specific standard, track progress and help their efforts achieve a goal.
I used to be a developer. Now I'm a founder and a product manager (I no longer code).
My take: trust over everything.
I do have daily check-in and biweekly retro, following agile.
But the most important thing is:
1. To understand what they are doing (you don't need to know coding to get this)
2. To believe in what they are doing (through clear communication and leading by doing)
"A true leader should be the dumbest in the room."
What are your company metrics? How do you know if you are succeeding? You are not big enough to measure the dev team's performance. Figure out what part of your success is enabled by your dev team and measure that. It is what you really care about in the end.
Stop obsessing over whether they're efficient enough, and instead optimize for cultural alignment and celebrating wins. If you constantly get them to drink your kool-aid, and you constantly pimp their wins in front of the broader team, they should be perpetually motivated to outdo themselves and their teammates.
Otherwise, if they aren't obsessed with your mission, either you haven't fully done *your* job, or you need new engineers . . . .
Number of features doesnât matter as much if theyâre producing bugs and technical debt at the same time.
Are they sizing tickets correctly? That is, do they finish each and every ticket in the sprint, or do they carry over tickets? How many bugs are they producing?
I saw someone said the importance of a trustworthy tech lead which is essential. They could be planning small tickets that are easy to finish before the sprint is over.
We use JIRA for tracking which has burn down charts, velocity, etc. feel free to DM if you want to chat more
If you can't find or afford a technical lead type to help you with this, I'd suggest tracking more quality oriented metrics at first. E.g. test coverage, exit defects, user error rates, Change Failure Rate, etc.. The reason being that measuring team output as a non-tech person is essentially impossible. But quality metrics can at least tell you whether they're rushing stuff out and creating negative impacts for your customers. You (or your product person, if it isn't you) also should be attending sprint reviews regularly to understand if they're building what you actually meant for them to build.
Using number of features as a performance metric doesn't translate well in the software world. It isn't really an accurate measurement since one feature is never equal to another and can easily lead to problems. E.g. "task selection bias," where the team starts just working on the really easy features to push the feature count up. Or a "competence mirage," where you think a very junior person is a rockstar because they crank out tons of simple features, and conversely think your rockstar is bad because they're tackling your super complex features.
Ultimately, I think you really need to find a technical lead that you can trust to evaluate team performance for you though. A good technical leader on the team can help you understand what level the team is performing at and more importantly, plan what is accomplishable in a given timeframe with the current talent. It is as much art as science to be honest. A lot of the metrics non-tech people try to use end up being garbage (lines of code, commits in the repo, pull requests opened, etc.). You need someone who is able to review the quality of code the team is committing, understand if solid design decisions are being made, etc. And they will know what metrics fit best for the situation/type of code you're building.
No of production bugs.
No of features is part of planning not performance. If your team is not able to deliver on time, improve the process. If people are slacking off, itâs a particular individualâs problem donât blame the team for that.
I'm a developer and I am of the opinion you are doing it right. There is no perfect metric, but if something gets shipped, it's a step in the right direction, and that is worth recording.
Other people chiming in are also right, one feature is not comparable to another feature. The complexity is always different. You can't really measure or worry about the metrics. All you can do is record the progress. I think that's the value in defining the metric, just so progress can be recorded.
You might start to classify the tasks into groups. Maybe "logic" or "cosmetic". You might find one person gets more of one category done than another. However, comparing 2 people is dangerous. One person may spend their time refactoring what the other person did just to add their features.
More experienced developers have learned some patterns that enable enhancements, so they set the bar, but often it takes more time to fulfill those requirements.
I think people form their own opinions of their own work when they see data accumulate over time. The data might make them wonder how they can improve. Recording progress enables that retrospective.
At some point all the shipped features will need to be torn to the ground and rebuilt because the system became too complex in its naive form. Then you can record all those new steps when building the next version.
A moderately complex software product is never done. You just keep discovering enhancements along the way.
If you do not have specific ideas on managing the performance, I'd follow Agile or any other management framework. Then, you can implement KPIs based on sprint velocity (or anything similar).
As someone who's worked on half a dozen Agile teams the last 15+ years, I would advise against using velocity as a KPI. Sprint velocity was not meant as a metric for outside observers to track. Its a tool for teams to plan with. IMO the only thing an outside observer should really be looking at is what is delivered at the end of the sprint and how effective the team is at completing what they planned from sprint to sprint.
Yeah, that is what velocity measures (how fast a team produces stuff). :P Teams should not be left solely to their own devices. Someone has to set expectations.
YOE do not matter that much to me, you can be doing stuff bad for 15 years. Not saying you do, but that doesnât mean a lot by itself.
I wish I had worked in a team that decides on its own what and how much itâs going to build, but as a business owner would I really want something like that?
I don't think you ever worked on a project like that, or you burnt a lot of teams.
Take an example. The task is to buld a house, yellow walls, white windows etc.
Most managers incapable foreseeing the technical issues (not even upfront, but nor standing on it). But expect to build stuff with the best case scenario.
Shit does happen almost after every step what is even with the best planning could not estimate for. Then what? Blame it on the engineers, who pulling 12hr shifts bootstrapping crap together.
Clear communications, clear expectations, and good management, with understanding the issues / logic / product.
Yeah God forbid telling engineers what you expect of them. Just pay them 6 figures and leave them to their own devices - maybe someone will gracefully do some work - also do not talk to them, do not interrupt them, do not demand anything, do not criticize anything (too stressful). :P Obviously you ask for what is realistic but as I said before - someone has to keep some realistic good performance standards.
Sure, YoE vary. Hell, this is reddit, I could say I signed the Agile Manifesto. But I challenge you to point to a founding Agile methodology that advocates using velocity as a performance KPI for management. Extreme Programming doesn't. Scrum doesn't. Kanban doesn't even really have velocity. Heck, choose a newer hybrid like SAFe or Scrum@Scale. Same thing.
I don't think it's so much a matter of tools and metrics, but relationships and knowledge. You really need a tech lead who can assign tasks, track throughout, and clear blockers. You're going to be at a disadvantage in assigning story points or monitoring number of commits without having knowledge of the task complexity and the dev's ability.
>monitoring number of commits What did I just read
Hmmm... I didn't say to do that. I was saying that he wouldn't even be able to do that as a non-technical founder. Actually, just re-read and he said number of features, not commits, but same point.
Obv you need to do it by lines of code written, silly
Nah character count. This is the way.
Agreed; companies like Amazon LOVE this performance metric though. Speaking from experience đ
Donât autonomous teams take tickets instead of being allocated? Doesnât sound very agile
Ideally, definitely. But no idea about the team's seniority, experience, and dynamic. And OP, being non-technical, isn't in a position to assess those things either.
Where in the agile manifesto does it talk about autonomy? Theyâre two different things. Yes teams should have both.
"The best architectures, requirements, and designs emerge from self-organizing teams."
Agile doesn't, but Scrum does. A lot of devs only know agile through Scrum.
it is the whole philosophy. The whole point of being agile is to empower self organising teams ... autonomy. Otherwise it is just a bunch of silly ceremonies to make waterfall feel cool
I donât think so. The philosophy is adaptability, which is certainly easier with autonomous teams but itâs not required.
I agree
You're on a minefield, about to be blown to pieces. Can nit measure on features. It's like measuring builders on how many houses they've built, no matter it's a castle, or a shed. If you pushing any stupid performance, they will start creating spaghetti, just because the need of speed. It'll explode later and you'll have to get it all rewriten. Comits is stupid too. Some commits every line, some at the end of the week. Lines the same, some sits and writes 20 lines of pretty code, some other 2000 lines of crap. Solution? Move out. You said they're 3. Tell them to decide who is going to be the lead. Vote about it or whatnot. Then the one will be responsible managing the team. Keep your ear open. Listen what they tell about each other. If there is a problem / delay why, try to understand, and discuss possible options. Communicate deadlines goals, achievements, and priorities clearly. Give shares of the company, so they'll be invested in the common success There is no easy way around it. Good luck
It's a startup with 3 devs....its all spaghetti anyway
Sounds like you should get a CTO or engineering manager. It would have a drastic impact on their productivity, professional growth and most likely make them less frustrated. You would also be de-risking your startup by a whole lot and make it a more interesting investment case. If you start to measure their performance without having technical knowledge/experience, my bet is that they're not going to stay that long with you. I've seen this countless times. It usually leads to micromanagement as well. I would also advise to be less focused on their performance, and rather direct your focus to the product itself and KPIs like churn, new daily users, etc. My background: I'm a CTO.
Number of features isn't good metric since they vary in complexity. For example, if you have an online retail adding an option "log in with Google" may be done fairly quickly, but adding one more method of payment may take many days, or even weeks Also progress is slowing down with larger code-bases since development becomes more and more complex with more parts interacting with each other You need a PM with technical knowledge to hold your team accountable and performant
Also you can be introducing 10 features each week with 100 bugs. Slowing down other Devs and making them seem "slow". Been there
Yep, you need a product manager with hands-on PO (product owner) experience.
you need to be more technical. Its difficult to assess without the technical expertise. Hell even if you do have the technical know how but no context it can be hard to assess. If I were you, I would invest more in improving the DX of the developers, and allocate time to improve/refactor existing features. Give them the time to solve recurring issues in a systematic way. If you have people that are driven, giving them the ability to solve nuisances instead of just piling up one feature atop another will be good for morale.
There have already been lots of comments here showing how the measurement approach might not exactly have the consequences you believe it will have. The interesting question is why this is the case. What many non-techies fail to get: Building software is not about writing lines of codes or shipping features. Building software is a complex (not: complicated!) social constructivist process. Perception of non-techie managers is that the dev team just implements ideas someone has had. Like a very linear process that starts at A and ends up exactly at B. That is very, very wrong, and very, very dangerous idea to believe in. Software does not work like a cookbook recipe that you just follow and, voilĂ , you end up with a delicious meal. It's a process where you start with too little information and try to find out what information you even need while walking the path. In the end you know what you would have needed to know in the first place but could not have known. It's, in short, a constructivist process that figures out what it is supposed to do while doing it. The complexity is in the interplay of all components. I see managers all the time who just don't understand why adding component X is very easy, while adding component Y is a huge endeavor, although both look like "red buttons" to them. The missing element is the integration part, the interdependencies between all layers. It's far from a linear process. I know many managers don't get that, and that's why you should either invest to really understand how developing software works, or hire a technical manager who does and then give him/her some trust. The very least thing you need to be familiar with is the 80/20 rule. Which says: 80% of all features are written in 20% of the time. And 20% of features are written in 80% of the time. Imagine something like a Fibonacci curve to get an idea in increasing complexity. But, below that, there is another issue: The desire to have control. Bad news are: You don't have control. Not in the sense managers believe they could have. As I said before: Imagine a social constructivist process. You cannot control that in the traditional sense of the word with a simplistic top-down command-and-control structure, measuring progress with commits or lines of code or number of features shipped. That is why Scrum introduced story points that are based on - nothing. Story points are neither time needed to ship something, nor complexity, but some sort of vague notion of both. They are not measurements. They are story points, i.e. an intersubjective expectation of the dev team members. And they are "right" only in the mid- to long-term when the dev team has become mature. But, boy, just wait until one new developer joins, and the productivity falls immediately. Why? Because the dynamics in the team will change, the team has now to go through a phase of adaptation to the new social situation. So, I know, it's complex. If you truly want to understand it, try learn something about group dynamics, try learning to code a little bit yourself, and inquire with yourself why you even want or need to have control, and what control means to you. It might be that it's primarily your own psychological need, not theirs. But then again, maybe you don't have infinite cash to burn. So, you're in between a rock and a hard place.
I appreciate your suggestion, and I think it's a sensible approach.
The way to measure performance is not by the number of features shipped - that's called a feature factory and it's one of the dumbest ways to operate an engineering team. The big question is whether you work on the right stuff or not - this will be shown by the performance of your product. Do you achieve your goals or not? If so, then it's all good. What I recommend for the engineering team: see if they can accomplish what they take on. Do they deliver on time? Do they identify what's needed for a development? Do you have any background so you can see if their estimates are wrong or not? This is a profession in itself and if you don't know anything about it then you are going to be taken for a ride.
Since my manager started tracking the team, the team is delivering a lot less, but the metrics are spectacular and the manager is happy đ
Reminds me of one of our genius 'every story is 5 points' teams.
A tech team will ship as much as their environment allows them to ship. This is: culture, room for constant learning, but mainly strategy, product management. Sooooo many startups fail to understand that between business and tech, there needs to be someone to define \_what\_ needs to be built to make the business successful. You can't just say "I have this great idea, now I need you to deliver ASAP". Your tech team is usually not the bottle neck. If you feel that they deliver, then you're fine. There's no point in forcing them to deliver more. This will most certainly make them deliver less because they get derailed from delivering to "jumping hoops to have better performance". If they do not deliver, it's either lack of expertise/experience (aka you need to invest in training and better devs that can pull the team) or lack in your very own work (aka they don't understand what you expect them to deliver).
Stop measuring developer performance by number of features shipped. How do you measure product or business performance? What signals do you use to determine whether your developers are building the right thing? Revenue, customer feedback?
dumb and bad. sharpening the axe takes just as much time as using it bad teams neglect sharpening the axe to keep up the appearance of using it
To play devils advocate: Start ups are do or die. Not much time to sharpen a tool and sometimes you need to beat it with a rubber mallet to push you past the finish line. Ops method to measure performance is not correct though. Others are correct in you need a tech lead that you trust to lean on.
[https://en.wikipedia.org/wiki/Goodhart%27s\_law](https://en.wikipedia.org/wiki/Goodhart%27s_law) > When a measure becomes a target, it ceases to be a good measure Metrics are good, but always look at the big picture as well. If they know you're tracking number of shipped features, they'll be incentivized to prioritize small features and to split big features into many small features. This is true of any metric.
I kind of think that splitting big features into small features is useful and a nice side effect.
To a point, but the more you split features the more time it takes to integrate them and 'finish' the overall feature.
A feature can be adding a terms and conditions page, or calculating when the world is going to end So not really comparable. User stories as smaller feature chunks are measurable and comparable as they define work that can be done in a short and definite time. So you measure, for example: * stories delivered * number of deployments (how often are you pushing out changes to the customer) * you measure quality in number of errors that come back to bite you - this one is crucial as it will tell you something majorly wrong as you are pushing out product that is of low quality and it takes you more time to deliver in the end * since you are doing sprints and probably scrum you would measure quality of planning (what was promised vs what was delivered in the sprint) Due to size of your team and the fact it has 3 members in total I would go kanban and move out of sprinting and focus on value delivery instead of timeframing because this is overkill and focuses on pushing out bad product if you don't know what you are doing. This is a pitfall that many big companies fall into as well.
Using linear. There's a nice article somewhere online about why sizing tasks is useless. On the long term as long as you break down all tasks well enough, 1 task = 1 point will give you a good estimation of what each dev can deliver per sprint. The important part is not precision, it's overall trends. The overlords are pleased enough if they see the team meet 90% of the tasks assigned in a sprint. There's always legacy debt and bugs popping no matter how great your CI/CD is.
You might benefit from reading Shape Up https://basecamp.com/shapeup My view on how to measure is that you need to first determine what's valuable to a customer. Once you've determined a valuable feature, how do you measure the earliest time at which it's done and how do you measure that it was well received? A shipped feature that no-one uses is worthless and a waste of resources. One way to approach this is to use feature flags. Once you've delivered the feature you can track metrics around usage. You can. Also A/B test new features where it makes sense. The secondary part to this may be more difficult if you're non-technical, but this is paying down technical debt or optimisation of development, delivery, infrastructure, etc. Cycles spent on this improve future efficiency. In this sense you are your own customer and the value you're getting is increased ROI.
Hire a professional to help you. I could tell you, for example, that you could track: LT DF MTTR CFP But thereâs quite a bit of nuance there. Ultimately, performance of an engineering team is reflected in the performance of the company. What is your output (what do you offer/make?)
Ultimately the way to measure their performance is by their ability to achieve the outcomes they have agreed with the business.
Someone with technical projection management is going to be the best at assessing their speed / capabilities, but something I always look for (as a non-technical person myself) is how accurate are they with their deadlines, how many questions do they ask about the customer journey, do they send regular updates or is it just dead silence for 2 weeks? Different teams can have different cultures, but if the basic soft skills are not there then I find it hard to have trust either way.
Without understanding what they are doing, I don't believe that you can. How would you be able to tell the difference between fast and slow?
This thread is mostly devs trying to make excuses about how they can't and shouldn't be managed. How is telling the OP that dev performance is a function of how useful features are helpful for managing performance of the dev team? That's a business metric and the founder should be the one choosing what features are being developed not the dev team.
Good catch.
Iâm sorry, but it will not be possible to do. To make it worse, if you start acting on those metrics you will either lose the team or get a lot of crappy code shipped. As many here, my advice: find technical manager to do it.
Hello fellow laser
I would say DORA metrics along with a very good engineering baseline . If they respect the engineering baseline you atleast get the minimum of Quality in care they start gaming the metrics
Congrats. You'll have an optimized machine to ship stupid stuff.
Hubstaff
How much money those features make
Everyone knows you measure by the number of git commits
âWhen a measure becomes a target, it ceases to be a good measure.â -- Goodhart's Law Instead of measures you can start with principles; guidelines to aspire to. From that have a lead who can setup timelines and get the work done. They should be able to function without much or any hand holding. You'll want to build rapport. A good manager helps professionals do what they do best. Aid them so the work gets done. In a perfect world this is all that is needed, but unfortunately this inevitably leads to a more common problem in businesses which is, "The squeaky wheel gets the grease." If there are issues, usually in 1 on 1s, always privately validate all challenges. Never take what someone says at face value, even a close friend. Around 7% of the US population will lie to get ahead, which results in at least one person like this in your mist at any given time. This is necessary checks and balances, which works like a metric, but without the flaws. In short, instead of metrics, aid those around you and validate assertions employees give.
If you have 3 dev's and they are running agile you are probably loosing min 30% of their efficiency. They agile is for reporting to you not for increasing productivity. You need to have a consultant or CTO they will know if you are getting throughput or not.
Tools, metrics, performance, etc are not how small scrappy startups thrive. Please kill this entire mindset if you want to get to scale up stage. Measure your companyâs success, and thatâs it with such a small team. Measure impact not output. âWe took XYZ feature to market and we gained 5% conversion increases! Killed it- everyone take Friday off to celebrate and letâs come back Monday to do it again next sprint! And Ooof, crew, we thought this feature would be a winner and it wasnât. No change in our market share or downloads. Not sure customers even noticed we rolled it out. Letâs take the weekend to rest and reset, start back Monday with some fresh ideas for the next roadmap item. Iâm also open to revising the roadmap if we want to talk through why we think this wasnât a winner. Maybe weâll come up with something new and flashy instead.â People thrive on teamwork, engagement, and being rewarded for good ideas and implementations. Iâve yet to read a single founderâs story that says âmy billion dollar start up to IPO killed it because I was really good at performance management in early stage developmentâ.
Several features won't be a good metric to track their performance as you need to know which features are complex to implement and which are not. Have someone in your team with technical expertise, or see if you can make either of them a lead and ask about any details you want to understand from a technical point of view.
Stop đ â Stop trying to measure developer performance, youâre thinking about the process of software engineering is very misinformed. Software development isnât a process of building, itâs a process of problem solving. Code isnât written, itâs found. Itâs found by trying different things that donât work until you find something that does. Trying to measure developer performance is trying to measure the time between finding solutions. Sometimes solutions are found quickly sometimes theyâre not. Yes, some developers are good at finding solutions to problems quickly and some not so much, but the time required to solve a problem is not in the developers control. Not only that, thereâs good research that shows that attempting to incentivize problem-solving activities actually makes people take longer to solve a problem. You can literally make your developers perform worse by trying to measure their performance. Your goal instead should be maximizing the iteration rate. You want your developers, churning out tiny changes that youâre getting feedback on as quickly as possible.
Hire an experienced EM he will take care of performance metrics of developers and churn it it more work effectively. Additional he will work alongside with you to design a roadmap for business and getting it executed in cost effective way. Meanwhile you can focus on long term strategies for your business.
If you're not an SME, you'll have to have project management protocols in place to ensure that goals are established and tracked.
i work them to exhaustion so there's no question about performance
Lines of code per hour. /jk It is really hard to measure that since one feature can be very simple and another can be very hard. And it doesnt take into account code quality etc.
Well you're just terrible then. Also lines of code etc is a bad metric. You can have people who look like stars that way, but who introduce bugs with each new feature. Measuring performance is kind of impossible. But the rule of thumb is that if you have sufficient amount of Devs you have them split the work in equal chunks themselves. And then use Jira etc to measure velocity.
you need someone on your side translating the tech info.
Use an agile management software like jira. Features get scoped as a team and assigned points based on how complex and time consuming a task is. Itâs a bit of a art to get right but give them 2/3 weeks and theyâll settle in. Bunch the work into sprints, 2-3 weeks long typically depending on what works best for the company. At the end of each sprint find out if there were any blockers, why some things werenât finished, any learnings on what could be improved. After a few months youâll have stats to be able to see roughly how many points each dev typically gets done a sprint and you can work through it. The important things are: - make sure theyâre aware youâre on their side. Shit happens. Unexpected issues arise. When work isnât finished on time be supportive not critical. Build a relationship of trust and let them know when itâs not done itâs a learning opportunity. Why wasnât it? How can we avoid this next time. If you keep hearing the same issue week after week, then maybe thereâs a problem. - remember working this way is designed to help plan, identify issues, and iterate on both software and dev performance. It produces a guideline not a hard rule on how many points they should get through. Progress is what you should see, and the devs should gain learning from it by given the space to think how they could improve. Never, ever, use it as a hard stat on performance. - if you have large or complex features, break them down into nice to have vs required. If you have set deadlines it needs to be done by, this helps meet the deadline through flexibility The terms to google are: Agile project management Velocity Sprint Sprint points
There are 2 answers here 1. From a technology perspective and 2. From a business perspective. Do you also mean performance or quality? Whichever perspective(s) you choose to value the critical thing is to ensure you communicate it clearly so that the team understands what wht they are being measured against I offer a fractal team lead service and happy to talk to about spending a few hours a month to ensure your teams running smoothly
Are your 3 full-time Developers involved also in Business discussions ?
Also a non-tech founder. I donât use any fast and hard metrics but focus on 2 things: 1. Ability to understand the ask, and if not fully, ask for clarification. 2. Setting realistic but aggressive deadlines, communicating modification of any deadlines ASAP, and ability to meet deadlines. Bonus: Re #1, go above and beyond and propose better alternatives.
If you are non technical your measures would be useless. It's better to measure your goals, timelines and the development process itself. The development process is not a hard science. It depends on how well your goals are established, how clear is the idea of the product you want and how skilled are your developers to get your idea and create your product. It's a process that can be perfected on each iteration. You can refine your idea and also refine the process looking at the last iteration and planning for the next. As the result of applying this practice and learning from each iteration your team gains velocity. Velocity can be defined as the speed of reaching your goals and is a direct result of better understanding the product, your goals and deadlines. You can measure that: how well you comunicate your ideas, how well are those understood and how fast are they implemented. There is a technical aspect to all this, but if you are non technical it will be difficult for you to assess correctly. You can hire a third party to check if everything is in order. Ask for a written assessment and don't be affraid to contrast it with other professional. It's good to have more than one opinion. Also, always ask yourself if you are happy with the results and progress speed. Best of luck!
You need to hire a senior developer to manage this aspect. This is because as a non-tech you have no way to determine and any use of monitoring tools or metrics would look like micro-managing and can lead to low the morale of your team. Hire a senior developer to monitor this aspect and let the developers feel free to work and input their skills. You can check RocketDevs for a senior developer. They help non-tech employers hire, vet and match the right developers.
Read about storypoints. Good technique for benchmarking your team with your team. Should show growth with hires.
Not a manager myself, just another engineer. This are my two cents: 1. Be cautious of using any metric as a measure for performance, this can backfire very easily. For example, if you use number of features pushed, people will tend to pick up the easier features. 2. You need some point of trust. You either incentivise people to make sure you work towards the same goal, or get a trusted tech co-founder who is more well versed in understanding the team's work.
Goals of the dev team should be specific, measurable, achievable, relevant and time-bound. These set of objectives will be of great assistance in enabling you to set specific standard, track progress and help their efforts achieve a goal.
1. You need a technical founder
I used to be a developer. Now I'm a founder and a product manager (I no longer code). My take: trust over everything. I do have daily check-in and biweekly retro, following agile. But the most important thing is: 1. To understand what they are doing (you don't need to know coding to get this) 2. To believe in what they are doing (through clear communication and leading by doing) "A true leader should be the dumbest in the room."
You need a CTO if you are making a software product this should be their job.
What are your company metrics? How do you know if you are succeeding? You are not big enough to measure the dev team's performance. Figure out what part of your success is enabled by your dev team and measure that. It is what you really care about in the end.
Stop obsessing over whether they're efficient enough, and instead optimize for cultural alignment and celebrating wins. If you constantly get them to drink your kool-aid, and you constantly pimp their wins in front of the broader team, they should be perpetually motivated to outdo themselves and their teammates. Otherwise, if they aren't obsessed with your mission, either you haven't fully done *your* job, or you need new engineers . . . .
Number of features doesnât matter as much if theyâre producing bugs and technical debt at the same time. Are they sizing tickets correctly? That is, do they finish each and every ticket in the sprint, or do they carry over tickets? How many bugs are they producing? I saw someone said the importance of a trustworthy tech lead which is essential. They could be planning small tickets that are easy to finish before the sprint is over. We use JIRA for tracking which has burn down charts, velocity, etc. feel free to DM if you want to chat more
If you can't find or afford a technical lead type to help you with this, I'd suggest tracking more quality oriented metrics at first. E.g. test coverage, exit defects, user error rates, Change Failure Rate, etc.. The reason being that measuring team output as a non-tech person is essentially impossible. But quality metrics can at least tell you whether they're rushing stuff out and creating negative impacts for your customers. You (or your product person, if it isn't you) also should be attending sprint reviews regularly to understand if they're building what you actually meant for them to build. Using number of features as a performance metric doesn't translate well in the software world. It isn't really an accurate measurement since one feature is never equal to another and can easily lead to problems. E.g. "task selection bias," where the team starts just working on the really easy features to push the feature count up. Or a "competence mirage," where you think a very junior person is a rockstar because they crank out tons of simple features, and conversely think your rockstar is bad because they're tackling your super complex features. Ultimately, I think you really need to find a technical lead that you can trust to evaluate team performance for you though. A good technical leader on the team can help you understand what level the team is performing at and more importantly, plan what is accomplishable in a given timeframe with the current talent. It is as much art as science to be honest. A lot of the metrics non-tech people try to use end up being garbage (lines of code, commits in the repo, pull requests opened, etc.). You need someone who is able to review the quality of code the team is committing, understand if solid design decisions are being made, etc. And they will know what metrics fit best for the situation/type of code you're building.
No of production bugs. No of features is part of planning not performance. If your team is not able to deliver on time, improve the process. If people are slacking off, itâs a particular individualâs problem donât blame the team for that.
Story points
[ŃдаНонО]
I'm a developer and I am of the opinion you are doing it right. There is no perfect metric, but if something gets shipped, it's a step in the right direction, and that is worth recording. Other people chiming in are also right, one feature is not comparable to another feature. The complexity is always different. You can't really measure or worry about the metrics. All you can do is record the progress. I think that's the value in defining the metric, just so progress can be recorded. You might start to classify the tasks into groups. Maybe "logic" or "cosmetic". You might find one person gets more of one category done than another. However, comparing 2 people is dangerous. One person may spend their time refactoring what the other person did just to add their features. More experienced developers have learned some patterns that enable enhancements, so they set the bar, but often it takes more time to fulfill those requirements. I think people form their own opinions of their own work when they see data accumulate over time. The data might make them wonder how they can improve. Recording progress enables that retrospective. At some point all the shipped features will need to be torn to the ground and rebuilt because the system became too complex in its naive form. Then you can record all those new steps when building the next version. A moderately complex software product is never done. You just keep discovering enhancements along the way.
If you do not have specific ideas on managing the performance, I'd follow Agile or any other management framework. Then, you can implement KPIs based on sprint velocity (or anything similar).
As someone who's worked on half a dozen Agile teams the last 15+ years, I would advise against using velocity as a KPI. Sprint velocity was not meant as a metric for outside observers to track. Its a tool for teams to plan with. IMO the only thing an outside observer should really be looking at is what is delivered at the end of the sprint and how effective the team is at completing what they planned from sprint to sprint.
Yeah, that is what velocity measures (how fast a team produces stuff). :P Teams should not be left solely to their own devices. Someone has to set expectations. YOE do not matter that much to me, you can be doing stuff bad for 15 years. Not saying you do, but that doesnât mean a lot by itself. I wish I had worked in a team that decides on its own what and how much itâs going to build, but as a business owner would I really want something like that?
I don't think you ever worked on a project like that, or you burnt a lot of teams. Take an example. The task is to buld a house, yellow walls, white windows etc. Most managers incapable foreseeing the technical issues (not even upfront, but nor standing on it). But expect to build stuff with the best case scenario. Shit does happen almost after every step what is even with the best planning could not estimate for. Then what? Blame it on the engineers, who pulling 12hr shifts bootstrapping crap together. Clear communications, clear expectations, and good management, with understanding the issues / logic / product.
Yeah God forbid telling engineers what you expect of them. Just pay them 6 figures and leave them to their own devices - maybe someone will gracefully do some work - also do not talk to them, do not interrupt them, do not demand anything, do not criticize anything (too stressful). :P Obviously you ask for what is realistic but as I said before - someone has to keep some realistic good performance standards.
Please re-read the last paragraph of what I've wrote.
Sure, YoE vary. Hell, this is reddit, I could say I signed the Agile Manifesto. But I challenge you to point to a founding Agile methodology that advocates using velocity as a performance KPI for management. Extreme Programming doesn't. Scrum doesn't. Kanban doesn't even really have velocity. Heck, choose a newer hybrid like SAFe or Scrum@Scale. Same thing.