Hacker News Reader

Comment by bshimmin | Hacker News Reader

This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks spread across two disparate platforms. Then let's say that a manager has an embedded belief from a past (probably non-startup) life that time-tracking by the hour is incredibly important, and they have a preferred tool for this (because, while JIRA has this functionality, it's pretty horrible, and Trello doesn't do it at all), and boom, you've got two different tools for tracking work and a third tool for tracking time.

View on HN

Sorry, an hour a day doing busywork (like entering hours) in a startup is utterly indefensible. I've done a bunch of startups and not only did this never happen, it would not have been tolerated. Even at <<<several large software companies>> I never spent more than about ten minutes a day doing tracking; during heavy bug crunches, maybe an hour doing detailed writeups within bugs for other groups, for communication purposes. In a small team in a company with a short fuse, you can't afford this.

Either you have people who can do the work and coordinate, or all the tracking in the world is not going to help.

(Time tracking by the hour . . . I can't even . . . it's time to get a new manager by firing the current one or finding a better job elsewhere. Totally serious).

> Time tracking by the hour...

How is that a difficult idea to get around? As a contractor I'm expected to keep track of my hours and what I'm working on. Lucky it's just a chrome extension that I click to start and click to stop. Boom, tracking by hour of what I work on.

It's not a difficult idea. Mindfulness of how you are spending your time is quite useful.

What results from it is, however, difficult. Nearly without fail I have seen these tracking systems degenerate into blaming, micro-management and tools for destruction ("Figby is working two hours a day more than you are, what's up?")

So no, not difficult at all. Easy to do. Much, much harder unless you want a culture of fear and overwork in your company, and screw that, I've been there.

Which chrome extension would that be?

Didn't want to name companies, but oh well, toggl and everhour both have chrome extensions.

The indignation seems misplaced. Time tracking seems pretty common in the industry, whether it be mandatory or voluntary. Several places I worked had detailed time tracking, and it was pretty informative/helpful as a tool to manage your own task prioritization. It can be pretty eye-opening to sit down at the end of the week and actually take stock of how much time you spent coding, thinking, in meetings, getting coffee, screwing around, etc.

While crude, I do think raverbashing has a point here. If a 10 person startup already requires their devs to use 3 different reporting tools that startup has a problem. If you can't streamline at a small size like this you won't stay nimble and you won't make it.

>time-tracking by the hour is incredibly important

As someone who does the R&D tax credit for a lot of tech companies, let me tell you that it really, really is. It's worth somewhere around 10% of all your developers' salaries if the company is profitable. As in, if they work 10 hour days, entering data into a time tracking system is a net benefit even if it takes up to an hour a day.

Thanks for that insight. I didn't realize that existed.

I'm wondering how widespread claiming "R&D tax credits" actually is.

To think that most companies could/would seems preposterous (how many are truly doing something worth of the monicker R&D?)

I'm seeing an ecommerce business applying for R&D credit, and that seems absurd, since

> Your company can only claim for R&D tax relief if an R&D project seeks to achieve an advance in overall knowledge or capability in a field of science or technology through the resolution of scientific or technological uncertainty - and not simply an advance in its own state of knowledge or capability.

From the gov.uk article:

https://www.gov.uk/guidance/corporation-tax-research-and-dev...

Well I'm in the US, so I can't speak to the UK's regs with much expertise, except insofar as I know most of the world's R&D credits are based on ours. But in the US, most web dev qualifies, including fairly run of the mill ecommerce site.

Just judging from what you quote here thought, the US rule is less rigorous. Taxpayers must resolve technological uncertainty just as in the UK, but it's a taxpayer centric test. Meaning, that uncertainty can be "simply an advance in its own state of knowledge or capability."

Honestly, I shouldn't say this because it's very much against my own interests, but the US regs are way too loose and permit credits for work that just does not seem to me to be worth subsidizing. But for a normal development company, it's worth tracking hours to gain that subsidy because the IRS primarily challenges us on the validity of the underlying data at this point rather than the qualification of the activities themselves, because a large amount of litigation has settled most of the questions in that area in favor of taxpayers.

Interesting.

I guess that, even if the rules appear to be stricter, in the UK it might de-facto be the same, if HMRC is not contesting many claims.

In Canada it's basically ubiquitous at small to medium companies. SR&ED and IRAP are the big programs.

The standards are pretty loose.

I think that you're not necessarily considering the side effects of (A) working 10 hour days, and (B) spending an hour on paperwork. People will often start to wonder why they work so hard if the company doesn't take their time seriously. This can negatively impact morale, and that has a real, if hidden, cost.

