team

Thinking beyond your team

Recently, couple of my teams decided to combine their codebases. It was essentially the same application, written twice over to do the UI for a wizard that went down 2 paths. Their backends do very different things. However, the customer sees a very similar interface.

After having done the migration, there have been some gripes. There is a lot of waiting between time zones. Ownership isn’t clear. Operational setup hasn’t been worked out. Perhaps the biggest issue was that there are two teams for a single codebase. It seems to trip people up when it comes to figuring things out.

So I’ve been asking this one question over and over:

Imagine the other team reported to you (or you were part of the same team). How would you solve this?

Another version of this question:

Imagine you had 15 people in your team across 2 locations. How would you run your scrum processes?

Once you remove the artificial manager/team/pod based barrier, people seem to work it out. This little mental barrier is the root of a lot of problems when collaborating. It is really important for people to identify their tribe. For most people, their tribe is their scrum team. Increasingly, that isn’t good enough to get the best results. At least in my team, we need to expand our view of what our tribe is.

The Bear and shows about teamwork

I love TV shows that show great teamwork. They aren’t always easy to find. Most shows tend to focus on an individual character and their story arc. I’ve been watching The Bear recently and it is one of those.

The Bear is about a restaurant that is in the brink of falling over. Most characters in the show are struggling with some issue in their lives: grappling with mental health issues, grieving lost loved ones, broken marriages, terrible childhoods etc. They bring the internal chaos to work and the there is no room for the individual skills to flourish. People are too busy screaming at each other to think about why they are there or really, to listen to any good ideas. There is strong push to go back to what was before. This feels a lot like many teams I’ve worked with. Maybe less dramatic.

It is interesting to see what gets them out of the rut. Some of it comes down to small changes — devising clever ways to say “sorry” when it is too intense to say it out loud (they roll their fist on the chest), calling every person a “chef” as a sign of respect, making sure the tape is cut properly etc. They have to continue to do non-ideal things to make ends meet. The individuals themselves have to go on their own personal journey in parallel. Some of it is brought on by new perspective from external events or time spent training internships. Overtime, they start to demonstrate to each other it can be done, as a team. Even things like changes in processes stop being taken as power plays or done for adversarial reasons.

Of course, their challenges get harder. Each individual have to step up their game overtime to make it work. However, the most important thing is that they learn to lean on each other. They learn to be candid, but respectful. Each challenge ties them closer together.

And they make great food. Check it out — highly recommended.

Picture of the crew from The Bear TV show

Image credit: TVDB

The other shows I loved for its team work is “Star Trek: The Next Generation”. It probably needs no introduction to many: there are so many things to like about it. I just couldn’t noticing how their team dynamics helped them get out of so many issues. “The West Wing” isn’t bad for teamwork either.

Building trust at work

Today I met a friend who has left his job only months after joining. His team lead had huge trust issues. Everything had to flow through him. He made all the decisions. There was a lot of frustration when people were proactive. I’m surprised he spent that long in this environment at all. However, it got me thinking, how do you work through situations like this?

Despite all the corporate mumbo jumbo people utter, it often comes down to groups of people not trusting newcomers. “You must earn our trust”, is something I’ve been told.

How do you build trust when you are the newbie?

There are some basic things you can do. While I am not very structured in how I interact, upon reflection, most of what I do fall into these areas.

❶ Talk to people. Learn about their lives. Be curious about them. This is by far the biggest step you can take towards building trust in any relationship. Show them pictures of your family. Most people I work with have seen my dog 😆. I figured, do I really need to build trust with someone if they dislike dogs?

❷ Emulate them a little. Learn the lingo. Build some familiarity between you and them. People come together because they have a shared identity or history or something. Learn about that and respect their ways. If they like to name their pull requests a certain way, definitely don’t send them a link on how to do it better.

❸ But of course, be yourself. Again… in small chunks. You are not going to swear like a sailor on your first date, so don’t do the same at work either. I mean, sometimes that will speed things up if you “met your peoples”. Unlikely. What has worked for me is to tell bosses that we are not going to standardise measuring velocity or report on story points. Gotta draw the line somewhere. I draw it at bullshit people metrics.

Over time, when there is enough shared understanding, you can take the next steps towards bigger things.

Companies Grow

As successful products increase in revenue, companies grow. Growth allows a company to improve their products, support more customers and create additional value-add services.

