Get in touch
Follow-Up to Everyday Life at the Agency
My article about timekeeping from July 2 attracted many readers and generated considerable feedback. A few people, first and foremost Adrian Zimmermann from the Swiss Internet agency Snowflake, criticized my hypothesis and explained their points of view. All very valid arguments, in my opinion. The discussion also branched out into dealing with employees, employee motivation and burnout, which I find very exciting, as I've made a few mistakes in this area during my 20-year entrepreneurial career and had to learn from each mistake (sometimes the hard way). For this reason I would like to bring up some ideas regarding each item.
(For better understanding it's recommended to have read the previous article and, especially, the comments)
One objection I heard from several readers was that foregoing keeping time by the hour would likely be possible in projects, but very unlikely in support, as settling on a daily basis is practically unheard of here. This is correct of course. In support, reporting must be done by the hour, there is no way around it.
Another objection voiced by some was that, in smaller agencies, it's par for the course that developers have to work on several projects concurrently. This would make logging time exclusively by the day impossible. I can follow the logic behind the argument, but don't share the conclusion.
My experience, rather, is a different one: It's possible in smaller agencies as well to work sequentially. Projects, after all, aren't smaller than a day (in which case it's probably support). Usually, however, there is a lack of coordination and agreement and most of the time the “confusion” can probably be avoided. Another thing I've also learned is that the vast majority of developers dearly hates to work on several projects at the same time. Maybe exactly because it's always associated with stress brought on by having to constantly ”put out fires.”
In my opinion agency management and the project manager are responsible for creating the necessary time buffers and a relaxed environment so that high-quality work can be delivered.
Adrian cites that timekeeping is legally binding in Switzerland (and in Germany as well). This is an extremely valid criticism; reading my article one could conclude that I let this issue fall under the table. The way in which one keeps track of time can vary, however. One thing is certain though, the legal requirements must be met. As you know, many roads lead to Rome.
When it comes to overtime our industry has a bad reputation. In many instances overtime is simply accepted as normal. It is absurd to use the frantic, pressure-packed project business as an excuse for overtime. The reality is that developers are relatively low in the food chain. In addition, they use only ones and zeros. In other words, there is no room for vagueness or unfinished business. But, it is exactly that which is produced in most cases by consultants, project managers and clients in waterfall projects. Consequently, it is the developer who must close the gaps, not because he really wants to, but because, factually, he has no other choice.
I assert that a large portion of overtime can be blamed directly on this circumstance, thus making it a homemade problem. In addition, and Adrian cites this to a T, communications and expectations are critical. Project teams often find it extremely difficult to meet expectations that are aroused by an agency's sales pitch. This creates additional pressure.
To cite timekeeping as a way to escape the overtime quandary is one possibility. In truth and actuality the responsibility for overtime is thus delegated to the employees. I think, however, that the responsibility lies with the employer. How can he assume this responsibility? With two separate measures:
In my original article I voiced my opinion that time logged in and categorized in hourly increments (or smaller) by the employees themselves creates negative side effects that one tries to handle, among others, through controlling. This doesn't mean, however, that no time whatsoever should be logged. Key assertion was: Employees themselves don't log in time and no small time units are tracked, which could then be used to analyze them together with the employee and use them to judge performance.
Logging in work time then is not the same as agency timekeeping. I have even heard of cases where, for example, the actual project work was tracked as work time. I find this less than optimal. At least as sub-optimal as hearing this story through three people. As an agency looking for good employees, image is almost everything.
I had two interesting discussions about burnout within the context of the article. In one of the discussions my conversation partner made the assertion that employers couldn't prevent burnouts anyway, as there were those with a predisposition (Attention!: Ideology discussion), in the other my interlocutor felt that employers (as those driving work) were always at fault where burnouts are concerned.
The fact is that an above-average number of burnouts can be found in agencies, but these aren't so apparent that people suffering from burnout go to the doctor, let alone take sick leave. Rather, especially those agency employees with burnout who are younger leave the company and do something else. That these employees are stressed out and have a work load that is too heavy cannot be denied – but, they can flee from the overload whereas their older colleagues are dependent on their jobs and (mistakenly) hold the opinion that they must “work” through the situation, no matter what.
My experience with this topic leads me to conclude neither to trust nor believe employees regarding this point: If an employee tells you he can handle the load and deal with the stress, don't believe him. For his sake.
You should rather use your healthy common sense (even if this has a severe impact on the project): I've only met a very few people who can handily survive 90-hour workweeks and high levels of mental strain and I know of no one who can deliver truly high-quality work at this pace. So, simply put, just forget about it.
In the end it all comes back to you: The project, the personal situation of the employee and the overall situation of the agency. Nobody wins.
To prevent that from happening lies within your responsibility; create an environment in which the employees feels comfortable, in which he can address his tasks, an environment that is challenging but not overly so. And create excess capacities to avoid those overtime hours.
Agility & Organisation
Digital health collaborations, use cases and business models - exactly our thing! Our healthcare experts led by Alexander Dallmer were at the E-Health Salon in Berlin. In a presentation on agility, they highlighted lessons learned from other industries that are also highly relevant for the healthcare sector. Agility is unfortunately increasingly degenerating into a buzzword: everyone is supposedly working with it, but very few are actually living it. At AOE, we have been working intensively on the subject since our founding in 1999, both in terms of methodology, organization and corporate culture, and in terms of the conditions necessary for it to function efficiently and in fact be practiced. Using real examples from successful agile projects, our presentation will provide inspiration and inspiration for digitization projects in healthcare. Download Presentation (in German)
Agility & Organisation
In software development projects it is often assumed that quality assurance is taken care of by software testers. But it is a team task!
Agility & Organisation
In the agile context, working with requirements poses major challenges for everyone involved. To avoid errors that arise from ambiguous requirements, there are methods that the team can use to identify and prevent them more quickly.