I picked those numbers to make the math easy. No one should or will spend anywhere near an hour entering time into a time tracking system, unless it is horribly designed.

>People will often start to wonder why they work so hard if the company doesn't take their time seriously.

This is a failure of communication. People tend to get frustrated with paperwork when they do not understand its purpose or importance. Those employees who are discouraged by hours tracking paperwork don't realize that the company is being paid by the government to have them fill out that paperwork. Management needs to communicate to employees that there is a very significant impact on the bottom line from them properly filling out that paperwork. That impact increases their wages and the company's ability to survive and thus to provide them continuing, stable employment.

Now, if you think its pointless that the IRS requires them to fill out this paperwork, well that's another discussion, but I can offer you arguments in favor of verifying R&D activities before granting public subsidies for them and in favor of the subsidies themselves.

What kind of tracking do you need and what's the needed resolution?

Can we just have "customer work" or "R&D work" for 8h a day?

The quality of your data dictates the probability of getting an accurate, audit defensible credit calculated. More detail makes it easier to defend. We can work with "R&D work" level of detail, but it is less defensible and it will cost more to have us (an accounting or consulting firm) calculate the credit for you. It also makes it much harder to calculate in-house or using paid self-help software tools.

Particularly because IRS rules require that the wage costs be allocable to a "business component." Business component is a technical term of art specific to the R&D credit, but roughly it corresponds to projects, and more specifically to a (1) new or improved (2) product, process, technique, formula, or invention. It must be one and only one of those, no mixing of new and improved or product and process. So if you have a new product and a corresponding new production process, they must be separated in the reporting of qualified research expenditures, even if you as a taxpayer have classified the two BCs as a single project.

So when you have time tracking, it is best when it allows us to tie specific hours worked to specific projects and tasks. We can then work out from the project list how to combine or split up your projects into business components and map the costs that way. From your activity codes, we can set a very specific and defensible qualified percentage to each employee's time, without having to disrupt your business by surveying your employees (plus the IRS does not respect self-reported, non-contemporaneous survey data much if at all).

As an example, I walked into a software dev client's offices a few weeks ago to sit down with the CFO, comptroller, and their head of development. I walked out with highly detailed project tracking data and spent four hours processing it using our internal software tools, calculating a $2m benefit with a high degree of accuracy. At other firms with lower quality data, it can take hundreds of man hours to achieve the same benefit. So we gave the software client a massive break on our fee (and actually still profited more than we would have with a less prepared client) and everyone walked away happy.

Ah I see. But task tracking != project tracking

And this does not necessarily require everything to be done by the developer

Even if the value that can be obtained by this is higher, it seems to me it's cheaper (in general) to have someone track the effort in this specific way than make developers do it. (Also if your developers are unhappy or busy no tax credit can save you)

An aside, but working 10-hour days is bad. Anything more than 40 hours/week and you're actually reducing overall output.

What if you're working four days a week?

Couldn't do it personally (I doubt I could be productive for that long in a row), but presumably it works for someone. The research on work hours I've seen is mostly about week-work length, but I imagine there's some research on workday-length as well.

I see in one of your sub-replies further down that you are in the US, but even hearing you mention "R&D tax credit" makes my blood boil. At least in Canada, the "Scientific Research and Experimental Development Tax Incentive Program" (aka SR&ED) is a complete scam.

Every development shop in Canada claims credits to recoup a significant portion of employees' salaries. Yet not a single one of my companies has ever performed R&D. The analyst comes in and spends a week getting every employee to lie about their work, enticing them to rephrase how their mundane copy-paste-from-Stackoverflow work somehow qualifies as "R&D". The majority of taxpayers' dollars paid to corporations through the SR&ED tax program is fraudulent.

Yeah, I felt that way too when I started this work. What I've come to realize is that the tax credit is not about conducting science in the strict, academic sense of the word, a la Karl Popper and the received view. The systematic evaluation of hypotheses just doesn't happen that often outside the academy.

Instead, the tax credit is really a political compromise crafted to appeal to both sides of the political spectrum. It's about subsidizing high paying, professional, white collar, technical jobs so that employers don't outsource them. That makes the credit an anti-free market subsidy designed to protect jobs but disguised as a pro-science, pro-innovation policy whose main beneficiaries are large corporations.