Growing up isn't easy. As a handful of engineers become hundreds, or even thousands, the added weight introduces many issues. These can often lead to the opposite outcomes of what growth should have brought: products falling short of providing value and unhappy customers.

-

Why is that?

As companies grow in size, chaos takes over. There is a need for structure to allow humans to successfully exist with one another. Typically, employees are grouped into "teams" and each team is assigned ownership over part of the product. This allows teams to work alongside others to achieve a larger outcome. Often, metrics are put around these areas to understand if progress is being made.

For example, an e-commerce product would usually be split up based on customer flow (or funnel). There will be teams tackling home and landing pages, search, product pages, payment, receipts and so on. Landing and homepage teams only work to increase SEO rankings and "click through rate" to product listings. Product page teams care about converting customers by sliding them to payment.

To ensure all these groups work well, we add management. Managers keep track of progress and tackle a constant stream of people problems. Sometimes, they are also to blame for these problems.

That's not enough. There has to be a way groups can communicate effectively and coordinate tasks. This layer of protocols is "process". Process mandates its participants work to a standard. When mistakes happen, process tightens up to prevent future occurrences. When efforts are successful, process digs deeper. In all instances, process wins.

These pieces that form the structure -- team layouts, metrics, management layers, process -- overtime leads to an organisation becoming more rigid. Rigidity, unfortunately, takes the innovative drive away from organisations.

-

Safi Bahcall, author of Loonshots, managed to capture this in an equation.

From "Innovation Equation" (HBR): In organisations, the competing forces can be described as “stake in outcome” versus “perks of rank.” When employees feel they have more to gain from the group’s collective output, that’s where they invest their energy. When they feel their greatest rewards come from moving up the corporate ladder, they stop taking chances on risky new ideas whose failure could harm their careers.

M = E x S² x F / G

M = certain size at which human groups shift from embracing radical ideas to quashing them

  • E = equity fraction — the extent to which incentives reflect the outcome of projects as opposed to rank within the organisation
  • F = fitness ratio — relationship between project-skill fit (PSF) and return on politics (ROP): F= PSF/ROP
  • S = management span — average number of direct reports that executives of the company have
  • G = salary growth — average step-up in base salary

He points out that organisations can alter the point in which they become too rigid by employing certain strategies to move the "freezing point".

-

Rigidity has its purpose.

Rigidity brings order to the chaos of having a huge community of people. Society needs laws, companies need rules too. Drawing lines between disciplines, roles and product teams help keep things under control. But, of course, you won't find innovation in excel spreadsheets.

