Company structure
The Company is barely 10 years old. It believes itself to be a successful start-up, a success story told to show the benefits of online marketing to run a multi-million revenue online retail shop.
Far from the start-up facade, lies a company that has been sold buy its founder for multiple million euros to one of the head pharmaceutical retailers in the country. The company is now owned at up to 70% by this holding company. While internally management still has a certain autonomy to direct the business, hard decisions are guided by the holding company, as we will see later.
Internally there are 5 departments divided into teams by countries and brands (the company sells in 5 to 7 countries and owns two brands). The biggest department is Marketing, they operate online marketing and Performance Marketing in all countries. Then come the Brand and Product teams. Brand defines the direction for each one of the two brands the company owns, it includes creatives that work on the visuals and media creations that either end up on products, the website, or any sort of advertisement. Product is both an innovation department, working on new products (the company does not manufacture any goods, but does brainstorm ideas with its manufacturer to development new recipes), and an operational department, tracking product sells, stocks, etc.
Customer Service is a fairly small team, both in size and wages, considering the amount of work that goes into discussing returns and refunds with dissatisfied customers, or solve any order or customer related problems that were caused by technical issues or business decisions (for example cancelling certain payment methods without letting anyone, neither team nor customers, know in advance).
HR is composed of 3/4 people, not all working full time on the job, and works as a pretty standard HR team. IT, the team that I worked in (and on which I will focus), is composed of 5 developers (3 part-time, 1 leaving, 1 full-time), 1 operations “manager” (mainly handling product data on the websites without much management role), a product owner and a team manager.
Business model
When I joined the company the business model was quite simple. Release new products as often as possible, and advertise them through as many online influencers as can be afforded. Influencers would then offer promo codes to reduce almost by half the price of these largely overpriced products that one can find on the websites.
Quickly after I joined, the company decided for a new strategy. First to be tried on the German market, and then in Italy and progressively in other countries. This new strategy consists in displaying the real sales price on the websites (meaning the price most customer did actually pay when using the promotion codes), changing the brand design and targeting a more specific customer base using a reduced and curated set of influencers instead of the previous strategy consisting roughly in pouring money on influencer marketing and expecting fast return on investment.
This change of strategy was forced by plummeting revenue of 2021. The previous strategy had worked well for a while, but sells ended up plummeting when Corona restrictions were somewhat lifted in Europe and sales froze. Because sales are not purely driven by visibility on an online market already extremely competitive by now, management was pushed to take hard decisions. This included reducing the company headcount by 25%. A decision that was taken in conjunction by the holding company and announced partly by its CEO.
Background of the IT Team
Before mid-year 2020, the IT Team was composed of only one permanent and full-time developer. To that were added various freelancers, without any consideration for the overall infrastructure of the shop and long-term strategies. Why care about the future when you can just throw money when you have an issue and someone will eventually solve it (often in the worst way possible)?
In 2020 the company recruited a head of IT who has been leading recruitment to create a “complete” IT team. The stated aim was to organise a team encompassing all IT needs (from development, to ops and support) following Scrum principles. However, this scope was quickly reconsidered when, as part of the “re-organisation plan” to reduce costs and save money, a new recruit was fired during his trial period, only a couple of weeks before his wife gave birth to their first child. His role that had just barely been defined had to be redistributed across departments and team members. The size of the team I gave earlier corresponds to its structure at the beginning of summer 2021, after this impromptu departure.
Scrum, buzzword and discipline
As a norm of project management in the industry of software development, Scrum is little more than an integration of team self-management into lean management. The implications of it are politically quite important. Engineers and highly qualified and technical sections of the workforce being already quite often aligned with the values and objectives if not of the owning classes at least with some levels of the encadrement class, structuring their work in an apparently autonomous way while keeping it heavily dependent on either market forces, or management requirements is far from a banal fact. It is a restructuration of the organisation of labour that promoters of self-management should definitely reflect on.
Very succinctly, Scrum, as a project management method, structures teams in order to achieve more structurally flexible teams (which includes changing team size or its work in very little amount of time) with the least management input possible. A similar logic applies to the distribution of tasks. Tasks are divided in relatively small sets that can still bring “value” to customers. This implies that, in the best case possible, anyone in the team could work on any task. This, of course is not often the case, but the goal really is to aim for highly responsive teams that are obviously aligned with business interests with close to no management control.
This, of course, is just theory. While there obviously have cases where the Scrum framework is followed and prove that workers self-organisation is not anymore an alternative to capitalistic modes of production but have become, in a somewhat specific form and in specific industries, integrated into them. In a lot of cases Scrum is just a buzzword. Throwing it around to describe teams has at least two purposes. The first one is for managers to claim to have “modern” teams, fitting “progressive” industrial values of openness, flexibility, commitment, etc. This, obviously sells well to managers and more liberal startupy businesses.
A second one I identify is what really worked in my team. It was in fact to maintain work hierarchies and use knowledge disparity and a tight division of labour.
While it is in theory quite contradictory to affirm that a management framework that affirms a somewhat flat, self-organized and flexible team leads to its opposite, my experience in this team proved that any principles could be used to management’s advantage if necessary. And this shouldn’t come as a surprise. In my team, Scrum, was a way to position the IT as a leader of project management in the company as well as a way for management to assert control through knowledge disparities.
Because the team was fairly new and employees kept being pushed in and out of it every month, there was no sense of cohesion, no “team spirit” that could have helped colleagues define their own work environment. Instead, a couple of people in management position were deciding the goals and the limits of the team organisation in an obviously very opaque way that only led to more atomisation of team members. Because recruitees were, for the most part, new to Scrum and similar practices, management could exploit hierarchies of knowledge.
These hierarchies are two folded. They are obviously based on experience and authority, but also on the lack of communication between various teams, companywide. This allows people in management position to pull information and communicate them only when they see fit. Instead of using more traditional top-down decision making, managers in the team can then call-in meetings to take “collective” decisions while being the only ones being able to control the discussion and take informed decisions.
These two forms of hierarchies usually work in conjunction. It isn’t unusual for team meetings — that should define anything from processes, tasks or even technologies — to happen only after some decisions have already been taken ahead of time during some management discussions. Typically, during those team meetings developers will have no idea what are the limits of the discussions, or for some, what the discussion is even about, which leads to either inputs dismissed as being irrelevant for the discussion (or unachievable for more or less valid reasons), or no input at all from team members. In both cases, when management needs to push a decision, they can fairly easily have their ways without leaving much chance to developers, individually and collectively, to decide for themselves.
I specify individually because it has come clear to me that the power of these informal hierarchies really only holds when management have already agreed on specifics and have a fairly specific view what they want and if developers either don’t care so much (or are not helped to care) or don’t have the same expectations on a certain topic. On the contrary, if management only has a faint idea, or a higher-level manager that had a precise idea on what they want cannot participate in the meeting, and developers find themselves having a very similar view on the discussion, it can lead to a fairly abrupt end of discussion (sometime the discussion can be discontinued until further notice) and can later on lead to quite tense discussions with some manager later on during individual discussions. “Why would anyone suggest doing something like that?”
Whether organised formally or informally, Scrum (or whatever it can be called in an informal context) is a tool to reorient team skills towards business interests. While the formal approach requires constant (micro-)discipline to guaranty those engineers and technicians do align with business, the informal approach doesn’t care so much about discipline, but relies on a disorganised team where members can be handled individually, and management can, on the other hand, align their goals.
Trying to organize in E-commerce in Corona times
In this section I want to briefly reflect on a personal failure. I have been unable to build a core of colleagues to collectivize grievances. It wouldn’t be so interesting to delve into the purely individual reasons why I failed, I prefer pointing at external factors that I think should be taken into account for future reference.
- COVID pushed everyone working in digitalized industries remote. While being online can mean that we can exchange lots of information without fear of being overheard in overcrowded offices, it mainly means that colleagues are completely separated from one another, and if your work doesn’t push you to get in touch with other people, you just won’t.
- When I finally reached out to people outside of my team, I found two types of reactions to the working conditions and previous redundancies. Either they claimed to align with management’s positions, or they felt so disillusioned that their only goal was to find a way out of the company. In a booming industry where finding jobs is tendentially easier than in most others, can be a rational strategy.
- Organizing requires meeting locations. Outside the office is obviously better. But when employees are mostly working remotely, in different cities, and sometimes even countries, building social bonds can be quite difficult. When people do come to the office, it was difficult to find a space where HR or management were not present. The office was separated in 2 floors, HR being on the first floor and management on the second. The kitchens were communal, and as such not the best place to talk about critical issues around a tea or coffee.
To push some sort of organizing we should try to circumvent the digitalization of social relations, the lack of motivation or the relative alignment with business imperatives and the strictly shared spaces between management and the rest of the employees as much as possible. Targeting them all at the same time is a hard task. Focusing on building a core group of workers and organizing meet-ups is probably the only way out. Of course, this leaves aside people that work remotely far from the office, but my hope is that workers in this core group would come from a fairly diverse set of teams (those most affected by short deadlines and redundancies) and would gossip with those remote colleagues about what was said during the various meetups. The tricky part being to keep managers, supervisors and HR in the margins. In an environment where “everyone sticks together” by design and by culture, it is not an easy task.
In this sort of environment grievances are often expressed in terms of mistakes management made, and that managers can fix just through more communication. This mindset should also be challenged. The short-term deadlines, large wage disparities between teams and surprise redundancies are not “mismanagement” issues. But those are large issues to tackle in a company where it has already proven hard to bring 5 people together. Using smaller grievances to gain momentum could also reveal difficult. Because teams are so divided, issues are prone to be team specific, creating a cross-team solidarity in such a context requires work.
I clearly do not have a ready-made recipe to address those issues, but they are, I believe, not unique to my workplace and should be discussed if we want to start building up again some sense of class solidarity, and a worker’s opposition inside tech companies.
