Complexity vs Ambiguity ? (with examples)

Most confusing terms in interviews, FAANG interviews

Whatever said and done, your team dynamics should be very good, to pull off tough projects. How is this related to this ? Read on …

Confusing — Complex and ambiguous !

I have come across these two terms very lately in my life. As you grow more older in your career, these terms appear more number of times in your life.

Why do you need to learn these?

In your career, if you grow more you will come across these terms.

1. You will see them in your daily job lives: “this is a complex project” , “there is a lot of ambiguity”, “the job complexity is high”
2. You will see them in the interviews: “explain the most complex and the ambiguous project you dealt with”

If you learn these now, you can have the framework in mind. You can use that framework readily to answer the questions in your daily job. And also, you can fit in the project stories that are “complex” and “ambiguous” in nature, in to your mind easily.

What do they mean?

Complexity: when a problem is too deep or has too many layers to understand, then it’s complex. Complex problems can be solved by dividing the problems into multiple modules and conquering them.

Ambiguous: when a problem cannot be understood or estimated even after spending more time trying, then it’s ambiguous. Then, how to solve ambiguity? Ambiguous problems can only be solved by implementing, testing and learning them.

Let’s repeat it:

Complexity problems: divide, list and conquer them. you can foresee them when you start your project.

Ambiguity problems: implement, test and learn them. you will not know them when you start your project.

Examples

Once we had to move 270gb data from Hbase-1 to Hbase-2. We worked out and listed all the tasks that needs to be done.

There are about 18 tasks that need to be done. These 18 tasks are to be done across 2 environments — UAT and Production.

What is the Complexity in this example:

1. Sitting and brainstorming with the team and Figuring out what these 18 tasks are in detail. We were trying to come up with the solution by going layer-by-layer and came up with the full blown list of steps that we would need to execute to achieve the solution.
2. mapping the dependencies between these 18 tasks, dependencies such as —which tasks goes to the testing/QA team, infra team and dev teams.
3. how to keep leadership and business clients informed
4. assigning dates, deadlines and buffers to the 18 tasks
5. identifying and requesting for additional testing resources to meet deadlines
6. raise tickets with support team so they’re aware and ready to implement our tasks
7. coming up with a full blown project plan
8. evaluating project risk and coming up with solutions for risk

and so on..

whatever we could foresee , we listed all of them and came up with a project plan — and tried solving the complexity of the problem

(problem statement is to come up with a project plan for this project)

What is the Ambiguity in this example & how to solve it:

there are a lot of moving parts here and as we went through the implementation phase of the project, we encountered these problems/ambiguities .

1. Support team dependency and ambiguity: support team needs to move data from a lower version hbase server to higher version hbase server. but they didnt look at our support ticket until very late.
2. Server Space ambiguity: once the code is executed on the data, duplicate tables will be created. after duplicate tables the server will be out of space, how to solve with the space issue ? we were aware of this problem, when we listed the tasks, but we were not aware of how to solve it.
3. Support team dependency, again: If any data needs to be moved around and solve the space issue — it should be with the support team. The support team is central and they’re occupied all the time with other tasks too
4. Code capability ambiguity: the code was not able to run through giant tables that are about 9gb and 7gb each. The connection pool is not alive for the duration that each of these tables are read and parsed.

The deadline is approaching in 10days

To summarize, these are the ambiguities issues that we ran into:

• space issues on server
• code execution capabilities on data
• support team dependencies

Did we foresee all these issues? some issues we have foreseen, some we did not. To the issues that we have foreseen, we couldn’t imagine or foresee the depth of them.

We solved these ambiguities on the fly: we prioritized and de-prioritized certain tasks, we added our buffer time into the plan, we worked extra hours, we were resolving misunderstandings with the support team, we were using the help of the management where required, we ran our plans through the Sr.Technical architects to see if we’re on the right track or not.

We used every resource at our disposal to make this project a success in a record time.

Extra notes (PM Triangle — Time, cost , scope)

If you’re an experienced PM, you will recognize the classic PM triangle here:

Time, Cost, Scope.

Our time(deadline) and scope (the data movement) were fixed here. So to achieve the specified SCOPE in the specified TIME, we increased the COST by involving more resources and our resources working over time.

Whatever said and done, your team dynamics should be very good, to pull these types of projects off.

What do they not mean

These terminologies are not related to time or space complexity of software development.

Conclusion

Complexity problems: divide, list and conquer them. you can foresee them when you start your project.

Ambiguity problems: implement, test and learn them. you will not know them when you start your project.

And we discussed one of the real-life examples for these topics.

Whatever said and done, your team dynamics should be very good, to pull these types of projects off.

Glad to conduct mock interviews for your upcoming PM interviews: https://www.linkedin.com/in/janakiramvit/