Rigidity helps an organisation be more disciplined and operationally excellent. It protects revenue. That is a key thing to think about: at some point, the organisation will squash attempts to innovate because it could hurt current revenue. Only proven, incremental changes are allowed. Changes have to be discussed, reviewed, checked, approved by many layers of management (that's why most employees just sit in meetings all day without building stuff). It won't even matter if the products are slowly degrading, as long as revenue stays on green.

If an organisation is full of professionals and makers, can't they override these tendencies? It is not quite that simple. In 1960s, Stanley Milgram ran an experiment to understand authority and obedience. He had an authoritative figure order a teacher (participant) to give increasing amount of electric shocks to a learner as they incorrectly answered questions. Two-thirds delivered fatal shocks to learner and no one checked on the suffering humans in the next room or stopped the experiment. Milgram concluded that people can exist in two states: autonomous, where they direct their own actions and, agentic, where they pass off responsibility of consequences to someone else.

Yep, it is hard to break out of a hierarchy of authority. Autonomy doesn't come for free. We have to create the right environment for it to flourish.

It is tough to steer culture back. It can be done.

-

Some companies try to break out by hiring high profile individuals from already successful companies. In the book Inspired, Marty Cargan talks about how many of these new hires have acclimatised to an organisation that's slowed its growth. So they aren't always best equipped to push the organisation towards innovation.

I've only had the opportunity experience the reversal of rigidity in one team thus far. In my previous team, the leadership team actively worked to bring part of the organisation to a more fluid state. While it will take this entire series of posts to explain pieces of it, there are some basic observations I made.

  1. We made a hard turn to focus heavily on outcomes
  2. We dropped all notions of what process works. We taught everyone how we worked and told them to change it.
  3. We worked extremely hard to take power away from leadership and push it down to the grassroots. In fact, we went as far as to break HR management hierarchy from the project work we did.
  4. We came up with a new branding for people who were willing to forego their silo and breakout... we called them Makers.

Wise words from a tall man: playing the long game

Vithun with some words of wisdom: vithun.com/posts/playing-the-long-game

...the longer the game one is in, the more they have got to be able to let something go. And not just let it go, but take it off their mind and start from blank for the next thing coming their way. Reacting to everything is something one does when having a shorter-term mindset.

Leave some balls. Thanks @vithungajendra.

Learnings from "Seeing like a State" by James C Scott

Seeing like a State inspects attempts of states bringing “administrative order of nature and society” that’s led to disastrous outcomes. It is an interesting window into inspecting how large, people based systems work at scale.

High Modernism

The book inspects state's appetite to use “high modernism” to solve issues at scale. "High modernism is a form of modernity, characterised by an unfaltering confidence in science and technology as means to reorder the social and natural world."(1) There is less consideration given to history and practical knowledge held in the grassroots.

States employ these high modernist schemes to simplify, standardise and make things more legible (easier to catalog and understand). Simplification and legibility makes it easy to monitor and control outcomes. For example, cataloging land ownership makes for easier track assets and income, leading to more efficient taxation.

It is incredibly difficult to simplify how a community operates. These societal systems tend to have multiple hidden outcomes; they tend to be complex ecosystems. Forcing change solely around an outcome the state is focused can cause a lot of disruption. They can go against the natural order of things. Often, the result is failure.

Scientific Forestry

In 18th century Prussia, the government tried to determine the revenue potential a plot dedicated for timber yield. This measurement resulted in forests being optimised for lumber, leading them on a path of monoculture (1 type of tree), planted in a strict grid pattern. While it made for maximised yield initially, subsequent generations collapsed. This attempt to simplify nature ignored how complex a forest ecosystem is and its need for that complexity to achieve continued growth.

There are learnings here we can apply to large teams and companies. Teams are complex ecosystems too. They have many hidden outcomes that are not visible to "people at the top". Therefore, we have to be careful when we apply new processes to get specific outcomes or do reorgs to align to new direction. It might look great on a spreadsheet or a diagram (high modernist?) but does it work for the humans who have to adopt it?

Visual Order

One of the key points made in this book is this idea of visual order over system order. States (and its planners) appreciate visual order, which is mistaken for actual order in a system. If something looks visually simpler and easier to understand, it must be better! However, it is often the case that visually appealing macro order leads to micro confusion. Complexity has meaning in a large systems; their order requires more context and knowledge to appreciate. A small example might be how a jet engine works. It may look complex to the untrained eye. However, its complex design has order, which yields the desired outcome.

If you are a leader of a company or someone designing software architecture, it is well worth thinking about this idea of “visual order”. Are teams laid out in a way that is easy to collect reporting reflect how work actually happen? Is the architecture side stepping the complexity of the business, which in turn gives it a competitive advantage? Are we causing confusion on the lower decks?

Le Corbusier’s plan for Paris redesign: grids and perfect right angles. Read more about Le Corbusier and Jane Jacobs here.

Mētis

“Mētis” stands for “practical wisdom” in greek. The author talks through examples of every day innovations that come from having context and experience. Not all problems can be solved at scale because the conditions of these systems are unique.

Excerpt from the book:

While doing fieldwork in a small village in Malaysia, I was constantly struck by the breadth of my neighbours’ skills and their casual knowledge of local ecology. One particular anecdote is representative. Growing in the compound of the house in which I lived was a locally famous mango tree. Relatives and acquaintances would visit when the fruit was ripe in the hope of being given a few fruits and, more important, the chance to save and plant the seeds next to their own house. Shortly before my arrival, however, the tree had become infested with large red ants, which destroyed most of the fruit before it could ripen. It seemed nothing could be done short of bagging each fruit. Several times I noticed the elderly head of household, Mat Isa, bringing dried nipah palm fronds to the base of the mango tree and checking them. When I finally got around to asking what he was up to, he explained it to me, albeit reluctantly, as for him this was pretty humdrum stuff compared to our usual gossip. He knew that small black ants, which had a number of colonies at the rear of the compound, were the enemies of large red ants. He also knew that the thin, lance-like leaves of the nipah palm curled into long, tight tubes when they fell from the tree and died. (In fact, the local people used the tubes to roll their cigarettes.) Such tubes would also, he knew, be ideal places for the queens of the black ant colonies to lay their eggs. Over several weeks he placed dried nipah fronds in strategic places until he had masses of black-ant eggs beginning to hatch. He then placed the egg-infested fronds against the mango tree and observed the ensuing week-long Armageddon. Several neighbors, many of them skeptical, and their children followed the fortunes of the ant war closely. Although smaller by half or more, the black ants finally had the weight of numbers to prevail against the red ants and gain possession of the ground at the base of the mango tree. As the black ants were not interested in the mango leaves or fruits while the fruits were still on the tree, the crop was saved. (2)

Successful workplaces allow employees to innovate and solve problems they observe on the ground. Sounds weird, given that is very much the job of an employee. However, processes and constraints put in place can discourage people from applying ingenuity altogether. Couple of things to do:

  1. The culture of your workplace has to embrace individuals using judgement to sidestep guidelines and rules that doesn’t make sense. When people blindly follow processes, leaders must push for using common sense. This is difficult for leaders as they are more concerned with order and ensuring everyone follows the same set of rules. Best to have less rules :).
  2. We must fight our impulse to solve every problem for people we manage/mentor/advice. It is a leader’s job to anticipate issues and clear the path ahead for teams. However, fixing every issue is unnecessary. Let the professionals on the ground figure it out by encouraging a bottom-up approach. Make it okay for them to be makers (think → do). Instead, work on issues that are more widespread that attack your value system or product direction.

