Technical Project Management is the process of managing all IT and IT-related projects. Technical project managers are essential in leading a project through initiation, planning, execution, monitoring, controlling and completion. Technical project management involves the communication of both technical and non-technical stakeholders. Project managers transformed the way companies plan and execute projects. They are innovators, strong communicators, data-driven facilitators and problem solvers who lead and inspire others.
Big Tech has different approaches to running tech projects than the other companies. I collected data by researching some well-known publicly traded tech companies. Here is how they usually get things done:
| Company | Do They Have a Central Methodology? | Project Management Methodology usually used when performing Engineering Projects. | Leader of Engineering Projects. |
| Amazon | Scrum | Plan (6-paager) – Build (iterate) – Ship | Tech Lead |
| Apple | Scrum | Plan – Build (repeat) – Ship | Tech Lead |
| Datadog | Team members get to decide | Plan (RFC) – Build – Ship | Tech Engineer or Lead |
| Team members get to choose | Plan – Build (iterate) – Ship | Tech Engineer or Lead | |
| Team members decide | Plan (Design Doc) – Build – Ship | Tech Engineer or Lead | |
| Netflix | Team members select an appropriate methodology | Plan – Build (iterate) – Ship | Tech Engineer or Lead |
| Shopify | Project Management Methodology is usually used when performing Engineering Projects. | No, the team chooses | Tech Engineer or Lead |
Here are some of the characteristics that Big Tech engineers share in how they execute projects
- Engineers drive most projects: Both developed startups and Big Tech usually use their engineers at all levels to lead engineering projects. As an engineer, building the skills to pull this off is essential if you want to grow into senior and staff roles. And as a manager, helping people develop these skills will help you scale as a leader.
- Teams have the will to choose the project management methodology: Many teams go with an RFC-like planning process, repeat on building, and ship all within a few weeks. Other teams utilise more Kanban-like methods, working on the items with the highest priorities.
- There is no committed project manager for team-level projects: Most companies have Technical Program Managers (TPMs) who come for large projects involving multiple teams or run across organisations. These managers also lead engineering programs that don’t qualify as products. When it comes to working, that is not a product or platform but is essential, like migrating from on-premises data centres to a cloud provider. These are the areas where TPMs take ownership.
This is very common for those employed in Big Tech companies. However, if you were to copy the same approach in a more traditional company, it would likely fail. This is because the organisational structure of Big Tech significantly affects how teams can perform and execute their duties.
WHY BIG TECH COMPANIES DON’T USE SCRUM
- Scrum is not agile: Scrum was so strongly associated with agile projects at the beginning that the community failed to see them as separate. Scrum’s scientific approach and enthusiastic promotion swayed many into a false sense of security. Scrum’s emphasis on empirical management is logically sound. When circumstances and priorities change rapidly, conventional planning and execution fail, so you must instead continuously observe and adapt.
- This is precisely what agile software development approaches accomplish, though they arrived at similar practices from a different perspective.
- Hubris and enthusiasm: Many expected Scrum to be a “wrapper” around any kind of new product development method that was well-meaning but ignored a fatal logical flaw: If you wrap a non-agile process, the whole thing is no longer agile. This hubris causes so many Scrum projects to sow the seeds of their failure. The fatal flaw with Scrum is that it sees itself as hollow; it has no opinion on how software “should” be developed. It’s as if Scrum’s association with Agile was seen as circumstantial rather than intrinsic. Agile is described by principles and values, not ceremonies and processes. Agile is governed by a manifesto, not a process manual. These are two very different things, yet even today many people are still confused by the conflation.
- Scrum often leads to scope creep, due to the lack of a definite end date.
- The chances of project failure are high if individuals aren’t very committed or cooperative
- Adopting the Scrum framework in large teams is challenging
- The framework can be successful only with experienced team members
- Daily meetings sometimes frustrate team members
- If any team member quits during the implementation of a project, it can have an extensive negative impact on the project.
- Quality is hard to implement without team members going through a demanding testing process
HOW BIG TECH ORGANISATIONAL STRUCTURES IMPACT PROJECTS
For you to understand how Big Tech manages projects, let’s take a step back and analyse the environment that most of these companies operate in:
Autonomy for software engineers. Developers at established companies are expected to accomplish tasks assigned to them. As for startups like companies, the expectation is to solve the problems that the business is facing now. This is a considerable difference which in turn impacts the day-to-day operations of any engineer.
Problem solvers, not mindless resources. A motivated engineer who solves problems quickly makes more impact than an industrial worker who only performs the tasks he has been told to do. For companies with an industrial worker setup, this method does not favour more heavyweight project management approaches that leave less room for interpretation on purpose.
Exposure to the business and to business metrics. Engineers must interact with the rest of the industry and create relationships with non-engineer staff. On the other side, traditional companies usually make it difficult for developers to interact with the rest of the business.
Engineer-to-engineer comms over triangular communication. What usually happens in traditional companies is that they promote hierarchical communication that slows down the information flow and results in slower decisions causing a delay in the release of products.
Creating a less disappointing developer experience. Companies that align their attention to engineers being able to solve problems as soon as possible create several platform teams, which reduce the developer experience churn.
Higher pay is justified by higher leverage. Companies that leverage engineers will have no trouble paying close to the top of the market or above it.
The calibre of the talent hired. These companies hire highly competent and highly motivated people, thanks to the combination of all the above. They have a large pool to choose from, as they are known for generous compensation packages and substantial career growth opportunities.
What is Scrum?
Scrum is an agile development methodology used to develop software based on repetitive and incremental processes. Scrum is easily adaptable, flexible, fast, and a practical agile framework that assists teams in working together. It encourages team members to learn through experiences, self-organise while solving a problem and reflect on their wins and losses to ensure continuous improvement. It is designed to deliver value to the customer throughout the development of a project.
Importance of the Scrum Methodology
- Scrum Methodology is straightforward and effective. It is something different from an essential collection of connected components. Scrum Methodology is usually misunderstood to be a philosophy. It actualises the logical method of experimentation. Scrum Methodology can also be used in place of a tailored algorithmic approach. Individuals tend to think of Scrum Methodology and agile as something similar because Scrum Methodology is based on consistent improvement, which is a central guideline of agile scrum methodology.
- Scrum Methodology is a framework for accomplishing work, whereas agile is an attitude. The Scrum Methodology framework is experiential; it takes help from continuous learning and changes following fluctuating components. It identifies that individuals do not know everything at the beginning of a project and will develop gradually.
- Scrum Methodology helps organisations infrequently adjust to fluctuating environments and customer necessities. The main priority of the Scrum framework is to improve the short delivery cycles and help organisations learn while working. While Scrum Methodology is organised, it is not very unbending. Its execution can be custom-made to the requirements of any association. There are numerous hypotheses about how precisely Scrum Methodology groups must function to be effective. Nonetheless, after over a time of helping agile groups complete work at Atlassian, we have discovered that good correspondence, straightforwardness, and a commitment to continuous improvement should consistently stay at the focal point of whatever Scrum and agile framework you pick.
Different Roles in Scrum
The three Scrum roles describe the key responsibilities of those who are on the Scrum team. These are not job titles, meaning that any title can perform one of the roles, including yours. In Scrum, the team usually focuses on self-organisation, continuous improvement and creating quality software. The owner of a Scrum project pays attention to defining the features that the product is to have ( what to build, what not and in what order) and overcoming challenges that could interfere with the development team.
The Scrum team incorporates the following roles:
Scrum master: the person behind the team who leads the way and guides them to act in accordance with the rules and processes of the methodology. The Scrum master also controls the reduction of impediments to the project and collaborates with the product owner to improve the return on investment. The scrum master also helps the product owner to define value, the development team creates the value and the scrum team makes it better. The scrum master not only describes a supportive kind of leadership but also describes the team’s daily operations.
Product Owner: this is the representative of the stakeholders and customers who utilise the software. They centre their attention on the business part and are accountable for the return on investment of the project. The product owner not only understands the needs of the customers but also visualises the value that the scrum team will deliver to the customers. They also ensure that there is a balance between the needs of the stakeholders. So, the product owner has to be in charge of these inputs and make work the number one priority. This is an essential responsibility because conflicting priorities minimise the team’s effectiveness and also break the trust between the development team and the business.
The Team: this is usually a group of experts with the required technical knowledge to develop the project, collaboratively performing the tasks that start each sprint. Most people think the development team must consist of only engineers, but that’s not the case. The development team can have all kinds of people including designers, programmers or writers. This team should be self-organised to be able to make decisions that get the work done. The development team, just like the production support team can implement decisions that fix problems at hand and also deliver value. This team also ensure transparency during the daily standup. The daily scrum standup offers transparency to the work and provides a platform through which team members can seek help.
Conclusion
We’ve discussed how companies at various stages run their projects with different methodologies and how Big Tech generally does not instrument a single approach. Nevertheless, big firms have lots of organisational support to make this process work.
How you run teams should generally depend on your context. Relevant factors include your organisational structure, the people you work with, the autonomy and skills of those people, your competition, and whether you’re operating in “wartime” or “peacetime.” The list goes on.
