I worked at one startup on the AI team, and we were allowed to deploy at will, we iterated constantly, pushed multi times a day, and had a flat hierarchy. We weren't under the political umbrella of the engineering and product groups. It was definitely risky but no major issues ever came from it and we gained the trust of DevOps team and our CTO.
The back end team, different managers, was very hierarchical, had to schedule deploys well in advance and inside certain time windows, and non technical engineering managers would monitor and send summary emails to everyone after each deploy.
Guess what, that back end team sucked. Their timelines for features were embarrassingly long, they watched the clock, their managers loved to booze, they overcomplicated the architecture and never produced anything innovative for the company.
Deploys can signal culture.
I worked at a company that deployed multiple times a day too. There were no automated tests and the QA process was terrible, so most of the deploys were bug fixes.
Deploys can signal culture, but not always in a good way.
Long timelines indicate difficulty interesting features into an already complex codebase. Leaving the office early can indicate that low quality hours had a higher downside risk of introducing problems into a complex situation. Pure speculation here, but I know that architecture can look overcomplicated when it's actually just solving a complicated problem.
They can signal culture maybe. But if you tell your back end team that you think their culture is bad because of not enough deploys they will crank up the number of deploys without fixing any of the deeper issues. All metrics like number of deploys , tickets closed , story points, number of commits are interesting data points but you should never try to optimize for them. Doing so signals lazy management that likes to beat around the bushes.
If you see interesting numbers, you need to figure out the why, before just trying to move the numbers.
This is why it’s hard to boil it down to a few simple metrics.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
I mostly agree. I for one am a big fan of "painless" deploys. To me it means we should be able to deploy pretty much when we want to...
My manager (also a programmer in previous life) once explained to me (privately) is we are neither waterfall nor agile or anything like that. We need to first have a repeatable process before we can even think about those things. (Officially, we were "agile" but that's beyond our pay grade.)
That’s a good goal.
https://www.marxists.org/reference/archive/descartes/1639/me...
You will only find out when you allow it to run.
EDIT: To be fair, my point may not directly address yours. "Value" is still a tough thing to determine.
Personally, I like to try to track how many times functions have been called (if possible), where bottlenecks are and if they make sense (is there some trade-off that necessitated them), and overall module usage.
That gives a more generally clear picture of performance.
- Dev rushes to make merge requests with the cost of thoughtful design and testing.
- Tension around code review turnaround time: how dare you take hours to review my code when I'm far behind in the leader board.
- Deployment has a bug? Awesome, now I'll have 2 deployments.
- Deploy faster and break everything.
Frequent and continuous deployment is good. Making it a metrics is bad.
It's not always easy to quantify value, and sometimes the return on an investment is slow and that can be unattractive. However, that doesn't mean we should try and hide away from figuring out the true value of work in business terms.
In my opinion, we should judge the impact and effectiveness on the base line metrics as the rest of the org. In a for profit company that's measures such as increasing customer spend, increasing conversion rates, reducing churn, reducing operational costs. All of those measures can be directly tied to revenue, costs, and profit. It's the language the business speaks, why would you want to speak a different language to the rest of the business? More than that, why would you want to start measuring performance in a different way to the rest of the business?
Security ends up just being a cost, nobody bothers to actually quantify the risk because nobody really knows. This leads down the path of "the only security that's quantifiable are my legal requirements."
You can't know the productivity gains/losses from a refactor until long after you've done it.
You can't know how productive different ecosystems are until long after your team adopted them. Your only measuring stick is how excited your devs are to use it. What's productive for one team might not be for another.
Nobody quantifies acquiring tech debt so it piles up while people "deliver" and the productivity losses come so gradually from it that teams don't even realize they've slowed down because their velocity says constant it's just that cards gradually get more difficult.
Performance becomes a cost because there's a huge grey area (Jira) between "so slow I consider it down" and "general annoyance that slowly nudges me away from the product." Unless you're planet scale or whatever your sample size isn't big enough to notice these things.
This way of thinking creates feature factories.
I agree 100% that we can do better than being totally disconnected from the business but this ends up being so much worse.
It's not dissimilar for security and code quality, they are just part of doing the job properly. They're also part of continually identifiying future business risk. If you find a vulnerability you can absolutely identify the risk of leaving it there, just like you can identify the level of risk of not thinking about it up front with a feature.
We absolutely can provide estimates to backup why we should tackle some tech debt, it may not be incredibly accurate but if you're unable to estimate any gain from tackling it, is it really a problem? When you see a security issue you've got legal risk and brand reputation risk. Both of those are very tangible, while they're not easy to estimate and there's a lot of room for error I don't know many businesses that would rather take the risk of EU data breach fines vs paying an engineer to spend a few days fixing it.
That doesn't lead to feature factories, it leads to informed decisions. Sometimes the business is going to choose to take on the risk of slower development in an area if they think they're unlikely to revisit it vs doing a refactor. Sometimes they may also take on a risk of security issues if they feel it's outside of their threat model. It's up to us as product/engineering teams to give a clear picture and side our professional advice in a way they can understand. In many cases we may need to push to do a refactor or learn a new technology, but we can't expect to persuade someone while we're speaking a different language to them. Saying that they're only interested in business value and that makes them a "feature factory" doesn't make sense in that regard.
Perhaps the business and leadership really enjoy the taste of risk, and if that's the case then trying to qualify value in some other language still won't help. There we have a larger problem with the practices of the leadership and company as a whole.
I agree that the areas you've mentioned are ones where it's hard to qualify value in terms the business understands, but it doesn't mean the system is broken. It's the language used to describe the goals of the organisation. If you're lucky enough to work in a company which places a goal as team happiness as well then you can also speak in those terms in some cases. However, in the context of the article (Atlassian) I struggle to understand why a team lead would try to abstract away the core business value a team is generating. A team leader should be rushing to quantify it as accurately and clearly as possible to give the team a leg up in the orgs career ladder.
That said, it really did change the team's behaviour. Code reviews became a priority instead of something left to batch up and do later. Whether that was a positive change or not it's hard to imagine an edict from management achieving the same result.
They put a PR reviews scoreboard on the TV that displayed a random metrics dashboard and we immediately started teasing each other about it and did more PR reviews as a consequence.
We liked it because it wasn't seen by anyone else apart from engineers taking a coffee break. Many people ignored it and noone thought less of them. If they told me a part of my bonus would be tied to my PR high score, I would be seriously demotivated.
But all in all - I think that just proves gamification works. What you're using it for is what matters in the end.
- Napoleon
The genderless generic has always been 'they/them', it doesn't require positive action, nor discourse about a hypothetical generic's 'self'-identified pronoun. It has always been third-person, since long before anybody gave a shit.
Perhaps it's wrong, but much like incorrect use of 'I' vs. 'me', one annoys me more because, rightly or wrongly, it reads to me more like deliberate thought/effort went into it; that the author thought they were getting it right.
I should also say I don't object to gendering specific hypothetical/imagined characters in a story-telling sort of way - 'let's say Sally is a software engineering manager, and her direct report Bob ...' - but the generic case should always be third-person, even if interspersed with such story-telling.
But having said that, a leaderboard seems like a handing out poor management tokens.
So now according to the companies public ranking system that is viewable to my bosses and coworkers, I look much worse than everyone else and the nature of the work keeps me in that situation.
Instead of feeling motivated, I'd go into the office every day feeling like crap because I'm doing my job and being told I'm less than my coworkers for it.
But hey, so long as we "move fast and break things" who cares right?
Or you do more complex stuff. No one else will want to do that so you become an expert in certain area and are above the leaderboard in a way. You answer to no one.
Or you get on the committee who decides these items and you push for a multipler for complexity.
Or you hack it.
> It didn't matter [...] what tickets I closed, only whether I fixed that bug that was bothering that one big customer
That's what "closing the ticket" means, right? You close the ticket when the bug is fixed. This is what matters.
The deployments are much more roundabout metric -- maybe you fix 5 bugs with one deployment, or maybe your bugfix is big, so you had to deploy schema change first. Only JIRA tickets (of the right type/severity of course) show the business impact.