Conclusion

We do have to solve issues at scale. This book doesn't discourage that. However, it is well worth understanding the complexity of systems we change and be careful not to oversimplify. It is difficult to have a full picture of how or why an ecosystem works. There are always second and third order effects for all new ideas introduced. We need to evolve systems in a way that can leverage scale to its advantage while not destroying the hidden goodness that drive outcomes forward.

Seeing like a State was well worth the read, despite its, sometimes, tedious academic writing :). I left out a wealth of good ideas presented in the book. Hope this summary helps you carefully inspect complexity that exist in your workplace.



Notes

Couple of detailed reviews of the book:

Citations

  1. James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed (New Haven, CT: Yale University Press, 1999), p. 4.

  2. James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed (New Haven, CT: Yale University Press, 1999), p. 333.

How to make remote work successful at your workplace?

You have to fully commit.

The whole world is going “remote”. But, it is hard to tell if imany places are finding success in a more distributed working model. It is a tough transition. Much of it is because most workplaces continue to operate with the same way they’ve always had. Somethings need to change.

First, we have to understand a small nuance. It matters whether your company is doing remote work within the same time zone or not. If your company has no location diversity, sign up for Zoom and Slack — you’re good to go.

For most places, remote is a chance to transition to more location diversity and offer flexible working conditions. Remote work can still happen “live” if everyone has a large amount of overlap. However, as more locations or flexible work hours come into play, “asynchronicity” start to be hugely important.

Asynchronous work is very different to how live work happens. Meetings don’t work anymore. Key players find themselves being needed all times of the day, which is super stressful. Answers aren’t always a call away. Traditional means for workshopping and collaboration just doesn’t work!

Leaders, especially, find asynchronous work really tough. It is a new level of trust (or lack of control). Most leaders have built their career on being charismatic talkers. They prod, steer, influence and inspire their people through words… live. Asynchronous work means these things are no longer straight forward to achieve.

Only way to transition to working remote + asynchronously is to get onboard fully and lead the change. If the commitment is lacklustre, what you will find is that remote work has low yield. It will create a class system within the organisation. Priority and decision making will reside in co-located regions (“HQ” vs “remote” workers). It will naturally lead to the conclusion that remote setups don’t work.

To make an asynchronous workplace work, start by identifying what needs to be live. Be very selective. Live activities tend to be operational aspects of maintaining a product and management tasks like 1:1s. Think deeply about how to set these up in a distributed format.

For activities that don't need live interactions, start to formulate some basics around these:

  • How do you communicate effectively in an asynchronously setting? (Read part 2)
  • How do people find each other to collaborate?
  • How do you move fast in a distributed environment when decision makers aren't in the same place?

