The dynamics of The Never Ending Project
As an organization is growing, it is likely that decision making process is getting worse over time, and the turnover time of decision making is one of the most important factors of successful projects. Tech companies today want to maintain an open and collaborative environment, where everyone’s opinion and input are welcome and taken under consideration. It is fair enough: one person can hardly make perfect decisions, but a team of experts can make close-to-perfect decisions by having a range of different viewpoints considered. Therefore, over the past decades there have been a strong tendency of gravitating towards collaborative and consensus based decisions, as opposed to authoritative decision making. Nowdays we prefer being collaborative, rather than having a team micromanaged.
We want “organic teams”, flat hierarchy, component teams, internal open-source. So let’s see how this midset affects decision making in a corporate environment.
Problem #1 — Shared Responsibility
In an organization where teams are being considered “component teams” (aka. silos), we have the illusion that a particular project is being owned by a development team (eg. task assigned to the team’s backlog), and the team is able to contribute in many components and repositories, as the organization has internal open-source mindset. In reality, no one really owns the entire project, as the project related tasks are distributed amongst many — interdependent — teams’ backlog. The painful reality is: the project can only be considered done, if all dependent team completes their part. Most of the times however, there will be one or more dependent teams where the related tasks are at the bottom of the backlog, with low priority. Sprint by sprint one team can ping the other — asking them to schedule the dependent tasks into the next sprint, but it is unlikely that a team can affect another team’s priorities and schedules.
The situation is a bit better if we have “cross functional teams”, provided that the teams have permission to touch/contribute in all repositories, and the standards are not set to an unrealistic or non-reachable bar. Developers should be able to merge a pull request within one week, otherwise the team is only labeled as “cross functional”, but in reality it is a pain in the ass to cross-contribute, which impacts delivery schedules significantly. Unfortunately I have never seen this version working: it is rare that repositories share the same static code analyzer rules; developers who worked a lot in the target repo would ask the author of the PR to rework the changes completely; code formatting problems are always good reasons for pushing back; and deployment procedures can also be different. Cross functional development efforts often end up with pointless never ending discussions over a PR, as senior developers are trying to convince other senior developers about design choices they have made.
Ford Motor Company’s has a slogan: “One Team. One Plan. One Goal. One Ford.” — This slogan is originated from the 1910s. The idea there is that, although they have multiple departments and teams, their end-goal is the same, and all workers at Ford are focusing towards the same direction: create affordable and good quality cars. Ford succeeded in that, over more than one hundred years, so there is something we can learn from them. One Team, One Plan, and One Goal.
Pro Hints:
— as your organization is growing, try to avoid creating dependencies for the teams (eg. a central team that is providing a shared service for other teams — there will be scalability problems, and other teams would rely on this single point of failure group).
— if your organization is overgrown already, and you already noticed that development processes are blocked because of the share responsility problem, you can still make changes to adopt and speed up. Engineering Managers within the organization can make an effort to make contributions into their repos easier for external teams. A shared global standard of static code analyzer would help a lot. Teams can work on updating Readme.md files, explaining what needs to be done if someone wants to set up a service / frontend locally, or what checklist should be considered if someone outside of the team wants to contribute into the repo. The idea here is to make cross-team conrtibution more lightweight, from technical perspective.
— hire Project Managers. A good PM would create a timeline (with the help of the team), and he/she would also consider costs. It is much easier to influence an external team’s roadmap — eg. asking them to complete a dependent task — if you have cost analysis. A good talking point can be: “If you fail to deliver this feature in the next month, the company would lose $300k in the following 3 months as customers would depart from us”.
Problem #2 — Analysis Paralysis
In a corporate environment, everyone loves to be in the spotlight, everyone looks for “visibility”, as most of the times “visibility” is the only valuable credit when it comes to bonus allocations. In order to be visible, developers and managers must show proactive behaviour towards their micro-environment. This can be done by jumping into projects that are in the “planning phase” (done by any team within the org), joining planning and design conversations, and raising as many concerns as possible. The good thing is that you do not have to make any commitment when you are raising your concern, as you are just chiming in into another team’s project. No work should be done from your side at all. Everyone will see that you are responsive and proactive on the communication channel, you represent yourself in many projects, and you have good ideas and good concerns. The initiator of the project would keep collecting ideas and concerns from you and from similar people — they dont want to be seem as a person who ignores others -, until the point when he/she gives up the project. Usually these projects can not be kicked off and brought into a developer team’s roadmap, and the organization would retry the initiative one year later. No work done from your side, but you gained credits for your bonus. How cool is that!
You might think that analysis paralysis is a good thing, as the organization would not jump into the development phase of a complex project, knowing that there are too many concerning circumstances. The problem is that analysis paralysis has nothing to do with the complexity of the project, it is just human nature. Engineers can overcomplicate and overengineer anything, even simple projects. I have seen a product team in my career that failed to introduce Google SSO login for 3 years. I have also seen another product team struggling with an API endpoint replacement for 6 years (eg. replacing frontend in-memory search to server side search with “autocomplete” feature on the frontend).
Pro Hints:
- hire a Project Manager. He/she will push the project towards into a higher energy level. It is legit for a PM to accept risks, and when he/she does that, people who are paralized by their concerns would chill down, and the project can move forward.
- the stakeholders of the project should agree on an MVP scope. This also means that some ideas should be put to the shelf, which is a potential tension point that could cause conflicts (eg. an Engineering Manager should tell a Vice President that his/her idea is not taken into consideration in the scope of the MVP).
Problem #3 — Stakeholder Overload
It is good if a project has active stakeholders, but it is not so good if the project has too many active stakeholders. Stakeholder overload is a situation in which engineering Directors, Vice Presidents and Senior Managers are gathering together on a workgroup channel (eg. mail thread, chat channel, etc), and everyone brings their hard requirements to the table. From job security perspective — or just considering the next bonus cycle -, it is not preferred to refuse these requests by the development team. No one really has the balls from the product team to confront with a senior leader by saying no. Everyone wants to be seen “Enabler”. So the requirement specification would just start growing endlessly: Replication, Caching, GDPR considerations, Data Sovereignty, Scalability, Fallback, Failover, Circuit Breaker mechanism, Microservice, Micro Frontend, etc, — all requirements are being considered as top priority even for the Minimum Viable Product. When the requirement specification is completed (a large list about irrelevant shit that will never be done), the team would start estimating the required effort to get the project completed, and at this point it usually turns out that it would take many years to deliver the most critical — minimum — features. This mindset is the opposite of “Product-Led Growth”, in which a particular feature should only be tackled once the need arises. It is funny that the company where I work loves highlighting the importance of Product-Led Growth, but in reality, our processes are driven by conflict avoidance.
Pro Hint: Product Owners must keep VPs and Directors (or other high level management folks) away from the project. The project’s workgroup channel must be private.