And honestly, even in the most "sciencey" firms, most of the R&D going on is dreadfully repetitive and unimpressive. Just as you cut and paste SO code, pharma researchers are just "cutting and pasting" the nth iteration of a chemical formula. They're not unlocking the secrets of the universe, they're just trying random shit until it works. Which, interestingly, is part of how the tax regs define a process of experimentation. Instead of "trying random shit until it works," the regs call that strategy "a systematic trial and error methodology."

Your issue is that you have a mental definition of R&D but the tax codes of the US and Canada do not define R&D in the same way, which to you seems dishonest. But you need to remember that, from a tax perspective, the definition isn't important except insofar as it helps or hinders the underlying policy objectives. Your definition may be closer to a colloquial or idealized definition of R&D, but it's not necessarily the definition which best achieves the policy objectives of the governments in question.

I am at a 13 person startup. We use Confluence, Bitbucket, Google Apps, and we also use Asana (instead of Jira). It is a nightmare... Information is spread out all over these platforms. We can't stick to only Atlassian tools because the CEO thinks they don't allow you to collaborate... We spend a lot of time looking for where information lives and debating where it should live, complete waste of time. In a smaller company this sort of behavior can be catastrophic.

I totally agree, and I think a lot of people will have been in this situation too.

There is, unfortunately, no simple solution other than the very obvious one, which is to use the right things for the right job, and as few of those things as you can. The really crushingly miserable situation is one where the documentation is in Confluence and Google Docs and some random files in Dropbox before they started using the first two and some files that someone shared on the Slack channel and a few things that are just in the CTO's inbox which he was sent by the CEO in PowerPoint and... it's utterly toxic.

This proliferation of excellent tools we have today should be a good thing, but really we are all victims of our own best intentions sometimes (in that horrible chain of misery, even the CEO honestly thinks he's being helpful by emailing a PowerPoint rather than just telling someone over the phone).

>> We use Confluence, Bitbucket... Asana (instead of Jira)

This is the thing with the Atlassian ecosystem. Whether you are pro-Atlassian or anti-Atlassian, there are only two sane options: you either all-in with everything Atlassian, or you are better off with nothing Atlassian. Mixing and matching products when Atlassian is involved is the wrong choice, every time.

The Atlassian suite as a whole is fantastic when the integrations are set up properly. If you dislike Atlassian's licensing or even one of their products, then you should not be using them at all. Don't take on 1-2 of their products, and then replace one of their other core products with an unintegrated competitor. Having a partial Atlassian setup is frustrating as hell to work with.

I dunno, JIRA works reasonably well as a standalone and integrates with everything under the sun. However I definitely see your point in replacing JIRA w/ Asana as it's really gutting the core of the suite.

Highlighting a table in Confluence, right clicking and turning each item into a JIRA ticket makes my life so much easier.

Similar with Bitbucket. Auto issue transitions means the devs don't have to muck around in JIRA as much. As soon as they start working on a branch (with one click in JIRA) the issue automatically transitions to the in progress column on the board, etc etc.

Reveal: I work for Atlassian and I work using Atlassian tools daily. Asana is a great tool but JIRA is built to help address the issues you are seeing. JIRA functions like a center of gravity to organize your work and many other tools (e.g. ~1000 integrations in the Marketplace connect into it.) We are working on some similar integrations for Trello and have shipped a few already.

If the non-technical staff wants to use Trello, that has nothing to do with the technical staff (though it might be painful for the people caught between the two).

In my opinion, detailed time tracking is pointless. I've worked for companies that required it (only small ones required this), and it was just a painful distraction that never had any perceivable benefit. In larger companies, most people just write 8 hours a day for their project, and that's it. No need to make it any more complex than that.

And Jira is not a reporting tool. It helps you keep track of the work you need to do, and roughly estimate how much work that is, but it's not suitable for detailed reporting. And for a small startup, you don't need detailed reporting. If the boss wants to know what people are doing, he just needs to drop by at the standup meeting.

> This kind of attitude is really unhelpful.

No, what's unhelpful is less than 10 people acting out in an noncohesive way

This is weak management and a lack of focus

I wouldn't go and say this is due to stupidity but as a senior professional that would sure be my starting point. That company is in a less than desirable situation, how many other gaffes are there?

This is not the big deal you're all making it out to be.

>but it's not necessarily a case of idiocy

proceeds to describe idiocy

Although it is understandable how someone could make this mistake, mandating redundant reporting is a very bad sign in a startup. It shows the manager does not comprehend the difference between a giant company where such large overheads are necessary, and a tiny startup where nimbleness and intimacy and the very thing that gives the company a chance to succeed.

Reply on news.ycombinator.com