Hope this gets you thinking 🤔. I'll follow up with my thoughts on the above questions soon.

How to drive your teams to care more about operational excellence?

When an operational outcomes needs to be achieved, we are after a predictable and repeatable process. This means that we can’t approach the execution of these outcomes like a creative task, allowing makers to self-organise. "OpEx" is an area where rigidity helps.

We can approach "Operational Excellence" on 2 fronts:

  1. Leverage an operating model where people must care for operational outcomes
  2. Help your team empathise with pains caused by operational failures

Here are a few ideas that’s worked in my team. (We are a group of ~60 makers.)

For operating model…

  • We assign leads for each area for each area of operational need. Their role is to understand current state, discover growing pains and bring opportunities to attention. Additionally, this creates buy-in and leadership opportunities in the team.
  • Alerts on production is a must. We always have someone on the pager to answer alerts. The paged person also has the ability to disengage anyone from their work to resolve production issues.
    • We keep “2AM playbooks” documented for quick help for anyone getting alerts on how to diagnose common issues and how to reach out to partner teams.
  • We talk about our operational stats once a week in a forum to provide wider visibility to the team and stakeholders. Being open about our failures and state of affairs help everyone get on the same page about investing in operational outcomes.
    • We present metrics for performance, availability, incidents, time to react and resolve, traffic levels, bug counts and SLAs.
  • We classify errors and incidents into buckets. For example, incidents and bugs that have significant $ impact should be critical (if customers can’t purchase from your store, it would be significant).
    • We break our errors to critical, major, standard
    • All logged errors carry a similar classification. Alert on % of categories of errors vs traffic and tune them based on severity.
    • We create SLAs for different categories of issues. When certain areas of application health is low, we set quarterly goals to lower them.
  • Automation helps keep incidents to a minimum. We invest in some of these efforts regularly. Our recent effort has been to put automation on accessibility issues!

On the cultural front, we do a few things too…

  • Most teams talk about how they value quality. For me, the talk has to be met with real investment to show the team “we mean business”. One of our recent changes is to allow directors the ability to vary investment into support by pausing/delaying other efforts. There is no need to get higher approval to invest in keeping the production environment low on errors.
  • We help the team understand business value of errors. Understanding revenue impact can change attitudes towards bugs. We try to also look back on previous quarter to quantify how much value was restored or added with our support and platform work to aid in this space.
  • Everyone makes a big deal out of operational wins. The PR campaigns to showing off wins in support and performance gains outweighs most other things in the team! Encouraging positive behaviour always helps.
  • In recent times, we’ve done a lot of work to make mundane things like support feel a lot more meaningful. Instead of focusing just closing out issues, we give engineers time to investigate root causes and fix system issues. Repeatedly resolving the same issues wears everyone down.

Ultimately, as a leader, we must ensure our team delivers on an operationally excellent environment for the business to thrive. However, one thing I try to watch out for is that we continue to have a team that is not afraid to make mistakes. Having some of the operational pieces set allow more fearless tinkering and innovation.

Attributing value to teams in large organizations

In a large tech company, there are layers and layers of teams that contribute to the success of a product or service offered. Many of these layers tend to only have indirect impact on customers. Teams that have a direct relationship with customers tend to have a lot of power. They bear the burden of delivering perceived value, in exchange for larger investments.

As organisations grow, responsibility of focusing on critical parts of a product gets split up and assigned to various teams. Many of these teams would would be in the middle to lower layers, not having a direction relationship with customers. Their contribution often go unchecked and under-appreciated, as their value isn’t easily captured and accounted for. This starts to erode their understanding of the value they provide. Focus shifts.

Let’s take an example of a team tasked with creating a data analytics library for a website. Collecting analytics on a product is critical to improving it. How important is it compared to contributions from the frontend or services teams? Should the analytics library team focus their efforts on accuracy, library performance, or perhaps, code quality?

As different parts of an organisation starts to think about value very differently, it becomes much harder to innovate and continue to be competitive. The product itself starts to suffer.

The key thing to work on here is “attribution of work” at every layer. If the business is making 100M a year, what percent of that is thanks to the analytics library? The relationship is not direct, and therefore, no obvious. But it is a worthwhile exercise to understand attribution.

Once attribution is understood, we can share growth targets based on that. Teams at each level can start to work towards a common goal. This facilitates collaboration among teams. Decisions like prioritising backlogs and staffing investments starts to become easier.

If the analytics library team understands that they will be at least 5% contributors to the 20M growth target for online sales, they can start to power features towards the growth target itself. They can start to ask questions like, “would innovating a new feature enable teams to evaluate and capture market segments that wasn’t understood before?”

Speaking a common language of value is a hard thing. Understanding exactly how “the janitor helps put a man on the moon” is tough too Doing these hard things can lead to a much more cohesive working environment and innovation.

Do "basics" well

High performing teams are about interperson chemistry that is built on a foundation of the “basics”.

Take sports for example.

Learning to play a sport require you to learn the rules and develop basic skills to play. For soccer, it would be passing, tackling, lobbing and shooting.

When you join a team, there’s drills, runs and short set plays. These are repeated over and over during practice. During a full game, these disconnected pieces mix together to form fluid play. Play together with your team for long enough and magic starts to happen — team members anticipate each others moves to outplay opposition.

Drills, runs and set plays allow you to improve and build on the basic skills: passing, tackling, lobbing and shooting. They improve player fitness and execution during gameplay.

The act of continually working on the basics seem to lead to continued advancement. This is an interesting idea as it would be easy to assume the opposite — to advance further, one has to work on increasingly complex drills. I think it comes down to the fact that most complex things are built up from very basic elements. The more confident and efficient we are with basics, the more opportunity we have to put them together to do complex things.

Therefore, I believe, basics and chemistry form important attributes for any team.

Chemistry can be a complex thing to establish, with time, environment and the individuals themselves. It’s a whole other discussion.

It is easy to establish basics when talking about soccer. What are the basics outside the context of sports? I’ve been trying to figure out what forms the basics for a software engineering team. Is it design patterns or code reviews? Is it practicing readiness to production issues? Or perhaps, it is our ability to document and capture tasks in Trello? These seem to be the essential building blocks in a life of an engineer; solving problems by applying technical concepts into code, that outputs a product to deliver value.

Software is more than just code. At the heart of it, it is empathy and collaboration. It is a bunch of people, observing and acknowledging pain felt by themselves or others, deciding to take upon themselves to resolve that pain. Solutions doesn’t just come from one individual. It is the work of many, fusing their minds, disciplines and skills together to make something truly valuable. For me, the basics for a team are contained in these core values.

Basics has to be more around the idea of problem solving. That is all we do as a team, every day. Even our individual disciplines themselves are various ways dimensions of problem solving — research, design, engineering, analysis etc.

This idea became clearer when I recently read the book “The Culture Code” by Daniel Coyle. The book investigates the elements of highly successful groups. There is a great case study around Danny Meyer’s wildly successful restaurants. In a restaurant, how should one go about preparing staff for both conveying the right feel to customers and be able to react to new and complex issues that come up? It is impossible to cover all the bases and situations.

Danny uses the idea of “heuristics”. He captures the behaviours and his ideology in short, catchy phrases that are used in high frequency. Staff learn to apply these heuristics in every day complex situations, leading to very delightful customer experiences. Applying these heuristics seem to be the basics Danny get his staff to focus on.

These “heuristics” aren’t the same as rules. They are shortcuts for understanding and applying “guiding principles”. They convey a behaviour that is core to situations that arise in a restaurant environment. They allow staff to be thoughtful and creative, while being aligned towards providing customers with a unique, delightful experience.

Heuristics based in problem solving… these can be our basics.

Here are some ideas for heuristics I’ve been collecting with the help of others:

  • Just start.
  • Try and try again.
  • Optimise for fast recovery.
  • Act like it is your company.
  • Coaching over management.
  • Challenge assumptions.
  • Understanding the problem is half the solution.
  • Ask why.

“Just start” — we can apply this heuristic over and over in many occasions, whether people are stuck on a decision or unsure of estimates. It embraces the culture of a “maker” in having a bias for action.

Whenever someone asks me why we allowed a bug to go to production, I like to say: “Making mistakes is part of the job. We’d be better off if our system was optimised for fast recovery instead.”

We do workshops to help everyone understand how to write a good problem statement. Because “understanding the problem is half the solution.”

I believe that practicing these basics of problem solving can lead to powerful teams. They can provide the fundamentals that enable magic to take place.

Keep practising. Keep doing basics well.